Let's Talk About DevOps

If you ask five people for a definition of DevOps, you will most likely get five different answers. The term is flung around by businesses and recruiters alike, and each has their own understanding of what it means, and what they want from it.

The term DevOps is about Development Operations. It describes a movement and practice towards both the close working of developers and operations professionals, and the combining of the two roles into one job. Developers write code, operations manage infrastructure and systems, and make sure that the plumbing is in place to keep a business running smoothly. In smaller businesses, it has been quite common for developers to be involved in every area of operations. In these organizations, they are doing a partial DevOps job without having that as part of their formal job description.

Up until quite recently, software development was quite regimented. We practiced waterfall lifecycle development, and there was a strict hierarchy of people and processes -- everything, and everyone, had their place. Over the past say, 10 or so years, we have seen the widespread adoption of concepts like Agile development, and have seen the emergence of cheaper computing, first with shared public and enterprise hosting, then the cloud. As time has marched on, the cost of developing software has gotten increasingly lower. This is due to both the lower price and increasing power of computing hardware, and also the increasing availability of free and open source software, and its associated services. Along the way, while all of this was happening, the various jobs that people did both diverged and overlapped at the same time, and edges started to get blurred. The emergence of the 'startup' phenomenon and new cloud centric technologies have also helped fuel this mix.

Whereas previously most software houses had separate team members working exclusively on different areas, the tendency now is driving towards heavier overlap, and team, rather than individual ownership, of the full end to end process. In larger, less informed organizations there is still a strict segregation between the roles of development and operations, but this is rightly falling away. Leaders everywhere are now seeing the great gains to be had by combining and/or fostering a closer relationship between the two previously isolated roles.

Google, Microsoft, and Amazon are great examples of how this merging of development and operations is bringing great benefits. In an article describing how Google runs their production systems, we learn that the key to Google's 99.97 percent uptime reliability is DevOps. The upshot of the article is that software developers don't like to repeat themselves, they like new things, and they like challenges. If you ask them to do the same thing over and over, they will get bored quickly, and will invariably find a way to automate the task. The follow-on from this is that automation, coupled with associated quality assurance, leads to better system reliability.



So where does that leave us, and what's the point of this message? Simply, that the world of software development is changing, and to not only survive, but to be up there with the best, you need to change with it. As software developers we need to take more responsibility for not only our code, but the environment where it operates. We need to be proactive in quality assurance, in system automation, in system resilience.

In the same way that a pilot is responsible for an aircraft, and safety of its passengers, from the time it takes off, to the time it lands, so too are we as developers responsible for our creations. Just like the batter protects the wicket from the incoming ball, as developers we need to be aware of what's ahead, watch for dangers, and code in a robust manner. It is not sufficient to simply put out code and assume it will work, we should question how it will be deployed, what kind of use it will receive, what environment it will be expected to survive in, and plan accordingly. When planning, we should be asking the big 'what if' questions. What if ... the number of users is 1000x ... the database goes down ... I have transactions locks ... the deployment machine runs out of disk space ... the list goes on.

There are tools to help us in DevOps. You will have heard about things like Docker, Chef and Puppet. You may be aware of services that assist in system reliability like Splunk, continuous integration like Jenkins, Octopus Deploy and Bamboo. But ... having heard of them is one thing - knowing what they do, is quite another. As the ecosystem of tools and services to ease development and help us with Devops grows, it becomes more and more difficult to keep on top of things. The best advice is not to try to understand and know everything. The best advice is simply to be aware of the landscape, and choose a number of specific tools to assist you in the job you are doing, and help your enterprise achieve its goals. You can't possibly know everything, but you can be expected to be able to intelligently know at a high level what's available, and where to go to investigate holistic solutions.