It wasn’t all that long ago that an agile software development process was a novelty. Even as Dr. Dobb’s Journal had a monthly column by Scott Ambler about it for a long time, it was slow to catch on in a lot of places, with much misunderstanding about it. Now, it feels as though companies not using some variation of agile are the exception, and DevOps has a lot to do with that.
DevOps is in many ways the ultimate manifestation of what agile is all about, something that has only recently become clear to me. It’s been less than a decade since I first worked for a company where this was used, but since then there has been no going back. Even when it was not being used in name, it was being used in practice. DevOps was not part of it originally, but it is very much part of it now.
Read The DevOps Handbook, and so much about modern software development with agile becomes so much clearer. It is a must-read book for anyone developing software, and I must confess that I had this book for well over four years before finally picking it up and realizing how important it is.
The book is a follow-on to The Phoenix Project, which is actually a novel, not a technical book. It picks up from a technical standpoint, although it is not a “hard technical” book, if you will – more like a core software engineering book that doesn’t get into tools and technologies as much as concepts and process. Far from being a book solely for managers or those we used to call release engineers, it is a book that belongs on any software engineer’s desk, especially a software architect.
DevOps is known in large part for automated builds and testing. While these are key components, there is much more to it, and unfortunately that often gets easily missed. I was no different – my first sense of it came from the use of the Jenkins tool for automated builds upon a check-in of code, but I now know a lot more than just that.
Many companies had a nightly build for years. Over time, it basically became an accepted standard in software, often including a suite of unit tests or even acceptance tests being run once completed. Nowadays, that seems quite insufficient. Code is checked in all the time, especially in big software companies, and anyone who has spent a little time in the software world knows that defects are more than a dime a dozen. One of the goals of DevOps is to cut down on these, especially ones that get shipped with a software release.
But let’s get beyond that. Properly understood, DevOps is the ultimate manifestation of what agile is all about because it goes with the idea of delivering working software on a regular basis – “regular” does not mean every few weeks or even every week, but more like daily or even multiple times daily. The book goes into some detail on companies that have increased their number of deployments by astounding numbers, aided by exactly this.
It goes deeper than this, though. Some may scoff at the idea that their company can pull off multiple software builds, tests and even deployments every day or week, especially when told that this is what the Googles, Amazons and Facebooks of the world do – it’s not uncommon for this idea to be dismissed because of the resources those companies have. But that misses the point, especially because none of those companies reached this point without growing pains, often chronicled in The DevOps Handbook.
In fact, where a lot started to click for me is in chapter 13. Entitled Architect for Low-Risk Releases, it goes into detail on architectural archtypes (that’s a mouthful!) and how organizations often have to evolve their architecture from one to the other, mainly because a monolithic architecture is often a starting point but not a good place to be later on. It’s not a long chapter, but what it drives home is as important as any in the book. Though surely not its intention, reading this also helped me get a better grasp of microservices, something I have had a hard time wrapping my arms around.
Deep down, using DevOps on a big level is about much more than just builds and tests – and it involves everyone, not just release engineers or those whose jobs emphasize DevOps. It is a big challenge for architects, because to best use DevOps and gain from what it offers, software must be properly architected. A big monolithic application where one change can break almost anything? It won’t work, and DevOps will expose this. The book shares stories of how companies re-architected their software from a big monolithic application (or multiple ones) into software containing many smaller applications or services, which then allows not only for DevOps to benefit them, but also to make their lives easier and their software more easily improved and deployed.
Of course, properly trained and practicing software engineers are software architects at heart. Software engineering is about much more than writing code, something easily lost in talking about the field and what working in it entails. And because DevOps is part of an agile software process, it makes sense that architects have a key role to play, while any engineer on the team should approach becoming an architect.
There is no going back from an agile process now. DevOps has a lot to do with that, and as books go, there may be no better one than The DevOps Handbook. Read it and understand what the present and future of developing software is all about.