#11 The Rise of 10X SRE

<< Previous Edition: 2 Mistakes to Avoid While Operationalizing a Pull Request

Last week I was at a DevOps conference and met a lot of technology professionals in the DevOps space. What was surprising was that not even a single one of the attendees identified as a DevOps engineer. There were a lot of attendees who identified as site reliability engineers.

How Invention & Innovation Spreads

SRE role was invented at Google exactly 20 years back. Any invention at a hyperscaler first gets adopted by (relatively) smaller technology companies & Independent Software Vendors (ISVs). ISVs are interesting in the way that they have problems similar to hyperscalers but nowhere close to their scale.

The rubber meets the road at the next level of adoption when invention makes it to practitioners. Practitioners are companies whose primary business is not to sell software but to use technology to improve their business operations. Since "software is eating the world", these companies are super-heavy users of technology. They also evaluate every technology purely from the business value perspective.

The Equity & Leveling of the Playing Field

Organizations work best when each member is empowered and respected. Engineering organizations always had a huge class divide between developers and mortals. Mortals included QAs, release teams, production support teams, etc.

The issue of being mortal was that they did not have a right to innovate. They were simply supposed to follow the process. It was demoralizing for folks who were considered mortals and untapped productivity for the organization.

Site Reliability Engineering & DevOps both leveled the field in their own ways by applying software principles and practices to operations. It not only improved the process but also provided non-core developers an opportunity to be more skilled and help in innovation. Now they could also think outside the box and find ways to be more effective than just efficient.

DevOps vs SRE

The simplistic silicon valley definition of SRE is that they are monitoring people. These are the folks who handle issues once workloads have made it to production. In other words, they deal with day 2 problems and make sure SLAs, SLIs, and SLOs are met.

On the other hand, DevOps engineering is to operationalize the developer's work. They are CI/CD people. Their productivity is measured based on metrics like change failure rate, lead time to change, deployment frequency, etc.

The question comes when we need to decide if DevOps is a process or a role. DevOps is better understood as a process while SRE is a role. There is also release engineering as an alternative which is both a process and a role but is not used widely.

The virtue of social mobility

I have yet to meet a QA who does not want to become a developer. A developer who does not want to become an architect. An architect who does not want to become a principal architect. Upward social mobility is ingrained into our psyche and that's what keeps us driven and motivated.

In 2003, with a very tough job market, for a few months, I worked as a business analyst in Austin. It was essentially a QA role with extra focus on business requirements and making sure there were no gaps. I could clearly see how constrained I was in what I could do and how developers were looked at as a different class.

Summary

The rise of the cloud has not only worked as a great disruptor but also as a great equalizer. While agile methodologies provided a framework for how the modern development teams should operate, the cloud made rebuilding the whole technology organization an urgent problem. I see the following convergent patterns:

1. CloudOps or Cloud Engineers will manage infrastructure
2. SRE+DevOps Engineer+ Integration testing+Release Engineering role will merge into one application operator role. There is a high likelihood this role will be called SRE.
3. Developers will remain developers.?>> Next Edition: Ephemeral Environments and the Winds of Change