Can cloud providers and software companies developing Software as a Service (SaaS) applications simplify cloud bursting for their customers?
There are plenty of things a cloud provider can do, but only within the constraints set up by the architecture of the applications themselves. It's ultimately the applications that determine whether cloud bursting can be done easily, not the provider.
It is possible to design an application that would make cloud bursting simple, but the majority of applications today aren't designed to be run in multiple instances, in order to improve performance. Application developers have two options:
Do you need advice?
- They could use a single database for both public cloud and private copies of the application, but that can increase latency and potentially lead to problems with concurrent updates.
- Alternatively, they could have multiple database copies for the application, one for each instance, but that increases costs and causes data synchronization issues.
There's also a common problem of what's called "state management," which requires the developer to ensure that a given user has a relationship with one -- and only one -- application server during a transaction so that the context of user/application messages isn't lost. In my experience, it's always possible to make this kind of cloud bursting work, but it's rarely easy.
Here's a different way to think about it: Pretend you're going to a bank. There's only one teller and a long line, so you expect another teller or two to be added. That's fine, providing that all the tellers have access to all the information -- that they share common access to a database -- and that if any one of them makes a change, it's reflected in what they all see. This is why you can't simply spin up new copies of an app to cloud burst -- common data integration is needed.
Then suppose you start working with one teller, and all of a sudden someone shouts, "Change partners!" and every customer is switched to another teller. You just handed your check to the first one, so how does the second one know to cash something he or she never saw? This is state management.
It's the application that controls both these things. The cloud can take advantage of what the application does, but it can't add cloud bursting or failover to something that wasn't designed to provide it.
App developers, including such software companies as SAP and Oracle that are breaking into SaaS development, can help by eventually building applications for easy hybridization. Standards bodies are already looking at the general topic of how to build elastic apps to support expansion for load-sharing or failover.
Things will get better as more applications designed for hybrid cloud operation, possibly via software companies developing SaaS, emerge. Modern cloud apps are designed to share access to a common, separate database and to preserve update integrity with multiple application copies involved. They use RESTful interfaces, so there's no issue with state management.
This was first published in June 2013