written by E.G Nadhan
E.G.Nadhan has 25+ years of experience in the IT industry selling, delivering and managing enterprise solutions for global enterprises. As the Chief Technology Strategist for the Central Region at Red Hat, he works with the executive leadership of enterprises to innovatively drive Digital Transformation with a healthy blend of emerging solutions and a DevOps mindset. He also provides thought leadership on various concepts including Cloud, Big Data, Analytics and the Internet of Things (IoT) through multiple channels including industry conferences, Executive Round tables as well as customer specific Executive Briefing sessions.
DevOps is a way of life for people with the right mindset to embrace the culture of collaboration while scientifically automating the continuous delivery of software features with the rigor and discipline of continuous integration, and a passion for continuous testing while using the power of standardized tooling to continuously monitor everything being done. Huh? You say? Well, I compiled this definition based upon myriad interpretations that I have come across in my interactions with my peers, customers, partners and service providers, not to forget my colleagues over social media. While practitioners strive hard to drive consensus, multiple interpretations abound even though the terminology is consistent. A word-cloud around all these interactions surfaces the usual suspects quickly. Allow me to highlight each aspect that contributes to this definition. And, by the way, feel free to tweak the definition as you deem fit – your comments are welcomed.
Culture of the enterprise. “You can use as much DevOps as you want”, was the quote I heard from one of my co-presenters during the Gartner ITXPO Symposium, the last fall. DevOps is about striking a balance between the desire for agility against the need for stability. Generally, the culture of the enterprise can strongly influence which way the balance tilts and by how much. Culture is also influenced by market forces, change of leadership and employee behavior. This brings us to the next aspect, people.
The Mindset of People. It all comes down to people. There are segments of the workforce who may be more comfortable doing what they have been doing for years together, and may be less prone to change. On the other hand, there could be a whole other segment who are all about introducing new paradigms and business models enabled by technology solutions perceived to be cool and enticing. Fundamental concepts like the willingness to work as a team towards a common goal are best driven by people with the right mindset — a mindset of collaboration.
The Art of Collaboration. Collaboration requires the workforce to reach across the table and assume the positions of the very individuals they are dealing with. Development teams need to think ahead and take proactive steps to ensure that the management and operation of what they are building is smooth, robust and stable. Operation teams must respect the need for the rapid injection of consumer driven features. Both teams must collaborate and have open exchange of information with the common goal of IT meeting the expectations of the business users. And the IT personnel must work together to inject the right levels of automation towards this common goal.
The Science of Automation. Automation is not just about using tools to do repeated tasks. The science of doing automation right is all about ensuring that the right processes are being executed in the right way in the first place. Automation of the wrong processes or processes being executed in the wrong way only proliferates more problems. The Science of Automation can also be applied to business processes too. Automation must be done in increments across logical subsets of process steps that are part of a continuous engine.
The discipline of Continuous Integration. DevOps is a way of life. It is something that is done in continuum like a smoothly operating engine in constant motion. This spirit of continuity applies to the integration of isolated changes to the larger code base on a daily (or more frequent) basis for a build to be conducted with each change. Active collaboration is a key catalyst to have developers integrate their work with other developers frequently which promotes early detection of problems – just what the Testing team ordered!
Passion for Continuous Testing. I will say that this is one term that I have not heard as often as I would like to. CI/CD. Got that. What about CT? The spirit of collaboration is the hallmark of the DevOps mindset and testing is everyone’s responsibility. To fail-fast, testing must begin early in the life cycle starting with software requirements, the architecture, design, with source code reviews, and unit testing by developers to deliver error-free code along with test data sets. With the common goal of delivering a timely and meaningful solution, development and operations must work together to configure the testing environment to be as close to the production environment. And while we are at it, testing is a fine process to be automated! With meaningful automation and relevant test data sets, regression testing can almost become a perfect science — which is what it would take to address the need for Continuous Delivery.
In the words of one commentator, “continuous delivery is nothing but taking this concept of continuous integration to the next step.” Instead of ending at the door of the development lab, continuous integration in DevOps extends to the entire release chain: including QA and operations. The result is that individual releases are far less complex and come out much more frequently.
The actual release frequency varies greatly depending on the company’s legacy and goals. For example, one Fortune 100 company improved its release cycle from once a year to once a quarter—a release rate that seems glacial compared to the hundreds of releases an hour achieved by Amazon.
Exactly what gets released varies as well. In some organizations, QA and operations triage potential releases: many go directly to users, some go back to development, and a few simply are not deployed at all. Other companies, —Flickr is a notable example, —push everything that comes from developers to users, and count on real-time monitoring and rapid remediation to minimize the impact of a rare failure.
The Need for Continuous Delivery. The concept of Continuous Delivery can be best described using healthy eating habits. All too often, I have heard about eating smaller portions more frequently than large meals which are widely spaced apart. It would almost seem like Enterprise IT, and by consequence, the business is looking for more frequent and continuous release of new features very fast. These firms go to the extent that they are also willing to accept the potential downside of occasional hiccups as long as they are quickly fixed. The steady stream of new features is a significant shift in mindset that has permeated to the business. Is business going DevOps?
A System of Continuous Monitoring. The only way to effectively inject the fail-fast mindset with rapid-fire releases of features is through continuous monitoring across the lifecycle, from development through operations. A challenge very often encountered is the proliferation of environments and platforms that need to be monitored. The only way to combat this rising force of technology proliferation is through ruthless standardization of the applications, platforms, and yes, tools.
The Power of standardized tooling. And finally, here we are, tools. Yes, we absolutely need the tools to do many of the activities discussed above. A connected suite of tools form a tool-chain of sorts which seamlessly integrates the DevOps life cycle. However, tools are not the first thing to be addressed when it comes to DevOps. Also, standardization of tools goes a long way in simplifying the business of IT while injecting healthy levels of purposeful automation with reusable processes.
There you have it. DevOps is a concept which can be clearly defined if the salient aspects are addressed in the order in which they are outlined above.
What is your opinion? Are there other aspects that would apply to DevOps?
What is your definition?