Cloud bursting is an application deployment model in which an application that normally runs in a private cloud or data center “bursts” into a public cloud when the application needs additional resource (i.e. computing power) and use Cloud Computing for the additional resource requirement.
Think of a scenario in which an e-commerce application is running in a data center and suddenly a few items became popular and a lot of users start checking them. Suddenly traffic starts building on the website and response starts becoming slower because of the load on servers. The only solution now is to scale the server infrastructure by provisioning more servers to handle the traffic. But provisioning new server on-the-fly is not an option in data center. Public clouds come as savor. The additional server can be launched in a public cloud like AWS and additional traffic can be routed to that server.
So, the Cloud bursting relates to hybrid clouds. The advantage of such a hybrid cloud deployment is that the resources become available on-the-fly and an organization only pays for extra compute resources when they are needed.
Cloud Bursting Architectural Model
The cloud bursting architecture establishes a form of dynamic scaling that scales or “bursts out” on-premise IT resources into a cloud whenever predefined capacity thresholds have been reached. The corresponding cloud-based IT resources are redundantly pre-deployed but remain inactive until cloud bursting occurs. After they are no longer required, the cloud-based IT resources are released and the architecture “bursts in” back to the on-premise environment.
The foundation of this architectural model is based on the automated scaling listener and resource replication mechanisms. The automated scaling listener first determines when to trigger resource replication for deploying the server in cloud. Next, when the additional resources i.e. servers are ready in cloud, it redirects requests to those servers along with the on-premises servers.
In this solution, we shall see how we can burst into AWS environment with minimal cost. A10 Lightning ADS will work as scaling listener and AWS Lambda functions will work as replication mechanism for this solution. AWS API Gateway will be required to invoke lambda functions from ADS.
In steady state, A10 Lightning ADS will front-end the application traffic and will monitor for server latency. An application server instance is expected in the AWS account in stopped state so that it can be started by the lambda function as needed.
Following presentation was done in AWS Bangalore meetup: