For many people, DevOps and infrastructure as code are synonymous. However, I am usually quick to point out the other moving parts that need to be managed. There is more to DevOps than infrastructure as code. Once the infrastructure is in place we need to do something with it. Application deployments, database updates, static content deployments, application configuration, middleware configuration, all of these things come into play after the infrastructure is in place.
There are many excellent applications for managing your infrastructure; tools such as Chef and Puppet obviously come to mind (they are easily the most popular). These types of tools are perfect for making changes across multiple servers, and making sure your infrastructure is in sync. They are also great for taking newly spun up virtual machines and making them identical the other servers in your environment.
Infrastructure is only part of the entire stack, and honestly it is not the most volatile part. New machines requiring infrastructure may be added daily but once the infrastructure is in place it tends to change less often than other components of the stack. For example, the middleware configuration, the applications, and the application configuration all change much more frequently than the infrastructure. Managing these changes is a crucial aspect of DevOps.
In the image above, the lowest layers can be handled by a number of tools. These layers are typically handled by the major IaaS providers (Amazon EC2, Rackspace, and others), which involve provisioning of the servers, as well as the OS and the OS configuration. Another great solution is to use Terraform or uProvision to handle the provisioning. These tools enable companies to build an internal PaaS offering to allow teams to automatically spin up servers and make them available for deployment.
The middleware layers have a handful of solutions for automation. Some companies include this configuration in the base image of their virtual machines. Another popular option is using any of the “infrastructure as code” tools mentioned above. These types of configurations can even be managed as part of your application deployment in an application deployment automation (ADA) tool such as uDeploy.
The application, and the application configuration can change multiple times a day in any continuous delivery environment. Often it may only be the configuration itself (and not the binaries) that need to be deployed. uDeploy is designed to not only automate the deployment of the application but also provide visibility into which versions of changes have been applied and where.
I would say that uDeploy is an ARA (Application Release Automation) tool. We should not forget to differentiate release from deployment. A release is generally thought of a production release but I tend to think about release as deployment of a set of components of their respective versions to add a business value in any environment. A release set (snap shot) allows tying up these versions together. Individual versioning allows components to evolve independently but still deployed, tested, rolled bak together.
We can accomplish deployment automation through any tool like chef/puppet etc but release management is a huge value that uDeploy provides and is what differentiates uDeploy from other tools.
My 2 cents!
More frequent app detpoymenls and Continuous deployment need a line to a new concept named App designed for hot/quick deploys .Applications can be designed in a way to allow for minimal/no down-time (eg. reference data with start/end times, property file listeners to automatically reload configuration changes, redundancy to allow for live detpoymenls).
Thanks Gede great input. I think that those things are imratpont (live reloading of settings etc) but should not be designed in from the outset (but then I’m an emergent design guy). Frameworks like OSGi are compelling, but charge a very high complexity tax. Allowing for fast (and automated) rolling restarts including re-deployment of externalised settings is most imratpont and as you say this requires redundancy and a simple architecture.