How to deploy apps in the cloud.
This post it’s just a little idea about how to move traditional applications to a cloud environment. The steps, ideas or whatever are totally subjective and based in my own experience, and repeat again…IT’S JUST A LITTLE OVERVIEW OF THE BIG PICTURE.
1.- Traditional APP
A traditional app it’s divided in three layers: application (presentation), business and data. This, in a network topology, it’s translated to a something like that (in a very simple way to see it):
- Normally the “app layer” is a web server and the data stored are static (no vary).
- The database configuration is always the same, it doesn’t vary.
- The only data, that vary, are the ones stored in the database.
This type of topologies can be seen as clusters or grids (a draft of a kind of “grid” infrastructure it’s shown below):
In this infrastructures, the frontend takes the petitions and send to the nodes, where they are processed. But when the load vary this kind of infrastructures have some problems:
- Investment: they are very expensive infrastructure, they are built by very expensive hardware (normally).
- Peaks: These infrastructures have limits, what happen when the limit is reached?. And when it’s not reached, the whole infrastructure has to be maintained as if it was being used by a 100%
- Maintenance: when these infrastructures are big, they need to be in the right place, the datacenters or rooms conditioned for that(in the simplest cases), maintain a datacenter cost a lot of money (electricity, security, monitoring,…)
- HW failure: If the hardware fails, how many time takes to replace?, is it critical time?.
We are going to take a exact example…let’s talk about a blog, implemented with WordPress. WordPress is composed by the two layers: APP and DataBase. The configuration of the DataBase will be always the same but the data stored in the DataBase not. The app files will be always the same, the files are not going to vary.
So…how can we deploy this “traditional” app in the cloud?
2.- Why should I move my apps to the cloud?.
This question it’s answered with these points:
- HW: The cloud doesn’t need you to invest on HW, the cloud provide the HW (as much as you want).
- Pay as you go: If you have your app in the cloud, you JUST pay for teh resources that the app consume, if you need a machine just 1hour, you just pay one machine 1 hour, if you need 9999 three days per week, you just pay 9999 machines three days per week.
- No maintenance is needed: In the price that we talked in the last point is included electricity, upgrades,… all the costs derivated from a datacenter. You don need to worry about these things.
- Peak responses: The cloud can support all kind the peaks (if it’s correctly configured). As long as you can provision as much instances as you want, you can support these peaks. The cloud can scale out automatic (just some providers).
Let me show the elasticity of the cloud with an example:
What that’s figure means:
- 1 server on the cloud at 40% of cpu (cpu is choosen as a performance monitor, but we can choose whatever. And the numbers are shown as example).
- When the server reach the 80%, the infrastructure grows automatic, and another server is attached to the load balancer.
- When the performance of this monitor drops to the 20%, the server is shut down, and we don need to pay for it.
That’s the elasticity in cloud, in three simple steps. Personally for me is the key of cloud computing.
There are one more element that is very important to build apps on cloud, it is the storage. When I’m talking about this storage, I’m not talking about a hard drive which can be linked to a machine, I’m talking about some space unlimited where I can store all the files that the app store (not the files of the app, I mean the files that the users of the app can upload, this content is dynamic content), this storage has to provide an API to embed this features inside the code of the app. We are going to call this “dynamic storage” for difference from the other kind of storage that providers offer.
3.- An example of infrastructure in the cloud.
Look at the figure:
Let see the way it should work:
- We have three images created and modified by us with static content, these images are app, ddbb and ddbb_backup. The content of these images never vary.
- At the begining we just have 2 load balancer: 1 load balancer for the app with 1 image of the app, and 1 load balancer with 1 ddbb image and ddbb_backup image. The database backup image is syncronized with the database and depends our backup policy we can make a backup of the database without stopping the database engine.
- Each database machine has a persistent storage attached, these storage is like a hard drive, we use it because the data storaged never can be lost, so if there are some problem in the instance and shut down, the data stored in this persistent storage are saved. We store there the database’s files.
- There are a “dynamic storage” for save the files generated from the app by the users.
- The infrastructure is totally elastic, it start with 1 server for the app and another for the database, and when some of them reach the 80% of cpu usage, the infrastructure provision another server automatically for helping with the load.
This is just a little overview about deploy app in the cloud, and IT’S JUST MY WAY TO DO IT. I’m sure there are better ways.