This post was started in May 2016, went on a sabbatical and is back having changed intent
Back from the annual Zühlke Camp and some conversations keep bouncing around in my head.
It has been about 5 years now that we started using Chef to drive infrastructure-as-code into our projects. The incentive that led to this is documented in a post back in February ‘11. Seems I have spent 5 years melting silver to make bullets.
For a company like Zühlke the use of provisioning tools like Chef might not be apparent from the start: It does not operate a data center, does not do traditional Ops1 and does not deal with a large scale of server instances per project.
What it does2 (and really, really well I might add) is put together engineering teams that build high quality software which - when occasion warrants it - is correctly integrated into a system of electronic and mechanical components (which it also develops).
What does that have to do with DevOps?
You now have two problems
Any software engineering team of significant size (arbitrarily defined as 5+ people) faces two problems:
Problem Number One: It works for me
You can’t build the software, but your colleague next to you cannot reproduce the problem. You are reduced to playing “Spot The Difference” to figure out what is wrong.
Few things are more frustrating than inconsistencies across your development infrastructure. It costs a lot of time and consequently money but it also has a severe psychological impact: You can never be sure3 if a green build really means there were no errors.
Problem Number Two: Newbie Blues
You hire me to write code and I spent a week installing software, fiddling with settings and most importantly consume time of your already stressed developers because the installation guide the trainee wrote three years ago in Word is outdated and only the people working know exactly what is going on and how it fits together.
Worse yet, there is only one guy who knows all the details and he’s on holiday (true story).
Strategic advantage
A technology consultant firm like Zühlke might not operate servers on scale, but it does engineering teams on scale, so the above mentioned problems become hurdles and the solution a strategic advantage in ensuring a high quality, high standards environment in the shortest time possible: The team hits the ground running.
Automation is codified expertise
I don’t remember coining the phrase but it has been attributed to me probably because I keep repeating it.
In a lot of ways automating is scaling your experts: Specific practices and solutions, especially in building and testing software systems can be automated, which means the computer takes over the boring, repetitive work.
Silver(ish) bullet
Both problems mentioned above are solved treating infrastructure as code and development environments as infrastructure:
Consistency reduces discrepancies leading to faster defect localization. Automation accelerates onboarding.
But just like regular expressions you have now introduced a whole other layer of complexity. You have added to your technology stack and this opens new issues.
Maintenance and documentation, the bane of every software. We are surprised by how much work is required - every single time, for every piece of software we use.
The irony of doing
I complained loudly (at camp) that I spent a lot more time explaining things instead of doing what I used to do: explore bleeding edge technologies and learn new stuff.
A colleague reposted with “you’re getting old mate, we have to get all that knowledge out of your head before you turn senile”. Apart from the old part (sic!) his statement reflects a perfect irony: the more you do, the more you find yourself having to set aside time to explain what you did, ending up doing less.
This post started as a highly technical tour of Chef usage for provisioning development environments. It turns out you get that out of the way in a couple of paragraphs.
The technical foundations of all this are not the really interesting parts. They are tools, tools that enable better communication, better teamwork, better planning.
What we aspire to is a team whose members have a common understanding of the system they are building and each member is enabled to develop, detect problems early and release on schedule. And we want that for every team.
And this leads us back to what I consider DevOps to be all about4:
- Holistic system thinking
- No silos between disciplines
- Short/fast feedback loops
- High degree of automation
Do you know what it actually means? It means we want higly motivated, educated people that have an interest in what they do and want to learn about every aspect of it. And we want these people to work together as a team, complementing each other in their tasks, learning all the way.
Mutual respect, appreciation, reasonable hours, good pay and interesting problems. Software development is mostly about people.
You didn’t expect that, did you?
1 Not quite true - basically Zühlke does not manage a data center but Ops are part of the portfolio of services offered.
2 Marketing will hound me to the end of my days for that sentence. Zühlke of course does more things. Great teams of great engineers building great software is my favourite though.
3 Well, you can never be absolutely sure, that is a given - we are talking software development after all. But you should be reasonably sure.
4See what I did there? I used a hyped up marketing term to get you hooked and kept airily going on about abstracty this and thats vaguely within the broad marketing blanket of the term. At least I’m nice enough to give you a definition at the end.