All Posts

As internal platforms evolve, composability has become a key way to build safe, scalable systems that still give developers freedom. This post explains how composable environments and business-aware PaaS help deliver the value of platform engineering, and how to use them without making common mistakes.

Terms like “Platform as a Product” and “X-as-a-service” are everywhere, yet many companies still centralise all platform responsibilities in a single team. This results in cognitive overload, bottlenecks, and missed opportunities to tap into institutional knowledge. This article reframes the discussion from “headcount” to “collaboration.”

When we talk about internal developer platforms (IDPs), we’re often talking about abstracting complexity away from application teams, as explored in our post on platform democracy. But how far should that abstraction go? Poorly defined CI/CD abstractions can stall delivery and erode platform trust. This post examines how platform teams can avoid common pitfalls and design flexible, composable abstractions that empower developers while ensuring consistency and compliance.

A Red Hat survey of 600 DevOps and security professionals found that 40% of organisations experienced Kubernetes misconfigurations in the past year. Over a quarter of respondents flagged access control issues, including RBAC, as high-risk security threats. In this context, understanding how to use ClusterRoles and ClusterRoleBindings safely and effectively is critical. This guide walks you through practical usage patterns, complete with hands-on examples you can test in your

You know the saying, “If we build it, they will come”? Well, it doesn’t hold up when building software today, and it definitely doesn’t work for internal platforms. You see, internal platforms are products. And like any product, they (should) have users. In this case, your users are your developers. That makes platform engineering a form of consumer software development, even if the consumer is inside your organisation.