Cloud Computing seems to be the talk of the town. It is very difficult to separate hype from reality. Overnight, people have been asking questions from our software products i.e. is it ready for the cloud? Cloud computing is a different model and not all products can be a good fit for the cloud. This article will assume that you have a current product and have done enough homework to move it to the cloud. The article will list down key high level areas that you need to consider while moving to the cloud. These are based on our experiences with executing projects over the last one year in the cloud computing space.
Self Hosting or Outsource
Given the options that are out there vis-à-vis cloud architectures, there is a tendency to think that one should do all the hosting initially and then move to a cloud (public) once the application gains more acceptance, etc. While this might seem plausible in the beginning, there is no point trying to replicate complicated and massively scalable architectures that cloud vendors have already built out. So it is important to do your homework first in terms of the cloud vendors that are out there, evaluate them, discuss your requirements and go with one of them. Depending on your choice of technology, you might have to go with a vendor who provides that platform.
PaaS or IaaS
This article intentionally keeps aside SaaS (Software as a Service) since that can be done for your product in the cloud, but before that you need to get to the cloud. You can either take the IaaS (Infrastructure as a Service) or the PaaS (Platform as a Service) route. The IaaS vendors such as Amazon provide you computing resources: Virtual Machines, databases and processing in a pay as you use model. This is most flexible if all you want is a virtually available application for everyone to access. You will have to most likely build an image of your application and use a service such as Amazon to host it for you. The IaaS vendor will take care of all aspects like scalability and availability.
The other route to go is PaaS (Platform as a Service). These are specific to a technology platform and PaaS providers provide you a complete technology stack to develop and a scalable network where they will host the application for you. Key players in this area are Google App Engine (Java, Python), Heroku (Ruby on Rails), Azure (Microsoft .NET) and Force.com (a PaaS platform from Sales Force). Do keep in mind that each of them have different billing plans (typically pay as you use) and not all of your application can be ported as is to a specific PaaS. You will in all probability have to rewrite some parts of your application to fit the PaaS Technology and runtime stack that you go with. For e.g. Google App Engine provides core services like Caching, Task Scheduling, Networking, etc that might not be compatible with the way your current code is written. If moving to a PaaS, you need to evaluate each of your core system and infrastructural services/layers with respect to the Technology Stack that the PaaS provider gives you.
Most applications are still dependent on a relational database (SQL). The current opinion is that relational databases are not that suited to horizontal scaling at a large level. The movement towards noSQL databases has found widespread acceptance and it is something worthwhile to investigate into. Several PaaS vendors simply do not support SQL databases at this point in time (Google App Engine) and instead provide support for NoSQL databases. Several NoSQL databases like Google Big Table, MongoDB, Voldemort, etc are gaining acceptance. The database layer is therefore something that you need to pay close attention to as you move to the cloud since it would impact the architecture/design of that layer.
A cloud in its purest sense stands for abstraction. You are more interested in the interfaces and service contracts rather that the details about the implementation. The same philosophy applies to your product architecture and functionality as it moves to the cloud. You need to abstract significant portions of your application and service enable them to be accessible using open technologies like HTTP, XML and JSON.
Versioning in the Cloud
Your product will go through several iterations or versions. Each new version will come with its new set of features. There is a good chance that the versions would be incompatible with each other and yet they need to be running and supported till end of life. The impact of this on your architecture will be the need to build in versioning in all aspects of your product. All Interfaces to the outside world vis-à-vis integration points will need to incorporate versioning.
Scalable cloud architectures rely on multiple instances of your application running across clusters that could be geographically distant. The cloud provider takes care of all this for you. The architectural impact of this will require that you take a good look at how you manage sessions in your product. An overreliance on sessions and expecting that the request will be forwarded to the same server that serviced the original request could result in problems. You will also need to employ Cache architectures in your product to allow for scaling.
Moving to the cloud requires that you provide new features in your product vis-à-vis managing the product. You will also need tools to help building, deploying and monitoring your product in the cloud. Some of these are:
- Keeping a track of resource usage that your application consumes
- Tools to provision a new instance or multiple instances of your application in case of increased load
- Mechanism to send out Alerts in case of System downtime
- New tools for building/deploying to the cloud
- A comprehensive dashboard that allows to do all the above along with access logs.
There are enough technical reasons why one should move to the cloud. Given the choices that are out there, you would be able to look at the pros and cons. A final point is about the economics part of the process too. At the end of the day, it should make economic sense to moving the product to the cloud. Business models that incorporate the cloud are being demanded. It would also help to determine how much it is going to cost to move to the cloud in terms of servers, resources, etc. Different payment plans are available and most cloud vendors provide a free quota along with plans that charge you only if you use resources. A quick check would be to analyze your current traffic, taking into consideration peak days and numbers and determine the approximate cost of moving to a cloud.
The above are high level architectural factors to take into consideration while moving to the cloud. Each of them can be broken down into fine grained points but these high level items should form the basis of a good discussion/strategy before moving to the cloud.