Got an ad running during the World Cup? Good for you; your business must be doing well to afford the gazillion dollars per minute those ads cost. Because your marketing team has made the ad compelling, thousands of people will be hitting your website, and you want to capture as much interest as possible. So during the game, you’ll need to have high-capacity servers available online.
Such brief, one-time events requiring an explosion in capacity are what the public cloud is made for. It’s also what many believe is the perfect use case for cloudbursting, that moment when you reach some capacity threshold and—voilà!—cloud resources kick in and provide extra computing power, almost automatically.
Dream on.
Cloudbursting is a great idea, but provisioning cloud resources to satisfy sudden capacity spikes requires a great deal of planning. More importantly, it almost never occurs automatically in response to an event-based trigger. That doesn’t mean that you can't achieve some of the benefits promised by cloudbursting.
Understand what’s real and what’s not with cloud capacity on demand. Here's a reality check.
Cloudbursting theory vs. reality
If you ask three people what “cloudbursting” means, you’re likely to get five different definitions. There’s little agreement, although the basic premise of cloudbursting is fairly simple. Enterprises want to use cloud capacity on demand to augment a hybrid workload. A sudden increase in demand theoretically “triggers” the burst. Or a complete failover from on-premises to the cloud-based resourced might be triggered by high demand, if the on-premises application is totally gone.
But the theory behind cloudbursting and the actual practice are very different.
A purist would say that cloudbursting requires that an application reside mainly on-premises, and that at some point, when demand begins to peak, you scale everything out to the cloud in one burst. But that's not practical, and I have never seen any organization even attempt it. You can’t easily shift over, on demand, from on-premises to the cloud.
Depending on the application, it takes minutes (or longer) to fire up new virtual machines on, say, AWS. The VM must boot up with a complete operating system, and that takes too much time to support a seamless user experience during a cloudbursting event. But even if latency were not a huge issue, there is a more significant problem: You must maintain duplicate, synchronized versions of your workload on both your on-premises (private cloud) resources and the public cloud.
And you must deal with different APIs for private versus public clouds, as well as configure your software for both environments. This is cumbersome, to say the least, as well as time-consuming and expensive. And if you want to take advantage of cloud services such as load balancers and database services, your end-to-end application architecture will look different on the cloud, making this duplication nearly impossible.
There is a better approach
It’s best to set aside the old idea behind cloudbursting and consider instead what you really need to do to provision additional compute capacity.
Going back to the example of the World Cup ad, if you know in advance that you’ll have a time period of five or six hours of heavy traffic, then you must provision for that need to increase capacity well in advance of the event. But how do you do that if cloudbursting, as generally understood, is not going to help?
You want an extremely well-designed application that can scale up or down in seconds. Okay. That could only work with cloud-native, container-based applications, where you can spin up new resources quickly, in seconds, in the cloud.
Of course, you have to design this hybrid application to have such elasticity from the beginning. One part of it resides on the enterprise’s private side; the other is in the public cloud. This is key—a hybrid application, where it is possible to distribute the application services across on-premises and cloud resources.
When you experience high demand on a web page or web application, you scale out using the public-cloud, user-facing portion of the app; the heavy, asynchronous business logic remains on-premises. It means that hybrid enterprises don’t need to completely migrate everything to the public cloud.
Now imagine this application supporting an online shop. Its front end is in the cloud, with the ability to scale out to accommodate higher usage, as needed. The part of the application that implements browsing and searching should be in the cloud—which is highly scalable and elastic. Once the user orders items, back-end processing can be done on-premises, where that portion of the app can run asynchronously.
More and more front-end applications are moving to the cloud because you can leverage, for example, content delivery networks from a cloud provider. Or you can leverage cloud service technologies—for instance, managed caching services such as Redis and Memcached.
4 use cases for scaling out in the cloud
Let’s say that two or three machines serve your normal workload. And you know from profiling to expect 10 times your normal traffic during the time you’re running that expensive World Cup ad. That means you need to run 10 or 12 machines during that time. It’s worth it to have that reserve capacity in the cloud, and with planning you can launch those additional VMs or containers ahead of time, without any special automation.
A more common example of extending to the cloud for a defined period of time is when moving workloads back and forth between the cloud and on-premises resources. CIOs and IT leads often describe to me their policies for using the public cloud for expanded compute resources. Their development teams, for example, need to expand to the public cloud for additional VMs when tests need to scale up, or when they need to perform heavy number crunching.
But when they have capacity restored on-premises, they typically move back to the enterprise. There are tools that can help with this by copying and migrating the entire workload.
A third use case involves a longer period of time in which you need expanded compute capacity. Perhaps you are running a two- or three-month-long voter registration campaign in a municipality. With the right tools, you can deploy that application to the cloud, for the time you need, then shut it down programmatically. While it's true that this example is not that dynamic, it’s typical of the needs I see.
A fourth use case is an actual cloud migration, which is often a project—and for good reason. A CIO does not want to expand the data center, or even shut down or shrink the data center, because that might disrupt the customer base. Careful planning, including a new architecture designed to take advantage of cloud services, takes time.
Here’s one thing about multi-tier applications that I’ve heard people talk about, but I don’t believe: Consider a typical architecture with the database at the lowest level, with a business logic layer above, and the front end on top of that. People imagine, “I only need the front end on the cloud, and I can keep my business logic and my database server on-premises."
That doesn't really work. If I’m requesting data from a website and that data is not already cached, the request goes down to the database for records, images, or whatever has been requested. And if you have high network latency, the business logic and database server response will be slow. You could break up an application between what happens on-premises and in the cloud, but separating the web server and the database is never a good idea.
At a minimum, you should locate read-only database slaves near the business logic and web front end. But a better approach is to decouple back-end processing, which you can do asynchronously, and without affecting the response time of the frond end, which needs to scale on demand.
Focus on the scale-out, not the old cloudburst concept
The bottom line is that you want a hybrid architecture that can scale like crazy and make best use of existing on-premises services. Scale out when you need to in the cloud. Then, when you can scale back down, the architecture should let you easily reduce cloud capacity you no longer need.
That’s what the cloudbursting idea was about. You can’t do it in seconds, as with careful pre-provisioning, but you can accomplish much of that goal in a reasonable amount of time. Most often, that's good enough, since most organizations don’t need to have a dynamic scaling capability that starts up in seconds.
If you don’t have the time or budget to rewrite your apps to run in containers or to refactor your application architecture, then your first step should be to bring the application into VMs by doing basic scaling and a partial re-architecture. But if you can do a rewrite for container architecture, you'll have more flexibility downstream.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
