I can see some people reading this right now thinking "well, yes, I am a member of that thing", or "there is no such thing". New tools and the name have caused a lot of confusion around this question. Let's take a look at why things are confusing and why the answer is an interesting one.
Good idea, terrible name
The term DevOps has become overloaded and misused in a variety of ways over the years. Some people still think DevOps is a thing they can buy and "boom", they have DevOps. It doesn't help that it has crept into the names of software packages and tools to make it even more confusing. The principals behind pure DevOps theory are a set of practices that strive to create a culture that can reliably meet the goals of your organization. It is more than just combining "Development" and "Operations". It includes automated testing, security and monitoring. I guess DevSecQualMonOps doesn't have the same ring to it.
Someone needs to bring it all together
Notice I said that DevOps is a set of practices. It isn't really a set of tools. Sure, there are a lot of really cool tools that allow you to accomplish your DevOps goals. Concepts and tools such as containerization, CI/CD pipelines, automated tests etc allow for really nice and streamlined DevOps principals to be accomplished. For example, you can create a CI/CD pipeline that builds your application, packages it into a container and runs a security scan against it and fails the pipeline if a violation is detected. That is shortening feedback loops and giving a developer fast feedback on if they have possibly added a security vulnerability. Ideally there would be some sort of IDE plugin or script that the developer could run locally that would let them know the same results before they committed their code and ran the scan. In this example, who built the pipeline and figured out how to run the security scan? Also, hopefully they created something reusable so all other application pipelines could leverage the same tools without having to reinvent the wheel.
Enter Platform Engineering
To leverage these tools and procedures it takes a team of people to build and maintain them. Now that things like build pipelines and cloud infrastructure are defined and implemented "as code" it means that they can incur technical debt. Software needs upgraded and common things need templated and made available for reuse. Think of it as creating the "yellow brick road" for everyone to follow along their software development journey with the goal being to optimize the developer experience and productivity. The term for this is now called "Platform Engineering".
Enter Site Reliability Engineering
Similar to Platform Engineering, Site Reliability Engineering leverages tools and procedures but to ensure the reliability of the application. This could be in the form of providing dashboards to show the performance and availability of an application by leveraging monitoring and display tools. This could be using software to define Service-Level Objectives (SLO) that software will use to determine if someone needs alerted or if an applications needs automatically restarted. Another example is providing the monitoring to ensure that if a release of the application has degraded stability then it will automatically be rolled-back.
So what is the answer?
If your DevOps team is really just a renamed Operations team then no, that isn't a thing. If your DevOps team provides value in the form of supporting Developer productivity in the form of reusable templates and components then they are probably a Platform Engineering team. If they provide value in the form of site reliability by providing monitoring and tools to better assist production deployments then they are probably a Site Reliability Engineering team. Maybe they are both and can be split into two teams and you got all the way to the end of this article to find out that the answer is "maybe". However, I encourage you to learn more about how the term DevOps has evolved into the creation of "Platform Engineering" and "Site Reliability Engineering".
Top comments (0)