Selecting the right SaaS for DevOps is not the solution

Luckily, getting value out of the software has become easier. Practically all software companies have already transitioned away from shipping DVDs to their customers in favour of offering their software digitally. Better yet, much of the software is now available as software as a service (SaaS), where customers pay for the consumption, and the software vendor takes care of the rest. After all, it only requires one company to know how to run the software properly, leaving the customers able to solely focus on enjoying the benefits of it.

Unfortunately, this march of simplicity hasn't fully happened with DevOps pipelines. If you are a software engineer or an R&D manager, there are still too many questions to know what software to choose and how to run it. You may have already made up your mind to go for one vendor, such as GitLab or Azure DevOps, which is an answer to almost all of your questions. But you still haven’t got to where you wanted: subscribe to a service, and the vendor takes care of the rest. 

You may have already made up your mind to go for one vendor, such as GitLab or Azure DevOps, which is an answer to almost all of your questions.

Just like you, many others are wondering the same.

The problem with DevOps pipelines is not one-dimensional

The challenge in the prevalent thinking is that these questions are represented in the scale of one axis. On one end, there are pieces of software that you weave together to use for software development, which you take care of yourselves. On the other end, there is a service that one vendor offers and runs for you, while you just pay the bill. 

When you look at continuous delivery pipelines, toolchains for DevOps, or software development environments in general, even reputable analysts present this dichotomy: either you do it yourself, or buy it as a service from a single vendor. Everything else is a shade of gray in between. And this, I argue, is a misconception – it is a simplification of a world that needs correcting.

I argue that there are two separate dimensions to take into account: whether you take care of it yourself, and whether you buy all of the single vendor's functionality. It is not a continuum; it’s a two-dimensional question. One of these choices concerns the arrangement of work and responsibilities ("how"), the other involves the architecture and flexibility of the software development environment ("what"). Refactoring the environment without refactoring the way to manage it is seldom the right way forward.

This graph show the two dimensions. Along the x axis: one tool vs. multiple tools. And along the y axis: DIY vs. buying it as a service. 

The problem in a nutshell

Let's imagine a company that is quite competent in its DevOps practices and tools. They have 5-10 engineers handling the software development environment for their R&D teams. 

Someone comes to the team asking for a solution to a problem that concerns their software development environment. They happily engage in a creative process finding out which one from the plethora of the options fit them and their requestor in the best possible way. They will then integrate them into the toolchain.

There are hundreds of "departments" like this. Many of them are happy – but many of them are not: 

• they have too much on the table 
• they have to trouble themselves with problems big and small 
• they have to burden themselves with the upgrades, troubleshooting, and bug hunting in the software development environment. 

Nothing of this adds value to the software they are developing for their customers.

While burning the midnight oil to keep things together, they conclude that a "single-vendor solution" would be a more appropriate choice for them to become more productive in their software development operations. It is at this point in the decision-making where I believe things go wrong. 

Yes, it is the right thing to do to offer developers the tools they love to use, or to bring the software development tools together so that the developers can create customer value easily. But the problem is it's easy to believe that instead of working with the best tools for the best purpose, the issues would go away by selecting a single vendor that would offer a service which had all of it.

If you gave a blank sheet of paper to a "DevOps engineer" (someone who is working full-time helping teams to become more productive in their software development practices) and asked them to draw up a solution that would fulfill their dreams, they would most likely paint a picture that combines the flexibility of the tool choices with what I call the “ease of ownership". 

This means buying some or all of the software development tools from the service provider with defined scope, service level, and price. They would want to focus on improving productivity, solving the problems that are closer to the customer value, and not worrying about the trivial parts.

Drawing the wrong conclusion

From the above perspective, if you adopt a simplified view of the world, yes – "DevOps SaaS" sounds attractive. However, the problem is that the trade-off between "what" and "how" is too big. If a team selects one SaaS vendor for all of their software development tools and replaces flexibility of the tool selection with ease of ownership, they are looking at a trade-off where there are no winners. At worst, the teams opt for the decentralized approach against the selection, leading to overhead and multiple fragmented platforms.

Don’t accept a trade-off between the flexibility and simplicity

The more complex a software development environment is, the more likely it is that a single vendor solution comes out superior in one part and falls short in another. When a company has years, or even decades, of software heritage, there is no business case to compromise the ability to keep the wheels turning in the interest of “making it simpler”. The show must go on while rebuilding a better future.

An R&D or IT manager would ask: is there a world where these two optimum choices come together? Are there options where you can keep the flexibility while adopting "ease of ownership"? We think there is. But before going there, let's take a quick look at how people buy bicycles nowadays.

Given the urbanization and attractive tax bills, a lot of employers now offer their staff the option to get a “company bicycle”. The employee then picks the “velocipede of their dreams”, which is delivered and paid for by a monthly fee (the "how"). If the urban dweller wants "ease of ownership", it does not require them to compromise on the kind and style of their favorite two-wheeler. 

So what would a scenario like this look like for software development tools?

Managed service is more than SaaS

There is a promised land. Some people call it "DevOps as a service", others a "function as a service", while there are also a few who refer to it as a “managed service”. 

In the levels of abstractions, it can be viewed as being less than "software as a service" because the service's functionality is not limited to the capabilities that a software vendor can give – because when you go for DevOps SaaS, the vendor almost invariably prefers to sell their own IPR. However:

• It's more than "infrastructure as a service" because you don't have to build everything on a stable foundation. 
• It is more than “software as a service” because a managed service offers not only a monthly subscription, but also support, change management, upgrades, and integrations for all of the parts of the entire solution – while allowing customers to continually adjust their choices regarding the tools their teams want to use.

Integration platforms show that SaaS is not one thing

Question: Considering that a SaaS solution from one vendor is a suitable solution in many areas of IT, why would it not be so for a DevOps platform? 

Answer: Look at what is going on with the integration platforms, and infer the answer from there:

While SaaS has continued to become a de facto way of consuming software (think of Azure DevOps, GitHub, or GitLab), at the same time, adoption of all kinds of integration platforms (iPaaS) have continued to increase – think of Mulesoft, Boomi, or Informatica. Would you believe that these integration platforms are used predominantly by "those left behind", with their on premises platform solutions awaiting the graceful day to be retired? I don't think so either. 

They are used to integrate SaaS solutions with complementary technologies to get what customers really need. And if you read the functional description of these integration platforms, they all talk about "multi-cloud" and the "ability to integrate different SaaS services". The reason for this is that these integration platforms are used for that purpose: to integrate multiple solutions together to deliver what the customers want.

You may have already decided to go for one solution from one vendor, such as GitLab, GitHub, or Azure DevOps. But it is very likely that you still have a set of problems that require a little bit of help from some other tools. This is when businesses resort to the integration platforms. 

Selecting a single vendor solution on "what" has not solved anything in the "why" department. To deliver 100% of the solution, the teams still need to glue the parts together to provide a software development solution that helps developers. Over time, that 85% will diminish to the minority share of your complete solution, and you will be back to square one, thinking about how to find a single vendor solution. 

That does not sound like a sustainable strategy.

Chase the right silver bullet

Instead of chasing the technological silver bullet, we advise you chase the silver bullet in the "ease of ownership" front. Do not compromise on the toolset – compromise instead on your requirement to run everything in-house by your own competencies.

Focus on finding a solution for software development “tools” that always serves you in the easiest possible way. Focus on using your resources to solve actual customer problems. Focus on providing happiness for your software teams. 

When you go for a managed service, you know that you can always swap individual tools in and out and continue to enjoy the best available for a predictable price. The ease of ownership is a superpower for your teams – when they have been able to continually add value to the developers and the final customers, they don't want to give it up. Why would they?

So, what does this "managed service for DevOps tools" include? 

As you might expect, it consists of: 

• identity and access management 
• product and document management
• team communication 
• design assets 
• artifact management 
• version control
• ...and of course continuous integration and delivery automation.

A managed service also consists of infrastructure automation for containers and their orchestration, as well as deployment and release management. There are also monitoring, analytics and integration for all of this.

Suffices to say, there are many managed services out there, but because I am mostly familiar with Eficode ROOT, I am using an overview image from them to illustrate what I mean.

An overview of the Eficode ROOT DevOps platform

But what really makes it a managed service is the available support for selecting the right solutions, building the complete solution, migrating the data, keeping everything continuously up to date, and providing customer service management. Please note that this list doesn't include any vendor names because there is always a choice, or an option to use more than one.

Do not chase after the dream technology solution – it will always escape you. Instead, chase for the dream ownership model –  because while your needs for a solution are continually changing, your need to always have the most suitable solution to your problem never change.