Lego World – No One DevOps Solution Fits All

I was entertaining the idea of Lego-style DevOps software for quite a while now. I wanted to write about this pretty much after success of my previous post about microservices, but then the whole situation with the virus started to unfold – which led me to a bit of paralysis. Today I’m trying to break out of this paralysis and write this down as a sort of return to normalcy 😉

Let me start with software in general and then move to DevOps specifically. This topic is really general, but as I’m building a startup in the DevOps field, I choose DevOps as being “close to home”.

The key narrative here is that gradually, since the start of the computer era, it progressively becomes easier to install a piece of software. For end users, app stores were the culmination of how easy things are – you click the install button in the store, and voila – you now how the software up and running. How cool is that!

But there is always a gap between end users and businesses in how we deal with IT and software.

For businesses – small, medium, enterprises – we still have this old IT Ops narrative that things are complex and therefore must be hard. Fortunately, even with all that resistance things get easier on different fronts with tools like Apt, Ruby Gems, npm, pre-built AMIs from vendors, and most recently – you guessed it – containers, compose files and helm charts. I’m absolutely positive the puck doesn’t stop where we are now – as many things still have a large room to grow and API integration is still a major pain point.

However, the trend is clearly to install software that you need when you need it, quickly and easily. Businesses are made of people – and those people want the ease of an application store to suit their needs just as all other people. Who wants to be stuck in a 10-year old tooling just because it costed a fortune back then? Yet questions like this one on StackExchange make me doubt whether IT departments actually get it.

So, as a business professional, I should have access to the tooling that suits my job best as fast as possible (ideally – immediately). Does this sound right to you too?

Now, let’s transition this thinking to the DevOps world. If I like EC2 on AWS but I’m positive that Azure Container Registry is a better product than ECR, I shouldn’t have an issue to mix-and-match the two. If I want to use GitHub for code storage but CircleCI for integration – that’s perfectly fine. These are examples of tools that are relatively easy to mix-and-match.

However, there is also an opposite direction in the market – namely to try to lock people down in a DevOps vertical and thus create a moat around all your products.

What is a DevOps vertical? It means you simply have your VCS Repository, your CI, your artifact storage, your CD, your infrastructure management and your actual cloud – all from the same vendor! How does that sound?

This certainly sounds great from the prospective of that vendor. But as a user, I don’t want to be forced into ECR just because I’m using ECS – if there is a better product on the marketing. Luckily, it works fine in ECR / ECS pair – I can mix and match and replace ECR with say Docker Hub easily.

But other vertical solutions are trying to actually lock users in pairs of products that could not be simply mixed-and-matched with alternatives. Even though alternatives exist, they are not connected or not compatible for subtle reasons. I.e., try to assign your 2nd level domain name to AWS Load Balancer without using Route 53 for DNS. Possible, but very difficult (because AWS only gives you cname for load balancer and not actual IP addresses, and you can’t add cname record to 2nd level domain).

Now, if I were to switch at this moment to a lock-in solution, what would happen in the future? Does it now mean I’m fully on the mercy of the vendor for the time being? Can they raise prices any time they want like Google just did with GKE? Plus, as their vertical grows and they add more components to it, can it get worse indefinitely? Does it remind you of “old” Microsoft?

My answer to all that is always plan for a switch to another product. When choosing a product, consider ease of transition in and out of this product as one of the key priorities. Stay away from those that force you on the same vertical. Not only because of today’s considerations but also because of the future and vendor’s philosophy. It’s a Lego-world. Moat of a product should be the ability for it to inter-operate with other software, not a lock placed on its users making them unable to get out.