My previous experience as a web app developer before joining Poppulo consisted of delivering applications packaged in .war and .jar files. Deployment consisted of dropping them somewhere, into a maven repo, hot-deploying to a running tomcat instance, or (shock horror) into an email, for someone else to deal with. Upping the memory on tomcat was the limit of my interaction with the live system. A nice bonus for joining Poppulo was that I would finally get to work with real life sysadmins and observe (from a distance) what they do to keep production systems alive and healthy and get some feeling for the tools and techniques they use while at the same time not getting my own hands dirty :)
However, this is not the way Poppulo works. In the world of microservices you don’t get to stay on the sidelines too long. Core concepts such as service discovery, provisioning and monitoring mean that you have to get up to speed very quickly with the areas that were previously the sole preserve of the sysadmin. You must enter the world of DevOps, where systems and application tasks blend into one.
Any new discipline can be daunting to undertake; but once immersed in the world of DevOps you begin to identify its important areas, patterns and processes, while building up an arsenal of tools that make your life easier.
It was a case of baby steps for me. I got used to working with remote servers, setting up my local SSH config with aliases and port forwarding, and brushed up on my command line “fu”, which made me more productive.
Then the inevitable hours of troubleshooting began. I am not going to lie, I went to some dark places. At one stage I spent a day trying to figure out an issue with my Cassandra cluster only to eventually figure out that different nodes were running different versions of cassandra...not cool :(
But through the provisioning of some environments in Docker and eventually in Ansible things started to click. The previously haphazard installation and configuration of software with ad-hoc scripts and console one-liners which made me shy away from the world of DevOps has been replaced with more manageable and maintainable configuration management tools. The various package managers, editing config files, setting up networking rules, etc all made more sense to me when I could apply them as configured tasks to a machine. Tools like Ansible bring all the pieces of the jigsaw together. With the manual pages being so excellent you can achieve great things and more importantly achieve great understanding!
Is the idea put forward by Formula One legend Jackie Stewart that understanding the technology which goes into building the race car makes you a better driver. Martin Thompson took this idea further with his belief that an understanding of the hardware is vital to the creation of the software that runs on it. I find this analogy also works well with regard to DevOps.
Having a deeper knowledge of the environments that my applications run on and a greater responsibility for them when they are released has enabled me to deliver code to a production ready standard that I am happy with.
When writing an application I now ask myself:
- Is it fully tested?
- By tested I now not only mean unit tested but also full integration tests (more than likely using a lightweight docker environment) and where applicable acceptance tests.
- Have I monitoring in place to help me proactively identify issues?
- Have I monitoring and logging in place to help me retrospectively diagnose any issues that show up?
- Is the performance of the code benchmarked?
- How is this code packaged up (image/jar/rpm/deb...)?
- How will it make its way through the build pipeline into production (continuous delivery)?
From having limited experience, in a few short months I have come from troubleshooting issues to understanding the need for versioned infrastructure as code (Ansible). Engaging with DevOps has put me on the road to becoming a more rounded developer. Though I may not have all the answers at the moment, I now know where to start looking for them.