Applications have to be build stateless to scale and shrink on cloud

Context of the presentation
Cloud is successful with Pay-per-use model in software, because it invented elasticity:

* If 2 companies in opposite time zones need 10 machines during day time and 1 machines during night time, a cloud provider can serve both the companies with 11 machines - 10 for one and 1 for another company at any given point in time.
* If each had run them in their enterprise, they would have bought 10 machines each (20 in total). 9 machines would have been idle during night time.
* Time zone is not the only reason for sharing idle capacity:

o Computing need could also be seasonal. Some business might need very high computing capacity during christmas, while some others might need it during financial year closure and so on.
o Some may not be able to predict when they need that capacity. e.g. slashdot effect. Either way, by sharing, you let others use your idle capacity. This enables Pay-per-use.
* You can extend the same concept to the cost of the platforms - application servers, database and applications.


The most important point about elasticity is that - 9 machines that are serving a company during the day time will shrink to 1 machine in the night automatically based on load. The 8 machines that are released will then start serving the other company along with 1 other machine. This property of cloud that allows these 2 tenants (or more) to share processing capacity is called shared-process multitenancy.


So why not stateful architecture?
Lets just say 1000 users are distributed across these 10 machines during day time i.e. 100 users in each machine. In a stateful architecture, the 100 users will be served only the server that created the session for the users during login. This happens because the session state is stored in the memory of that server. This is done by the http load balancer and is called session stickiness.
When night falls, lets assume that 900 users are logging out of the system, while the rest of the users (i.e. 100 users) are still logged in. Ideally, 1 machine should be good enough to serve all of them. However, these users could be distributed across all the 10 servers with 10 users each. So shrinking back to 1 machine is not possible i.e. it breaks elasticity.
One way to solving this problem is to replicate session state across all the 10 servers. This way the user can be served by any server in the 10. But each server will occupy 10x times memory than having just it's users session state. This reduces the usefulness of the servers as more servers are added to the cluster when more users are added to the system. So this doesnt work for exploding number of tenants, who sign-up for your application in shared-process multitenancy.


How does this change with statelessness?
With stateless application, you can execute user request anywhere - session stickness is no longer relevant. So when the number of users reduce from 1000 to 100. You can immediately release 9 servers to the other company and serve the 100 users from 1 server.
It sounds simple. But in practice it is not. All applications needs state. So if the application server is not going to handle it, someone else has to do that. And that will be the database. Current databases has enough scaling problems already. So adding state management to it woes is a non-starter and hence NoSQL "distributed" datastores.


You would see this as the common architectural pattern across PaaS vendors:

* Google App Engine - stateless requests + Big Table
* Microsoft Azure - web role + Azure storage/SQL
* Of course, my company - OrangeScape that runs on top of GAE/Amazon EC2.
* and i would expect the same from VMforce - Spring stateless session beans + Force.com DB

So build for Cloud! Stateful apps with SQL databases are for oldies listening to "enterprise" tunes. (Sorry! couldnt resist it.)

Source - http://manidoraisamy.blogspot.com/2010/07/why-does-elastic-nature-of-cloud-impose.html

Amazon Launches PAAS as Beanstalk!

Service Highlights

Easy to begin – Elastic Beanstalk is a quick and simple way to deploy your application to AWS. Use the AWS Management Console or an integrated development environment (IDE) such as Eclipse to upload your application, and Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. Within minutes, your application will be ready to use without any infrastructure or resource configuration work on your part.

Impossible to outgrow – Elastic Beanstalk automatically scales your application up and down based on default Auto Scaling settings. You can easily adjust Auto Scaling settings based on your specific application's needs. For example, you can use CPU utilization to trigger Auto Scaling actions. With Elastic Beanstalk, your application can handle peaks in workload or traffic while minimizing your costs.

Complete control – Elastic Beanstalk lets you "open the hood" and retain full control over the AWS resources powering your application. If you decide you want to take over some (or all) of the elements of your infrastructure, you can do so seamlessly by using Elastic Beanstalk's management capabilities. For example, you can browse log files, monitor application health, adjust auto-scaling rules, setup email notifications, and even pass environment variables through the Elastic Beanstalk console.

Flexible – You have the freedom to select the Amazon EC2 instance type that is optimal for your application based on CPU and memory requirements, and can choose from several available database options. For example, you can specify a deployment consisting of high-memory instances if your web application has a large memory footprint.

Reliable – Elastic Beanstalk runs within Amazon's proven network infrastructure and datacenters, and provides an environment where developers can run applications requiring high durability and availability.
↑ Top
Pricing

There is no additional charge for Elastic Beanstalk – you only pay for the underlying AWS resources (e.g. Amazon EC2, Amazon S3) that your application consumes.

New AWS customers who are eligible for the AWS free usage tier can deploy an application in Elastic Beanstalk for free, as the default settings for Elastic Beanstalk allow a low traffic application to run within the free tier without incurring charges. If these applications require more resources than the default environment provides, customers will be charged the normal AWS rates for the incremental resources the application consumes.

The costs of running a web site using Elastic Beanstalk can vary based on several factors such as the number of EC2 instances needed to handle your web site traffic, the bandwidth consumed by your application, and which database or storage options your application uses. The principal costs for a web application will typically be for the EC2 instance(s) and for the Elastic Load Balancing that balances traffic between the instances running your application.

The table below is an example which shows the monthly costs of running a low traffic web site using the Elastic Beanstalk default settings, both with and without the AWS free tier:
Service and Resource Unit Cost Breakout Cost
Amazon EC2 t1.micro instance 1 $0.02/hr * 24 hours * 30 days $14.40
Elastic Load Balancer 1 $0.025/hr * 24 hours * 30 days $18.00
Elastic Load Balancer Data Processing 15GB $0.008/GB * 15GB $ 0.12
Elastic Block Store volume 8GB $0.10/GB * 8GB $ 0.80
S3 Storage for WAR File and Access 1GB $0.14/1GB + $0.01 for<1k PUTs, <10k GETs $ 0.15
Bandwidth In and Out 15GB 15 GB in * $0.10, 15 GB out * $0.15 $ 3.75
Total Monthly Cost without Free Tier $37.22
Total Monthly Cost with Free Tier $0

Source - http://aws.amazon.com/elasticbeanstalk/