The Cloud seems to be the buzz word of the modern generation, such as HTML5, Ruby on Rails and AJAX were before it. Everyone is scrambling to use it, some bash out an idea or two after a few days tinkering but its only a few that actually understand the technologies.
So what does it take to develop a cloud solution? – The best analogy I would use is that of building a house on sand; whether you are setting down one brick or a thousand, without proper foundations you are doomed to failure. The cloud is good if it is designed correctly but can go horribly wrong horribly quick otherwise.
So what are the areas that could go wrong, where do people run into difficulty?
- Redundancy & Failover
Most of the Cloud providers such as Microsoft Azure, Google AppEngine and Amazon AWS provide a Platform as a Service (PaaS) which provide an API set and sometimes an SDK to develop against. There are also Infrasture as a Service (IaaS) which could be classed as the ‘Cloud OS’ such as OpenStack which provide underlying load balancing, networking and file access which PaaS and eventually Software (SaaS) sits on.
Each are slightly different but most provide extensive documentation and examples (hopefully), the problem of which is that they are keen to show how easy it is to connect to the cloud. It can take less than a day to sign up, and fling a file or data record to the cloud. This is where developers show a demo and managers call it done.
Ramping up from this 1 demo to 10,000+ machines is a nightmare.
Depending on what the cloud service is being designed for, whether it is serving or processing data security is still a concern but in different ways. The areas where security should be considered are:
- Connection Security (Injecting data)
- Direct Data Injection & Corruption
Even if you have a reliable connection, if someone can insert ‘Drop Table’ or corrupt inbound data your service may fail. Moving to larger services, sometimes people or companies may target you for DDoS and thus you may need back off strategies.
This is the much toted idea of cloud computing, but it requires work. You might have a powerful server but if it doesn’t load balance incoming requests then its just as useful as a small PC. The idea put fourth is that of Starbucks where data comes in and placed on a queue, lots of workers come along and then fulfil the requests.
On a larger scale the concept of load balancing between multiple servers, and task managers to cull spun off processes become important. – Again something that isn’t required with just one connection. Eventually it may just get to a point where you can’t just get a bigger server, and you will have to refactor your design to either fix it or make it more efficient.
Redundancy & Failover
Your cloud solution may need to connect with other cloud services or external APIs (think Facebook, Twitter, authentication servers etc.) The first rule of this situation is never to believe they will be available 100% of the time, even your own database may sometimes not be available. Designing a solution with possible redundancy or routes of action when these external services fail is a must.