Developing and Deploying applications for the Cloud

In this blog, I will cover the considerations for developing and deploying applications for the Cloud along with the newer deployment models like Devops and Paas based approach.

Developing applications for the cloud is little similar to developing applications for the web but its not exactly the same. In the cloud, there are considerations like failure handling, traffic unpredictability, resource distribution which does not apply to typical web based application. Can we take any enterprise application and directly put them in the cloud and make it an Cloud based application? This normally does not work unless the enterprise application has the cloud application characteristics which I have described below.

Following are some of the important characteristics of a Cloud based application:


Typical public cloud is built with commodity hardware including compute, networking and storage. It is possible for any of these to fail so the application should be capable of dealing with any of these failures.

To achieve resiliency, the application should be modular, stateless(state should not be maintained in the application, instead the state needs to be maintained in the database) and communication between modules should be asynchronous. Following is the layering model used in a sample cloud application which illustrates the modular and stateless nature of the application.


Figure 1:

In the above figure, the application is split into 3 tiers: load balancing tier, app server tier, caching tier and database tier. Load balance tier is responsible for balancing traffic between different application servers. Each application server is able to do its task independently since the application does not maintain any state and the database maintains all the state. Caching tier is used to speed up the application processing. Database tier is used to interact with the databases. Each of the tiers has redundancy built-in and geographical redundancy can be achieved by placing the servers in different geographic locations. In the above application, the application tier can further be split into web tier and service tier if needed.

Typical database redundancy is achieved using the model below:


There is a master and slave database server and associated databases. Master is used for write operations and multiple slaves are used for database reads. There is another concept of database clustering where more than 1 active database can be used for write but as per what I read, that model is not robust yet.

To achieve the asynchronous nature, following model can be used for communication between modules:


The above figure illustrates different modules using a common messaging system to talk to each other and none of the modules are tightly coupled.


The main advantage of a Cloud is its elastic nature and that necessitates the application to be modular. Some of the application requirements of resiliency also plays a role in Elasticity. Application has to be modular so that it can be made elastic. There are 2 kinds of Elastic models:

  1. Horizontal – In this model, we can start with an instance of low CPU and memory and when the usage is high, we can migrate to an instance with higher CPU and memory.
  2. Vertical – In this model, we can start with 1 instance for the application tier, as the traffic increases, we can keep adding instances.

Dynamic scaling is the term used to refer to dynamic scaling of resources based on the traffic. There are 2 kinds of Dynamic scaling.

  1. Proactive scaling – In this approach, scaling is done based on some knowledge of future traffic pattern. For example, if we know that the traffic will spike during certain time of the day, we can allocate more resources only for that time duration and scale the resources down during other periods.
  2. Reactive scaling – In this approach, scaling up or down is based on the current resource usage exceeding or going down below a particular threshold. By periodically monitoring the resource usage, instances can be scaled horizontally or vertically.

The choice between Proactive and Reactive scaling is based on lot of factors and it depends very much on a particular need.


Here, we are talking about application security and not perimeter security. Perimeter security is normally provided by firewalls and IDS. Since the application is hosted in a shared infrastructure in a Cloud, it is possible that other applications can compromise the security of our application. Some important considerations here are Encryption, Network security and Third party security.

  1. Encryption – When data is sent between different modules, its better to encrypt atleast sensitive data.
  2. Network security – For each application server, its possible to enforce network security based on firewalls. This controls the ingress and egress rules for the application. Simple example is to keep the web tier of the application accessible from outside world but application tier and database tier need not be accessible to the outside world.
  3. Third party security – Applications typically use a lot of third party libraries, its important to make sure that they don’t have any vulnerabilities.


In a Cloud based environment, we are charged based on the usage, so its very important for the application to be efficient from cpu usage and memory to save the cost. Application performance monitoring tools are available that can optimize the performance of applications.

Manual application deployment:

Following is an example of AWS modules that are typically used to deploy a Cloud application using IaaS model.


  • EC2 and S3 provide basic compute and Storage. Our application might be using multiple of these instances.
  • Elastic LB provides load balance service.
  • Cloudwatch monitors all the resources and the results can be tied in with other AWS services.
  • Auto-scaling allows compute instances to scale up and down based on conditions we define. Auto-scaling is enabled by Cloudwatch.
  • SQS is the message queue service.
  • SDB is the simple DB.
  • Cloudfront is the content delivery service provided faster website access and reduced latency.
  • Elastic mapreduce uses Hadoop to distribute and process big data.

Other cloud providers provide similar services with different names to create a Cloud application. The above approach is the manual way to deploy a Cloud application.

Newer application deployment models:

Following are 2 other approaches to deploy a Cloud application that makes deploying applications easier.

  1. PaaS
  2. DevOps

I found a nice definition and comparison here.

  • PaaS — PaaS takes a developer, application-driven approach. A PaaS platform provides generic application containers to run your code. The PaaS platforms deals with all the operational aspects needed to run your code such as deployment, scaling, fail-over, etc. DevOps — DevOps takes a more operations-driven approach.
  • With DevOps, you get tools to automate your operational environment through scripts and recipes, and keep full visability and control over the underlying infrastructure.

Following are some more notes:

  • With PaaS, everything below application looks like a blackbox to the developer and the developer does not need to worry about it. Disadvantages are inflexibility and difficulty to port applications between cloud providers.
  • DevOps approach uses tools like Chef, Puppet to do the automation of resources that the application uses.

Amazon AWS provides all the ways for deploying application including PaaS, DevOps and manual. Following picture gives an good overview of their services comparison.


Some notes:

  • Elastic beanstalk is the AWS equivalent for PaaS. Its not totally PaaS since user still gets some control over resources. This approach gives maximum convenience to the application developer.
  • In the other extreme is the manual process of deploying applications where all application needs are provisioned manually.
  • AWS Opsworks and Cloudformation are somewhere in the middle between the above 2 approaches.


2 thoughts on “Developing and Deploying applications for the Cloud

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s