As mentioned in the last Post, deployment is a very tricky thing in the Cloud. It can be easy if you run your applications on a PaaS-Service. However, it might be tricky in IaaS Environments.
There is mostly a need for an Operations-Team that takes care of deployment and maintains the Application for failures. In DevOps Environments, we often see the following:
„It‘s not my Code, it is your machines!“
„It‘s not my machines, it is your Code!“
This means that there are often problems between the two teams. The Development Teams finger-point at the Operations Team and vice versa. Flickr gave some best practices on how to overcome this issue. These Reccomendations are divided into two main points:
Right Tools consists of the following recommendations:
This consists of different tools such as Puppet for IT Automation, Cobbler for Automated Installation, CFengine for Configuration Management or other Tools
Shared Version Control
All Build Actions are done in a Skript, no need to do more command-line-ing
Shared Metrics (Easy to read metrics to see improvements)
Large Applications such as Amazon, Google, eBay, Facebook and other large Websites have problems when it comes to deploying their Applications. Often, there are some 10,000 servers or even more of them when a new Version needs to be deployed. In Cloud Platforms, we often have similar issues. Even if we need to deploy to 100 instances, it might be difficult to get everything correct.
There is a significant difference between PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) Applications. If we use IaaS, we have to take care of deployment. Each instance needs to have the newest Version. There are different tools available to automate that task or you either write your own tool for that. If you use PaaS, it is easy since most platforms (such as Google App Engine and Windows Azure) usually take care of that.
There are several issues and challenges if you use IaaS Platforms to run your applications:
You have to deploy to a lot of Servers – usually 100 or more
It is not possible to allow a “maintenance timeout”. In this timeframe, you loose money and your customers will be angry if you have a “maintenance downtime” for 2 hours or more every week
Deployment goes to the production System, where probably million users interact with – problems will immediately have effects.
This leads to some problems and the short answer is that there is no easy solution to that. Each deployment strategy must be tailored to the application. However, it is possible to use a specific iteration strategy, which is illustrated below:
There are 5 major phases in each deployment:
Develop. Software/Platform is in development phase.
Verify. Everything that was developed in Phase 1 is now tested. This is basically done by the testing department. There are no user tests involved so far and the new release is not deployed to a real environment.
Stage. The new release is put on a staging environment. This is a sandboxed environment where no damage can be done to the real system.
Verify. The new release is verified on the staging environment. This is basically done by beta-users or internal departments
Deploy. The new release is deployed to the final system and all users access it from now on.