Skip to content

What is the Best DevOps Topology for My Company?

Technology

Feb 28, 2023 - 9 minute read

800_DevOps_blog_article_illustration
Łukasz Uruski Java Guild Master

Java Guild master; DevOps movement and Teal organisations enthusiast.

See all Łukasz's posts

2988 HC Digital Transformation 476X381

Share

Table of contents

  1. Most Common DevOps Topologies
  2. Fully Shared Ops Responsibilities 
  3. Ops as Infrastructure-as-a-Service
  4. DevOps Advocacy

Some time ago, at a conference, I met Dave, an Operations Lead from a UK-based automotive company. We spent quite a while discussing their journey to cloud and DevOps transformation happening at the same time. The results were quite impressive. Within less than a year from a siloed organisation with Devs and Ops barely talking each other, they became an organisation with a platform team delivering tools and autonomous, cross-functional DevOps teams owning business-oriented services. As a result, time-to-market went down, while the quality of software and stability of services went up. Using the terminology and criteria from DORA’s State of DevOps reports, I’d classify them as highly performing teams.

Nevertheless, what struck me most was the fact that when we talked about the beginning of this journey, I heard the following words:

“We knew that as Operations team we don’t have experience with the Cloud and DevOps, but at the same time we didn’t want to outsource this service to software house; we didn’t want to fire anyone. At the end of a day, we ended up hiring several contractors whose goal was to teach us everything.”

First, I entirely agree that releasing experienced staff with domain knowledge simply because they lack some technical skills is the worst thing one could do.

Secondly, there are several different DevOps working models (topologies) and they picked one of them quite intuitively.

3 Most Common DevOps Topologies

When I was analysing our internal teams working on different projects for different clients over the last two years, I found this particular topology being followed relatively often, yet it’s not the only option. In their book entitled “Team Topologies”, Matthew Skelton and Manuel Pais identified almost ten different topologies.

In this blog post I will focus only on three most common ones, and based on our experience, I will try to suggest when it’s recommended to choose them, and I will also point out the key benefits and risks. 

Fully Shared Ops Responsibilities 

Full DevOps model scheme

In this model, sometimes called simply full DevOps or DevOps Managed Service, a product team is fully responsible for a service they are creating. They have got a great deal of autonomy and a wide range of responsibilities. On one hand, they pick frameworks, services and tools by themselves, but at the same time, they need to have broader competencies, and if they make bad decisions, they will bear the consequences. Gathering a minimal number of people with sufficient skills is a key challenge here, so let’s quickly recap their responsibilities:

Development — this covers architecture design, development of new features and bug fixing. It may happen that other product teams will implement changes in service owned by the team in question, simply because they need it and it's common in organisations with DevOps culture. However, they always must be reviewed and accepted by the team that has ownership. Remember, they are fully responsible for this service. If the service is down, nobody will accept explanations such as 'it's not my code that’s broken'.

Environment provisioning — the team needs to make sure that they have the required infrastructure. They prepare and maintain tools to provide (and decommission) IT environments. What’s more, they decide if something requires a dedicated tool and process. Perhaps it’s not a common activity and investing in automation doesn’t make sense? It’s up to them. If one can precisely assess what resources are required (e.g. it’s going to be an application used by internal employees), then you can do it effectively even without the cloud. Otherwise, it’s simply too risky, or even impossible.

Build, package, release — the team decides what a delivery process looks like, from coding to production. How do they integrate, what tests and when are being run, how security aspect is being addressed? Teams classified as elite performers can decrease the time required to push new code to production to less than one hour. Since in this topology the team owns the whole delivery chain, the sky is the limit, and it’s only the matter of competencies and priorities to become one of those super-efficient teams.

Monitoring & alerting — since they run it, they need information what’s going on in the production environment. The team is responsible for the availability of the service, so it’s in their best interest to have an insight into what’s going on there and to be proactively informed about any malfunction.

When does it make sense to use it?

There are a lot of aspects that the team has to manage, but once properly resourced, the team can be highly effective. This DevOps topology works well when you need to quickly build and confront product ideas with the market; when your top priority is short time-to-market, or when you need to build Proof-of-Concept or a pilot product. However, it may happen that once a business owner confirms that this new service is valuable, the team will have to invest time in adopting the product and delivery process to the standards followed by the company.

This team topology can be the right choice if your organisation has just a few product teams and there is not much value in standardisation. After all, if you have just a few bikes in your garage, you aren't going to spend money and time on sophisticated tools used by professional bike fleet servicing companies.

If you work in a highly regulated branch and every product needs to be compliant from day one, then you need to pay special attention whether the team is aware of those policies. It is absolutely doable, however, this is done through the education of the team rather than formal delivery process or tools provided.

Summary

In a nutshell key challenge is resourcing and the Team needs to be very good at following “you aren’t gonna need it” rule, but inevitably they will build their own solutions and in-house tools.

Ops as Infrastructure-as-a-Service

DevOps Mature Operations model scheme

In Team Topologies, Skelton and Pais coined the name Ops as Infrastructure-as-a-Service, however I also like to call it Mature Operations. This emphasises the fact that this model depends on a true platform team and, in many cases, those were formed by former Ops/Infra teams.

In this topology, the team takes care of the whole service, similarly as in Full DevOps. However, in this case, they can and should use tools provided by the platform team.

Environment provisioning — let’s assume hosting is on cloud, so the platform team can provide scripts (e.g. Terraform scripts) easing provisioning. Of course, the team doesn’t have to use it and they can prepare everything by themselves from scratch, BUT if they do and there are issues with provisioned resources, the platform team will help to solve them. Otherwise, they will be left alone. Additionally, in case of elements that need to be standardised (e.g. unified tagging of resources required for Cost Management activities) such tools give it for free.

Build, package, release — mature platform teams not only provide automation servers as a service but also pipelines as code (Jenkins Pipelines, Azure Pipelines, Circle CI Pipelines to name a few). The team must focus on how to effectively use them and continuously provide feedback to the platform team on what new features are required.

Monitoring & alerting — some companies, once new service is stabilised and amount of new features and active development is minimal, still transfer responsibility to support teams. In such case, standardisation in the monitoring & alerting area makes transition process much simpler.

When it makes sense to use it?

This is a very good team topology if your company has many internal teams or cooperates with multiple vendors. Reused components provide standardisation, hence it’s easier for the client to move ownership of a delivered product. The same standardisation can help satisfy regulatory requirements.

The greatest risk is related to the level of cooperation between product teams and platform teams. Product teams should refrain as much as possible from building custom tools, but in order to be able to do so, platform teams must collect feedback and quickly implement the requested features. The lack of such a culture, multiplied by the fact that the product and platform teams are physically separate, is a recipe for failure.

DevOps Advocacy

DevOps Advocacy model scheme

In this model, the team stands between Devs (Product teams) and Ops/Infra. Its main goal is to spread DevOps concepts through knowledge sharing, transparency and cooperation. They educate Ops and effectively push them toward the Ops as Infrastructure-as-a-Service model. They do prepare tools for product teams and, if necessary, they introduce standards and policies, but in a manner that allows product teams to still be effective. Let’s look at a few examples:

Environment provisioning — the team can extend and enrich everything that is provided by Ops and Infrastructure teams. A common challenge is that those tools aren’t provided in a self-service model. The main goal of the team is to remediate that. An example can be an automation server (e.g. Jenkins) as a service, but with no predefined pipelines. By being aware of the best practices, the team can create such pipelines and speed up the kick-off phase of each new product. Additionally, the team can periodically review whether the environments and services created by product teams follow the best practices as well as the company’s rules.

Build, package, release — if the Ops or Infrastructure team has any offering that could be used by product teams but it’s not available as a self-service, the team tries to mitigate that. Once again, it could be an automation server or static code analysis or security scans. One of our clients had a process when every release candidate was analysed by a dedicated team, and this usually took two weeks. The team found out that this step can be effectively replaced by integrating Zed Attack Proxy and Trivy scans within the Continuous Integration process. This way, it can be done in less than 30 minutes.

Monitoring & alerting — on the one hand, the team provides tools impacting delivery process that can take care of standardisation and as such ease monitoring (e.g. resources’ naming conventions, tagging, logging infrastructure, exposure of key metrics). On the other hand, by working closely with Operations and educating them, the team significantly simplifies Ops work and increases overall level of automation.

When it makes sense to use it?

If you need to optimise delivery processes and shorten time-to-market by introducing automation, such a team will be the right choice. They will decide what is worth automating, (because it’s used by several teams), or what should remain manual work (e.g. a small new service that will be built in two weeks doesn’t need a full-blown pipeline). However, in order to be efficient, they need time to understand the organisation’s challenges as well as its structure.

Thanks to having an insight into how their tools are being used, they can become either gatekeepers or advocates. A gatekeeper won’t allow to do something wrong, an advocate will educate colleagues about good and bad practices. DevOps paradigms strongly suggest the latter, however, let’s be realistic. Different organisations have different needs, so it’s very often a combination of both. How the team will work depends on the company’s strategy around cooperation type with vendors. If a vendor only produces software and returns it to the client, then a gatekeeper makes more sense. If a vendor needs to produce software and will be responsible for this service at least for a few months, then an advocate might be a better choice.

Another use case for this team topology is when you want to change your Operations team into a Platform team. A properly resourced team will not only have technical competencies required in order to implement the company’s strategy, but also will be very good at coaching and knowledge sharing. The same applies if you want to change the way your development teams work. If you want to move away from software delivery towards a situation when development teams will work in the DevOps mode and be responsible for the service end-to-end, then this is your model as well.

Bear in mind that the team working in the DevOps advocacy model may be limited in areas that are owned by operations/infrastructure team. To be able to optimise change, they will need a strong mandate from business stakeholders, but more importantly, all sides must understand and follow the main DevOps paradigms, namely knowledge sharing, transparency and collaboration.

Summary and Conclusions

This model allows you to quickly introduce a lot of knowledge and expertise to your organisation without affecting its current structure, and this is exactly what Dave and his company did. They didn’t ask the vendor to provide the whole team, but instead they hired several contractors — the model is the same, though.

After several months, once the Product teams and Operations learnt new techniques and tools and got used to the shared responsibility model, they smoothly moved to Mature Operations or Ops as Infrastructure-as-a-Service. Well done! Nevertheless, bear in mind that not every company can or should be aspiring to this particular model. What mostly determines the best DevOps team topology is the size of your company, level of regulations in your business domain, and the way you want to interact with vendors.

2988 HC Digital Transformation 476X381
Łukasz Uruski Java Guild Master

Java Guild master; DevOps movement and Teal organisations enthusiast.

See all Łukasz's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle