DevOps have been making the rounds in many technology-driven industries. Ever since the concept was introduced in the late 2000s, it has meant many different yet related things. For some, DevOps is considered a methodology for software development. In other cases, DevOps is understood as a combination of both methodology and specific tools, and, sometimes, an overall cultural movement related to development and software management.
As the meanings converged over the years, DevOps are now understood as a twofold concept combining methodology and the engineers themselves. The two definitions overlap, one as a set of principles, and one as a team of people involved in managing the practices of software development, as part of the DevOps methodology implies the distribution and activity of engineers within the company.
Embedded DevOps vs Centralized DevOps
- Embedded DevOps: In this approach, DevOps engineers are assigned to different software development teams to learn their processes and implement best practices. It’s considered less resource intensive, however, it can create silos within the DevOps team.
- Centralized DevOps: In this approach, DevOps engineers operate as an independent software development team that partners with other software teams to implement best practices. It’s considered more resource intensive, but engineers have a better picture of the entire organization.
Because DevOps exists in this gray area, integrating them into the company processes is challenging. Some argue that the best approach is to embed DevOps engineers on individual teams. Others believe it’s best to deploy a centralized DevOps team. Both sides believe that DevOps engineers should be able to get an in-depth look into existing processes, which necessitates a high level of practical expertise within each team and a complete overview of the company, requiring a broad spectrum of knowledge.
Your decision on whether to embed or create a centralized DevOps team depends on the intricacies of your business.
Regardless, every company has to make a choice, creating an inevitable dichotomy between embedding and centralization. One of the choices is better for creating changes within teams, but lacks the overall view of the company, the other may have issues pushing smaller changes, but can grasp the entire vision better. In either case, it all begins with establishing the right culture.
Establish a DevOps Culture
Before you decide to adopt a centralized or embedded DevOps approach, it’s important the company understands the methodology and underlying goals of DevOps. No amount of CI/CD, automation and process optimization will work if no one follows the methodology and agreed conventions. DevOps engineers need to first have social influence, which is gained through educating teams about the possible options, tool choices and ways to optimize their work.
Culture underlies all practical operations. For example, let’s say you need to implement a new data collection tool within a team. As long as there are no budgetary constraints, purchasing and implementing one within an existing tech stack is relatively easy.
Issues often arise in having the team adopt a new tool. Developing new habits is often much more complicated as the initial interest wanes. Soon the tool is forgotten, never having the intended impact on operations.
In most cases, people are naturally averse to change, especially when that change affects their work. The DevOps methodology, however, always involves change. It may be gradual and continual, but it’s always there.
The necessity for change stems from one of the foundational DevOps principles — the destruction of siloed work. Teams have to communicate, work and approach challenges together, which means adjusting, changing and sometimes even introducing new processes.
DevOps engineers become a necessity, as the culture and mindset shift would be exceedingly difficult without experts in that specific methodology. They can identify areas where changes would be most impactful and start implementing the cultural shift. Yet, at the same time, they need to have some authority to minimize the possibility of friction between teams.
DevOps integration depends, at least partly, on the ways they can exert cultural influence. Determining whether to embed or have a centralized DevOps team often depends on company size, department sizes and many other social factors.
Advantages to Embedded DevOps
Regardless of the social and business factors at play, there are some objective benefits of either choice of DevOps integration. Embedded engineers will be able to work much more closely with each team and get to know their processes better.
Additionally, the experience gives them the unique opportunity to push automatization and methodologies from within. They can match the needs of that particular team much better than a centralized and independent DevOps department could.
It’s also much easier to assess how many engineers are needed if they are embedded within existing teams, reducing the likelihood of overspending and wasting resources. In some sense, embedding is less resource intensive in the short term.
Challenges of Embedded DevOps
There are several practical issues and theoretical conflicts within such an approach. DevOps is about minimizing silos across development departments. Embedding engineers within existing silos makes it harder for them to break away from the practices that led to them in the first place.
Additionally, it’s much harder for the scattered DevOps engineers to properly ensure alignment with business requirements. As they are a part of the team, they are also influenced by it, making it harder to push possibly unpopular changes that may be beneficial for the business at large.
Moreover, a DevOps engineer that’s embedded in another team (e.g., web development) will have a much harder time developing their own skills. Their team might not be able to guide them toward growth due to a lack of experience with DevOps. It also makes it more difficult to bounce ideas back and forth or discuss potential changes with other DevOps experts on different teams.
Getting a good picture of the overall business needs according to DevOps methodology may also be somewhat more difficult with an embedded DevOps team. Even with many embedded DevOps engineers, finding unity between all of them may become troublesome. Each team often has their own performance metrics, which means they might clash with DevOps methodology.
Advantages of Centralized DevOps
Another option is to create a centralized and independent DevOps team, which would work with all development and engineering teams to implement the culture and methodology. Again, such an approach has its own benefits and drawbacks.
One of the greatest advantages is that they can fully commit to implementing true DevOps. They have their own independent goals that can be easily made to match business strategy and alignment.
Additionally, since they work with many teams simultaneously instead of being limited to one, engineers get a better overall understanding of the flaws and strengths of the entire development pipeline. They are also free to propose implementations without fear of internal pushback.
Finally, an independent department creates an environment where DevOps engineers can both grow professionally and validate their ideas between themselves.
Challenges of Centralized DevOps
One of the drawbacks, however, is that an independent department is usually more expensive, all else being equal. Even with numerically the same amount of engineers as it would be in an embedded approach, a team lead or head will be required.
In addition, the implementation might be a little slower as engineers will have to constantly work with teams externally, meaning more meetings, more processes, and more discussions.
Also, it should be considered that the gray eminence picture will be much starker with an independent team. DevOps engineers will often come into a team, investigate processes, and propose solutions. No matter the approach, it always seems as if an outsider is attempting to influence your team, which inevitably leads to friction.
Which Should You Choose?
DevOps implementation, whether within teams or independently, has an enormous long-term impact. Switching between the approaches is costly, both financially and socially, as lots of people will have to be moved around, new processes will have to be created, and, potentially, someone will have to be hired (or fired).
Setting out on the right foot from the get-go is essential to the long-term success of DevOps. Unfortunately, there’s no easy solution to the problem. Embedding DevOps engineers within teams may be beneficial for smaller organizations, while independence could be better for large companies.
Cultural considerations, however, should precede either of the choices. Analyzing the current state of affairs and picking the approach that would let DevOps engineers implement their methodology with the least amount of friction should be chosen.
