How would you describe what it is like to develop and deploy applications in the public Cloud?
FAST, BREAKABLE and FLEXIBLE.
These are all three very different ways to describe what it is like to program and deploy applications in the Public Cloud infrastructure. However each adjective was chosen for a very specific reason.
Programming and deploying your applications in the public cloud is extremely fast. You can literally be setup within a day – literally. The signup process for an account with RackSpace or Amazon AWS is simple and straight forward. If you wanted you can signup for a free RightScale account to sit on top of those services to help you administer your virtual servers. Using RightScale you can select one of the premade templates from the community to install, say a LAMP based server, which would install Linux, Apache, MySQL and PHP. Your next task would be to setup your VHosts, run your DataBase schema and install your application code.
Sure I made it sound really easy – but if your application was straight forward – you could literally be up and running within a business day within the public cloud infrastructure. It is extremely FAST.
It is appropriate that I move straight from the main benefit of the cloud FAST to arguably one of the biggest complaints about the cloud BREAKABLE (probably second only to security which is arguably more of a misunderstanding). It is also note worthy that I choose the word Breakable instead of Unreliable. The reason being that the public cloud can be extremely reliable – if you add in redundancy to account for the very breakable characteristics that it is subject to.
By nature – a virtual machine can have so many things go wrong with it. The difference is that in most cases it is faster and easier to re-launch a new virtual host then it is to diagnose and repair the existing host (compared to physical datacenter hardware). For this reason if you are intent on living within the cloud – you need to build in redundancy and disaster recovery – THERE IS NO EXCEPTION.
What this means for data stores (such as MySQL) is that they must replicate to a slave environment, preferably one that can easily be promoted into the master position. What this means for lossy memory storage (such as Memcache) is that your memory storage layer must be exactly that – a lossy memory storage layer designed for faster access then the data store layer. If the data is considered critical and/or permanent then it has to be placed into a data storage layer with replication and regular offsite backups. Your code logic will also need a graceful handling procedure for the time when that data disappears. What this means for your web tier is that these servers need to be designed in a way to shift traffic from one node to another. For example, your load balancer must be able to detect when a web node goes offline and must be able to shift traffic to another available web node.
Despite the public cloud being a Breakable environment. It is one where you can create scripts and routines to react to breaks. This allows you to create a reliable environment despite having servers within the environment that can – and will – break.
This is probably my favorite reason for being in the cloud. Social revolutions such as Facebook and the hundreds of large scale applications that feed off of it would not be possible if it was not for the public cloud infrastructure. Look at NetFlix, one of the major players within the Amazon EC2 cloud environment. Their streaming services would not have been able to grow as fast as they had without the ability to grow their hardware and networking needs. A need which they clearly were unable to perform on their own.
As more and more public clouds come online – services like these will be able to create a very blended mix of public cloud infrastructure delivering services as close as possible to the end point user. This will create faster services and better user experiences.