DevOps? Just say Developer Operations? - SinC(n9)

Are they still what we think they are?

Let’s SinC(n)

Developers to do the Operations

---

The first time I heard phrase “DevOps,” I thought, what is this? Yeeeahh, I do that, I do that every day; I’m an engineer. But, is this a role? For what? Why? Okay, maybe this will make my life and the entire system better. But how consistent is this role / group’s impact? Are they really delivering on their promises, or is it just more dummies validating their own existence? Psst!!! You know Ai has a place here too 😍.

DevOps is supposed to help the developer’s experience, right? To provide support in our dynamic, ever-changing environments.

Over time, I question if they’re still aligned with how Squads and other engineering groups have evolved.

Some of the work I originally did as an engineer is now being passed back to engineers. Does DevOps have new responsibilities? What should the new ecosystem look like?

DevOps is short for Developer Operations, coined around 2009. It was primarily defined as a cultural shift aimed at improving collaboration between development and operations (platform teams). The goal was to break down silos, automate tasks, and accelerate the software delivery cycle.

• Platform Teams in Engineering: Platform teams build and maintain the foundational systems, tools, and infrastructure; Operations. This enables Squads to develop, deploy, and scale applications more efficiently.

• Squads: Squads are small, cross-functional teams that operate autonomously within an organization.

• DevOps 2024: While still rooted in cultural collaboration, DevOps has evolved into a comprehensive approach that includes a wide range of practices, tools, and roles like SRE and Developer Experience, with an emphasis on continuous integration, delivery, deployment, and overall automation across the software lifecycle.

Recently, I was pulled into a meeting to discuss the improvement of CI/CD. This could surely enhance our collaboration and efficiency. But halfway through the presentation, it started to sound like, “We [DevOps] don’t have the time or resources, so can the engineers do it?” I could be wrong in my feelings, but in engineering, the environment is ever-changing. You have to adjust to your industry standards, company initiatives & the global tech industry recommendations for better execution. ALL of it!!! Let’s be real; every organization has a tech department, a group of people doing tech things. This makes engineering a vital part of every organizational structure that leans heavily on Conway’s Law, which is reflected in our code, processes, and delivery.

• CI/CD: Continuous Integration and Continuous Delivery/Deployment. A set of practices that automate the integration of code changes and delivery of software updates, ensuring faster and more reliable releases.

• Conway's Law: The principle that an organization’s software architecture reflects its communication structure, meaning the way teams are organized influences how the code is structured.

• SRE (Site Reliability Engineering): A discipline that applies software engineering principles to infrastructure and operations, with a focus on ensuring the reliability, scalability, and performance of software systems.

• Developer Experience (DevEx): The overall experience and satisfaction of developers with the tools, processes, and environment provided to them, aimed at improving productivity and reducing friction in software development.

• Architects: In engineering, architects are responsible for designing and overseeing the overall structure and strategy of software systems. They ensure that solutions align with business goals, technical standards, and security requirements, guiding development teams to build scalable and robust applications.

Does the current DevOps role owners know what they’re doing, or are they just passing off work? Or are they truly collaborating on the new world of tech methodologies, Ai, and industry? Here’s my thoughts:

Experience of the Developer

Feels like a mistake to me, but this might be slightly outside of my scope of experience. Yes, DevOps tasks were handled by engineers when I was just coding. It was a pleasure joining a new organization and hearing, “Hey, you don’t have to do that anymore; DevOps has got this.” However, being at a medium to large organization that still tells squads they need to interface with production frequently and end users seems like a problem waiting to happen. The statement “teams should own everything” has too many parameters to decipher. Sure, they do, but that’s a matter of scale, which is why we adjust how we do things.

Alignment with Evolving Engineering Practices

In a smaller organization, such as a startup, the squad’s responsibilities are naturally broader. As the organization grows, like patterns in code, we separate concerns and responsibilities. This is where operations come in to help squads with delivery. But it’s not only about delivering; it’s about the entire management process that squads aren’t equipped for. Take a platform like Instagram, which may have 5 squads supporting different parts of it. These squads should be solely responsible for their respective parts. However, the entire platform should be managed by DevOps to ensure these squads don’t put crap into production for the end users, along with any other supporting processes or guidelines to achieve this goal.

The New Ecosystem and AI's Role

They’re here to protect our squads, to ensure they have a great experience building code and fixing problems. But when you give engineers a pinhole into production of an application like instagram in the name of responsibilities, it puts the entire organization at risk of issues in production. In a medium to large organization, squads should focus on their specific application parts. Architects are there to help them verify that everything meets the architecture, security, and guidelines set by DevOps. This creates a new team; a collaboration between the squad, the architect, and DevOps; working together for delivery and managing outages. It’s not about putting all this responsibility on squads that don’t have sufficient access. It seems like, at my org, DevOps are glorified architects who sit on their thrones and point, while engineers scurry around asking for permissions and solving the issues.

This is another area where Ai can totally help is by handling common tasks, which can truly improve the Developer Experience; actually, all experiences. Take the DevOps principles and lay out a plan. Here’s the thought:

• Train AI on all things DevOps, including:

  • Managing applications

  • Infrastructure

  • SLOs, SLAs, limits, and thresholds on services

• Alert engineers and squads as a whole when these boundaries are reached.

• Be the first responder and provide suggestions for common problems.

• Allow DevOps teams to focus on managing the DevOps Ai, freeing up time to:

  • Mentor engineers on the ecosystem

  • Create more human connections to fill the gaps

---

Your thoughts matters to me, please share a comment, ❤️ below or pass this article on to someone who might benefit.

---

---

You’ve made it till the end…fantabulous❤️

• Looking for deeper support? I offer personalized Achievement Facilitation to help you reach your goals; DM me for more info.

• Featured: Keila (KJ) Aartila

• If you found value in this and would like to support in ways beyond subscribing; whether through a donation or other forms of contribution. Feel free to reach out to me directly.
  
  …and as usual follow me on social media if you want that smoke 💨.