Is Cloud Fu strong with you and your development teams? Do you and your development teams have Cloud Fu skills worthy to defend your app when moving to the cloud?
Historically server/environment configuration has been treated as a manual, one time setup done by sys
admins. Reversing this paradigm and instead bringing the server/environment setup into your deploy process is key to achieving the full potential in the cloud. Although many definitions/images of cloud computing exist with people they are usually based around three fundamentals, to which #3 we will address with self-bootstrapping deployments:
- Available anywhere
- Pay as you go
- On demand access to resources
The great part about focusing efforts in this area is that your application and development teams will see benefit regardless of whether you’re actively running in the cloud. Therefore if you automate your application and deployment process, it will be ready for an internal or external cloud when the time is right. The deployment process for an application is one that is normally overlooked in regards to automation, especially if the deployments are handled by a separate SCM group. Bootstrapping your deployment is a great and powerful place to start and will start getting you thinking in a cloud friendly manner.
One of the best areas to automate is your deployment process. Historically sysadmins and development teams rely on a server to pre-configured prior to deploying their application. Therefore things such as java, application container of choice (tomcat, jboss, etc), libraries, file paths, etc. are usually either manually done when a new server is provisioned or an image is built after all that work is done. This approach has the following downsides:
- When upgrades to an OS are needed, it requires manually making a new image
- When upgrades to java or the application are needed, it is a manual process outside of deployment and still requires the making of a new image
- Tracked changes of overrides to configuration files or other such actions are usually not captured or held with one person’s knowledge
The solution to the above is self-bootstrapping deployments in which we assume a completely new server during every deployment and automate the installing and setting up of the environment. This involves following a rule of thumb of complete isolation of apps running on a server. So for example if you had five java web apps running on a server, it would be expected to have five copies of java installed with each one dedicated to the specific application.
By doing the above we gain the following:
- No Secrets – all configuration, modifications, steps, etc. are self-documented in your source control repository and automated as part of a deployment. Therefore no hidden surprises.
- Everything is a Deployment – whether you’re rolling out a regular release, upgrading java, or switching to a whole new server farm, nothing changes! Since it’s all part of the deployment process no special action is needed.
- No Ghosts – Sometimes people will make changes to your environment (ie. tweak a java config) and it is unknown until you move servers or upgrade java. Since with each deployment, a fresh copy of everything is used, there are no “ghosts” or artifacts left behind from the previous application.
With the above, your application and development team will possess the necessary Cloud Fu to migrate and survive in the cloud. For the technical details on how to use ANT, shell scripts, Jenkins, and your web app, start the discussion below in the comments and we’ll share what we can.
About Ryan Schneider
Not sure I could take more technical details, but you’ve certainly helped me get more of a hold on cloud deployment