‘Autoscaling,’ as the name implies, is the ability to have an application dynamically take advantage of additional compute resources as required and then release those resources when they are not required.
Some examples include:
- A consumer facing web application might “scale out” (i.e. add extra servers) the web tier (and maybe even the local balancing tier) of an application architecture during periods of high traffic and then scale back for quieter periods.
- An analytical application might scale out the servers performing in calculation process – using 20 machines for 1 hour, rather than 1 machine for 20 hours.
This concept of ‘autoscaling’ has become the poster child for cloud adoption because it actively illustrates the power and flexibility offered by cloud infrastructure. At an individual application level, a good part of the business case for cloud rests on only paying for the compute resource actually required.
Without autoscaling, an application deployed in the cloud is no more effective in its utilization of resources than in a traditional, physical, or virtualized environment and will have the same ‘over provisioning’ required to meet peak demand.
With autoscaling, an application can reduce its consumption to match actual demand and increase efficiency dramatically, particularly for an application with a high variance between peak and off-peak demand.
The only public or private cloud platform that provides any application autoscaling function is AWS ….and that is a command line tool.
If you want to autoscale an application, you need a cloud management tool like enStratus that understands the application architecture and can automatically request additional resources and connect them into the target architecture according to your defined scaling rules.
For example, enStratus allows you to scale the different tiers of an application based on basic metrics such as CPU utilization, or on custom business function such as transaction per second or concurrent active users. Additionally, you can define autoscaling across regions or even across clouds; so for example, you could scale your web tier up to 10 instances within your cloud.com private cloud, but then add further web instance, in EC2, while maintaining the database tier within your private cloud.
And enStratus can autoscale within any of the public or private clouds that we support -- Amazon Web Services, AT&T Synaptic Storage, Cloud.com, CloudSigma, EMC Atmos, Eucalyptus, Google Storage, GoGrid, OpenStack, Rackspace, ReliaCloud, ServerExpress, Terremark, VMware and Windows Azure.
We have found autoscaling adds value to a surprising number of application deployments, not just the highly volatile applications that are so often discussed. A little bit of attention can often reduce your cloud bill by a significant sum.
The very thought of starting an article marketing and advertising campaign might seem like a daunting process, yet if you take it 1 step at the same time, this becomes far more workable.
Posted by: Coach Footwear | 03/23/2011 at 11:09 PM
The Auto-Scaling feature provided by EnStratus shows that best way to offer PaaS is to invite customers to choose. This is the philosophy of CloudSigma, but not of AWS which offers their own competing PaaS. The definition of the cloud is incomplete without Auto-scaling, as simply reserving say 30 instances and paying for them, even when as a customer I use less than a half, it is not a cloud in true sense of the word. Clousigma billing cycle of 5 minutes interval, will pick immediately the change in resource usage and the saving are real. Other cloud providers., most of them listed in teh article above, do not have the 5 minutes billing. So the elegant autioscaling feature EnStratuss offers will not result in savings whatsoever, if the billing cycle is say, 1 month
Posted by: miha ahronovitz | 03/03/2011 at 08:55 AM
What happened to "I don't like Auto-Scaling"?
http://broadcast.oreilly.com/2008/12/why-i-dont-like-cloud-auto-scaling.html
Posted by: Shlomo Swidler | 03/02/2011 at 06:44 AM