Why A Cloud Service Broker Helps IT Succeed

Why A Cloud Service Broker Helps IT Succeed

When we look at IT’s ability to deliver services from the cloud, a few tools stood out as associated with high degrees of success, as measured by ability to restore services quickly when trouble arises (and trouble always arises). At the top is the cloud service broker.

Pushbutton Deployment is Great…

The cloud service broker lets IT spin up a workload out of a catalog in any environment it is configured to manage, be it private cloud or public. It expects to have multiple clouds to deploy into. It should be able to either deploy into a specific cloud as specified in the catalog item (e.g. “Create new Docker cluster in Google Cloud Platform”) or decide on its own where, based on criteria programmed in (e.g. “Create new Hadoop environment where spot cost is lowest right now”).  Lastly, a broker solution should have an API so monitoring software can trigger it to re-deploy when there is a problem.

…but Responsive Redeployment is Key

What Nemertes found in its 2019-2020 Cloud and Cybersecurity Research Study is that the companies that are best at restoring service are not those who do it least.  In fact, the organizations that are fastest at restoring services have more than 6 times as many outages annually as everyone else – but about 1/20th as much downtime, because they are a couple orders of magnitude faster restoring services when an outage occurs.

A big part of the difference is cultural, down to process and staffing. These organizations are more likely to have a robust workload placement process for deciding where a workload should be sourced in the first place (e.g. in data center, IaaS, PaaS, SaaS).  They have therefore assessed each workload they manage for its suitability to being deployed in the cloud in the first place, usually including an assessment of architecture (Is it built well for cloud?) and of staff operational readiness (Can we run it well in the cloud?).  They are more likely to have a cloud workload onboarding process that ensures they understand the ownership, stakeholders, operations, security, and data stewardship requirements for the applications in their clouds. And, they are more likely to have a cloud architect helping guide and unify the work of cloud solution architects and cloud security specialists, all of whom contribute to clarity and depth of understanding of the cloud environment.

Cloud Management and Cloud Service Brokers Speed Service Restoration

But, tools use is also a critical factor in bringing down that mean time to restore normal service. The more successful folks are more likely to be using both a cloud management platform to manage on-premises resources and a cloud service broker to deploy workloads across clouds. (And we do mean across. Nearly everyone using IaaS is using more than one provider: Amazon Web Services and Azure, or AWS and Google Cloud Platform, or Azure and Oracle Cloud, etc. We see no indication that organizations won’t continue to add IaaS providers over time.)

That level of automation is the cornerstone of rapid service restoration: replacing a failed or failing instance of the workload with a pristine new instance. The swap of good for bad can be fully automatic (using monitoring tools to trigger API calls to shut down one instance and spin up another) or can be manual – but with the manual part being limited to a mouse click or two. On average, the most successful organizations take only 29 minutes to detect an outage and restore services.

By contrast, the more manual restoration of service by the “everyone else” group can take nearly 2700 minutes, on average.

One More Reason to Automate

Not that we need one!  It’s been clear for the last decade that demands on IT are scaling up beyond the ability of mere mortals to manage–if they don’t lean heavily on automation at many levels. IT needs automation baked into technology directly (e.g. RAID drives, SD-WAN), overlaid with automation platforms (e.g. an iPaaS like Dell Boomi or Informatica, or a runbook automation system), and of course written ad-hoc using a scripting or programming platform. CMPs and CSBs are automation platforms; IT needs to continue to deepen its embrace of them to operate sustainably in the hybrid multicloud age.

Share this post