So you’ve got your agile team, perhaps even a couple of successful projects on their back. What could be next? Well, there’s a whole world waiting in the fields of DevOps and Site Reliability Engineering (SRE).
While DevOps refers to the process of maintaining an continuous and reliable delivery stream, SRE refers to a specific role within a development team, which ensures that the product can function as a service that can be relied upon, which also includes DevOps.
Looking at the big picture: A website as a service
When a website or application becomes something that users need to use frequently to accomplish tasks, it strays from the denomination of “product” and starts to become a service. While products should be of high quality and reliable on their purpose, services also have their own scope of quality and reliability. When it comes to software, a high quality piece of software is at least fast, secure and accessible. On the other hand, reliability means that users can be certain that the system will not fail, even if it takes a while to accomplish its tasks. Development starts by making the software able to complete a task. Later, the issue evolves and use cases represent a different set of requirements.
Agile development allows to streamline manageable tasks, but at a higher level, agile falls short. That’s where DevOps and SRE come in. DevOps comprehends all the tools that developers can use to continuously test the project and add new features without breaking the whole system apart, while SRE refers to ensuring that DevOps is done right and that the system is always on an functional state.
While DevOps is a task where the whole team participates, a software reliability engineer needs to be a single person that’s on the lookout for new possibilities and unexpected bugs that may surface, such as version conflicts and compatibility issues.
Many times, the terms seem interchangeable – but they’re not
Clients that are not quite clear of the roles within software development tend to think that SRE and DevOps are the same thing. When in doubt, just remember that DevOps looks into automation and actual development tools, while SRE is more akin to system architecture, where matters like hardware, networking and project scaling are more important. In smaller projects, the tasks of DevOps and SRE are usually assigned to a same person.
Site reliability engineers are expected to create their own set of tools for each particular project. Oftentimes, a single site reliability engineer can work with many development teams, each with their own set of standard practices and architecture requirements.
Just like in DevOps, one of the most important tools that serve towards SRE are delivery managers, like Mesosphere or Kubernetes. These are cluster orchestration systems, which allow teams to deploy containerized applications, scale deployment, update and manage software versions, and debug in isolation without damaging the whole system.
Today, users want web services to be available at all times, while developers want to be able to deploy new versions at all times. SRE’s purpose is for both needs to be fulfilled, as the service is expected to experience zero downtime. The prime example is Google, which is also the author of the role of site reliability engineer. Google needs all of their services to be working continuously, while also delivering regular updates. Any downtime means a loss of revenue for every user involved. This is why site reliability becomes critical at some point. Of course, it is not for every single project, but it is easy to see that projects that are meant to scale will require a specialized effort to maintain them effective at all times.
