What DevOps Is
Around the year 2007, a systems architecture consultant named Patrick Debois was frustrated with the incongruence between developers and operations teams. It was during this time that he was trying to formulate a better way for developers and operations teams to work more symbiotically. A few years later, John Allspaw and Paul Hammond gave a talk at the 2009 O’Reilly Velocity Conference called “10+ deploys per day: dev and ops cooperation at Flickr.” The Velocity Conference brings together engineers focused on exchanging ideas about what works best when building and maintaining complex cloud-native and hybrid systems. It was with this talk that Patrick was able to resonate with the issues revolving around getting dev and ops to work harmoniously towards a common goal. After the 2009 Velocity Conference, Patrick organized a conference called DevOps Days in Belgium of the same year, where the entire conference was dedicated to sharing hard-won lessons in the pursuit of a better way for dev and ops to work together. It was after these two conferences that the term and philosophy of DevOps were formalized and eventually iterated to become what it is today.
DevOps has roots in the Agile methodology, which has its roots in the Lean Manufacturing movement. DevOps focuses on maximizing efficiency, identifying programmable processes, and increasing automation. Agile has a fail-fast mindset while centering around adaptability and keeping pace with customer needs. The DevOps philosophy helped solve the issue of dev, ops, security, QA, and testing teams still working in silos, which wasn’t addressed by the Agile methodology. But, using an amalgamation of both philosophies has made tremendous strides from the days of the waterfall methodology. Teams that practice DevOps ship better work faster, streamline incident responses, and improve collaboration and communication across teams.
What DevOps Isn’t
Let’s get straight to the point–DevOps is not a role or a position. No matter how many times you see ‘DevOps Engineer’ in job postings, it is a play on the hype surrounding DevOps. The job description lists the responsibilities a Solutions Architect or a traditional Systems Administrator would carry out–with a more cloud-centric focus. DevOps is a culture, a philosophy, and a way of organizing and executing processes. These philosophies can be adhered to by dev, ops, testing, QA, and security engineers working as cross-functional teams.
However, the evolution of DevOps has opened the door to new specialized roles: Site Reliability Engineer (SRE) and Platform Engineer.
Site Reliability Engineer (SRE)
The term Site Reliability Engineer (SRE) was coined by Ben Treynor Sloss, the VP of Engineering at Google. Some people mistakenly assume SRE is DevOps 2.0, but this is not true. DevOps as a philosophy, allows organizations to deploy applications faster, which results in a more optimized application lifecycle. SRE, on the other hand, is about optimizing the reliability and availability of systems, sites, and running applications. So, site reliability follows the principles of DevOps to accomplish its task.
Before the advent of cloud service providers, organizations relied on system administrators to deploy software and manage data centers. These responsibilities included setting up storage, networking, security, backups, etc. These are responsibilities we now associate with operations. While, software developers were responsible for, well, developing software. Today, with cloud environments, everything is a software problem with a software solution. The goal of an SRE is to keep our applications available and reliable as much as possible through software solutions with automated processes and observability. This fits in with the DevOps mindset. Therefore, an SRE is not DevOps 2.0, but a specialized part of the DevOps philosophy. You could say that SRE is a specialized evolution of doing operations. Previously, operations were done in a particular way that may not have always led to satisfactory results. SRE incorporates a more software engineering aspect to operations and infrastructure problems, but still adheres to the DevOps principles.
You can think of the relationship between the DevOps philosophy and the role of an SRE like our fancy cars today: all the engineering behind keeping our cars moving from point A to point B is DevOps, while the sensors that notify the driver that the car is drifting out of the driving lane is site reliability. In essence, site reliability ensures our applications continue to run and course corrects when the unexpected happens. Now, what is a Platform Engineer? How does that role fit into the DevOps philosophy? I’m glad you asked.
A Platform Engineer is another specialized role that is part of the DevOps philosophy of automating and delivering applications in a faster and repeatable fashion. They improve the developer experience and developer productivity by providing reusable autonomous service capabilities, such as tools and workflows to automate parts of the infrastructure without the operation team’s involvement. An example tool could be a CLI that allows the developer to create separate dev, stage, and production servers. An example workflow could include a source control system connected to a continuous integration system, along with a way to deploy assets into production.
Platform engineering is found in large organizations with complex application lifecycles. The platform engineer creates and centrally manages reusable tools and workflows which the developers use to do their job. You can think of these resources like using Canva. Canva provides templates, tools, and resources to create design assets that would otherwise be more difficult to create using Adobe Photoshop, as Photoshop expects you to start from a blank canvas. This is similar to the benefits that platform engineers provide developers. It allows developers to accelerate the delivery of applications and provide faster business value through the use of centrally managed tools and workflows allowing developers to act fast and independently through established systems.
The DevOps Evolution
The new roles that DevOps has created, address the challenges of doing DevOps at scale by aligning developer practices with business values and reducing the complexity of modern software lifecycles. DevOps is a broad movement that began with a focus on eliminating traditional silos between development and operations. While we have new roles within DevOps, they are intended to allow more interoperability between teams rather than create new silos. The new roles are an evolution of DevOps, rather than a revolution.