Open source tools are the foundation of many internal developer platforms. What are the reasons why and when you should consider using commercial tools, in addition to the many open source components that are most likely already a part of your platform engineering tool stack?
Where are commercial tools unavoidable?
It’s perfectly feasible to build an internal developer platform entirely with open source components. This is what many organisations are already doing.
The most common places where commercial tools are nevertheless used are:
- Cloud infrastructure and managed services: Unless you have your own bare-metal infrastructure or happen to be a cloud service provider yourself, it’s highly likely that you use commercial cloud offerings. Why? Because it’s simply cheaper for most organisations to use on-demand cloud services than buying physical compute infrastructure.
- Since software is often bundled with cloud offerings (e.g. the entire AWS universe of tools), it’s also very common to use at least some commercial software from cloud providers, like for example container registries or managed git services. Why? Mostly for convenience: Since those software offerings are closely integrated with the cloud service, it is typically easy to use them together.
- IDEs and other developer tools (some of which are used locally, so not really part of the platform engineering stack) are also very often paid for in large engineering organisations. Why? Because they often offer better user experience than open source alternatives.
Beyond that, open source tools are the most common choices for container orchestration, CI/CD, secret management, logging etc. But commercial tools exist in all of these categories and in many cases, it absolutely makes sense to use a commercial tool instead of, or in addition to, open source solutions.
Read more:
- Best Platform Orchestration Tools
- 5 Internal Developer Portals (…and what software engineers say about them)
- Platform Engineering Tools for Building an IDP
When to consider commercial tools
Commercial and open source tools that solve the same problems are typically different in the following ways:
- User experience: While open source tools are often great for solving a specific problem, their development is often not focused on providing good user experience. UX is often the point where the difference between open source and commercial tools is biggest. Whether or not that is worth paying for depends on the user group and their preferences. Tools used by a small, highly technical platform engineering might need UX less than tools that are supposed to be used by every single engineer in your organisation.
- One tool instead of many: One of the reasons why platform engineering is such a complex topic is because the number of tools in the stack is huge. There is a natural tendency for open source tools to focus on solving one particular problem. This means using many separate tools which each does something very specific. Using several of them together can be a challenge. While the majority of open source tools have APIs that allow them to be integrated, this integration still has to be set up and maintained, and adds complexity to the stack, in addition to the specific tool knowledge required for each of the open source components. One major advantage of many commercial tools is that they have a broad and well integrated feature set that reduces the number of tools you need, and the overall complexity of your stack a lot. Especially when you have a small team, using one commercial tool instead of ten, five, or even just two separate open source components can make your life a lot easier.
- Unique features: Many commercial tools have “killer features” which are simply not available in open source tools.
- SLAs, Support and Services: This is one of the most common arguments in favour of commercial tools. It’s not entirely true anymore because there are services companies offering managed service, support and SLAs for many popular open source tools. There are also many commercial software vendors who offer an open source variant of their tool. However when you buy services and support for an open source tool, you might just as well buy a commercial tool straight away and get direct vendor support with it.
What does this mean for you?
Open source tools are a great choice for you if you have:
- An highly skilled and well-staffed platform engineering team with deep expertise in open source tools and time to invest in learning,
- More budget for headcount and less budget for software licenses.
Commercial tools are a better choice if you have:
- A small platform engineering team and/or many junior engineers,
- Less budget for headcount (or simply less headcount) and more budget for software licenses.
Overall cost is often higher in open-source heavy stacks because it requires more (expensive) manpower to build and maintain. While this is commonly known, many organisation still choose open source tools with the argument that they are “free”. Open source tools are definitely cheaper than buying from IBM, Oracle or Broadcom – but when it comes to specialised DevOps or platform engineering tools provided by independent, small or mid-sized vendors, the cost-benefit calculation is often on the side of the commercial tool.
Building Internal Developer Platforms Guide
Learn how to design and build an IDP that accelerates software delivery and reduces complexity.
House advertising: When to consider Cloudomation 😉
Cloudomation is a pure Python framework for platform engineering. Intended to sit at the very core of your internal developer platform, we like to call it “platform backend” or “platform orchestrator”. This is a type of component for which there are not many open source tools available (yet).
Instead, many IDPs either
- focus on a single type of infrastructure, e.g. only Kubernetes, and build services for the IDP within that infrastructure, which requires less orchestration/integration, or
- have a lot of manually scripted glue code that is either spread across different tools (e.g. custom resource definitions in Kubernetes, lots of different Terraform templates, manually maintained bash scripts, some automation in Jenkins etc.) and/or is completely custom, meaning that some sort of custom orchestration component has been scripted from scratch (often starting with cron 😅) which is continuously extended and typically needs a lot of maintenance.
It is perfectly normal to start like this. Especially focusing on one type of infrastructure in the beginning is sensible. But there comes a point when the dependencies that need to be orchestrated become so complex that:
- Most problems with IDP services don’t happen within one component, but between them: incorrect configuration is provided as input, dependencies are not present or incompatible, services that rely on each other are not deployed in the correct order, etc. Identifying the root cause of such problems takes a lot of time. Fixing them is even harder. It often means extending an already complex piece of logic to account for another case. If this logic is spread across different tools and files, this is hugely cumbersome to maintain.
- Most effort of a platform engineering team goes into maintaining and extending glue code, instead of building new services. A lot of resources are tied up that debug configuration errors and similar problems.
In short: Glue code is the least transparent and most fragile piece of most IDPs.
If you are in a situation like this, you should look at Cloudomation. We built it to provide a home for glue code, and to transform it from a liability to an asset. The purpose of Cloudomation is to
- integrate your stack across technology boundaries in a maintainable and transparent way,
- enabling you to build a layer of abstraction across your tool stack that makes it simple to provide standardised services to other stakeholders on top of a diverse tool stack that spans different technologies
Broken down into the arguments I mentioned above, here are the reasons why you might want to consider using Cloudomation in addition to the open source tools you already have:
- One tool instead of many: Due to its broad feature set including workflow automation, state management, configuration, API and CDE management, Cloudomation enables platform engineers to solve many of their challenges within one unified framework instead of a patchwork of many different open source solutions. Having one unified framework that covers many use cases means faster implementation and much easier maintenance of your platform long-term. Read more about which tools Cloudomation Engine can substitute.
- Unique features: There are some things Cloudomation can do, that open source tools can’t:
- Custom objects with custom life cycles: Similar to custom resource definitions in Kubernetes (but more flexible), custom objects allow you to create a layer of abstraction that is custom and completely unrestricted by underlying technologies. This means lifecycle management, state management, and full transparency, for whatever it is that you want to provide to your engineers (deployments, sets of test data, applications, servers, etc. – you can model whatever you like as a custom object). This is invaluable when you want to sustainably manage complex infrastructure across different clouds and tech stacks.
- Unrivaled stability and scalability due to savepoints: How Python is executed on Cloudomation is different from how it runs elsewhere. We persist the execution stack of your scripts with every call of our Python API. This means script executions can be interrupted and resumed easily. This makes it robust, and easily scalable.
- Cloudomation AI assistant: While lots of AI assistants offer code completion or can help with questions about Python, our built-in Cloudomation assistant knows Cloudomation specific functionality and has tools that allow it to directly create resources and write code in Cloudomation. Even though Cloudomation is a powerful and complex tool, using it becomes easy with the Cloudomation AI assistant.
- Services & support, SLAs: With us, you don’t just get standard support, but a personal contact person from our dedicated consulting team.
Summary
While open source tools are a core component of most internal developer platforms, it is sensible to use commercial tools as well. Especially when you have a small or over-stretched platform engineering team, commercial tools can help a lot to reduce the operational overhead for platform engineering tools.
As a pure Python framework for platform engineering, Cloudomation enables platform engineers to easily and visually create a layer of abstraction that consists of custom objects representing your infrastructure and services. This layer of abstraction is tied to workflow automation and lifecycle management directly in the Cloudomation platform, and is intended to span different technologies and clouds.
As such, Cloudomation effectively reduces the complexity of building an internal developer platform, and empowers platform engineering teams with limited resources to sustainably manage complex infrastructure and large tool stacks.
Now that you're here...
Cloudomation Engine is a platform orchestrator that enables you to provide self-service tools, automate complex tasks, and gain full visibility into your infrastructure.
Let’s talk about how Cloudomation
can make that happen for you.
