Kubernetes revolutionized infrastructure management with Custom Resource Definitions (CRDs), allowing platform teams to extend the Kubernetes API to model and manage anything, from databases to entire cloud environments.

But what if you want the same abstraction power without being tied to Kubernetes?

That’s exactly what Cloudomation enables with Custom Objects and Object Templates: a powerful, technology-agnostic way to model and manage infrastructure and platform services, independent of any runtime.

Building an IDP isn’t just a technical project, it’s a strategic effort that requires the right tools, workflows, and team alignment. That’s why we’ve created a new resource:

“Building Internal Developer Platforms: Best Practices, Tools, and Strategic Insights for Tech Leaders”

Whether you’re in the early stages of evaluating platforms or already working on your in-house solution, this free guide is full of actionable insights to help you get it right.

As your organization scales, so does the demand for faster feature delivery. But without proper support, engineering teams often end up bogged down by infrastructure work, slowing development and increasing cognitive load. That’s where Internal Developer Platforms (IDP) come in.

This article walks through how to structure an IDP, categorized by key components, with examples of tools you can use.

Let’s jump right into it!

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?

In this article, we introduce three platform orchestration tools: Cloudomation Engine, Humanitec, and KusionStack. Each tool helps organizations streamline infrastructure management by automating the setup, deployment, and orchestration of applications and resources across different environments.

Explore these tools and their features below!

Platform engineering seems to be all about Kubernetes. Platform engineering tooling landscapes are awash with tools focused on Kubernetes, and most reference architectures assume that internal developer platforms are only about deploying containerised microservices to Kubernetes clusters.

Kubernetes is undoubtedly a core component of many platform engineering initiatives. According to the Cloud Native Computing Foundation’s 2023 Survey, 66% of organizations are already using Kubernetes in production, with 18% more evaluating it.

But: Organisations that use Kubernetes also have infrastructure outside of Kubernetes. Many even have most of their infrastructure elsewhere. Some don’t use Kubernetes at all.

Which means that there is a need to manage infrastructure outside of Kubernetes. It means managing hybrid infrastructure that is spread across Kubernetes, Linux VMs, Windows servers, serverless infrastructure, bare metal servers and other curiosities.

In this post, I want to talk about the challenges of managing hybrid infrastructure, how they can be solved, and what the benefits are of focusing platform engineering on the entire infrastructure, and not just containers in Kubernetes.

Let’s not mince words: Platform engineering is really difficult. Platform engineering teams by definition only exist if a software company’s tech stack is too complex for individual software engineers to manage on their own. The very purpose of platform engineering is to reduce complexity for software engineers – meaning that the platform engineering team is the place where this complexity is moved to (riffing on the “law of conservation of complexity”: Complexity cannot be reduced, it can only be moved). Read more about it in this post: Why Platform Engineering? ; also worth a read in this context: DevOps vs. Platform Egineering)

So there should be no expectation that platform engineering can be made easy. There are no magic tools out there that suddenly make a platform engineer’s life a breeze, allowing every junior system administrator to suddenly become a platform engineer.

But there are decisions you, as a platform engineer, can make that will make your life harder, or easier. Let’s take a look.

Challenge 1: Too many tools

TL;DR: Yes. Deal with it. That’s what you’re hired to do. To make it better long-term, add new tools which are generic, multi-purpose and flexible. Also, it is possible to get rid of tools.

“Too many tools” is the very core of what makes platform engineering difficult. It’s not just individual tools, it’s cloud providers, internal components and their dependencies, scripts your own team wrote, and everything else that makes up this highly interconnected thing that is the stack and infrastructure you’re supposed to make simpler for others to use. (Related: Platform Engineering Without Kubernetes)

The advice I read in various blog posts out there with helpful concepts like “portfolio management strategies” and “vendor ecosystems”. Most of it comes down to a belief that central management will help with the mess platform engineers deal with on a daily basis. I think this idea is inefficient, and removed from reality. It assumes that it is possible to devise a set of requirements that any tool a company buys has to fulfil, which would help procurement. In my experience, it typically doesn’t – on the contrary, it makes finding something that works a lot harder. In most cases, it means that only products from large vendors have a shot, which check the boxes, but often don’t provide the best feature set, and are for sure not the best choice when it comes to value for money.

In my experience, the most successful teams are the ones that are allowed to come up with their own requirements, pre-select tools that they’d like, and then hand them off to other teams like security or compliance, which can audit these tools and veto them if they find a significant blocker. This approach I’ve found to be much more effective and faster than asking security, compliance, legal, and other teams to come up with generic lists of requirements, which is pretty much an invitation to spend a lot of time coming up with a list that has to be bullet-proof, cover every edge case, and as a result is pretty impossible to fulfil by any one tool. Such an approach leads to the kind of decision making notorious for enterprises where tools are bought that check the boxes of the legal and security teams, but can’t do what the original requirement was.

However, it might not be in your power to decide on the process of choosing tools in your company. But what you most likely can do is lobby for tools that are:

• Open, in the sense that they can be customised / extended without relying on the vendor,
• Are simple to integrate, i.e. have a well-documented REST API and ideally other integration features such as webhooks,
• Are as general-purpose, broad and flexible as possible. This might mean a bit more time on your end to get the tool to do exactly what you want, but in the end, it will allow you to get exactly what you want – and helps a lot to reduce the overall number of tools you’ll need.

Side note: There is a strong incentive in the software market to build very specialised tools for very specific use cases. From the perspective of a software vendor: If your tool can do one thing only, it’s likely that you can explain very quickly what it does, and it’s very likely that it will do that one thing very well. This makes it easier to sell. However, it also means that the market is littered with very niche solutions that focus on very specific use case(s).
If you fit the product’s intended user group perfectly, then go ahead. Most likely, however, you will end up with a tool that is very good at very little, and very bad at everything else. Tools that are general purpose and broad in their feature set generally provide a much better value for money. It takes longer to get to know them, but once you do, they are a lot more powerful and will provide you with a lot more value than a dozen very specific tools that you each have to learn and maintain individually, and then integrate somehow.

Another piece of common sense advice that seems to rarely make it into blog posts: Getting rid of tools is possible. In 90% of cases, it will be true that once you’ve started to use a tool and have integrated it into your ecosystem, you’ll end up using it forever. But for 10%, it is perfectly feasible to just kick them out when they turn out to be more work than they are worth. When it comes to getting rid of tools, the same applies as for everything else you do: Pick your battles. If it is possible to get rid of a tool, it’s generally a good idea to do so. However it might not be the most important thing you have to do right now, so be sure to propose this only when you have a very good reason to.

Challenge 2: Developers don’t use the platform

TL;DR: Whenever you start working on a feature or service, ask yourself the question: Who needs this feature (or service)? Then go and ask them why, and write down at least one, better three, use cases for your feature or service. Then build the feature / service to make those possible.

It’s a sin as old as software: Engineers go and build something truly beautiful. Then they give it to other people who are supposed to use it, who stubbornly refuse to do so. Why? Most likely because they simply don’t need it.

In my experience, getting people to describe very specifically how they want to use a feature and to what end (i.e. getting them to describe their use case(s)) is the easiest and most direct way to build a feature or service that is useful.

There is nothing else to say about this. If you like, you can call it “cultivating a product mindset”, “user centricity” or “prioritising features based on user value”. I prefer to just call it “talking to people”. (You can also just assign them a ticket, if you prefer not to talk.)

As software delivery grows more complex, organizations struggle with fragmented DevOps practices, inconsistent workflows, and operational inefficiencies. Developers are expected to manage infrastructure, CI/CD pipelines, security policies, and monitoring—often leading to cognitive overload and reduced productivity. This is where Platform Engineering comes in.

Platform Engineering focuses on building an Internal Developer Platform (IDP) to streamline workflows, standardize processes, and enable self-service capabilities for developers. Unlike traditional DevOps (Read more: DevOps vs. Platform Engineering), which emphasizes cultural shifts and automation, Platform Engineering operationalizes these principles at scale, providing a structured and reusable approach to software delivery.

Platform engineering is redefining how software teams operate. Internal Developer Portals are at the core of this shift, empowering developers with self-service workflows.

Here are five Portal tools you should know and what software engineers say about them.

I have been reading and thinking about (internal) developer platforms for a while now. I quickly understood the purpose and benefit of developer platforms: Their purpose is to make the lives of software engineers easier, and the benefit of that is more time for software engineers to do actual software engineering – i.e. an increase in productivity and happiness.

I also often read that developer platforms are a layer of abstraction. Software engineers should no longer need to know about the underlying infrastructure in order to use it (e.g. to deploy their software to it).

So far so good.

I also read that developer platforms

• should be treated as products, and focus on providing useful services to their core users: Software engineers.
• can really be anything: Documentation, templates, APIs, or portals. Anything an organisation identifies as a place where developers can get information, support and resources to handle infrastructure, pipelines and deployments.
• are unique to each organisation. How a specific developer platform looks like, which components it has, which features it provides, depends a lot on what is already there in an organisation.

So far so great.

Individually, all of these points make sense. But I struggled to put them all together. In my head, the idea of “developer platforms” became a large blob that was hard to describe – and even harder to apply.

Then I came across this video by Victor Farcic. It was the first resource that helped me break that mess down into tangible, applicable categories through which I understood how to go about building an IDP: Where to start and what’s important.

In the video, Victor Farcic describes how to build a developer platform in 5 steps: API, State management, One-shot actions / Workflows, RBAC & Policies and User interfaces (which, funnily, he calls optional). I found these steps useful, not so much as steps, but because they describe the core capabilities a developer platform should have in order to be useful. They don’t try to say what a platform should look like by listing product categories, but instead what a platform should be able to do. How you achieve those capabilities is totally up to you.

This post is not a summary of the video, it is my own take on the core capabilities of IDPs, which was inspired by the video. However, I formulate them slightly differently and added another one:

• APIs
• User Interfaces (not optional)
• Automation: One-shot Actions and State Management
• Constraints (policies, RBAC etc.)
• Documentation and Discoverability

Let’s take a look at each of those capabilities, what they mean, and why they are important.

Read more: How do IDPs work