A Prequel to Open Source Application Development on Azure
For much of my career, I’ve been building applications on a variety of cloud infrastructure. Over that time, I’ve targeted platforms as a service (PaaS), infrastructure as a service (IaaS), and others that fall in the vast territory somewhere between PaaS and IaaS. Over the course of those experiences, one often plays the role of both the application developer and DevOps engineer. From playing both of these roles, I’ve built up some opinions on how to deploy and manage applications in the cloud. In a series of posts, I’m going to apply this experience and provide a progression of DevOps maturity on Azure using FOSS tools targeting both PaaS and IaaS.
Before we get into deploying bits in Azure, I would like to first describe a hypothetical DevOps maturity model.
Concentrating on the build and deploy cycle, rather than the social / team interaction aspect of the DevOps / Agile movement, let’s consider some levels of project maturity.
In Level 0, deployment of code is a manual process characterized by adhoc commands and manual intervention — think paper and pen check list. Often these application servers are looked at as “pets”, that is, they are carefully crafted and maintained. Deployments are usually cumbersome and error prone.
Level 1 progresses from level 0 by introducing deployment scripts, which could be run manually with little human intervention. The key to level 1 is that the scripts are not part of the continuous testing workflow and are not validated with the rest of the product. The servers are still “pets” and need lots of hugs. The deployments are still manual, but are becoming less error prone.
Level 2 advances from level 1 through the introduction of an infrastructure as code model. Tools like Terraform, Ansible, Chef, Salt, Puppet, etc. provide high level languages to produce the infrastructure as code model. Some characteristics of an infrastructure as code model are the following:
- infrastructure requirements are codified in a high level language
- infrastructure scripts are tested as part of build validation
- standardized automated deployment workflow — continuous integration / continuous delivery
- servers are no longer “pets” — they can be destroyed and rebuilt *quickly*
Level 3 plays off of the ideas espoused in Level 2, but solidifies them in the form of testable, self-contained deployable artifacts. These artifacts are often in the form of Virtual Machine Images or Containers. Some characteristics of an immutable infrastructure are the following:
- artifacts are *immutable* — the same artifact that pass tests is the same artifact that is deployed
- application artifacts are self contained
- artifacts are tested and validated as an entire unit — code and operating system dependencies are encapsulated
In an upcoming series of blog posts I’m going to build an application and provide a progression of DevOps maturity on Azure using FOSS tools targeting both PaaS and IaaS.
