over 2 years ago by Gary Rawlings

Why is DevOps in such demand?


To answer this question you first need to understand what DevOps is and why it adds value, so lets rewind the clock and go back to the good old days, before agile when waterfall was the standard methodology. From my own experience, I remember working on a platform supporting a global business processing millions of transactions per day with over 100 different microservices being orchestrated as part of the flow. We had multiple global instances of the infrastructure, all hopefully running the same version of the codebase & config with our regression cycles taking ~2 months to complete, with over 30 developers globally working on the testing. Our regression & release cycle became so expensive we made our biggest mistake and reduced the frequency of release even more… Guess what? Our next release took even longer to test and release!


Why? Well the answer is obvious in hindsight:

  • There was even more layering of code changes made to the same modules by different developers making unpicking bugs and preserving intended behaviour even more challenging
  • As not all changes were mandatory for a given release, as the deadline for freezing the code would hit we’d inevitably start branching heavily and that caused more risk & more effort post release to merge to trunk
  • Poor traceability from requirement to code change coupled with developers fading memories of a change they made months ago made determining correct behaviour challenging
  • Our testing approach relied heavily on running a prod parallel, but with so many changes happening within a given release it made determining which breaks were intended behaviour versus bugs impossible to manage
  • The branching also meant different instances of our platform ran different code versions which made subsequent releases, code merges and testing even more challenging


Not pretty to say the least, in fact it was a nightmare! Back in the day the answer wasn’t as obvious as it is today which clearly is taking an Agile, TDD approach with a strong focus on DevOps. These disciplines promote frequent releases with continuous integration, deployment and delivery. DevOps specifically focuses on the automation of the steps in the build, test and deploy part of the SDLC.


Specifically DevOps is focused on:


  • Continuous Integration/testing: The process of executing automated tests, typically daily though ideally even more often, which allows for immediate developer feedback on their changes
  • Continuous Delivery: Frequent release cycles into production supporting the delivery of incremental client benefit and enabled by concurrent and continuous cycles of development, testing and deployment


So how is this achieved? Well, there are a plethora of specialised products & scripting languages that allow people with the right set of skills to set-up and manage this delivery pipeline, both for in-house and cloud based deployments. To give a sense of the complexity in this space there are dozens of different specialised tools / scripting languages and hundreds of books on the subject. To give a sense of the demand for these skills, right now in London alone, looking at a number of the major job boards there are more job adverts for DevOp roles than there are for C++, Python and Scala combined!


The next question is why are people with DevOps skills hard to find and why can their skills often fetch a premium? The answer is supply. To be a good DevOps Engineer you need to be strongly technical and you need to enjoy the challenges that can be faced in this space, like for example, having to ensure that the same version of your code and config is running across 50,000 nodes in an AWS environment. That’s a very different problem space than many software engineers work in, some like to build core platforms for other engineers to use, some like to face off to their users and gain a depth of knowledge of the business domain they operate in, some like to build UIs etc.. Strong software engineers who are passionate about solving the problems within the build, test and deployment cycle are hard to find, but find a good one and they are gold dust!


Gary Rawlings currently works as CTO at The Difference Engine.