Why and how to design a cloud app

When we are talking about cloud application. One question come in our mind what the difference between web application and cloud application. Cloud application basically web application which used cloud provider company infrastructure for application hosting and these cloud applications resilient to failure. In cloud world hardware can fail any time, so our application design helps us to overcome these situations. If any failure arises in our application, it will automatically restart the process and try again. Cloud provider companies have automated everything with help of software's. Anything failed or crashed it automatically restart, retry and try to fix it. It clouds world very less human interaction required for server maintenance. In below given difference between web application vs cloud application.

Web based application

A company owns and operates some servers and hosts their website on it, we would call that a web-based application.

Cloud based application

If that company moved their web application to Amazon Aws (Azure, Google) owned servers, I would call that same application as a cloud-based application.

Some features provided by a cloud provider, that is not available on regular web servers.

1.       Fast scale out and scale in ability.

2.       Ability to just pay for what you use.

3.       Outsource the maintenance of the server and its security to the cloud provider.

4.       Out of the box monitoring features.

Keep in mind Amazon themselves started out as a web application. Then they grew huge and started letting others use their servers for a fee and hence started getting called the “cloud”.

Why and how to design a cloud app?

The big question is why cloud applications in the first place and why do they require a different way of thinking or mindset. In the past we think for small group of people(enterprise or company) as user and now anyone(public or whole world) can use the application. Now days different type of users, different countries and they use different type of languages and different type of requirements. When we design application now need to consider these points as well. Now you know we need a different type of mindset for distributed cloud application. In the below table it show what we think about application design in past(web application) vs thinking now (cloud application). 

“Distributed cloud applications we assume that failure is always possible. We take that into account very early on when design application architecture”

More information about "Distributed Cloud Apps" by Jeffrey Richter

Client (User)

In the past we used to think of our services for the enterprise internet so with generally very small or enterprise you saw for example one hundred thousand employees and maybe you have some partners that you work with to but we're generally not talking in the millions are tens of millions are hundreds of millions. The people but today we're building services that are access by the public at large and the public it is a worldwide set of people from lots of different countries across the right so that the scale is will be different now.

Demand

We were building the services for small people (small number of users). It was a set of the man (small number of users) but now you're hoping that it will be used by public (large number of people). If the service starts doing well more and more people will adopt the service and if it's doing great that even more people will up the service. It's hard to know in advance when you're designing the service well. That’s why in advance when you're designing the service you have to make sure this application will be used by lot of people.  You would prefer massive growth over time. We design things for scale kind of from the beginning so that it can scale well as the load increases.

Data center

Data center feature come in the past with single tenant that is you would sell up a service and that would be the only customer the hitting that service. If you had another customer, you would stand up another instance of that service, they would be isolated or separate from one another. In Public cloud data centers have multi-tenant where your code is running on the same machine is some other companies code and now you're competing for hardware resources. This situation we have this problem is called the noisy neighbor problem. Where your code might be placed on a node with some the else but that somebody else is getting a lot of network traffic and they're using a lot of memory and that could adverse effect your service because you happen to be end up being placed on the same box. These kinds of things need to be thought about and consider and when you're designing your service now.

Operations

Past we would use people for operations and of course we must pay their salaries and you have to deal with things like the operating system upgrading the hardware operating the networking infrastructure and so on. Now days and age, we're trying to get more automation point of view where these things are just happening automatically. Which makes it much cheaper around the service. That's a lot of the benefit that people see going with a public cloud provider is that they don't have to worry about the network infrastructure they don't have to worry about the load balancers they don't have to worry about the hardware device, power supply failure and network router fails.

We can also automate our code deployment process (DevOps). We take the code that developers had written and going to check that in and then we automatically build that code, run tests and deploy code into the cluster ideally without any human intervention. It just can happen on a regular basis several times a day and want to service running in the data centers all time. This allows you to be very agile and responses to customers whom like be reporting bugs or might be desiring new feature. It's just a great way to get into this rolling process of that whole thing and we can do it very inexpensively without any human involvement.

Scale

Scale is very closely related to the demand feature. As we know few reliable pcs that is your company have a lot of ram in them and very fast hard disks which makes these pcs (servers) expensive. These pcs(servers) used in past for application scale. Scaling is very expensive in past and it takes time to prepare expensive machines.

Now days when we are using cloud computing. This is new mindset we are trying to get lots of cheaper inexpensive pcs (servers). We just assume that failure is going to happen anytime. Distributed cloud applications we assume that failure is always possible. Scaling we can do easily everything done automatically.

Failure

In past we used very expensive machines for application deployment there chances very less of failure. Now days we are using cheap machines (in cloud) they may be failed any time. When we design new application, it will be resilient to failure.  

Machine loss

As we have talked above in past application generally used expensive server. It is catastrophic (extremely unfortunate) if there any server failed. Now days cloud application used cloud provider cheap server, so it is very likely to loss machines.

Resilient to failure

We must do things differently when building cost-effective, failure- resilient solutions for cloud application. These 2 points need to consider when design application.  In past when exception arise application just log those with help of logger library and skip that step. Now days exceptions can arise anytime so our application can handle these exception and automatically restart the process and try again.

Exceptions

In past when any exceptions arise it catch the exception and log it somewhere (txt file and database) with help of logger library but application keep running and skip that step. Now days in cloud application as you know hardware failure is very likely it can be crash any time so if there any exception arise. It will restart the application and try to execute the process again.         

Communication

As You know in past application communicate in sequence and application flow in sequential manner. If communication failed due to some reason it will stuck. User has to retry again. In Cloud application failure can arise any time when if anything failed. It will try again automatically. Application flow in not sequential it helps it to retry again.

Why cloud application failures may happen?

Some reasons why a service instance may fail (stop) in cloud infrastructure

1.       Developer: Unhandled exception in service code

2.       DevOps: Scaling the number of service instances down if less traffic in service.When we making service instance down (offline)  may be that instance servicing client request due to this it will failure can happen.  

3.       DevOps: Updating service code to a new version in cluster of service instances. This is like above point 2 may be old service code servicing client request and same time we updating new version due to this failure can happen. 

4.       Orchestrator: Moving service code from one machine to another. like above point 2 and 3 this can failed when moving code from one machine to other.

5.       Force majeure: Hardware failure (power supply, overheating, hard disk, network controller, router, bad network cable etc.)

6.       Force majeure: Data center outages (natural disasters, attacks)

Since failure is inevitable & unavoidable, embrace it

1.       Architect assuming failures will happen

2.       Operate services using infrastructure that avoids single points of failure

·         Run multiple instances of services, replicate data to avoid single points of failure.

Keep in mind when you design cloud application it needs to be “Resilient to failure”. Failure can happen any time.

Keep share keep learning