Today, I’d like to discuss a long-standing debate that has been ongoing within technology organizations, where leaders often find themselves at a crossroads when deciding which model to adopt for their organization. This debate is related to DevOps vs the Development and Ops model vs embedded SRE. I know many of you are thinking, 'Yet another write-up about this debate,' but hear me out. Having been in organizations that followed all of the above, I can shed some light from my own experience.
Development and Operations model
Infrastructure teams are responsible for building the infrastructure based on the requirements provided by the development teams, often without having much context about the business domain. This leads to churn and slows down development teams due to back-and-forth communication, presenting a velocity challenge. Development teams, on the other hand, are frustrated because they can’t move fast. In this model, when there’s an issue, both teams are engaged at the same time, even though the problem may be related to only one domain, and sometimes it can be an amalgamation of both, causing burnout for both teams. Postmortems do not yield fruitful outcomes, as both teams are siloed, resulting in their own takeaways, which may or may not address the problem at hand to avoid future recurrence.
DevOps model
The DevOps model usually means merging both development and operations throughout the application lifecycle to break silos and deliver software as a whole. This model works well until it doesn’t, and I’ll talk about when it works and when it doesn’t.
Let’s take an example of a team with 8 to 10 developers working on applications that are deployed as part of a product.
The integrated operations team members usually do the heavy lifting upfront by setting up code repositories, CI/CD pipelines, and building the infrastructure where the application will be deployed. All seems to be working well until this point. Then, when the application is deployed into production, the operations engineer again works on setting up operational dashboards to make sure the application is monitored if there’s an issue.
Now, since the application is deployed to production, the infrastructure engineer doesn’t have a lot to do. However, all of this changes if they’re not just an infrastructure engineer but also a developer. In that case, they can go back to contributing to the team’s codebase along with managing infrastructure and operations. If they’re purely infrastructure engineers, they need to find another team they can help with.
Another approach is having developers manage both development and operations. This is a big challenge, as they need to cover a broad range of topics including pipelines, infrastructure, security, development, and operations. This increases cognitive load and is usually hard to sustain. This is not to say it cannot be done, but teams often struggle with simple infrastructure problems that would be obvious to operations or infrastructure engineers. This model usually leads to high operational load, which burns out team members and leads to high churn, in turn causing instability for teams and their associated services.
Embedded SRE Model
The embedded SRE model usually means an engineer with an infrastructure background works with application teams in an away-team model while still being part of a central team. They are SMEs for everything related to infrastructure and platforms used by application teams to deploy applications, and they usually have domain expertise in a set of services. If issues arise, they are the first to respond and triage before engaging the application teams. In this model, SREs are the guardians of availability, and developers are rewarded for pushing out new features. Whenever a new release happens, SREs need to sign off on the release before it is deployed to production, and if there is any regression or negative impact on SLAs, they push back on the application teams, thus protecting the customer experience. Teams are usually happy with this model, as they own their specific domain within the application lifecycle. This approach typically works well for teams that follow the traditional model and are working toward a DevOps model.
Conclusion
At the end of the day, these models aren’t rigid boxes we have to stay in. They are really just milestones in a company’s growth. If you are looking for a way to stop the burnout cycle without losing your competitive edge, I believe the embedded SRE model is the best path forward. It works because it treats people like partners instead of just tickets in a queue. When an SRE is actually part of the team, they understand why a service matters to the customer. That makes troubleshooting feel like a shared mission rather than a frustrating handoff. This model protects developers from getting buried under operational noise, and it ensures customers get a stable product. By bringing SREs into the fold as allies rather than hall monitors, you create a culture where shipping fast and staying reliable are not at odds. They simply become two sides of the same coin and define how the team gets things done.