According to Darwin's Origin of Species, it is not the most intellectual of the species that survives; it is not the strongest that survives; but the species that survives is the one that is able best to adapt and adjust to the changing environment in which it finds itself.
In my two previous articles, I discussed the principles of the SRE and DevOps. The observant may have noticed that the principles are similar, with a lot of overlap. This isn't by mistake;
Many are the same or extended...
To refresh on the principles of both, please see the previous articles:
What is DevOps? https://www.serverdevs.com/post/what-is-devops
What is an SRE? https://www.serverdevs.com/post/what-is-an-sre
As shown in the diagram above, most principles from SRE and DevOps align:
Tooling To have the right tools is critical to success. The tools you have access to define what you can do and the speed you can do it at. That said, we don't want to spend time unnecessarily searching for ultra specific tools, when we have access to tools that are capable of doing the job well enough. Just enough from SCRUM can be applied here. Additionally, remember that culture trumps tools. Having an API (Common way to interact with a system) will outlast any user interface put atop of it.
Ownership Collaboration is at the forefront for DevOps. A codebase that is open and accessible to the whole development team enables collaboration, inquisition, and scrutiny. This extends to an SRE, but the SRE extends past the team boundaries into other parts of the business which allows them to share knowledge of how the system is built.
Change is necessary and Continual Change A business will always need to change based on market conditions, competition or customer demands. These are best released via DevOps; through small, automated and tested changes. It's critical for the SRE to manage this, so that they are able to respond to incidents caused by any changes and build-in protections to minimize how often these incidents occur and their impacts.
Measurement Changes need to be measured to know whether they had a positive or negative outcome. From a team perspective, they need to measure the work they are doing to be able to predict their efficiency in the future. SRE are focused on SLOs where measurement is key. You cannot improve something if you do not know how it performs now. All of these measurements feed back into the business and give an overall view of the company's ability to adapt.
Blameless Sometimes bad things happen and we need to figure out why. DevOps and SRE both support the blameless post-mortems. This is in order to get to the root of the problem quicker, putting ego and actor aside.
Holistic It is encouraged for all members of the team to get out of their comfort zone. For instance, a testing engineer should be prompted to get familiar with the database and viewing values as they are inserted. Each team member isn't required to be an expert, but rather to have a high-level understanding of the different components in the stack. Knowing this, they will know who to turn to if they have any questions. An SRE is a seasoned professional and will have likely worked in a number of roles in a team, such as a backend engineer and a platforms engineer. They will be capable of making sense of most of the code across the stack and have the ability to modify or at least know enough to seek out an expert.
Where DevOps differs
DevOps is focused on a wider area than SRE and is a philosophy that applies to all members within a development team. DevOps is concerned on breaking down barriers, enabling collaboration and thus increasing efficiency. It is also responsive to the context it is applied to.
SRE
SRE is not a philosophy. As with DevOps, it has its own set of principles. But it is a role that someone performs. It focuses on the systems and how reliable they are for the end-users. This means that the role is opinionated on how best to meet the goal of reliability (opinionated intellectual framework). The reason SRE promotes CI/CD is not because of the business case, but for the three R(s) (Reliability, Repeatability, Reproducibility). Having a process that takes the same input and reliability reproduce the same output repeatedly. Meaning there is less surface area to analyse for an issue.
Conclusion
The main takeaway is to remember that both SRE and DevOps although completely separate, could very well be used in isolation; however, put together, they have a lot of commonalities & overlap. The overlap isn't because they are the same, it's because they believe in the same thing for different reasons.
Commentaires