Beyond the Buzzword: DevOps as a State of Mind
🔄 TL;DR Link to heading
- DevOps is more than a buzzword and involves a set of practices and a mindset.
- Emphasis is placed on shortening software development cycles, automating repetitive tasks, and continued learning.
- DevOps involves integrating and delivering frequently and fostering innovation and continuous improvement.
- It is not just about using tools and processes but taking ownership and running your work.
- Daily work is important, but improving daily work is even more important.
The world of technology is rapidly changing, and so are the buzzwords that come with it. “DevOps” has carved out a distinct and enduring presence, although, for some, it has become just an ordinary “buzzword”. Many organisations have embraced it, considering it a practice to streamline their development and operations processes. However, for me, DevOps is more than just a trend. It is a state of mind, a set of practices, and a philosophy that goes beyond the tools and processes. My journey with DevOps began not with a formal introduction to its principles but as an intrinsic approach to working with technology. It is this journey that I wish to share, shedding light on why I see DevOps not merely as a role but as a mindset.
The Essence of DevOps: A Historical Perspective Link to heading
At its core, DevOps represents a blend of practices and philosophies aimed at unifying software development (Dev) and software operation (Ops). The principles of “you own it, you run it” and “be a boy scout” encapsulate the essence of DevOps, advocating for ownership and continuous improvement. Though formally labelled as DevOps in more recent times, these ideas have been part of the technology landscape for decades.
As a professional working with computers for over twenty years, I have always embraced the DevOps mindset. When people ask me how long I’ve been a “DevOps Engineer, " my answer is always the same: since I started using computers professionally. In the early days, we didn’t have the tools and processes we have today. Still, we aimed to shorten the software development cycle, automate repetitive tasks, emphasise continued learning, and integrate and deliver frequently.
Rewind to the late 1990s, before the term “DevOps” was coined. My foray into the digital world began with the publication of my web page in 1999. This endeavour, albeit simple by today’s standards, was my early encounter with the practices now associated with DevOps. The web page was a professional portfolio for my work as a concert photographer.
The page is still available on Wayback Machine: AlesL Photography
The Pioneer Days: DevOps Before DevOps Link to heading
As mentioned, I published my web page offering professional services as a concert photographer in 1999. While it may seem unrelated, DevOps was already involved in my work. I did web development involving many tools and technologies, starting with WYSIWYG HTML editors like Microsoft FrontPage and Dreamweaver and evolving to PHPEditor and the Smarty Templating engine. This evolution was driven by a desire to shorten development cycles, a cornerstone of the DevOps philosophy. Utilising HTML + Javascript, PHP + MySQL, and ASP + MSSQL was a testament to the continuous learning and skill expansion that are pivotal in the DevOps mindset. Automating tasks, such as image manipulation with ImageMagick, deployment with rsync, and leveraging Linux and later FreeBSD’s jails mechanism, were early practices of continuous integration and delivery.
We were unknowingly laying the groundwork for what would become DevOps. Our efforts were not defined by a title but by a relentless pursuit of efficiency, learning, and improvement.
DevOps: More Than Tools and Titles Link to heading
The proliferation of DevOps in recent years has seen a surge in professionals labelling themselves as “DevOps Engineers,” armed with expertise in an array of tools designed to facilitate the DevOps process. However, the essence of DevOps transcends mere tool proficiency.
Despite their claims of DevOps expertise, I’ve observed instances where developers exhibit a lack of ownership and a reluctance to engage with the challenges that arise in the development process. The schoolbook example is posting screenshots of failed pipeline builds on a Teams/Slack channel with the caption “Can someone fix this!”. How hard can it be to take a peak at the pipeline logs? The ethos of DevOps—innovation, responsibility, and continuous improvement—is conspicuously absent in such scenarios. This disconnect highlights a fundamental misunderstanding of DevOps as mere tools rather than a holistic software development and operation approach.
DevOps: A Mindset, Not Just a Methodology Link to heading
The true spirit of DevOps lies in its philosophy of ownership, collaboration, and continuous learning. It’s about embracing challenges, diving into the logs to understand failures, and viewing every obstacle as an opportunity for growth. DevOps is not confined to specific roles or technologies; it is a mindset that can transform how organisations develop, deliver, and maintain their software. Adopting DevOps is more than just implementing tools or hiring individuals with “DevOps Engineer” on their resumes. It is about fostering a culture where every team member is committed to improvement, innovation, and accountability.
In conclusion, my journey with DevOps began long before the term was popularised. It is rooted in practices and principles that have withstood the test of time. Let’s look beyond the buzzword and embrace DevOps as a state of mind. It should be about owning and running your work, being a Boy Scout, emphasising continued learning, automating repetitive tasks, integrating and delivering frequently, and fostering innovation and continuous improvement. And last but not least, improving daily work is more important than doing daily work.