↓Skip to main content

Let's Talk SRE and Systems Engineering

·2 mins

Let’s talk modern Network Operations, Systems Administration, and Systems Engineering. Not in the specific, but as general roles in a modern team.

About 15 years ago, these 3 distinct roles got combined under a single title, called “Site Reliability Engineer” (SRE), which basically was a focus on bringing software engineering (I know, I know) principles to what was a more site specific, often environment specific, infrastructure. The end goal being resilient, holistic approach to handling system, software, and network infrastructure lifecycles, and overall availability of the site; often incorrectly being assumed “website”, but really it’s lower level than that.

In turn, the SRE role created the need for Development Operations (DevOps), in which development (software engineering) principles are used to automate the deployment and operational lifecycle for software or a service. Effectively making the software development team part of the operational lifecycle for software.

The interesting thing here is that a modern SRE is now a generalist, much like a System Administrator was in the late 90s: a network engineer, a UNIX Systems Administrator, UNIX Systems Engineer, and infrastructure architect, all rolled in to one single title, often a single team member. And the SRE’s counterpart, based in a unwritten philosophy of Mutual Assured Suffering, is the DevOps engineer, who has basically inherited the unenviable role of dealing with software on the system, deployment of said software, and attempting to deliver their app in a controlled, and hopefully sane, method.

These new roles indirectly created what is basically became huge service boon: containers. Why deliver the service to hardware with underlying libraries, potentially different releases, differences in behavior, networking, full operating systems, when the option to just deliver a container, and ensure repeatability exists instead? Why bother with a full system when what’s really required is much easier: reliable networking, some disk for the application, and the ability to define those requirements in a repeatable and isolated fashion?

In effect, this recreated a new dividing line: Infrastructure (SRE), and Applications (DevOps), with a focus on Service Teams that rely on the infrastructure being available and scalable.

And, in turn, created a new opportunity for cloud providers: managed infrastructure to build, and deliver, for just the service teams.