The Myth of Cloud Bursting

The Myth of Cloud Bursting

Chris Evans Cloud, Data Mobility, Opinion Leave a Comment

We hear a lot of talk these days about hybrid and multi-clouds, in many cases conflating the two into a single expression.  I remember hearing the term cloud-bursting as early as 2010 as a way to make use of the hybrid cloud, but was it ever really a thing and are there any practical ways to implement a multi-cloud strategy?

Definitions

Everybody has their own definitions, however, I think of hybrid cloud as a combination of two clouds (public or private) working together.  In general, this usually means an on-premises location extended to a public cloud provider – but it doesn’t have to be.

Multi-cloud refers to using more than one cloud provider.  This doesn’t have to mean using those platforms together.  For example, businesses could be using Office 365, Salesforce.com and AWS all separately, with no connection between each.

Cloud Bursting

Early assumptions were that public cloud provided the ability to “burst” busy applications at peak or likely to be at peak on the platform they were normally deployed on.  To cope with busy periods, the application is somehow magically “stretched” to the public cloud and spans both, moving back when the peak demand is over.

There are some real challenges with this assumption.

  • Consistency.  For anything other than read-only applications, there needs to be data consistency.  Deploying a highly consistent application across multiple sites and platforms is hard and introduces inevitable latency challenges.  I would agree that some read-only systems can work this way (like static websites), but anything that has to touch a back-end relational (or similar) database will have challenges.
  • Security.  Applications need consistent protection, wherever they are deployed.  Any platforms that integrate with standard authentication tools (LDAP/AD), need that to be extended too.  We can federate a lot more of that security today than we could 5-10 years ago, so this problem may be easier to overcome.
  • Networking.  How will traffic be routed between applications?  How are challenges like zero-trust models to be implemented across clouds?  What levels of resiliency are built into the networking design?  Where will front-end traffic be routed through?  These are not unsurmountable problems but need some thinking.
  • Data Protection.  Running across multiple locations introduces challenges for protecting data.  This might be something as simple as understanding where the most current backup copy resides but could be very much more complex if an application becomes distributed across multiple platforms and locations.
  • Latency.  I mentioned latency already, however, it deserves discussion again. Applications built within the same data centre will rarely need to worry about latency implications.  Take one or two of those out and move them to a different data centre and applications can behave in unexpected ways.  I’ve seen “chatty” applications that have problems over distance, which wasn’t apparent until the application set was stretched to geographically dispersed data centres. 

I’m not suggesting that the above issues are insurmountable.  But, lots of thought needs to be taken as to exactly how a “cloud bursted” application might work.  The cost of implementation may easily exceed any potential benefits. 

Lift & Shift

One solution to the bursting requirement could have been simply to lift and shift an entire application.  Velostrata (acquired by Google) had one solution that effectively acted as a virtual machine cache.  Simply moving an entire application is a potential solution, but not an elegant one.  A straight lift & shift usually means experiencing a period of downtime during the move and still has many of the challenges listed already.

Unstructured

Of course, there are applications where data can be extended to the public cloud.  Avere Systems (acquired by Microsoft) allowed the stretching of unstructured file system data into and out of the cloud.  The software keeps track of updates and keeping both copies in synchronisation.  Unfortunately, caching alone isn’t a solution as some mechanism is needed to ensure the source content and cache are aligned (in case something or someone updates the source copy).

The Architect’s View

So is cloud bursting a myth?  I think for 99% of traditional applications, the idea is a myth.  For some unstructured use cases, then hybrid cloud can work.  Looking at how we move forward with micro-services, I think we have more chance of creating true hybrid cloud as applications are rewritten and new ones developed to use technologies like containers. 


Copyright (c) 2007-2019 Brookend Ltd, no reproduction without permission, in part or whole.  Post #9fa8.