The DevOps movement has been running for close to a decade, and has produced some of most powerful tools for managing and deploying software.
We talk about how automation improves our lives, but we don’t talk about the underlying goals that drive why we focus on automation. We talk about moving from specialist servers to classes of machine, with only an implicit idea of the problems we are solving.
As part of our journey, we’ve identified three core principles that underpin, on a technical level, everything that DevOps is trying to achieve and improve, the principles of isolation, repeatability and determinism. These principles are the guiding forces behind the technical choices that our tools are making, and frame the way we think about reliability and resilience.
Isolation
In DevOps terms, the isolation principle covers clean lines of authority within our technical components, where each component of our infrastructure must be separate from each other piece by the greatest extent possible.
In a deployment sense, this tells us that our product is distinct and must be considered distinct from the operating system, and isolated from changes.
In a microservices sense, we’re taught that each service must have a strong, defined interface between other components, one that is static and unlikely to change.
Repeatability
The next property speaks of our processes, insisting that repeating the process is possible. In order to achieve that possibility, we are required to fully capture every detail of the process, in a form that can be consumed by others.
A process isn’t repeatable if it relies on steps in a single persons’ head, after all, and so that specialist knowledge must be documented, each step fully explored, and each stage thoroughly captured.
In a server sense, this tells us that a new server can be created from scratch in a known and knowable way, that we can give that task to anyone on our team and be reasonably assured that the process will be completed.
This principle is the first time we begin to capture the necessity for automation.
Determinism
The final property tells us that the process we’ve defined must always produce the same result. If I set up a server, then it must be the same as the server you set up. If I install the product, it must be the same as if you install the product.
This final tenet demands automation due to the difficulty inherent in achieving consistent results without automated testing and build processes.
Determinism seems like it should be a part of Repeatability. After all, doesn’t a repeatable process imply that the results will be the same? Rather, Determinism posits that people performing a process will produce similar, not identical results, and the goals of Determinism is to fully control for that variation.
Properties
Using these core principles we are able to see the very powerful properties that DevOps practises offer us, enabling new forms of deployment and maintenance of our infrastructure.
Lowering the Costs
For instance, the DevOps principles insist we invest in both automation and consistent and decoupled interfaces between our components, which allows us to begin to treat our infrastructure as disposable. Why would we modify a system in an attempt to repair it when rebuilding it from scratch is an automated, repeatable, and deterministic act?
But a pure replacement does not help us diagnose the failure. Fortunately, instead of removing and replacing failed systems, we can disconnect a failed machine and isolate it for forensics and analysis, all without impacting the core of our infrastructure.
Being able to discard and recreate our infrastructure in this manner is only possible because we can guarantee the result of our process, because we know that there is no tight coupling that will break when we remove critical infrastructure, and that possibility only exists by adherence to the DevOps principles.
Scaling Further
Strongly isolated components in our infrastructure also allows for access to the true power of the cloud, scale. By providing standard interfaces and decoupled properties, any component that communicates with another component shouldn’t need to communicate with just one, it could communicate with one of many.
With determinism and repeatability we are able to reach the promise of the elastic cloud, because we are never in doubt of our ability to guarantee the consistency of our processes.
Fail Fast, Fail Often
We can start to talk about the reliability and resilience properties that DevOps unlocks. When we guarantee that what has failed will be replaced with an identical result, we can treat failures as a known quantity. Test environments to reproduce the failure can be constructed without complicated work because our automation ensures the process will be identical.
This allows transient failures themselves to be managed automatically, reducing the workload of operational firefighting and freeing up resources to work on improving resilience in other areas of the infrastructure.
Test It All
Finally, adherence to DevOps principles allows for development and quality assurance to happen with access to an environment as close to production as possible. Changes can be tested, tried, and retested without complicated work creating environments or long change requests, increasing the turnaround from development to testing.
Complete automation also allows for tested environments to be vetted before introduction into production, with full, visible and automated visibility into the differences now being within reach.
Potential
These are the properties that the DevOps principles unlocks, by viewing our deployments as integral to our software development and by adherence to the principles, we are no longer limited to “I think”, but are much more able to say “I know.”