Core Services
Rapid Software Development
Application Modernization
Expert Services
Product Design
Platform Engineering
QA Automation
Data & AI
Advisory Services
Technical due diligence
.svg){kind=small}
M&A Lifecycle
Go back
Around 2007 a movement started in online forums when software engineers (builders) and operations teams who keep systems alive (operators) started highlighting the severe dysfunctions in how software is shipped and run. I call them 'the DevOps pioneers.' In a scenario where the digital world borrowed several concepts from the industrial world, these dysfunctions were apparent but easy to ignore.
However, these like-minded individuals recognized the need for rehabilitation of how software is shipped and managed.
Two trends were emerging from the chaotic and pressure cooker business environment of that time, which I might argue is still the case:
Traditionally there have been two distinct phases in software development - (1) Development & (2) Operations supported by 1) People who think software is IT 2) People who think infrastructure is IT. These siloes in teams and mindsets resulted in opposing agendas, blame games, poor work environment, and adverse impacts on the business. Edward Yourdon's book 'Death March' captures this very well. With software playing a role in critical parts of companies' and peoples' lives, something had to change.
How people develop software needs to be in lockstep with how it will be used. Neither the builders nor the operations team are the eventual users of the software. When things went wrong, and they always did, the blame games and the throw-it-over-the-fence culture became prevalent.
The concept of deep collaboration between the 'builders' (software developers) and the 'runners' (operations teams) emerged out of the discontent of these DevOps pioneers who started talking about this online and in local meetup events. The overarching question in their minds was this
"How do we test and launch digital products that are highly reliable at a faster pace to keep up with the chaotic and fast-changing business environment and market needs without killing ourselves?"
It was supposed to be a significant harmonization of different cultural practices, philosophies, and tools that would enhance an organization's ability to build next-gen apps and software solutions that can revolutionize the digital space.
DevOps then quickly evolved into the harmonious working of the development and operations engineers in the entire project lifecycle, from the design and development process to the final product release and after support. These two teams are usually integrated into one where the engineers work efficiently, exhibiting a range of skills that are not just limited to a single function.
As DevOps models continue to evolve, quality assurance and security teams also find it beneficial to be cross-functional and have collective accountability rather than being siloed - DevOps, DevSecOps, SecOps, etc.
The collective accountability, single mindset, and high degree of collaboration meant faster software and increased reliability. It also meant people began to learn cross-functional skills, learn the challenges of each other's jobs, and become more empathetic.
These benefits quickly spread like wildfire, given the fantastic success of unicorn startups that changed the world we live in. The rest of the technology industry started taking notice, and these early adopters became the stalwarts and sought-after.
With these concepts, the reality of the simple act of combining two siloed organizations and setting a common goal as one team, DevOps was on its way to becoming mainstream without a doubt.
The alliance between developers and operations teams focuses on minimizing inefficiencies. The more efficient the process, the shorter “order to ship” time. The purpose is to produce a product quickly without sacrificing quality, so spending time pointing fingers inherently becomes counterintuitive. Imagine a world where your washer and dryer were more focused on bickering than cleaning your clothes. That’s where the stagnation occurred before DevOps. But how did we go from this counterculture argument to a standard inclusion in organizations’ portfolio?
It’s been a journey, albeit a fast-paced one. The process needed fine-tuning. This led to the rise of “Lean Manufacturing,” Agile, and other methodologies. Organizations were finding new levels of quality, minimizing deployment time, and utilizing innovation to a greater degree. All because this partnership between engineers and operators bloomed. The results were undeniable. This continuous maturation saw IDC forecast the DevOps market reaching $8 billion by the end of 2022. Sliced bread may have seemed strange at first, but once you have that perfect sandwich, all questions disappear. DevOps is here to stay, so maybe it’s time to embrace the change. A survey by RedGate Software noted that 74% of organizations are now utilizing DevOps in some capacity. This is no longer a fad, but a verified form of improvement that can benefit organizations.
Although the intent is right, a flexible concept such as DevOps tends to get mangled by people who misinterpret, misconstrue, or simply pretend to understand the intent. As a result, the reasons for poor outcomes are blamed on the concept itself. This is not unheard of when new concepts and principles arrive in the market.
Examples of poor implementations of DevOps are all around us. When survival of the fittest is a determining factor, organizations will alter and misuse anything at their disposal to stay afloat. DevOps wasn’t meant to be a one-stop shop, but that’s what it’s become for certain entities. There doesn’t need to be a jack-of-all-trades, master-of-none approach. Expertise and knowledge are commodities within this space. However, stretching your greatest resource, your team members, too thin won’t lead to the promised land. DevOps is an imperfect space constantly being reinvented. If organizations want to truly benefit from DevOps, then it needs to take on a form unique to them. Copying and pasting what works for others may not work for you. The best implementation of DevOps possible comes from the innate understanding of how the organization will benefit from it. Set it up your way, and the difficulties associated with this approach might not be as common as you believe.
The fundamental function of DevOps likely won't change. Still, new processes and procedures are inevitable. Companies around the globe still search for the best way forward with DevOps. Artificial Intelligence and automation will continue to influence the trajectory. AIOps as a term has already been coined. Additionally, the usage of data science will only increase as organizations seek new levels of efficiency. The continued integration of DevSecOps (DevOps with an emphasis on security), GitOps (a nuanced infrastructure trend involving Kubernetes), and other collaborative structures will also pick up pace.
DevOps' success as an entity has highlighted the need for multidisciplinary teams. Monopolizing these units will be a focal point moving forward. How? That is unclear, which leads to the overarching theme of most articles involving DevOps. The emphasis is on the journey, not the destination. These teams' rapid expansion has seen unprecedented levels of efficiency, quality, and innovation. It's impossible to truly pinpoint the final form of DevOps, but its usefulness begs for further investigation. The form, label, or structure used matters less than the philosophy overall. Buckle up, and enjoy the ride. The unknown is meant for exploration, and this includes DevOps.
If you're interested in an audio version of this blog, look no further! Here is a narration of the above article, so feel free to check it out. No matter if you're at home, in the car, or lounging at a park the history of DevOps is one to be explored!
.webp)
