Key check points for Deployment of Web scale applications on Cloud Server

As a developer, you probably hear a lot about new technologies that promise to increase the speed at which you can develop software, as well as ones that can increase the resiliency of your applications once you have deployed them. Your challenge is to wade through these emerging technologies and determine which ones actually hold promise for the projects that you are currently working on. No doubt, you are aware that cloud computing offers great promise for developers. However, you might not know about the areas where this technology can provide value to you and your projects. You also may not know the best practices to employ when implementing a project in the cloud.

Three possible deployments:
When people begin discussing cloud computing they are generally speaking about one of three possible deployment choices for application code: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). Which one is right for your project depends on your specific needs for the code base that you are working on. Let's examine each one of these cloud choices.

Infrastructure as a Service (IaaS)
IaaS is a platform where an infrastructure is provided for you. With a click of a button, you can spin up virtual machines hosted by a provider with an operating system of your choice. The vendor providing the machine is responsible for the connectivity and initial provisioning of the system, and you are responsible for everything else. The vendor provides a machine and an operating system, but you need to install all of the software packages, application runtimes/servers, and databases that your application requires. Generally, IaaS requires that you have a team of system administrators to manage the system and apply firewall rules, patches, and security errata on a frequent basis.
Pro: You have complete control over every aspect of the system.

Con: You need system administration knowledge or a team of system administrators to maintain the system(s), since you are responsible for their uptime and security.

Platform as a Service (PaaS)
PaaS is a fairly new technology stack that runs on top of IaaS and was created with the developer in mind. With the PaaS platform, everything is provided except the application code, users, and data. Typically, when using a PaaS, the vendor maintains the application server, databases, and all of the necessary operating system components, giving you time to focus on the application code. Since the vendor manages that platform for you, it is often hard to open up ports that are not specifically called for the application server, runtime, or database in use. PaaS also provides features that are specifically meant for applications, including the ability to scale the application tier up based upon the user demand of the application. In most platforms, this happens with little-to-no interaction from the developer.

Pro: PaaS provides a complete environment that is actively managed, letting you focus on your application code.

Con: Developers are often restricted to certain major/minor versions of packages available on the system so that the vendor can manage the platform effectively.

Software as a Service (SaaS)
With the SaaS platform, everything is provided for you except the users and the application data. The vendor provides the application code and the developer has limited access to modify the software in use. This is typically not a choice for deploying custom applications, as the vendor provides the entire software stack. Hosted web email clients and hosted sales automation software are two good examples of how SaaS is used.

Pro: The entire stack is provided by the vendor except the application users and the associated data.

Con: You have limited control over the hosted application and it's often hard to integrate external workflows into the system.

Now we will choose paaS

Application scaling
As mentioned previously, PaaS provides scaling out of the box for most languages and runtimes. However, as a developer you need to be aware of the types of scaling offered and when it makes sense to scale horizontally or vertically.

Vertical scaling
Vertical scaling refers to a type of scaling that has been the default choice for decades. This type of scaling refers to the notion that to handle load, you simply use larger systems. This is one of the reasons why there are servers in place today with a terabyte of RAM and a massive number of CPUs and cores to serve a single Java® application. Typically when using vertical scaling, a single large system is used to handle most or all of the application requests from the users.

Horizontal scaling
With horizontal scaling, the application load and requests are spread over a group of smaller servers that are typically behind a load balancer. As a request from a user is made, the load balancer sends the request to a server and then manages the session state across the cluster of servers. There are often two types of horizontal scaling that can be utilized to ensure the best possible experience for the users of your application, manual and automatic scaling.

Manual scaling
With manual scaling, you specify that you want the application to scale up to handle increased traffic when you know you have an upcoming event that will increase application demand. For example, if you know that you are going to be running a marketing campaign to attract more users to your application, you might want to proactively add additional servers to your cluster. Most PaaS providers allow you to accomplish this task with a simple command.

Automatic scaling
With automatic scaling, you specify conditions where your application will automatically scale without any human interaction. This condition can be based on such things as the number of concurrent HTTP requests your application is receiving, or the amount of CPU usage that your application is using. This enables the developer to automatically add new servers to the load balancer when the demand for the application is high. Automatic scaling provides a truly hands-off approach to scaling while ensuring that demand from the users is met in a timely fashion. Automatic scaling is crucial when you have unplanned usage of your application due to certain circumstances -- such as getting your mobile application featured on an application store for a short period of time where your back end services reside in the cloud.

Application state
Most cloud providers that provide a PaaS want you to start with green field development -- meaning, projects that are not affected by the constraints of prior work. Porting existing or legacy applications to the platform can be a challenge, mainly because the file systems in place are ephemeral in nature and do not allow for saving application state or resources on the file system. This restriction is why you might hear that you need to think about future applications as being stateless. To receive the benefits of an infrastructure that resides in the cloud, you need to employ stateless application design in your projects. To achieve that, take into account the following practices for new applications:

• Allow the application server or container to maintain the session state of the user across the cluster instead of relying on the file system.
• Do not store files or user assets on the physical file system of the server that your code is deployed to. Instead, consider using a cloud-based storage service and delivering assets through the provided REST API for the storage service.
• Use a database for storing assets related to a user if you do not have access to use a cloud storage API.