Do you know when DevOps was introduced to the market and when SRE came into existence?
Everyone knows that DevOps is all about Dev and Operation team’s collaboration with CI/CD technique to achieve automation in application delivery. Many organizations moved their sysadmins to DevOps team framework to reap the benefits of DevOps.
DevOps word first came into existence in 2009 and gradually took its position in IT operation and deployment management. Most of the companies still in phase to move their sysadmin teams to DevOps model and major migration percentage are completed.
DevOps helped to create a milestone in IT operation and infrastructure management and still one of the important components of it and still continue to evolve and giving its benefit to the industry.
But suddenly IT giants started listening about new buzzword SRE. I heard this word first in 2011 during one of my interview round where that organization was looking for SRE engineer and at that time I was just relating this word to traditional sysadmin role where I was assuming that team will be having responsibility to manage a complete site like management of one DC or one region where company-owned infrastructure will be hosted and I refused that role as at that time it sounds me similar to sysadmin role whereas I was looking to move into cloud market during those days.
Sometimes my colleagues ask me why there is so importance to SRE engineer and why people are looking SRE’s to handle IT infrastructure.
I normally answer them with these words, “DevOps word is gaining much hype and major cloud vendors are also using it as a key element while selling their services and SRE term was coined by Google 2 decade ago where they never used sysadmin word during their hiring process as well as in managing their IT operation work and greatly managed their big IT infrastructure with SRE framework where they reliably delivered their services in a scalable manner. Google is having a battle-tested SRE framework that can be easily adapted by any organization to make its services available and reliable. In addition to that, Google is trying to get cloud market share and using its own coined SRE word to tell IT market that they managed to build and handle such a mammoth infra and can provide same to their customer hosted on GCP. I might be thinking small when I am telling that they would like to use this word to gain GCP market. But when I think big, it seems that they are exposing internally used best practices to the world to handle challenges faced by current IT market and helping the industry by disclosing all aspects of it.”
NOTE: Before you read the following content, I would like to repeat that it is for those organization those are already matured on DevOps automation part(CI/CD) and even it can be applied where it is not 100% compliant but it can be applied on case to case basis in non DevOps matured organization.
But after working in development, sysadmin, DevOps and finally SRE role I am able to differentiate among all roles and able to tell you the importance of each role so I would like to give you some experience to not to have separate team of DevOps and SRE in DevOps matured organization due to inter complexity in both role and both are part of single goal wherein technical programming terms SRE implements the DevOps class.
There are 3 broader reasons for my point of view i.e.
- Inter complexity in the role where permission and access issue can arise and such thing impact team’s performance on delivery front.
- Better human resource utilization for resource cost management, team collaboration
- A single team that will look leaner from IT operational point of view and it includes involvement in dev product designing, deployment through automation work and continuous monitoring on managed infra.
Ideally, DevOps are more involved in writing automation work for you like CI/CD and automation around it and SRE’s are more involved in incident handling, RCA, monitoring stuff, identifying toils and removing overhead and keeps their eye on availability and reliability of the product. SRE part can be ongoing but DevOps part is not the work that your team will always be doing in DevOps matured organization and at some point your organization will be compliant or achieved 100% automation goal and at that time they should work in coordination with SRE’s to assume SRE’s role and such collaboration will help in better utilization of human resources and at same time DevOps can share toil information within collaborated DevOps/SRE team so that both can flesh it out from environment.
Image Ref: Link
People can argue over DevOps ongoing work like Dev team can come up by saying they need DevOps for their ongoing work and always need them in their assistance to remain more agile, but it is my opinion that DevOps is not ongoing activity for DevOps matured organization and Dev team should not have the luxury to have 100% DevOps availability to dispense as these resources are motivated, highly skilled and highly paid and keeping them for only Dev work is not in favour of organization due to human resource utilization point of view and as well as it can harm motivation of DevOps people by doing monotonous work so sharing work/resource between SRE/DevOps team is a great idea to reap the benefits of both methodologies and a win-win situation for both team.
There are possibilities to define more granular line about when DevOps will be available to Dev team and who will assume DevOps team member role after collaborated team, but I assume collaborated and motivated team member can easily sort it out and align DevOps member for such duration of work. Google already shared information regarding SRE resource sharing among teams for the shorter duration so there should not be any debate about resource sharing and SRE leaders should focus on definition about how such a framework will work.
I am initiating this thought in the market to have collaborated DevOps and SRE team instead of having them separate and open to get comments about pros and cons of it and what are all the cases where you really require 100% dedicated DevOps team in matured DevOps organization.