DevOps Team Structure and Best Practice
DevOps practices come and go as they are put to a test against real life scenarios. Some prove to be viable, others just don’t bring the results we expect. In this post, we’ll take a closer look at the most popular and effective DevOps team structure best practices, so that you can better understand what’s working or not.
Structure 1: DevOps Inside the Organization
Best suited for: small to mid-sized organizations with a dedicated IT department
This is the most common DevOp structure for SMBs. It assumes putting one or several DevOps engineers in charge of all the operations and deployment processes. The main drawback here is a possible decrease in software quality during implementation of new changes. This often leads to additional re-work from developers.
DevOps Organization Structure 2: Dev and Ops Collaboration
Best suited for: organizations with a strong tech core
Dev and Ops Collaboration is one of the most common team structures and best practices in DevOps. The key here is to ensure fast and effective collaboration between Dev- and Ops-teams. Depending on your needs, you can switch between using only one specialized team or using two teams together. This approach also accommodates having several separate Dev-teams that can work in parallel on partially independent products.
Dev and Ops have seperate, clear functions and effectively collaborate with one another. This means that Ops specialists should feel comfortable working closely with Dev counterparts on issues related to development. Whereas Dev teams should also have a clear understanding of the needs and challenges of the operational teams, mainly those related to deployment.
As well, Ops will be responsible for generating and cultivating new solutions, aimed at reducing the development and deployment times and pass on that information to Devs.
Structure 3: Dev and Ops Together – the Best Team Structure for IT DevOps
Best suited for: organizations with one digital product
This team structure assumes a tight integration between the Dev and Ops teams. They act as a united front, with shared goals and unified product vision. Either of the teams does not have seperate functions. Everyone’s working together to reach a shared goal. Sometimes, this practice is also called “NoOps” as it does not assume having a segregated and visible Ops-team.
Netflix and Facebook – companies developing one digital product – are prime examples of companies using and succeeding with this DevOps practice.
DevOps Organization Structure 4: Оps as IaaS (Infrastructure as a Service)
Best suited for: organizations with several different products and services, who already have an established IT Ops department; companies using cloud services.
Ops as IaaS works best for “cloud-ready” companies using AWS (Amazon Web Services), Azure or another cloud services provider.
As well, it’s a good approach for organizations with a traditional IT Ops department – one that cannot be completely transformed or replaced fast enough. In this case, an Ops-team acts like Amazon EC2 – a web service that enables the creation of scalable virtual services (instances), along with resizable compute capacity in the cloud.
In this case, we have a seperated “DevOps” team (possibly virtual) operating inside the Dev department. This entity is directly responsible for the following tasks:
Operational features and metrics
Handling communications with an IaaS team (optional).
Structure 5: DevOps as an External Service
Best suited for: small teams and organizations with limited experience in IT operations
Hiring external DevOps consultants may be useful for smaller companies who want to get a better grasp of the latest best practices in automation, monitoring and configuration management without hiring in-house expertise. Engaging with a reputable DevOps services provider makes perfect sense in this case.
In the future, such organizations will likely move on and adopt structure 1 or structure 3.
DevOps Department Structure 6: DevOps / SRE (Google model)
Best suited for: organizations with mature operations and development culture
Some companies (including Google) use a custom model that assumes having a certain practice for transferring software from Dev to an additional team, responsible for further operations called SRE (Site Reliability Engineering).
Under this scenario, SRE team will require development teams to collect and provide relevant logs/metrics, demonstrating that the produced software is robust and up-to-specs.
More read: DevOps Trends 2019
The key here is that an SRE-team can bounce back software that does not meet its standards, and provide feedback on what should be fixed before the product can move further down the cycle, towards operations. The collaboration between Dev and SRE teams is based on operational metrics.
Only when an SRE-team approves certain changes and development modules, the product can move on to Operations. SRE acts as a “gatekeeper” to ensure top quality standards. In other words, any change is vetted by SRE-team, and only after they are satisfied with the quality, the software moves on to Ops-team, who’s responsible for deployments.
How Romexsoft Can Help You?
If you are interested in transforming your organization software development best practices, we encourage you to consider our DevOps as Service offering. Engage with AWS-certified DevOps engineers, who can help you effectively develop, automate, deploy and launch your product on AWS. 24/7 support, staff training and adherence to the latest industry best practices are among the few perks you’ll gain.
Get in touch with us today to schedule a free consulting session!