In this episode Andrew and Paul cover the high terrain of DevOps. We have come to understand that great software delivery is more about practices than process, and none are more important than the practices we collectively term “DevOps”. We’ll talk about what we mean by DevOps, what the underlying principles are, discover that DevOps isn’t like sex at all, and note some bear traps you should avoid.
This is part one of a two-part episode. You can read and listen to part two here.
If you work in software development, and if you haven’t been living in a cave since 1994, you’ll have heard about DevOps. Everyone talks about it, everyone has their own idea about what’s involved and everyone assumes that everyone else has got it better. Maybe it’s more like sex than we thought…
This is another big topic and we’ve split the discussion across two episodes. In this episode we’re introducing DevOps and looking at principles 1-5. In the next episode we’ll look at principles 6-10 and wrap up. This is a feast of content for those who work in software, and you’re in for a treat if you like to draw on the experience of people with decades of industry experience.
Here are the highlights of the episode:
- Principle #1: Automate everything
- Spare everyone from the toil of repetitive work. Humans should focus on solving problems not cranking the handle on the machine.
- Automation is a prerequisite for quality. Without automation there is no repeatability, and without repeatability there is no quality.
- Our automation includes the following:
- Testing
- Static code analysis
- Building and packaging applications
- Deploying and configuring infrastructure
- Principle #2: Git it the source of truth
- Everything goes through a Git repository (well, almost – see #3).
- We create appropriate security boundaries around our knowledge and IP.
- We have an audit record of changes, who did what, who approved what, and when.
- Avoids issues from dispersed knowledge and information.
- Principle #3: No sensitive data or values are stored in Git
- Applies to application secrets, keys, certificates with a private key, personal data, tokens.
- You can get into big trouble very easily if you have credentials in the wrong place! Paul gives an example of someone who left their AWS keys in a Git repo that accidentally became public.
- Use secure stores such as AWS Secrets Manager, AWS KMS, HSM’s, K8s Secrets.
- Adopt a rotation policy for secrets and make sure your DevOps process can handle rotating secrets.
- Think about how you will secure your sensitive informaition, how it is processed and who has access to it.
- Principle #4: Adopt an infrastructure as code (IaC) approach
- Infrastructure becomes declared as templates and can be automated.
- Changes to infrastructure are captured and can be rebuilt when needed.
- Principle #5: Adopt an immutable infrastructure approach
- VM nodes and containers are replaced rather than changed.
- This approach prevents configuration drift, which is a danger with mutable infrastructure tools such as Chef and Puppet.
- Updated images can be tested and verified prior to deployment.
- Live production infrastructure is not updated while running, which improves availability.
- This approach gives you the ability to roll back, perform canary deployments, blue/green deployments etc.
- We use desired state for services (e.g. cloud services) where we are not provisioning the infrastructure ourselves. An example of this is AWS EKS.
You can watch the video here:
You can listen to the audio here:
