Bloggo back to the blog
What is DevOps? Understanding DevOps Methodology-->
I always consider myself to be very fortunate in my career that I have had not only very interesting roles but also worked with some very interesting people. As a Software Consultant I like to ensure that I am up to speed with what is happening in the industry and when new terms or buzz words come out I am very keen to ensure I am informed on what they actually mean or represent. One of my clients a while back knew this and whenever they heard about a new term they would ask me for a quick explanation, which I was more than happy to provide. After a while however I was curious about the amount and variance of terms I was being asked about. Many of the terms made sense in the context of the client’s work but some were a bit leftfield and really didn’t make sense. It turned out that this client worked with a vendor that had a particular habit of using terminology to sound impressive while not really knowing what the terms meant. The vendor seemed to rely on the assumption that no-one else fully understood the terminology being mentioned either so they thought they could get away with it. The client never called the vendor out on his assumptions but rather found the whole experience quite amusing. Of course, strategically speaking it also helped that the client was able to stay one step ahead of someone they relied on for technical delivery as well.
New Industry Terms
Apart from the obvious moral lesson in this story, the thing that really caught my attention was how people latch onto new industry terms and use them incorrectly. There have been quite a few instances over the last decade where technological advances in software development have come into the industry but also gained some level of momentum from being misused. From the N-Tier Architecture, Restful Services right through to HTML5 there have always been great bits of technology that have been misunderstood and slightly over-hyped. This hype almost seems to take on a life of its own and before you know it the technology in question is being claimed to be the silver bullet for every software developer’s ills.
Learning From Agile
Agile has probably been the most prominent term which has been incorrectly used over the last decade or so. I have never known a technology or methodology to polarise opinion as much as Agile has. From Junior Developers, Project Managers, Senior Testers to Technical Directors I have heard stories of how Agile is pointless, Agile is problematic and how Agile just doesn’t work. One interviewee once told me that they outright hated Agile. Strong words indeed and probably not the best thing to raise to a potential employer when they are knowledgeable about such things. On the other side of the spectrum people in similar positions would be evangelising about how Agile saved their lives and how they don’t understand why everyone doesn’t use it.
Now don’t get me wrong, I’m a massive advocate for Agile development practices but I also know from experience that it’s not always the best fit for every business. There can be a lot of factors that can prevent a business from adapting an Agile approach to developing software but these companies are usually in the minority and most of the common problems mentioned above do not come from those factors. Although Agile is now a well understood methodology, it wasn’t always the case. In the early days most problems came from people not understanding what Agile actually was. Most would adopt some Agile techniques and graft them onto their Waterfall process. This often created a project management monster of Frankenstein proportions, creating more management overhead rather than reducing it. Although the teams involved start by expressing their pride at being an Agile development house, after a couple of months they would reject Agile like a heartbroken teenager. Why does this happen? Well, as I mentioned already the real problem here, in my experience, is not Agile itself but rather a lack of understanding of what Agile is, what the objectives are and how it impacts and benefits a business. It’s not a collection of closed off development tools, it’s a methodology for the whole development lifecycle which should be adopted by the whole business. The gap between the idea of Agile and implementing an Agile approach is huge and sadly the rush to adopt a new approach or technology supersedes the pragmatism required to implement the approaches successfully.
What is DevOps?
As Head of Development Operations (DevOps) for SQS in Ireland this is now something I am seeing with DevOps as well. DevOps is the latest term to be banded around liberally online and in technical discussion groups and many people, in my experience, still do not fully understand or appreciate what it is. Like Agile there is an appetite and passion for change but the myths can sometimes supersede the reality.
For clarity’s sake DevOps is a methodology for ensuring the engagement of all stakeholders of a development project across the whole project’s lifecycle. The main goal, like most development centric methodologies, is to build the highest quality application possible in the most efficient way. As the industry leaders in software quality this is something that we at SQS are very passionate about. Very much like Agile methodologies, the DevOps methodology works best when people have clear roles, there is transparency, full engagement and strong communication in place. This could/should involve Tooling through practices like Continuous Integration and Continuous Delivery, involve cross department engagement through Agile methodologies and ensure that nothing is ever just thrown over the fence between business departments.
One common area we assist clients in is ensuring that the Development process and QA processes are well coupled through Continuous Delivery. Martin Fowler (software engineer, author and international public speaker on software development) describes Continuous Delivery as “a software development discipline where you build software in such a way that the software can be released to production at any time”. By employing these techniques linking an automated delivery mechanism to an automated build process means that releases can be automatically delivered to the QA team. This stops QA teams having to wait around for developers to push releases to testing environments and likewise prevents developers spending time pushing out releases into test environments. With this approach both teams needs are satisfied automatically and they can get on with the business of finding and resolving issues. This isn’t all about the QA process however as the whole project can benefit from these techniques. With these types of approaches the lag between a feature request and making a beta version of that feature available to end users can be dramatically minimised.
These are only small examples of how following a DevOps methodology and applying appropriate tooling can really improve how teams work together, increase quality and improve the software development process. Of course each business is different and, like the experiences encountered in the early days of Agile adoption, there is no “one size fits all” silver bullet. At SQS we have experienced how, by understanding a client’s business model, we can help clients make dramatic improvements to how they operate. These types of successes are the reason why DevOps is the hot topic of the moment. It might not stop people using technological terms and jargon inappropriately but when understood it can definitely streamline your business approach. Hopefully with DevOps we can keep our feet on the ground and stick to the reality rather than letting the myths take over.
Author: Gareth Burns
Gareth is a highly experienced consultant and developer with experience of managing a department as well as working directly with high value clients. Initially specializing in the Microsoft .NET family of technologies Gareth possess a decade of experience developing top of the line on-line and offline solutions for clients.
As head of Development Operations for SQS in Ireland he leads the development-centric strategies and services SQS offer from Belfast and Dublin. As well as supporting local clients in Ireland he also assists clients all over the globe in improving development processes and practices.
He currently consults on Development Methodologies, Continuous Integration, Continuous Deployment, Development Operations and Development Management.