Coder Legion - Recent posts tagged platform-engineering

LLM Serving on Kubernetes in 2026: What's Solved and What's Still Open

Sat, 10 Oct 2026 16:09:22 +0000

A field survey of the Kubernetes + LLM inference stack in 2026 — the problems that now have serious players, and the edges that are still genuinely underserved.

If you run large language models on Kubernetes, you've probably noticed the ground shifting fast. A year ago most of the hard problems were open. In 2026 a lot of them have serious, well-funded players — which changes the calculus if you're deciding where to build. Competing with a GA project is very different from pioneering an empty space.

This is a map of the territory: what's crowded, and where I think the real gaps still are. I'm deliberately not pitching any of these as "my novel architecture" — several have academic papers or shipping projects attached. The point is to show where the open problems are so you can decide where your effort pays off.

What's already crowded

These are the areas where the obvious pain points now have mature answers. Building here means competing, not pioneering.

KV-cache-aware routing / model-aware gateways. Largely solved. The Gateway API Inference Extension (a kubernetes-sigs project) defines a standard InferencePool routing contract, and llm-d, NVIDIA Dynamo, and GKE Inference Gateway (which went GA in 2026) all do prefix-cache affinity and cache-aware routing on top of it.

Prefill/decode disaggregation. NVIDIA Dynamo and llm-d cover this well.

Fractional GPU sharing (MIG / MPS / time-slicing). Run:ai, cast.ai, the NVIDIA GPU Operator, and vCluster all address it.

GPU scheduling primitives (DRA, gang scheduling). KAI Scheduler, Grove, Kueue, and Volcano are all in play, with Dynamic Resource Allocation graduating in core Kubernetes. Crowded, though still messy at the edges.

If your idea lives in one of those buckets, go in with eyes open: you're entering a race.

Where the real gaps still are

Three edges still look genuinely underserved, and each is shaped like a Kubernetes-native problem — a CRD plus a controller plus some node-level machinery.

1. Model-weight distribution as a first-class Kubernetes primitive

This is the one I find most interesting. Model weights are often 100+ GB, and today they're still delivered largely by ad-hoc downloads from object storage — without the pull-caching, digest addressing, and content verification that Kubernetes already gives you for container images. That gap is a major driver of the two-to-ten-minute cold starts that make scale-to-zero economically painful for inference, since every new replica pays that cost before serving its first request.

The literature backs up the problem. An empirical study (arXiv 2607.16596, "Cold-Start Model Delivery in Kubernetes Inference Serving") measures the delivery paths — modelcar sidecars, native image volumes, object-storage download — on artifacts sized to 1B-, 7B-, and 70B-class weights, and a companion paper (arXiv 2609.20874) frames the same two-to-ten-minute startup as the reason reactive autoscaling is structurally late. So the pain is validated; what's missing is a first-class primitive for it. Note that these papers study and characterize the problem — they don't ship the CRD-shaped solution below, and neither do I claim to have invented it.

The interesting shape of a solution: a ModelArtifact / ModelCache CRD, a controller, and a node-level DaemonSet that treats weights like OCI-addressable, content-verified, node-locally-cached blobs — with topology-aware peer-to-peer prewarming (pull from a neighbor node's cache over the fast fabric instead of re-pulling from object storage), plus scheduler hints so pods land where the weights already live. NVIDIA Dynamo's ModelExpress already does some of this (one worker publishes weights, others pull over NIXL/RDMA), so even here you'd be refining a direction others have started, not working in a vacuum.

Why it's a good build target: it's infrastructure-shaped, CRD-heavy, and not yet a solved commodity. You can prototype the caching, P2P, and scheduler-hint logic and measure cold-start reduction on modest hardware — or even with simulated weights — without a large GPU budget.

2. SLO-driven inference autoscaling that understands request heterogeneity

A caution up front: "SLO-aware inference autoscaling" as a headline is already a shipped commodity — AWS, KEDA, and academia all have versions of it. So this is only interesting if you go narrower than the headline.

Current autoscaling scales on queue depth or KV-cache utilization. But the Cascade paper (arXiv 2608.06557, "Exploiting SLO-Aware latency budget for fair and high goodput LLM inference serving") shows that requests under the same SLO can differ in urgency by a wide margin — a short chat versus a long agentic reasoning trace — and that you can direct queueing and data-movement overhead toward the requests that can absorb it. Related systems like Scorpio (arXiv 2505.23022) exploit the same SLO heterogeneity for admission and scheduling, so this is an active research line, not an empty one. The defensible wedge is per-request-class latency budgeting plus admission control: an InferenceSLO CRD where you declare per-class latency budgets, and a controller that combines a batch-latency predictor with HPA/KEDA to make admission and scaling decisions on predicted goodput rather than raw queue length.

This one is more research-flavored and genuinely publishable — but only if you build and benchmark it against the existing SLO-aware baselines. Without numbers, it reads as a restatement of what's already shipping.

3. Multi-LoRA adapter lifecycle as a CRD

Serving hundreds of tenant-specific LoRA adapters over one base model is now a real production pattern (arXiv 2511.22880), and vLLM and Dynamo support runtime adapter loading. What's still hand-rolled is lifecycle management: which adapters are hot, cache eviction by usage, routing requests to workers that already hold the adapter, and VRAM budgeting. Dynamo has some declarative Kubernetes support here, but it's early.

The shape: a LoRAAdapter + AdapterPool CRD that manages adapter placement, usage-based eviction, and adapter-affinity routing hints — essentially "KV-cache-aware routing," but for adapters.

How I'd choose

If you want a portfolio or OSS operator project: idea #1. It's clearly the most infrastructure-shaped, there's a fresh paper validating the problem, and it's demonstrable without a big GPU budget.

If you'd rather write something paper-worthy: idea #2, with the per-request-class framing and real benchmarks.

Idea #3 is a reasonable middle ground.

A closing note on honesty, because it matters in this space: none of these are empty green fields. Each sits next to active prior art, and readers who work on inference will know it. The value here isn't a claim of novelty — it's a clear-eyed map of where the race is already crowded and where there's still room to build something useful.

Sources

Gateway API Inference Extension — kubernetes-sigs/gateway-api-inference-extension (github.com)
NVIDIA Dynamo; ModelExpress weight distribution (docs.nvidia.com)
Run:ai, cast.ai, NVIDIA GPU Operator, vCluster (GPU sharing)
KAI Scheduler, Grove, Kueue, Volcano; Dynamic Resource Allocation in Kubernetes
arXiv 2607.16596 — "Cold-Start Model Delivery in Kubernetes Inference Serving: An Empirical Study of OCI-Based Distribution and Its Integrity" (G. Kliukovkin)
arXiv 2609.20874 — "Decomposing Predictive Kubernetes Autoscaling for LLM Serving Under Long Startup Delays"
arXiv 2608.06557 — "Cascade: Exploiting SLO-Aware latency budget for fair and high goodput LLM inference serving"
arXiv 2505.23022 — "Scorpio: Serving Right Requests at the Right Time for Heterogeneous SLOs in LLM Inference"
arXiv 2511.22880 — "Serving Heterogeneous LoRA Adapters in Distributed LLM Inference Systems"

The platform adoption shock

Wed, 09 Sep 2026 22:19:00 +0000

In this episode of Continuous Delivery Office Hours, Steve, Charlotte, and Matt take a sneaky look at the forthcoming Future of Platform Engineering report. They look at changes in adoption patterns since the Platform Engineering Pulse report published last year.

The pressure to force adoption has increased with AI stealing all the oxygen in the room, but the silver lining comes from a dramatic change in platform success, driven by platform teams increasing the quality and frequency of feedback from developers.

Watch now to delve into:

Why mandatory adoption remains a persistent pressure
The role AI, security, and compliance play in the adoption drive
The shift in developer sentiment
Why adoption patterns are becoming a less helpful signal

System Architecture: End-to-End Encryption in a Flutter-to-Microcontroller MQTT Bridge

Sun, 07 Jun 2026 09:04:37 +0000

As software developers, we must treat physical IoT hardware as a secured endpoint. Relying on unencrypted, local Wi-Fi connections to trigger microcontrollers leaves physical devices vulnerable to packet sniffing and local network exploits.

In this architectural overview, we outline a secure, end-to-end communication pipeline:
Local Biometric Keystore Verification: Flutter client authenticates the user locally and generates a cryptographically signed payload token via the OS secure enclave.

Encrypted Decoupling: The payload is published over encrypted MQTT (MQTTS with TLS 1.3 over Port 8883) to a secure broker.

Hardware Execution: The local microcontroller (ESP32/PCBA) subscribes to the secured topic, verifies the cryptographic signature of the token, and executes the physical command.

We also dive into integrating edge-sensing telemetry arrays (such as our local ML-driven E-Noses Precision Agriculture AI project) under the same unified gateway architecture.

Check out the full system topology and code pipeline design:
https://www.seosiri.com/2026/06/biometric-iot-security-hardware-manufacturer.html

Modern developer experience has deep roots

Tue, 12 May 2026 11:37:21 +0000

In his 1956 account of the SAGE program, Herbert Benington highlighted the opportunity to use computers to reduce the cost of programming, documentation, and testing.

The creation of utilities, compilers, and instrumentation accounted for about half of the programming effort for SAGE. Benington had recognized that writing programs to improve developer productivity was an essential investment.

At the time, computers were costly, so the idea of making programmers more productive had far less economic weight than it does today. Programmers earned approximately $15,000 per year, and computers cost $500 per hour to operate. Now programmers cost about 70 times the cost of the computers they use. That means the value of developer productivity is worth far more today than it was in the 1950s.

Betting on software

There has been a thread of developer experience all the way back to the earliest attempts to build software at scale. Savvy organizations know that money spent on providing the right environment and tools is worth more than simply “time saved”.

There are two ways to look at software development: Cost and value. It certainly costs money to build software, so the software must provide value that exceeds this cost to be viable. Software systems are built based on the anticipation of value and survive if they manage to meet or exceed that expectation. When an organization becomes cost-obsessed with software, it suggests a low anticipated value or a realization that the value won’t be realized. It’s better to bravely abandon attempts with such a thin payoff.

The sweet spot for software is where the value is highly likely to be obtained, or where there’s a chance of it providing a huge return on investment, so that in any 10 attempts to create value with software, a single success would pay for all the attempts and return a profit.

When you consider how software is a bet, it divides software delivery approaches into two categories: cost-focused or value-focused. Traditional project management works to keep the promise of cost and timeline. Modern agile methods try to increase the probability of the bet succeeding by adjusting course as you learn more about the problem you’re trying to solve.

And here’s the crucial insight. When you manage costs effectively, the best you can achieve is zero cost. When you seek out value, there is no absolute limit to how much value you could produce. It could be twice the cost, ten times the cost, or 1,000 times the cost. There is far more upside than downside if you’re creating valuable software.

Cost-first approaches to software delivery decrease the probability of success, and one (of many) reasons is that it damages developer experience.

DevEx is economics, not hugs

For whatever reason, the universe decided that you must treat people well, whether you like them or not. Even when you examine organizational culture through the lens of cold, hard business goals, you’ll find that unhealthy cultures are less successful than healthy ones. You can be a philanthropist or a capitalist; either way, you have to treat your employees well, or it will damage the thing you care about.

Here’s a simple way it plays out.

The developers need a bit more screen real estate so they can display more information in front of them without having to switch between background and foreground apps. Additional monitors incur costs, and a cost-focused organization will likely deny the request. Developers will have a lower fully loaded cost, but produce less value. A value-focused organization sees the potential returns and their developers will get more screen space, be less frustrated, produce better work in a shorter time, and produce a lot of value.

Having an extra monitor moves the needle a little, but it’s a strong signal. Once an organization chooses between the cost or value pathways, it tends to stick to that decision. That means it’s not just monitors; it’s also chairs, code editors, refactoring tools, test tools, and automation tools. The experience diverges further with each decision made based on cost rather than value.

Another individual who understood the concept of developer experience was Joel Spolsky. He created the Joel Test as a “highly irresponsible, sloppy test to rate the quality of a software team.” The Joel Test has items like “Do programmers have quiet working conditions?” and “Do you use the best tools money can buy?”

I haven’t met Joel, so I can’t speak for his motivation, but I don’t need to know if he was motivated by kindness or cash. The result was an excellent workplace for developers and phenomenal value creation; a win-win, as Stephen Covey called it. Spolsky’s most famous products, Trello and Stack Overflow, sold for $425 million and $1.8 billion, respectively.

You don’t need to make it easy

There’s a certain amount of inherent complexity to writing great software. You must fully grasp a problem, have a strong opinion about how to solve it, and be able to execute on your plans to make it happen. Developers don’t need protection from the difficulty of building software; they need minimal unnecessary complexity from tools, processes, and the workplace environment.

There was a trend that prioritized developer comfort above all other needs, which meant providing them with frameworks to tame complexity. The frameworks made development easier, but limited a developer’s options to the extent it damaged user experience. User needs were subverted to developer ease, which is wrong and somewhat patronizing to developers.

It’s not developer experience if you’re using frameworks that improve the ease of development while annoying those trying to use the software. Developer experience means providing the right environment and tools for developers to build valuable software. Software that doesn’t surprise people with a new paper cut every 5 minutes, pushing them ever closer to demanding an alternative solution.

Think instead of how we set up a surgeon for success. A sterile room, excellent lighting, high-quality equipment, and working with skilled individuals who can anticipate and respond as the situation unfolds. Surgeon experience is centered around a shared goal of achieving optimal patient outcomes. We don’t simplify the scenario by removing things like the need to prevent infection; we make it possible to handle it well.

Developer experience is the same. We don’t choose easier problems to solve; we set developers up to succeed at solving hard problems.

Modern DevEx and Platform Engineering

With the rise of Platform Engineering, developer experience has been largely absorbed. Your organization might have a DevEx team, a platform team, or even both. Across the industry, the two teams share more commonalities than differences. From a list of 30 features offered by platform and DevEx teams compiled by DX, only 4 were exclusive to a single discipline.

Platform only:

Certificate management
DNS
Networking

DevEx only:

Developer training and education

Everything else is along the scale from DevEx to Platform Engineering, where it may be more common in one or the other, but can be found in both.

Platform Engineering and developer experience both build on Benington’s early thoughts and Spolsky’s belief that if we provide developers with the right environment and the best tools, we can amplify their skills and generate lots of value. Forming teams around this idea helps standardize and scale the approach, rather than each team being subjected to differing views based on management styles or simply not knowing what they don’t know.

The Q1 2026 DevProd headcount benchmarking report from DX highlights how well this scaling works. Rather than costing a fixed percentage of your engineering organization’s headcount, developer productivity teams scale non-linearly, with their ratio shrinking as the number of engineers increases. This makes sense, as their work is being reused, unlike approaches that work within individual teams and depend on teams having access to the necessary skills and knowledge.

Engineers	Productivity headcount
200-600	5.1%
600-1000	4.2%
1000+	3.49%

That’s not to say the goal is to have the smallest possible teams. The goal is to unlock the value you create by developing software. If having half of all engineers in productivity roles resulted in the highest levels of value creation, that would be the right mix. There is likely a point of diminishing returns if you approach 10-15%, but you should be testing this by tracking meaningful outcomes for your organization.

Make sure developers have the right environment and the best tools so they can generate the most value for your organization.

We Found 23 Abandoned Kubernetes Environments Running in Production. Here's What They Cost Us.

Sun, 03 May 2026 09:27:32 +0000

The call came on a Tuesday afternoon. Finance had flagged another unexplained spike in our AWS bill — $40K higher than the previous month, no obvious cause. Our CTO wanted answers by end of day.

We started where everyone starts: kubectl get namespaces. The output was longer than expected. Much longer.

What We Found

We had 23 namespaces nobody could explain.

Not "nobody remembered creating" — we could trace most of them back to specific PRs, specific engineers, specific features. The problem was that the features had shipped, the PRs had merged, the sprints had ended. But the environments hadn't been deleted. They were just... running. Quietly consuming compute, memory, storage, and money.

A typical idle environment in our cluster looked like this:

A Postgres 14 StatefulSet with a 50Gi PVC
Two or three replicated API services
A load balancer with a public IP
Redis for session caching

Nothing exotic. Nothing obviously wasteful. Just a full staging stack that nobody was using.

Each one was costing us between $180 and $250 per month.

Twenty-three of them.

According to Flexera's 2025 State of the Cloud report, organizations waste up to 32% of their cloud budget on idle and overprovisioned resources. We were a data point in that statistic.

How They Got There

The honest answer: no process, no ownership, and optimistic assumptions.

When an engineer spun up a staging environment for a feature branch, the expectation was always that someone would clean it up when the branch merged. That someone was never specified. In practice, it was nobody.

Senior engineers assumed junior engineers would delete theirs. Junior engineers assumed the environments would expire automatically. Nobody had written down who owned cleanup. It wasn't in the PR template. It wasn't in the offboarding checklist. It wasn't anywhere.

This isn't a people problem. It's an infrastructure design problem. Manual cleanup relies on humans remembering to do a thing they have no immediate incentive to do, after the work they actually cared about is finished.

What Idle Actually Costs

Let's be specific, because "cloud waste" is easy to wave away as someone else's problem.

A Postgres StatefulSet on EKS with a 50Gi GP2 volume runs roughly $40/mo in storage alone. Add compute for the database pod, two API replicas, a Redis instance, and the load balancer's hourly charge — you're at $180/mo on the conservative end, $250/mo if the services have any memory headroom built in.

Multiply by 23.

That's between $4,140 and $5,750 per month. Gone. Not to any business purpose. Not to any engineer's productivity. Just gone.

What We Did

We built idle detection into our Kubernetes Operator.

The logic is straightforward: if a namespace has received zero inbound traffic and had zero new deployments for 48 consecutive hours, it's flagged as idle. The system surfaces it in our internal dashboard with an estimated monthly cost and a one-click archive option. Auto-shutdown is configurable for environments marked as non-production.

This is now part of Fortem — the IDP we built after running into this problem (and several others like it).

In the first month after we deployed idle detection, we identified all 23 abandoned environments. We archived 21 of them. Two turned out to be actively used by contractors who hadn't told anyone — good to know.

The Result

$4,200/month recovered. Not from switching cloud providers. Not from negotiating reserved instances. Just from finding and deleting environments nobody was using.

The bigger shift was cultural. Once engineers could see that idle environments cost real money — and that the system would flag it automatically — cleanup started happening proactively. The dashboard made the invisible visible.

We still spin up environments on demand. We still use short-lived namespaces for feature branches. The difference is that now we actually clean them up.

If you're running Kubernetes and don't have idle detection in place, run kubectl get namespaces and count how many you can't immediately explain. The number is probably higher than you think.

We built the tooling to fix this into Fortem — a self-hosted Kubernetes IDP. Free tier available.

The reality of GitOps application recreation

Tue, 21 Apr 2026 04:19:42 +0000

Your application code is in Git, and you've adopted GitOps principles, so you can recreate it anywhere, anytime, right? If you're like many teams, the honest answer is "sort of". While GitOps promises the ability to recreate your application from version control, the reality is often more nuanced as you consider the holistic view of deploying and running your applications.

Our State of GitOps report reveals some fascinating insights about recreatable applications. As part of the survey, we asked this question:

Can you recreate the application from the configuration files stored in version control, for example, to recover from a disaster or to create a new test environment?

Overall, 52% of respondents feel confident they can recreate their applications from version control. For high-performing GitOps teams, this jumps to 70%. But what caught my attention is that "partially recreatable" was a significant response across GitOps maturity levels and the most common response among teams still developing their GitOps practices. It suggests that while most teams can handle their core applications, they struggle with recreating the complete environment stack.

Interestingly, our data reveals that teams often become less confident about recreation as they advance their GitOps practices, only to see confidence surge at higher maturity levels. This pattern likely reflects a natural discovery process. As teams dive deeper into GitOps, they uncover dependencies and complexities they didn't initially realize existed.

So, what does complete application recreation entail? And why do so many teams find themselves in that "partially recreatable" category?

The real-world value of recreatable applications

Recreatable applications don't make sense for all organizations and applications and arguably could be viewed as nice to have rather than a necessity. However, recreating your applications from Git can solve real problems teams face at different scales and circumstances.

When disasters occur, having your entire application stack defined in code means restoration becomes a deployment rather than a scramble. You can rebuild from your Git repository instead of hunting through documentation or recreating manual configurations. The same capability proves valuable during cloud provider migrations driven by acquisitions, regulatory requirements, or strategic business decisions, where recreation becomes a non-trivial but controlled transition rather than a risky lift-and-shift operation.

Of course, your application is just one piece of the puzzle. You'll still need to consider the surrounding infrastructure, networking, and foundational services that enable your application to run in the target environment. While mature teams often manage this infrastructure through tools like Terraform and Crossplane, getting to that level of complete recreation from Git requires thoughtful planning and infrastructure provisioning processes.

Operational efficiency improves when you can create new test environments on demand with minimal overhead. Whether you're testing critical fixes, running performance tests against production-like infrastructure, or validating new features, the ability to spin up identical environments quickly and tear them down when finished reduces both time and infrastructure costs.

Recreation provides auditable proof for regulated industries that infrastructure and deployment processes are fully documented and reproducible. Suppose you need to satisfy compliance frameworks that require demonstrable change control. In that case, recreatable applications help you meet audit requirements for deployment consistency and provide evidence that you can rebuild systems according to documented specifications.

The maturity journey

Our survey data's confidence curve tells a story about how teams learn and adopt GitOps. Rather than steady upward progress, there's an initial dip in confidence before teams reach far higher levels of certainty about their recreation capabilities.

This pattern might highlight the natural learning process. Pre and low adopters will typically approach GitOps from an application-down perspective and focus on getting their manifests into Git repositories. The initial confidence may come from successfully deploying applications this way and feeling like they've "solved" recreation.

However, as teams mature, reality sets in when they add more applications to their GitOps processes and try to recreate complete environments. They likely discover their core applications are relatively easy to recreate, but the surrounding environment may not be. Infrastructure provisioning may be required, whether manual or automated, and teams may not have accounted for external dependencies yet.

You need backup and restore strategies for stateful components like databases that go beyond what you define in Kubernetes manifests. While the application might be recreatable from Git, the data likely isn't. You’ll consider whether to increase cost and complexity by replicating databases across infrastructure, configure automated backup and restore processes, or accept that provisioning new environments require data restoration as a separate step.

This explains why "partially recreatable" was a popular response in our survey across all GitOps maturity levels. Most teams can handle their core applications but struggle with the complete environment stack. As low and medium-maturity teams adopt foundational GitOps practices, they discover the full scope of what requires management, decreasing their confidence in complete recreation.

What to consider with complete recreation

Success stories do exist. Teams using infrastructure provisioning tools like Crossplane, Terraform, and mature GitOps workflows have achieved recreatable applications. But getting there requires stepping back and considering what recreation means from a holistic perspective.

Your application manifests assume that the underlying infrastructure exists, but something must first create that foundation. Many organizations still manage infrastructure provisioning through separate Terraform workflows, creating a gap where recreation often breaks down. While infrastructure provisioning may be mostly automated, unless integrated with your GitOps workflows, you must step away and use another platform to create the infrastructure first.

Recreation means recreating the configuration and access to secrets in the new environment. Your GitOps process needs strategies for safely managing environment-specific values, API keys, and certificates.

Teams can easily recreate applications but can't recreate data the same way. You need strategies for database backups, data replication, or accepting that data restoration happens separately from application recreation.

External services, APIs, or legacy systems your applications depend on often fall outside what GitOps can recreate. Your recreation strategy needs to account for these dependencies, whether through service discovery, configuration updates, or fallback mechanisms. Additionally, can your target environment support the infrastructure you rely on? Not all cloud services are available in every region, especially during disasters.

70% of high-performers have achieved confidence in their recreation capabilities, and have worked through these considerations. They prove that complete recreation is possible and likely find it worthwhile, but it requires treating it as a comprehensive system design challenge rather than just putting YAML in Git.

The path forward

While the journey from partial to complete recreation involves discovering complexities you didn't know existed, 70% of high-performing teams that achieved this capability prove it's possible and worthwhile.

The key is treating recreation as a systematic challenge rather than an afterthought. Whether you're just starting your GitOps journey or working through the complexities that come with maturity, understanding what complete recreation entails helps you make informed decisions about where to invest your efforts.

For more insights into how teams across different maturity levels approach GitOps and application recreation, download our complete State of GitOps report to see the full research findings and implementation patterns.

Building NeuroScale: Why I Document Production Failures Instead of "Happy Paths"

Fri, 17 Apr 2026 12:40:11 +0000

Hello CoderLegion! I’m Sodiq, a Platform Engineer focused on Kubernetes, AI Infrastructure, and DevSecOps.

I recently spent 6 weeks architecting NeuroScale - a production-hardened, self-service AI inference platform using KServe, Backstage, ArgoCD, and Kyverno.

While building it, I realized that 90% of the tutorials online only show the "Happy Path." They assume your Helm charts deploy perfectly and your network routing works on the first try. But in the real world, infrastructure is messy.

So, I decided to document the exact, gritty production failures I hit along the way - complete with terminal outputs, root causes, and the Kustomize patches required to fix them.

I have just imported my two most popular "Reality Check" post-mortems to CoderLegion. If you are deploying AI models or Internal Developer Portals, these will save you hours of debugging:

I’m excited to join this community. Let me know in the comments: What is the hardest undocumented infrastructure bug you’ve faced recently?

Avoiding golden cages in Platform Engineering

Mon, 13 Apr 2026 13:40:30 +0000

I zipped up to London to share the Platform Engineering Pulse report with the amazing London DevOps group. Afterwards, we spent several hours talking through some of the findings and I thought I’d write up some of the results of those discussion.

In particular, the question of whether platforms should be optional or mandatory has a lot of talking points. It also intersects with the golden cages problem, as an inflexible platform intensifies the nastiest problems of mandatory platforms.

As we’re continuously talking golden paths, we’ll head to Oz to look through the hazards and how they come together to cause some serious problems.

The wizard of ops

Imagine our house has been lifted by a hurricane and deposited in a strange land. The friendly people we meet tell us about a golden path, and off we go to see a wizard. We sing a little tune, because we don’t yet know about the hazards awaiting us along the way.

Why in Oz didn’t the munchkins mention the wolves, crows, and flying monkeys? They certainly had plenty to say about the darn road.

Let’s explore the wonderful and magical world of gold and platforms.

The golden path

There’s a crucial distinction between a paved path and a golden path. I’m sure the munchkins would have had a verse or two on it.

Paved paths are an analogy based on desire paths; those animal trails and shortcuts that, over time, create a signal that people want to travel between two points. If your platform is just the encoding of desire paths, it’s not terribly different from whatever came before. You’re missing an excellent opportunity to create something better.

In product development, we know that you don’t just build what the user asks for. Instead, you explore their needs and design something better than what is currently available to them. The same goes for golden paths.

If you take existing paths and pave them, you’re just transferring the complexity from developers to platform engineers. There is some benefit of splitting complexity (the developers handle the product’s complexity, and the platform engineer handles, well, whatever toxic waste is ejected into the paved path).

Golden paths shouldn’t just divide the complexity; they should manage it. This is vital as we hope the golden path handles aspects that were absent from the well-trodden desire path. Things like cost control and security, which were previously applied haphazardly, if at all.

We’re not trying to achieve the shortest path (through the quicksand, tar pit, and snake-infested rocks), but the shortest route that satisfies the constraints (such as safety).

Got a golden path? Great, we’ve defeated the wolves, now it’s time to face the crows.

Golden cages

On day one, golden paths and golden cages look exactly the same. You only really find out you’re in a cage when the platform you use doesn’t let you do something. You only discover the lack of flexibility when you push on a surface.

As standardization is high on the list of goals organizations have for Platform Engineering, it’s no surprise to find platform teams taking this to a rigid extreme. Developers may want 90% of what the golden cage offers, but if they can’t achieve the other 10% they become frustrated. This is a contributing factor to cases where developers circumvent the rulebook and find a way to bypass the platform entirely.

Signals of golden cages include a heck of a lot of negging the platform, highlighting its flaws, pointing out that development goals will be missed, and generally wearing down dev managers until they sign off on letting developers do things their own way.

The solution isn’t to correct the developers. You have to correct the platform. It should provide extensibility points and escape hatches, so developers can achieve their goals within the policy constraints set by the organization.

That’s the crows dismissed. Time for some flying monkeys.

Golden manacles

Your organization is investing in a platform initiative. They have a bunch of goals in mind, often related to standardization, compliance, security, and cost control (and hopefully flow of value and developer experience). Why would they let all this time, effort, and attention be wasted by allowing development teams to choose whether to adopt it?

It’s evident that platforms should be mandatory.

Except this is the breeding ground for some very toxic outcomes. Everybody has some level of rebellion streaking through them, and mandating anything is the perfect way to energize it. Why do so many British kids hate Shakespeare? Because teachers forced them to read it.

Now, you may think your developers are low on the rebel-scale, so you’ll be okay. You can tell them what to do. The thing is, while those high on the rebel-scale will provide noisy dissent, those lower on the scale will be more silent and subversive. When a mandated platform introduces friction, everyone will rebel, and they’ll do so in their own wonderful and unique style.

You could have a great platform and make it mandatory, and maybe never see this problem. If you mix mandatory adoption with a golden cage, you’re guaranteed to see strange behaviors as teams thrash around trying to achieve their conflicting goals. Developers are supposed to be delivering valuable software, platform teams are trying to force compliance, and the two are in constant conflict.

If this sounds familiar, it’s because DevOps was the solution to this problem. When you have two silos with conflicting goals, you’re in flying monkey territory without a monkey-proof umbrella. The solution to this mandated golden cage conundrum is simple. You need to align goals, encourage collaboration, and let people do the good work.

In Platform Engineering, the best way to achieve collaborative bliss is:

Make platforms optional to increase the desire in platform teams to understand the needs of platform users. Make it a shared goal to meet the organization’s policies, so development teams and platform teams both want the same thing.

When developers and platform teams share the goal to meet policy, the platform becomes a far more appealing option. Other goals, like flow of value, should also be shared, so platform teams are motivated to solve the right problems for the development teams.

The silver slippers: Platform as a product

This is why the prevailing advice from smart people is to treat the platform as a product and the developers as customers and prospects. Put a good feedback loop in place so you can see where the platform is starting to fit too tightly. Then, collaborate with your customers to provide a good way to flex where needed.

Make your platform optional, and your policies mandatory.

The End of Data Export: Why the Cloud is a Compliance Trap

Mon, 06 Apr 2026 11:12:00 +0000

The End of Data Export: Why the Cloud is a Compliance Trap

Privacy is not a feature you bolt on at the end — it is infrastructure. For anyone with real capital at stake, the sharp risk is often not “using AI” in the abstract; it is routing the full ledger (positions, identifiers, broker notes) through systems whose defaults are long retention, broad subprocessors, and training-adjacent logging.

Sovereignty is Pocket Portfolio’s architecture philosophy — not a slogan layered on top of a conventional SaaS core. It means user-anchored truth for the portfolio story, cloud inference used as compute (models run where the keys point), and a deliberately small vendor footprint for that narrative: bounded context across the wire, stateless handling of the payload for Ask AI, and no server-side portfolio database that turns every prompt into durable ledger replica. The Sovereign Engineering serial is the engineering record of that bet.

How many fintech backends still look

The conventional pattern:

Ingest everything — CSV or API sync into a central database (PostgreSQL or equivalent).
Central API — the product server reads rows and powers dashboards.
“Add AI” — paste summaries or raw rows into an LLM gateway, or sync user documents into a vector store.

Blast radius: one dump, one misconfigured replica, or one over-collection in logging, and the full history shows up in breach response, subpoena scope, and “why did you keep column X?” Compliance follows architecture — rarely the reverse.

Sovereignty on the wire (and why it is not “no cloud”)

Sovereignty does not mean we pretend servers do not exist. It means truth and retention follow the philosophy above — not the default SaaS pattern of centralizing everything “because we can.” Concretely for Ask AI:

Layer	Typical SaaS stack	Sovereign Ask AI path
System of record	Vendor DB holds full ledger	User device + optional Drive; no server-side portfolio DB for chat
AI input	Often “enough rows to be dangerous”	Client-built bounded string: totals + top-N holdings (default path)
Server memory of prompts	Logs, caches, “improve the model” pressure	Stateless handler: payload drives one stream, not stored as portfolio rows

Narrow cloud is how Sovereignty shows up in code: the API behaves like a pure function on portfolio text for that request — prompt in, stream out — without a portfolio row store on our side for that inference path.

The stateless boundary in `app/api/ai/chat/route.ts`

The route begins with an explicit comment that matches the implementation:

/**
 * Stateless: request payload (message, context, attachedContent) is used only
 * to build the LLM prompt and stream the response. No database write or cache
 * of the payload; only analytics/quota metadata are persisted.
 */

Request path: message, context, and optional attachedContent are folded into the model prompt for this request only. They are not appended to a durable chat_logs-style table of portfolio narrative.

Operational writes: quota and product analytics need identifiers and flags, not paragraph-long portfolio text. On success the handler records a toolUsage document whose metadata includes fields such as uid, tier, isPaid, hadAttachment, provider — not the context body:

await db.collection('toolUsage').add({
  toolType: 'pocket_analyst',
  action: payload.action,
  metadata: {
    uid: payload.uid,
    tier: payload.tier ?? null,
    isPaid: payload.isPaid ?? false,
    hadAttachment: payload.hadAttachment ?? false,
    provider: payload.provider ?? null,
    status: payload.status ?? null,
    errorCode: payload.errorCode ?? null,
  },
  timestamp: Timestamp.now(),
});

That is telemetry, not a ledger replica of what you asked. Free-tier quota also touches Firestore (aiUsage) as counts and period, not your CSV.

Sovereignty versus residency

Sovereignty — the architecture philosophy: the sensitive financial narrative is not our row-level system of record for inference; cloud inference is bounded and stateless for that payload; we shrink what must sit in the vendor center.
Residency — “Our database is in EU-West.” A different question (where bits are stored). It can coexist with Sovereignty, but it does not replace it: you can meet a region checkbox and still run a central ledger + full-prompt retention story Sovereignty rejects.

Where this architecture stops

Paid attachments: if someone includes file text, that text is in the prompt for that turn. It still is not “our portfolio database,” but it does cross the wire for that request — the same transparency you would expect when any file is sent to a model.
Regulation: a stateless inference path narrows what you retain; it does not substitute for sector-specific certifications or counsel-led privacy work. Architecture supports the story; it does not replace the paperwork.

Why persistence is leverage — and liability

Every column you keep is a column you must justify, protect, and delete on a schedule. Sovereign design chooses forgetfulness of the portfolio payload for the inference hop: a smaller vendor system than one that remembers every turn as product of record. That is the compliance trap this philosophy sidesteps for analyst-grade Q&A — not “no server,” but no server-side ledger replica for the chat path.

Part 1 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

Leveling up your deployment pipelines

Mon, 02 Mar 2026 13:03:30 +0000

Our Platform Engineering Pulse report gathered a list of features organizations commonly add to their internal developer platforms. We grouped sample platforms into common feature collections and found that platform teams follow similar patterns when implementing deployment pipelines.

They begin by creating an end-to-end deployment pipeline that automates the flow of changes to production and establishes monitoring. Next, they add security concerns into the pipeline to scan for vulnerabilities and manage secrets. This eventually leads to a DevOps pipeline, which adds documentation and additional automation.

You can use this pragmatic evolution of CI/CD pipelines as a benchmark and a source of inspiration for platform teams. It's like a natural maturity model that has been discovered through practice, rather than one that has been designed upfront.

Stage 1: Deployment pipeline

The initial concern for platform teams is to establish a complete deployment pipeline, allowing changes to flow to production with high levels of automation. Although the goal is a complete yet minimal CI/CD process, it's reassuring to see that both test automation and monitoring are frequently present at this early stage.

Early deployment pipelines involve integrating several tools, but these tools are designed to work together, making the integration quick and easy. Build servers, artifact management tools, deployment tools, and monitoring tools have low barriers to entry and lightweight touchpoints, so they feel very unified, even when provided by a mix of different tool vendors or open-source options.

In fact, when teams attempt to simplify the toolchain by using a single tool for everything, they often end up with more complexity, as tool separation enforces a good pipeline architecture.

Builds

Building an application from source code involves compiling code, linking libraries, and bundling resources so you can run the software on a target platform. While this may not be the most challenging task for software teams, build processes can become complex and require troubleshooting that takes time away from feature development.

When a team rarely changes its build process, it tends to be less familiar with the tools it uses. It may not be aware of features that could improve build performance, such as dependency caching or parallelization.

Test automation

To shorten feedback loops, it is essential to undertake all types of testing continuously. This means you need fast and reliable test automation suites. You should cover functional, security, and performance tests within your deployment pipeline.

You must also consider how to manage test data as part of your test automation strategy. The ability to set up data in a known state will help you make tests less flaky. Test automation enables developers to identify issues early, reduces team burnout, and enhances software stability.

Artifact management

Your Continuous Integration (CI) process creates a validated build artifact that should be the canonical representation of the software version. An artifact repository ensures only one artifact exists for each version and allows tools to retrieve that version when needed.

Deployment automation

Even at the easier end of the complexity scale, deployments are risky and often stressful. Copying the artifact, updating the configuration, migrating the database, and performing related tasks present numerous opportunities for mistakes or unexpected outcomes.

When teams have more complex deployments or need to deploy at scale, the risk, impact, and stress increase.

Monitoring and observability

While test automation covers a suite of expected scenarios, monitoring and observability help you expand your view to the entirety of your real-world software use. Monitoring implementations tend to start with resource usage metrics, but mature into measuring software from the customer and business perspective.

The ability to view information-rich logs can help you understand how faults occur, allowing you to design a more robust system.

Stage 2: Secure pipeline

The natural next step for platform teams is to integrate security directly into the deployment pipeline. At this stage, teams add security scanning to automatically check for code weaknesses and vulnerable dependencies, alongside secrets management to consolidate how credentials and API keys are stored and rotated.

This shift is significant because security measures are now addressed earlier in the pipeline, reducing the risk of incidents in production. Rather than treating security as a separate concern that happens after development, it becomes part of the continuous feedback loop.

Security integration at this stage typically involves adding new tools to the existing pipeline, with well-defined touchpoints and clear interfaces. Security scanners and secrets management tools are designed to integrate with CI/CD systems, making the additions feel like natural extensions of the deployment pipeline rather than disruptive changes.

Security scanning

While everyone should take responsibility for software security, having automated scanning available within a deployment pipeline can help ensure security isn't forgotten or delayed. Automated scanning can provide developers with rapid feedback.

You can supplement automated scanning with security reviews and close collaboration with information security teams.

Secrets management

Most software systems must connect securely to data stores, APIs, and other services. The ability to store secrets in a single location prevents the ripple effect when a secret is rotated. Instead of updating many tools with a new API key, you can manage the change centrally with a secret store.

When you deploy an application, you usually have to apply the correct secrets based on the environment or other characteristics of the deployment target.

Stage 3: DevOps pipeline

The DevOps pipeline represents a shift from building deployment infrastructure to accelerating developer productivity. At this stage, platform teams add documentation capabilities, infrastructure automation, and one-click setup for new projects. These features focus on removing friction from the developer experience.

The impact of this stage is felt most strongly at the start of new projects and when onboarding new team members. Instead of spending days or weeks on boilerplate setup, teams get a walking skeleton that fast-forwards them directly to writing their first unit test.

While the earlier stages focused on moving code through the pipeline efficiently and securely, this stage is about making the pipeline itself easy to replicate and understand. The automation added here helps teams maintain consistency across projects while giving developers the freedom to focus on features rather than configuration.

Documentation

To provide documentation as a service to teams, you may either supply a platform for storing and finding documentation or use automation to extract documentation from APIs, creating a service directory for your organization.

For documentation to be successful, it must be clear, well-organized, up-to-date, and easily accessible.

One-click setup for new projects

When setting up a new project, several boilerplate tasks are required to configure a source code repository, establish a project template, configure deployment pipelines, and set up associated tools. Teams often have established standards, but manual setup means projects unintentionally drift from the target setup.

One-click automation helps teams set up a walking skeleton with sample test projects, builds, and deployment automation. This ensures a consistent baseline and speeds up the time to start writing meaningful code.

Infrastructure automation

Traditional ClickOps infrastructure is hand-crafted and often drifts from the intended configuration over time. Environments may be set up differently, which means problems surface only in one environment and not another. Equally, two servers in the same environment with the same intended purpose may be configured differently, making troubleshooting problems more challenging.

Infrastructure automation solves these problems, making it easier to create new environments, spin up and tear down ephemeral (temporary) environments, and recover from major faults.

Evolving your platform's pipelines

Whether you choose to introduce features according to this pattern or decide to approach things differently, it is advisable to take an evolutionary approach. Delivering a working solution that covers the flow of changes from commit to production brings early value. The evolution of the platform enhances the flow and incorporates broader concerns.

Your organization may have additional compliance or regulatory requirements that could become part of a "compliant pipeline", or you may have a heavyweight change approval process you could streamline with an "approved pipeline".

Regardless of the requirements you choose to bring under the platform's capabilities, you'll be more successful if you deliver a working pipeline and evolve it to add additional features.

Happy deployments!

Platform Engineering’s patterns and anti-patterns

Tue, 17 Feb 2026 10:22:51 +0000

Platform Engineering has been around for a while. Interest recently accelerated, however, thanks to its relevance to DevOps.

For some, Platform Engineering solves a common DevOps Topologies’ problem: Embedding IT operations into DevOps teams that lack time and experience to do it well. This is an anti-pattern, also known as Anti-Type F.

Platform Engineering can help you scale the organization and reduce developer overload.

Use our Platform Engineering decision flow to find out if it’s the right solution to your problems. It also guides you to put key measurements in place early so you can track the value of your internal developer platform (IDP).

We describe the anti-patterns and positive patterns of Platform Engineering below. Let us know if you have a suggestion.

Platform Engineering anti-patterns

If familiar with Team Topologies, you’re less likely to use one of the common Platform Engineering anti-patterns. The library can still be a helpful way to describe problems to your colleagues when you find trouble.

Complex platforms

An IDP should reduce complexity and remove cognitive overload for developers. If the platform is too difficult to use, it failed at a crucial goal. There are several ways a platform can add to a developer’s burden:

It uses a configuration file format that isn’t familiar to the developer
APIs don’t have a consistent convention for methods and parameters
There’s no documentation
The platform doesn’t reduce developer pain

If you have configuration files as part of your platform, be flexible with the format. It should be trivial to parse the same data from a JSON file from web developers and a YAML or XML file from back-end teams. This means the developers can use a format familiar to them rather than one convenient to you.

When creating an API or command line interface (CLI), being meticulous and consistent with method names, parameter names, and the order of parameters can make it easier to use.

Your IDP documentation should be concise and clear, focusing on what’s available and how to use it.

Where developers don’t meet governance, risk, and compliance (GRC) objectives, adding a platform that handles these needs adds more load to development teams. Solving existing developer problems first allows you to solve external requirements without burdening developers.

If your IDP doesn’t significantly reduce developer cognitive overload, complexity, and burnout, it doesn’t work. It also fails if it transfers all the pain to the platform team.

”Field of dreams” platforms

In the 1989 movie Field of Dreams, a voice tells Ray Kinsella (Kevin Costner) that “If you build it, they will come.” In the film, building a baseball park in a cornfield reunites Kinsella with his father and produces a stream of fans coming to watch games at the farm.

If you take the same approach when building your internal developer platform, you’ll struggle to gain internal market share. You need to involve developers from the start and build a platform that solves their specific problems.

If you build the platform before talking to its potential customers, you find yourself with a product that doesn’t fit your market. Some symptoms include:

Poor technology fit: Making it easier to manage Kubernetes only to find developers moved to serverless functions.
Skill assumptions: Creating a simplified template for microservices only to find developers are microservice experts and don’t value your solution.
Forcing choices: Designing a platform with the latest and greatest technology and finding the business doesn’t want to move from stable solutions.

You can’t design your IDP on faith alone. You must talk to developers across many teams to find common pain points your platform could remove. Creating a platform in isolation guarantees low adoption rates.

The skill concentration trap

When you create a Platform Engineering team, you’ll likely add people with the most experience in areas the platform will cover. This can cause a problem when:

The platform team thinks they know better than the development teams
Development teams lose the knowledge they need to run their software
Development teams lose the people who could migrate them onto a platform

Suppose you move people from development teams to create a platform team. You need a strong succession plan and a greater focus on collaboration to upskill the development teams for self-service. You must ensure you don’t create a cognitive overload and burnout by removing skilled team members.

If people leaving the teams were the only ones who cared about operations, the remaining members might see little benefit to the platform. It would be a disaster if developers ignored operations tasks.

You may need to start your platform team with fewer people. You can then solve problems that make it easier for teams to release more people. Choosing platform team members on communication and collaboration skills, and not just technical knowledge, increases the chances of success.

Magpie platforms

People attracted to shiny objects are often called magpies. That’s because members of the crow family tend to take shiny objects belonging to their owners when kept in captivity. A magpie platform focuses on shiny new technologies and not solving problems developers face with existing systems.

Building a platform to support a greenfield project is attractive, but there are far better ways. You make more impact by helping teams with their existing production software.

You build a better platform for the new software once you can identify the areas where developers struggle. When a development team adopts new technology, it can look like they need help with everything. You should let them establish their knowledge for the actual pain points to emerge. Many of their early pains will disappear when they get used to the new tech.

You need to prove the platform’s impact, so a stable starting point is necessary for others to take your measurements seriously. Stakeholders may dismiss your improvements if they think it’s due to teams getting familiar with the technology and business domain.

Platforms must prove their impact on existing teams and the tech stacks they use. There will be many opportunities to merge technologies where teams solved a problem differently. Sometimes introducing a new tool for deployment or monitoring can remove pain from many teams at once. It’s crucial you can show the platform’s benefits.

Under-invested platforms

Once you’ve introduced a platform into your organization, it needs long-term investment to keep it usable. When a platform team disbands after delivering a product, the platform can become an anchor that adds drag to all who depend on it.

The context that led to the decisions you baked into the IDP platform can change, leaving teams stuck with old choices that no longer work. The platform will become so difficult to use that teams must migrate away from the platform to get their work done.

Platforms need to continually improve. You need to add new golden pathways and phase others out to ensure the platform continues to benefit the business.

You should limit the platform’s ambition to match the long-term investment levels.

Stretched platforms

If your organization has a fragmented technology landscape, it can be tempting to solve too many problems with the IDP. Suppose you support all existing tools and technology. In that case, the platform will become stretched too thin to be useful. Your platform team will be even more overloaded than the developers were.

A common cause of stretched platforms is measuring the platform team on internal market share. Adding more golden pathways is one way to increase market share, as the platform can help more teams. However, this defeats the goal of using the pathways to encourage consolidation around good technology choices.

MONK metrics can help balance market share with developer satisfaction and outcomes. This can help you avoid the problem of stretched platforms.

Other signs of trouble

Alongside common anti-patterns, you should watch for other signs of trouble. Common gaps can open when an IDP becomes available.

Self-service cost problems

When you make a platform with self-service options, you must ensure a strong story around how you track and control cost. If every developer spins up production-like environments, costs could rise out of control.

Any button that makes spending easy should include a feature to limit that spending automatically. This means test environments have short lifespans, and there’s a cap on concurrent environments.

There’s an opportunity for the platform team to bridge with the finance team on this subject.

General-purpose DevOps platforms

When platform decisions happen away from technical knowledge, there’s a temptation to try an all-in-one DevOps platform to solve all problems.

This doesn’t align with Platform Engineering or DevOps. If you buy a single general-purpose tool, you limit the platform’s capability and your continuous improvement abilities. The features of the tool constrain the solution for all problems.

Instead, you should design the platform as an internal product that solves specific pain points of development teams. Rather than opting for general-purpose tools, select best-in-class tools where you need them. You’re also likely to create reusable libraries that make it easier for developers to align with unified logging and telemetry design.

A golden pathway is not a tool, though it makes sense to increase the platform’s capability by leaning into specialist tools for builds, deployments, and monitoring.

Flexibility has two sharp handles

While platform teams aim to help development teams move towards a standard landscape, edge cases will always exist. A rigid platform will force development teams to exit and find alternatives. Talking with teams and listening for edge cases allows platform teams to counter edge cases and keep internal market share.

Equally, accommodating every scenario without any consolidation into golden pathways causes other problems. It could swamp the platform team with the complexity and cognitive load that Platform Engineering should remove. The best software products have a clear focus. They don’t try to do everything.

You should design the platform to allow teams to add edge cases without necessarily bringing the edge cases into support. Edge cases shouldn’t force people off the platform or increase the platform’s surface.

Don’t attempt to support every tech stack in the business. When you report on platform market share, highlight:

Total market size (all developers)
Size of the supported market (all developers using a tech stack supported by a golden path)
Market share (the number of developers using the platform)

The market share chart shows:

The total size of the internal developer market
How much of the market could use the internal developer platform
How many chose to do so.

You can use the chart to guide decisions for new golden pathways and track the platform’s appeal to its intended audience.

Platforms can’t solve culture

It’s easy to create a team. Building the interactions that make them successful is far more work. Team Topologies describe this using a combination of team and interaction modes.

If you create a platform team without paying attention to the design of interactions, it will fail.

Software delivery requires a high-trust, low-blame culture to succeed. Platform Engineering is no different. Culture is one of the biggest predictors of performance. Find out more about DevOps culture.

Building a platform isn’t a project. If you create an IDP, it must be a long-term strategy. When a platform is on-hold it limits the performance for all its users. This is worse than not creating a platform in the first place.

You need solid team design, clear interaction modes, and a platform as a product approach to build a good IDP.

How to do Platform Engineering well

Now you’ve seen many ways Platform Engineering can fail, it’s time to look at what success looks like.

In the Puppet State of Platform Engineering Report, 94% of respondents found the concept helped the organization realize the benefits of DevOps. If you have strong performance against the DORA Metrics, you’re likely to succeed with Platform Engineering too.

The internal developer platform is a product

The most critical sign of good Platform Engineering is that it’s run as a product. Developers are customers, and the platform should solve their problems to win internal market share.

If doing this well, you’ll have regular contact with developers, and measurable platform success criteria. If you have a product manager, the don’t only maintain a backlog. They should raise awareness of the platform and network with other departments to incorporate their needs. They help developers satisfy security, governance, risk, and compliance needs.

The platform needs a strong vision that inspires good decision-making. The platform shouldn’t support bad choices to gain internal market share. The product manager should capture decisions to refer to later on. It’s common for good decisions to get reversed when everyone’s forgotten the reason. A register of decisions can prevent mistakes.

By treating the platform as a product, you must ensure documentation quality stays high. High-quality documentation is crucial to product adoption.

Having a product-based approach and running a competitive product are vital signs of good Platform Engineering.

Use DevOps to build the platform

DevOps combines the following to increase software delivery performance:

Transformational leadership
Lean product management
Continuous Delivery
Organizational culture

The same capabilities will increase the likelihood of creating a valuable platform.

You don’t need to create a fully formed golden pathway immediately. Instead, solve 1 wide-reaching problem and iterate to success.

A typical pattern is to make it easy to:

Deploy common approved tech stacks
Provision infrastructure and create environments
Collect telemetry and error logs and track systems in Production

The underlying pattern is to find and abstract a complex area so the development team doesn’t get lost in the weeds. In some cases, an off-the-shelf tool will help with this. In other cases, the platform team might create a facade to simplify a tricky area.

The goal should be to start with the thinnest viable platform that supports developers where they most need it. It’s better to expand features slowly. Pick the areas with the most significant impact rather than trying to solve all problems.

For example, if your toolset has large JSON, YAML, and XML configuration sets, you could provide a unified format offering fewer options. Developers then only need to adjust 1 small file in a single format instead of many large files in different formats. You should provide considered default options for all the settings you don’t expose through the platform.

Another popular option is putting different tools and workflows behind a simple API for developers.

Make good build or buy decisions

Successful platform teams know when to build something from scratch and when to bring in a specific tool for the job. Many best-in-class tools for Continuous Integration, deployment automation, and monitoring offer features to the IDP.

It would be best to avoid general-purpose solutions that try to do everything, as they can become a limiting factor. A crucial platform capability is swapping out a tool without creating work for developers. Imagine changing your event logging tool. Without Platform Engineering, it may involve a list of applications to update and schedule many similar changes. The internal developer platform should lower the cost to change this by managing the swap behind the platform API.

No matter how you compose off-the-shelf and custom components, aim to:

Keep the developer in their preferred place, usually a text editor or IDE.
Make everything work seamlessly together
Provide snap-in solutions to common problems (authentication, logging, monitoring, for example)

A team that brings in specialized tools will create a more robust platform faster than when building everything from scratch.

Create the network

When developers adopt your platform, they should also become part of your customer network. The teams using the platform can help each other when they get stuck. Your long-term customers can share how they have used the platform to solve their problems. That can inspire other developers to adopt or extend their use of the IDP.

You can also create opportunities for different teams to discuss typical pain points the platform could solve.

Run like open source

Let the platform’s users contribute to it; they are all developers, after all! This is ‘inner sourcing.’

This means more than accepting code contributions. It also means you need to:

Publish contribution guidelines
Keep contribution documentation up to date
Think about how a suggested change may impact other customers

You can find more ideas at InnerSource Commons.

Keep an eye on progress

You need to track the platform’s impact to inform product management and ensure continued investment.

The MONK metrics are an excellent place to start. The MONK metrics are:

Market share
Onboarding time
Net Promoter Score (NPS)
Key customer metrics

Read more about the Platform Engineering MONK metrics.

Summary

There are several anti-patterns as well a strong pattern of successful Platform Engineering.

You’ll be more likely to succeed if you run the IDP as a product with lean product management techniques. You should capture the positive outcomes development teams achieve to encourage long-term funding from the organization.

Platform Engineering solves a particular set of problems. Team topologies provide many ways to design your team structures if Platform Engineering isn’t the right approach for you.

Navigating Platform Engineering with the maturity model assessment

Thu, 29 Jan 2026 09:29:41 +0000

The CNCF Platform Engineering community has been working on an assessment to accompany the Platform Engineering Maturity Model. It’s now available as a preview for feedback, but it’s crucial to understand its purpose to know what it can do for you and what you need to put in once you get your score.

The assessment is a series of multiple-choice questions that takes around 20 minutes to complete. It runs in your browser and no data is shared. Once complete, you’ll get a report card that shows you where you sit within the Platform Engineering Maturity Model.

Help us out by trying out the assessment and giving us feedback.

Platform orienteering

Picture yourself at the edge of a vast forest. You know there’s a destination somewhere out there, but between you and your goal lies unfamiliar terrain filled with hills, valleys, streams, and dense woodland. This is orienteering, the sport of navigating unknown territory using only a map and compass.

You can take part in orienteering with minimal kit. If you have a map, you can work out the rest using landmarks. Perhaps you’ll spot that distinctive hill in the distance, follow the bend of a river, or use a church spire as a reference point. But it gets a whole lot easier if you have a compass to tell you which direction you’re facing.

That’s why we wanted to add an assessment tool to accompany the Platform Engineering maturity model. Just like orienteering requires both a map and a compass working together, a successful Platform Engineering transformation needs a clear picture of the landscape and a way to determine your current position.

The maturity model is the map

In orienteering, a map is your window into the landscape. It shows you the contour lines that reveal steep climbs and gentle slopes, the symbols that mark forests, clearings, and water features, and the network of paths that connect different areas. But here’s what’s crucial to understand: the map shows you the terrain as it exists, not where you are within that terrain.

The Platform Engineering maturity model works the same way. It’s a detailed map that describes the features of the Platform Engineering landscape. It has the organizational structures, the technical capabilities, the process maturity levels, and the cultural elements that define different stages of platform evolution. It shows you what “good” looks like at various levels of sophistication.

What a map doesn’t tell you is where you are right now, or where you want to go. When it comes to your destination, it’s your journey, so it’s for you to decide. We’re each heading somewhere different, and that’s as true for Platform Engineering maturity as it is for choosing whether to head to a peaceful lakeside clearing or push for the challenging summit.

Some organizations want to reach the beach: a stable, reliable platform that serves their current needs without unnecessary complexity. Others are drawn to the heady heights of mountains, pursuing cutting-edge capabilities and pushing the boundaries of what’s possible with Platform Engineering. Both destinations are valid; the map just helps you understand the terrain that lies between you and your next waypoint.

The assessment is a compass

Once you have the map and an idea of where you want to get to, the one thing standing in your way is knowing where you are right now. In orienteering, you might recognize that hill over there and that stream down below, but you can’t orient the map correctly without knowing which way is north. You could be looking at the landscape upside down for all you know.

You can’t plan a route until you know your starting point. Are you at the bottom of the valley looking up, or are you halfway up the slope? Are you even on the side of the right mountain? The difference determines everything about your next steps.

This is where the Platform Engineering assessment comes in. It functions as your compass, not the magnetic but the organizational kind. It helps you work out which way around to hold the map and where you are within the Platform Engineering landscape. The assessment asks targeted questions about your current practices, capabilities, and organizational structures, then plots your position on the maturity model map.

With both map and compass in hand, you can finally see the whole picture: here’s where you are, there’s where you want to go, and now you can begin to understand the terrain you’ll need to cross to get there.

Route planning

When we were gathering feedback on the assessment during its development, one question came up repeatedly: “This is great for showing me where I am and where I could go, but how do I actually get from here to there?”

It’s a natural question. In orienteering, once you know your position and your destination, the next step is route planning. Do you take the direct path that cuts straight across that steep hill, or do you follow the longer but easier route that curves around the valley? Should you push through the dense forest or stick to the clearer paths that might add distance but save time?

At the moment, detailed route planning isn’t part of the assessment. Think of our current tool as a reliable map and compass combination, but not a complete GPS navigation system yet. The “SatNav version” that provides turn-by-turn directions is a later evolution we’re considering.

The assessment might prompt you about your intended destination and offer some general recommendations, like suggesting that organizations aiming for advanced platform capabilities typically need to focus on developer experience metrics or that teams targeting rapid scaling should prioritize automation investments. But we deliberately don’t want to remove human expertise and judgment from the process.

When we add more detailed recommendations in future versions, those recommendations will remain general enough to require customization. There’s always space for the next steps to be tailored by people who understand your organization’s unique context, constraints, and goals. After all, no two orienteering courses are exactly alike, and neither are any two Platform Engineering transformations.

Prototype assessment feedback

We are open to feedback for all elements of the assessment. For example:

Are the questions and answer options clear?
Did the result match your expectation?
Are the visualizations helpful or should we try something else?

The assessment scores responses for each category in the maturity model. This information is shown in three ways in the assessment’s output.

Spider chart: Uses the average score in each category to highlight strengths and weaknesses.
Matrix: Plots answer density to show the spread within each category.
Table: Displays average scores per category.

Helping you navigate

The assessment gives you the essential foundation: a clear understanding of where you stand and the possible paths forward. From there, the art of navigation, whether through forests or platform transformations, remains a uniquely human skill.

You can help by trying out the assessment and giving us feedback.

The top 5 features of internal developer platforms

Tue, 20 Jan 2026 14:59:13 +0000

Our Platform Engineering Pulse report looked at many aspects of real-world practice, but one interesting study area was the themes for common platform features. We're launching a broader study to investigate this further, but here are the top 5 features the platform teams we asked had added to internal developer platforms.

Build automation
Deployment automation
Infrastructure automation
Test automation
Monitoring and observability

1. Build automation

Build automation should be triggered each time you change the code and provide you with fast feedback on your changes. If you're practicing Continuous Delivery, you'll commit changes to the main branch every few hours, with the feedback from the build process, including fast-running tests, arriving in around 5 minutes.

The build process includes compilation, linking, and bundling. It usually consists of a suite of fast-running tests that validate the functionality and fitness of the application. In practice, this is typically a sequence of scripts or commands that run each tool in the build chain, but some build processes are more complex.

The benefit of bringing build automation into your internal developer platform is the opportunity to harmonize pipelines and bring them all up to a common standard for fast and secure builds. For example, instead of each team having to invent a way to sign their package so it can be verified later in the deployment pipeline, platform teams can make this a standard part of the build.

Development teams rarely touch their build process, compared to how much focus a platform team might put into builds. That means they are less familiar with the tools and may not be aware of features that could improve build performance or security.

2. Deployment automation

Manual deployments are one of the primary reasons for bad paths to production. Even simple manual deployments can go drastically wrong, and when they do, the organization responds by introducing process steps that slow down the flow of change. This is well-meaning, but we've learned that reducing deployment frequency results in larger batches, which carry more risk and cause bigger problems.

Deployment automation is the heart of change in your software delivery. When deployments are reliable, repeatable, and low-effort, you can teach the organization to do them more often. Automated deployments help you build trust and reduce heavyweight processes like change approval by committee, which universally clogs the ability to deploy small batches frequently and safely.

The steps, process templates, project templates, and policies related to deployments are a perfect fit for Platform Engineering. The platform team can ensure crucial steps are included in all deployments, like verifying the provenance of the packages being deployed and ensuring the packages and deployment process have progressed through appropriate environments before reaching production.

When the organization needs to level up security across all deployments, a platform team using the right deployment tools can quickly bring the whole organization into compliance with the new standards.

3. Infrastructure automation

There was a time when ClickOps was the default for infrastructure changes. Modern software teams have rejected the idea of managing their infrastructure by clicking around in administration consoles, cloud portals, and command lines, as the result is that no two instances of anything are the same. These differences, though sometimes subtle, can cause production incidents that are difficult to identify and resolve.

By treating infrastructure as code, the definitions can be stored in version control and follow the same review and promotion patterns developers apply to application code. When infrastructure is created and managed this way, each instance is an identical copy, and it's easier to scale out, recover from a disaster, or create ephemeral environments for testing.

Platform teams can create standard setups for teams to use that are aligned to the technology choices in their golden pathways. Reducing the breadth of choice makes it easier to secure the infrastructure, control costs, and apply patches and updates.

4. Test automation

Sometimes it seems there are automated tests everywhere, from unit tests that run continuously in the background as a developer makes changes, to tests used in the build process, to validate end-to-end functionality, and test the fitness of the application's performance and security. The reason for their prevalence is that testing really works.

Without test automation, your team would need to perform the same checks manually, and when you don't do it, your customers do, which is incredibly frustrating.

While platform teams don't typically write tests (the research shows the most effective automated tests are written by the developer creating the feature), they can provide the tools that make it easy to define tests and have them run throughout the software delivery process. Platform teams may also provide easy ways to consume test services, making it easy to spin up end-to-end tests or performance tests without managing infrastructure.

To shorten feedback loops, all types of testing should be performed continuously and ideally represented by fast, reliable test automation suites. You should cover functional, security, and performance tests within your deployment pipeline.

You should consider how test data is managed as part of your test automation strategy. The ability to set up data in a known state will help you make tests less flaky. Test automation lets developers know early if their change causes a fault, reduces team burnout, and increases software stability.

5. Monitoring and observability

The ability to see information-rich logs can help you understand how faults occur so you can design a more robust system.

Other popular features

Though they didn't make it into the top 5, documentation, security scanning, one-click setup for new projects, artifact management, and secrets management are common features of internal developer platforms.

The features are useful on their own, but when combined, they amplify their effects on overall software delivery and operational performance. Platform teams who provide a seamless toolchain from commit through to production and on to day 2 operations will find they have lifted a massive burden from developers.

What high performers do differently

The high-performing organizations used the amplification effect to provide a complete toolchain for deployment pipelines. Platforms that provided this set of functionality had more impact on the organization and its goals for Platform Engineering.

Builds
Test automation
Artifact management
Deployment automation
Infrastructure automation
Monitoring and observability

By creating a strong pipeline with equal consideration for long-term sustainability of the platform, you can create an offering that helps developers today and continues to help them as the organization navigates changing requirements, regulations, and competition.

We also looked at organizations with low performance; they were often missing 3 key features:

Test automation
Artifact management
Monitoring and observability

If your platform is missing any of these, you may be missing an opportunity to amplify the benefits of platform adoption.

Platform success

Throughout our study, we used each organization's individual definition of success for its platform. There are many different motivators for funding a platform initiative, and the ultimate test of a platform is whether it meets the specific goals it was founded to achieve.

You can use the MONK metrics to measure your Platform Engineering initiative. They balance benchmarkable metrics with contextual measures that track the platform's progress against the organization's goals.

Despite the many different ways platforms are measured, the presence of a complete feature set increased the chances of success.

Happy deployments!

DevOps team structures

Fri, 16 Jan 2026 14:34:30 +0000

As Jim Benson says in The Collaboration Equation, 'individuals in teams create value'. Individual skill combined with collaboration is where great things happen. Under-performing teams happen when you don't build in the need for people to work together to unlock their unique talents.

Since DevOps became the industry buzzword, many examples of anti-patterns emerged. However, patterns and anti-patterns mean nothing when you put people into a room and ask them to solve a problem or deliver value. Rather than one true way of organizing teams, you need to pay attention to:

Culture and context
The skills of each individual
What systemic issues might be stifling collaboration.

You don't need to start from a blank page. Look at existing DevOps team structures that other organizations use in certain circumstances. Interaction models can help you understand the nature of dependencies between teams.

DevOps

The original idea for DevOps wasn't to change team structures at all. It was about development and operations teams working more closely to deliver software. To make this happen, you had to remove conflicting goals. After identifying and fixing systemic value-damaging behaviors, collaboration becomes possible.

Many organizations were already familiar with cross-functional teams. Unsurprisingly, operations folks began moving into existing software delivery teams to work with other disciplines, like software developers, testers, and product managers. Having one team makes it much harder to find conflicting goals.

Other organizations formed a team between development and operations, often called a 'DevOps team.' This is generally an anti-pattern, but if it results in more collaboration and shared understanding, it's a step toward better outcomes. It's likely to succeed if the team has members from both existing teams and where it's a stepping stone to cross-functional teams.

DevSecOps, BizOps, and others

Your organization's primary silo boundary might not be between development and operations. Many organizations used variations of DevOps as an internal campaign to increase collaboration. This is where DevSecOps and BizOps encouraged specialists to work closer together.

You might use BizOps to highlight a disconnect between the business and the teams supplying their tools. To make this successful, you must repeat the DevOps process of finding conflicting goals and other barriers preventing teams from working together. The name alone won't change anything.

You can expand the idea wherever you find silos separating people that need to work together. If you have many silos, you must address the core cultural issues causing these defensive barriers. The section on Team Topologies can help you redesign your teams and interactions.

Measure all DevOps initiatives on organizational outcomes rather than local measures.

In all cases, the DevOps research and modelling covers leadership, culture, and technical practices. DevOps bakes in collaboration, with many opting for cross-functional, autonomous teams. These other names reflect pressing concerns for specific organizations.

DevOps PATHS

There are two common mistakes in DevOps team design:

Hiring one person for each skill, which creates silos-of-one
Loading a single person with too many skills and causing cognitive overload

You can only avoid these two extremes by adopting a position somewhere in the middle. You must find a mix of people who bring different skill combinations to the team. It's a complex task as each person you add changes what you need from the next person.

To help you design your teams, you can use DevOps PATHS.

PATHS stands for:

Process (Lean, Agile, Kanban, DevOps, Continuous Delivery, Extreme Programming)
Automation (scripting, tools)
Technical (Programming, architecture, cloud)
Human (communication, culture, empathy)
Specialist (development, operations, security, test)

Using PATHS can help you balance individual silos and cognitive overload.

You can use DevOps PATHS to detect common accidental team structures to fix and avoid long-term problems.

Hero teams

Teams filled with specialists, like software developers, are 'Hero teams'. One highly-skilled team member manages builds, deployments, and responding to service outages.

In some cases, the hero gets a role such as DevOps engineer. Often they are just passionate about the broader software delivery process and want to improve it.

In the long run, the burden on this team member can lead to burnout. It's not great for the individual, and it's bad news for the organization when their performance drops or they leave.

Use DevOps PATHS to detect dense skill clusters and encourage team members to explore other areas they have an interest in. It helps you spread the knowledge and load more evenly.

Blinkers

A team with blinkers is performing well against many of the PATHS skills, but there are massive blind spots. They may be delivering a great product but with low automation. The lack of automation isn't clear during regular operation, but it takes a long time to deploy a fix when you discover a critical production issue.

Over the long term, cracks start to appear, spreading from the blind spots into areas the team initially did well. Many low-performing teams were previously blinkered teams that were delivering well.

Use DevOps PATHS to detect skill areas with little or no coverage and look for champions in the team to grow into those subjects.

Using DevOps PATHS

As well as these examples, many other designs are problematic over the longer term. The DevOps PATHS provides a way to address overloaded team members and skill gaps.

By creating communities of practice around each of the five skill areas, you can:

Encourage knowledge sharing
Highlight critical skills you need in the team
Spread ideas across team boundaries

You can use your skill map when team members are looking for growth opportunities or during the hiring process.

Team size and composition are part of management's broader system design. As teams grow, individual productivity decreases, but you're more resilient to sickness, holidays, and team members moving on to new roles.

It's easy to create a team with all the needed skills by hiring many people, but the team won't have resilience as each member handles a small, isolated area. A professional manager's job is to build a team with a strong mix of skills with overlap while keeping the team as small as possible.

Team Topologies

You can revisit your understanding of these DevOps team structures using Team Topologies. This model recognizes that communication within a team is high-bandwidth. How closely aligned two teams are can affect the speed that information moves between them. In some cases, information flows very slowly.

You can take this into account when you design teams. This doesn't mean putting people together if they will regularly share information. You also must solve problems causing unnecessary communication.

For example, if everyone needs to speak to a team developing an API, it's possible the API:

Isn't well designed
Has many problems
Isn't self-documenting

You can also use the 4 fundamental team topologies to understand a team's role, responsibilities, and interaction mode. The 4 team topologies are:

Stream-aligned
Complicated subsystem
Enabling
Platform

You don't need a team of each type, but any given team should resemble one of the 4 types. The authors describe this as a series of magnetic poles, with each team attracted to one type.

Stream-aligned teams

Stream-aligned teams work on a single valuable stream of work, usually aligned to a business domain. They might focus on a specific feature or group of features, work only on one user journey, or align with a particular persona.

A stream-aligned team works on everything needed for delivery. For example, the team would discover user problems and operate and monitor the system in production. When you view a stream-aligned team, they have no critical dependencies on any other team. They have all the necessary skills to deliver value.

Finding the right mix of individuals to create a small team with the necessary skills is challenging. Still, the results are high-bandwidth information flow and increasingly brilliant collaboration.

Complicated subsystem teams

Where part of your system is highly specialized, you might use a complicated subsystem team to manage it. You shouldn't create this team unless circumstances force you. For example, if the skills needed are so specialized, you must pool them.

Stick with stream-aligned teams wherever possible. If you have to create a groundbreaking 3D rendering engine, you may need a complicated subsystem team to handle the challenges.

Enabling teams

An enabling team takes a long-term view of technology to bring a competitive advantage to organizations.

They research potential new:

Tools
Capabilities
Practices
Other technologies

They protect the autonomy of stream-aligned teams by helping increase skills and install new technology. As an enabling team, the goal is to give the knowledge to teams, not to dictate what they do with it.

Enabling teams are helpful as a part of a scaling strategy, as stream-aligned teams are often too busy to research and prototype new tools and technology. The enabling team can explore the new territory and package the knowledge for general use within the organization.

Platform teams

A platform team acts like an enabling team that packages the knowledge into a self-service offering. Stream-aligned teams can use the products created by platform teams to simplify and accelerate their work.

Platform teams promote good technical practices by making good decisions easier to access. They help stream-aligned teams achieve more.

Interaction modes

Even more useful than the team types are the interaction modes. The interaction between two teams should be one of the 3 interaction types:

Collaborating
Facilitating
Providing a service

Classifying each interaction can help you understand the nature of dependency and the level of service offered. You will likely interact with teams differently, but each relationship should be identifiable as one of these modes.

Platform Engineering

Platform Engineering is often found alongside DevOps and has a strong link with software delivery performance. It intersects with team topologies, as platform teams have many 'as-a-service' interactions with the other team types.

Platform teams work with development teams to create one or more golden pathways. These pathways don't prevent teams from using something else but offer supported self-service products that help teams improve delivery capability. The pathways encourage alignment without removing team autonomy.

The Accelerate State of DevOps Report shows that you commonly find Platform Engineering teams in high-performance organizations.

Category	% with Platform Engineering
Low	8%
Mid	25%
High	48%

If you're expanding the number of teams delivering software, Platform Engineering offers consistency without stifling team choice. Because your teams don't have to use the platform, it benefits from competition with other software delivery pathways.

Site Reliability Engineering

Site Reliability Engineering (SRE) solves operations as if it's a software problem. The SRE team strongly focuses on performance, capacity, availability, and latency for products operating at massive scale. Google pioneered this approach to manage continental-level service capacity.

Although the role of SRE is to impact reliability, many aspects of Site Reliability Engineering align with DevOps concepts.

Cross-functional collaboration
Extensive automation
Empirical learning
The use of measurement techniques

SRE practices are commonly found in DevOps teams, regardless of if they formally adopt them. DORA's research has found reliability unlocks the effect of software delivery performance on organizational outcomes.

Summary

You shouldn't judge team design from an external perspective. Every organization is on a journey of continuous improvement. You can only assess their current state relative to how things were before. The objective is higher collaboration and continuous improvement. If an organization achieves these goals, it's irrelevant that it looks like an anti-pattern from the outside.

Problematic team designs (like hero teams or dedicated DevOps teams) are necessary for stable long-term solutions.

You can use DevOps PATHS and Team Topologies to inform your team design. Take inspiration from Platform Engineering and Site Reliability Engineering when you need to scale.

The needed conditions for success are:

A high-trust, low-blame culture
Transformational leadership
Lean management.

The technical capabilities will have less effect on your outcomes without these prerequisites.

Your IDP needs DDD

Tue, 13 Jan 2026 12:14:52 +0000

It has been more than two decades since Eric Evans published his book on domain-driven design (DDD). The idea was to create software designed after the business domain, using the same language and mental models people used outside of the software team.

We don’t talk about domain-driven design much these days. But as George Santayana said: “Those who cannot remember the past are condemned to repeat it.”

As Platform Engineering grows into a movement at scale, we need to revisit the past and apply some lessons from domain-driven design to our internal developer platforms (IDPs). Otherwise, we continually step on rakes to learn why they shouldn’t be left on the lawn.

There’s a host of interesting interconnected ideas in domain-driven design, but one that resonates with Platform Engineering is the concept of a core domain.

What core domains are

When you build software, there are several areas where your innovation, opinions, and solutions create unique value for your organization. You also need many things that don’t add much value, but your software isn’t viable without them.

Let’s use a pizza restaurant as an example. If you sell pizza, you want to make it easy for customers to choose what they want to eat and have it delivered. To complete the process, you need to look up their address and take a payment.

Core domains are the areas where you want to do something different that will give you a competitive edge. For your pizza company, that might be how you present the menu, collect customizations, and offer deals and rewards.

Non-core domains, also called generic domains, are areas where innovation and differentiation make little difference, or where doing things differently may even be undesirable. Customers expect that looking up their address and paying will work like elsewhere. They don’t want you to be innovative here, as it makes it harder to use.

So, core domains are something unique or special to your organization. It’s essential to your business’s existence, and where you should invest the most. This is something you want to do so well that it’s hard for your competitors to copy.

The problem of generic domains

When you spend time on generic domains, you direct time, attention, energy, and investment away from the areas that impact your organization most. Generic domains have limited value because they don’t benefit from doing something different or unique. The pizza company will never create such an excellent payment flow that you’d choose their offering over a competitor who offers better customization.

Generic domains can be just as complex as your core domains, which means they can consume large amounts of investment. Suppose there’s a commercial provider of an offering in your generic domain space. In that case, they’ll be treating it as a core domain and innovating the space, which puts additional pressure on you to invest to avoid falling behind user expectations.

Organizations that avoid the generic domain trap can outpace their competitors as they spend more time working on features that will make them stand out.

How to tame generic domains

There’s an easy way to avoid the generic domain trap. Domain-driven design provides a pattern for managing them, which recognizes the asymmetry in the value gained by investment in core domains versus generic domains.

Instead of reducing costs on paper, the goal is to minimize the real cost of working on generic domains: Lost value.

Press enter or click to view image in full size

You should work through this list from the top and choose the earliest exit available.

Off-the-shelf: Look for existing software or services that address the generic domain. In particular, look to use:
Commercial products and software-as-a-service offerings where the provider treats it as a core domain. Their innovation and support will ensure the generic domain doesn’t become an anchor dragging you back.
Open source tools that are robust and maintained, and where the overheads of adopting and updating them are low.
Isolation: Where you have to build custom code for a generic domain, encapsulate and isolate it. Placing it behind a well-defined interface minimizes the impact on your core domain and lets you switch it out if an off-the-shelf solution emerges later.
Outsourcing: While outsourcing your core domain can cause problems, outsourcing generic domains helps control the cost and distraction of the work. You can define the interface and have an outsourced team focus on the implementation details.
Minimalism: When no other option is available, create a simple minimalist solution that meets the immediate need. Don’t over-engineer the generic domain or add features you don’t need. You can be reluctant to iterate the solution and keep your eyes and ears open for when someone creates a software product or service you can use to replace it.

Analyzing build versus buy

Platform Teams who want to create the most significant force multiplier for the developers they serve need to protect their focus on fitting the tools to the organization. To do that, they need to identify and eliminate areas where their skills are wasted.

A crucial part of this optimization process is performing a solid build versus buy analysis, which should factor in the initial development cost, ongoing maintenance and support costs, and the opportunity cost of diverting resources away from the core domains.

Returning to the pizza restaurant, offloading the address lookup to a vendor that commonly provides this feature will mean users are familiar with how it works. The vendor will dedicate more attention to improving the user experience of their tool, and when the vendor introduces innovations, they appear commonly enough that users accept them.

Similarly, you’d want to offload payments to a fast and secure payment provider. Hence, it works like other sites and keeps pace with developments like 3D secure, tokenization, card security codes, multi-factor authorization, and biometrics. These industry innovations would have forced the developers to revisit this generic domain many times just to keep pace with the baseline.

Why this is crucial for Platform Engineering

Domain-driven design (DDD) tells us to optimize our development efforts where they will have the most impact on the organization’s success. You shouldn’t over-invest in non-core domains, as they have limited business value and drain resources. Building custom solutions for non-core domains brings unnecessary complexity and maintenance burden, and for what? To build something that you could have bought or outsourced.

The software industry is about to re-learn the lessons that led to the discovery of domain-driven design. Industry-wide, we are dedicating thousands of developers to building the same thing. Not a simple minimalist solution to fill a gap left by commercial products, software-as-a-service, or open source software, but a million giant platforms that are out of date before they’ve been pushed to production.

Internal developer platforms sink unless platform teams can shift weight down to underlying tools. By transferring ballast to commercial products or open source tools, the platform team can get back to agility and create simple, minimal solutions that handle real gaps in toolchains caused by truly bespoke needs.

And it’s these very needs that are missed with behemoth platforms. An organization that needed to go an extra two miles on security may adopt Platform Engineering to tailor a truly robust solution to their security needs. As that platform grows and accumulates additional custom features, the focus on security is lost, and the investment is wasted building and maintaining code that doesn’t solve a unique need for the organization.

But it’s not all doom and gloom for Platform Engineers. Commercial and open source tools can rescue them from this inevitability by providing features that make it easy to shift the weight down and keep the platform light enough to float.

Float on our Platform Hub

That’s where Platform Hub comes in. By adding features platform teams need, like process templates, project templates, and policies, platform teams can transfer the effort down to Octopus and lighten their platform by removing thousands of lines of bespoke templating code.

Platform Teams can get back to focusing on the unique needs that make their platform vital to their organization. They will benefit from our innovative mechanisms for template management and policies, which go well beyond the attack of the template clones and the synchronization conflicts that platform teams report with their bespoke solutions.

Happy deployments!

How organizations measure Platform Engineering

Fri, 09 Jan 2026 07:40:46 +0000

Our Platform Engineering Pulse report is coming soon, containing insights, strategies, and real-world data on how organizations adopt and succeed with Platform Engineering. We’ll also launch a survey to deepen our understanding of the patterns, challenges, and future direction of successful platform building.

One of the areas we explored in the Platform Engineering Pulse report was how organizations measure their internal developer platforms, with results that varied from technical measures to not collecting any metrics at all.

This post looks at which metrics were popular and how you can use them to structure your measurement approach to avoid the zero-metric illusion.

Measurement is essential

At the start of a Platform Engineering initiative, the immediate problems take precedence, and measurement becomes an afterthought. This leaves platform teams without a pre-platform baseline, which makes it challenging to demonstrate the platform’s impact.

The lack of measurement also increases the risk of platforms adding features that don’t align with the organization’s core motivations. For instance, a platform team might focus on standardization, only to discover that the primary driver for investing in Platform Engineering was to improve developer experience.

Platforms often fail not because they are inherently bad, but because they target the wrong personas and attempt to solve the wrong problems.

Even successful platforms struggle with ongoing justification and optimization when they lack clear goals, a robust measurement system that reflects those goals, and baseline data. The platform team may find leadership challenges continued investment if they can’t show the platform’s value.

Therefore, it is crucial to measure platform performance against its established goals. But how are organizations currently approaching this?

What organizations measure

The survey found organizations focused on 3 key areas for measurement: Software delivery, operational performance, and user experience. The variety of metrics likely reflects the variety of contexts that platforms can assist, though is also evidence that metric systems are skewed to the elusive productivity problem rather than true developer experience and engagement.

Software delivery metrics

The software delivery metrics assess the speed, quality, and throughput of development teams using the platform. They often align with DORA measurements, highlighting how platforms are seen as a route to shipping software more often and at higher quality. The metrics encompass throughput (e.g., deployment frequency, build time, features delivered) and stability (e.g., change failure rate, build success rate).

Deployment frequency
Deployment times
Change failure rate
Recovery time
Build success rate
Build time
Features delivered

While valuable for understanding delivery performance, these metrics primarily reflect downstream outcomes rather than the platform’s direct contribution to developer productivity. They are most effective when measured before and after platform adoption to demonstrate improvement.

Operational performance metrics

Metrics for operational performance track the cost, performance, and efficiency of applications that use the platform. They combine traditional infrastructure monitoring (e.g., reliability, error rates, system performance) with resource optimization (e.g., usage efficiency, cost management). Project count is a basic adoption indicator, but it lacks the context of the addressable market size.

Reliability
Error rates
System performance
Resource usage
Infrastructure cost
Project count

These metrics are crucial for demonstrating that the platform is operationally sound and cost-effective, but they don’t necessarily indicate developer value or ease of use.

User experience metrics

These metrics directly measure how developers and teams perceive and interact with the platform, treating internal developers as customers. They focus on satisfaction and onboarding journeys. Net promoter score (NPS) offers benchmarkable sentiment data, while user satisfaction provides broader feedback. Onboarding time is critical as it represents the first impression and adoption barrier.

User satisfaction
Net promoter score (NPS)
Onboarding time

These metrics are vital for platforms run as products with optional adoption, indicating whether the platform is compelling enough for developers to choose and continue using voluntarily.

Most organizations prioritize technical and delivery metrics, with fewer focusing on user experience or business outcomes. This suggests a risk that platform teams are measuring what’s easy to collect rather than what truly demonstrates business value. The heavy emphasis on technical metrics indicates that many organizations still measure platforms like infrastructure rather than products serving internal customers.

How measurement improves platform performance

For metrics to improve platform performance, you need to measure multiple dimensions, not just one. Internal developer platforms offer many benefits, so the measurement system should cover all platform goals.

We found organizations that measure more dimensions were more likely to be successful. A single metric gives you a one-in-three chance of creating a successful platform, while 2 metrics make it 50/50. Organizations measuring 6 or more metrics were most likely to be successful.

Platform sponsors may expect you to deliver technical reliability, boost developer productivity, offer a positive user experience, manage costs, encourage adoption, and align with business objectives. Relying on just a handful of metrics cannot adequately capture the interplay of all these dimensions.

Breaking the success illusion

The data shows a zero-metric high-success effect. This occurs when organizations that don’t collect any concrete measures of the Platform Engineering effort report high success rates. This phenomenon comes from two very different situations masquerading as the same outcome.

There may be easy and obvious success criteria the platform can address, such as a critical and evident problem where success is undeniable without formal measurement. Where the effectiveness is apparent, formal measurements may be unnecessary. A more likely explanation is that there’s an illusion of success caused by a lack of measurement.

Without concrete metrics, platform teams can focus on outputs (e.g., features built, no outages) rather than actual outcomes (e.g., increased developer productivity, achievement of business goals). Stakeholders may mistake activity for impact, especially if the team is busy and there are no apparent failures.

This also helps explain the dramatic increase in success rates observed when moving from one metric to three or more. Teams relying on a single metric might choose one that doesn’t capture holistic success, leading to a false sense of achievement. However, when multiple dimensions are measured, maintaining illusions becomes difficult. For instance, you can’t claim unqualified success if deployment frequency is high but Net Promoter Score (NPS) is low.

The data also suggests a dangerous middle ground where minimal measurement can create more problems than no measurement. It provides false confidence without the comprehensive feedback necessary for genuine improvement.

Using MONK metrics

MONK metrics offer a balanced approach to measuring Platform Engineering success, combining external validation and internal alignment. This framework is more adaptable than purely technical metrics, yet still provides a standardized basis for comparison and improvement.

The MONK metrics are:

Market share
Onboarding times
Net Promoter Score (NPS)
Key customer metrics

The first three, market share, onboarding times, and NPS, form a benchmarkable trio. These metrics allow for comparison against industry standards and are broadly applicable to Platform Engineering initiatives, serving as a starting point to understand high performance in other organizations. For example, if your onboarding times are slower than those of your industry peers, you can investigate their methods and implement similar improvements.

Including “key customer metrics” is crucial for preventing the measurement framework from losing touch with business realities. Organizations kick off Platform Engineering to solve specific organizational problems, but their success is measured using generic technical metrics that don’t reflect the original investment’s purpose. Instead, it’s essential to translate the motivations behind adopting Platform Engineering into the key customer metrics to track progress towards the platform’s objectives effectively.

MONK metrics address the common issue of platform teams optimizing for metrics that appear favorable but don’t contribute to actual business value. For instance, if you introduce Platform Engineering to reduce time-to-market, measures of infrastructure uptime or build failures fail to track tangible improvements in delivery flow.

Lack of measurement makes your platform vulnerable

Without measurement, platform teams end up in a vulnerable position. They can’t demonstrate their value when budget discussions come up, they can’t identify what’s working versus what needs improvement, and they can’t make compelling cases for continued investment or expansion.

The absence of data also hinders course correction. Platform Engineering involves complex trade-offs between developer experience, operational efficiency, security, and cost. Without clear metrics, teams may prioritize visible or politically expedient solutions over those that deliver actual value.

MONK metrics offer a practical solution. They are accessible, enabling organizations to begin measuring with minimal tooling or data infrastructure. You can gather basic market share data through surveys, track onboarding times simply, and get NPS using lightweight feedback tools.

Their benchmarkable nature also helps address the common “what’s good enough?” dilemma. Instead of abstractly debating whether a two-day onboarding time is acceptable, teams can compare their performance to similar organizations.

SHIPPED25: The Research Panel

Tue, 09 Dec 2025 21:43:05 +0000

In this panel discussion, Matt Allford, Charlotte Fleming, and Steve Fenton walk through some of the key findings from the research projects that took place at Octopus Deploy this year.

The State of GitOps report

The State of GitOps report investigates the adoption, practices, and benefits of a GitOps approach. Our research is based on data from 660 survey responses and interviews with a panel of experts and practitioners.

The Platform Engineering Pulse report

The Platform Engineering Pulse report reveals how organizations implement Platform Engineering today, what's working, what isn't, and why. We surveyed technical professionals across industries and roles to understand the gap between Platform Engineering theory and reality. The research explores what drives adoption decisions, which platform features deliver real value, how teams measure success, and which strategies actually move the needle.

Compliance through Continuous Delivery

This report, surveying 50 financial organizations in 2025, shows how automated Continuous Delivery pipelines can simultaneously increase throughput and stability, resolving the speed-versus-safety trade-off.

Measuring Platform Engineering with MONK metrics

Wed, 05 Nov 2025 14:29:12 +0000

When you create an internal developer platform, treating the platform as a product is crucial. That means you need to measure progress with a product mindset, too. The MONK metrics help measure your progress and prove the value of Platform Engineering to your organization.

Measure Platform Engineering with MONK metrics

MONK metrics mix platform adoption and performance with metrics to show impact on the platform’s customers; the developers:

Market share
Onboarding time
Net Promoter Score (NPS)
Key customer metrics

Your market share is the number of developers who use the platform rather than an alternative. You must run a regulated market, so you can’t force people to use your platform. Developers who opt not to use the platform must have the same responsibility to deliver security, reliability, and governance requirements.

Developers should have the option not to use the internal developer platform. The platform team should respond competitively by improving the platform to gain market share. If developers move off the platform, find out why. Take a second look at your relationship with developers and explore why they didn’t flag an issue before moving away.

To understand your market share, you should track the number of developers:

In the organization
The platform could help
Using the platform

When you need to choose between possible features for the platform, it helps to consider the impact it will have on market share. What problems are causing pain for development teams that your platform could solve? Understanding the share, and the trend over time, can help your decision-making.

You can increase your market share by supporting more scenarios or convincing teams to move onto an existing ‘golden pathway’. Avoid adding workflows you can’t do well and focus on spreading the joy developers will experience by adopting one you can handle.

Onboarding time

Your internal developer platform should shorten the time it takes to get a new developer’s first change into Production. New developers should find it easier to start as the platform simplifies workflows and removes the need to learn some underlying technologies.

You should also track the onboarding experience for teams adopting the platform. Opting in should be easy, and the benefits should be quickly apparent. Developers don’t have weeks to invest in platform adoption, so you need to make the onboarding process swift and easy. Building case studies with teams using the platform will help convince others to consider it.

Net Promoter Score

Net Promoter Score (NPS) is a popular market research metric used by two-thirds of the Fortune 1000. Your organization may already collect this from end customers, but you must also collect the platform NPS from the developers. You only need to ask one question to collect NPS, collecting a score from 0 to 10 as the answer:

How likely are you to recommend the internal developer platform to another developer?

You can group responses based on the answer:

0–6: Detractors
7–8: Passives
9–10: Promoters

To calculate the score, take the percentage of promoters, and subtract the detractors.

Score	% of responses
0-6	20
7-8	35
9-10	45

With the table above, you can ignore passives (35%) and calculate the NPS as promoters (45%) minus detractors (20%). So, a net promoter score of 25.

Positive scores are good and negative scores need improvement. The software-as-a-service industry has an NPS in the range of 30 to 40, according to Beamer and userpilot.

A downward trend in NPS can show the platform fails to address an essential developer pain. It may also suggest developers are considering a move away from the platform.

When you collect NPS, you should ask further questions, not least why the user chose their score. This provides valuable product feedback. Don’t pester the same customer for feedback too often and limit how many survey questions you ask as you want to show you respect their time.

Key customer metrics

Your customers, the developers, are also tracking their own success metrics. For example, they may use DORA metrics or the SPACE framework. When talking with your customers, ask what measurements they care about and find ways to track them.

Many platforms are introduced to improve developer experience, reduce cognitive overload, and prevent burnout. Whatever motivated your organization to invest in a platform will be something to track over time.

You can help developers achieve or exceed goals by adding needed features to the internal developer platform. If you do this, they’ll love the platform and encourage others to adopt it. The DevOps capability model can help find techniques or practices you can add to your golden pathways to improve software delivery and operational performance.

Summary

Don’t only collect numbers. Regular conversations with developers are crucial whether they use the platform or not. Your customers (and potential customers) know their pain points and can help you find areas to help.

Regular customer interaction shows you run a healthy Platform Engineering effort.

MONK metrics help you:

Define the product roadmap for your internal developer platform
Start essential conversations with customers
Show the platform’s value to the people who pay to build it

MONK metrics should be part of your product management strategy. You also must speak to developers to find out more and keep track of the problems they care about.

Hello World! Welcome to the Platform Engineering Group!

Mon, 03 Nov 2025 15:13:56 +0000

We’re excited to have you here! This is a space where you can share, learn, and connect with other developers who love Platform Engineering and Team Topologies.

Start by saying hi!

Introduce yourself in the comments below—tell us your name, what you’re working on, or something fun about yourself. We’d love to get to know you!

Once you’ve said hi, you can:

Share your Platform Engineering tips or interesting projects.

Ask questions and get feedback from the community.

Comment on and support other members’ posts.

We’re happy you joined the Platform Engineering Group and can’t wait to see your contributions. Let’s make this a friendly and helpful place to learn together!

8 Real-World Reasons To Adopt Platform Engineering

Tue, 29 Jul 2025 17:21:32 +0000

Everyone wants to deliver software sooner and consolidate tools and practices. A platform that considers these needs will likely achieve further benefits.

There’s a clean, academic version of platform engineering. When we detect an increase in burnout as we scale and trace it back to cognitive load caused by software delivery and infrastructure complexity — bingo! — it’s time to add platform engineering.

But this neat and tidy path to adoption doesn’t match reality. The reasons for adoption rarely fit the cognitive load category, and understanding motivations for platform engineering in the wild will help those considering its adoption.

This topic is under active investigation, and I’ll outline what we’ve learned so far.

Who Drives Platform Adoption?

An internal developer platform (IDP) may serve the needs of many business units. You might find ways to streamline governance, risk and compliance requirements, or help finance with cost control. However, the drive for IDP adoption almost always comes from developers and technology leaders within the organization.

The Top Drivers for Development Teams

Tool Consolidation

Your tool chain is more likely to become fragmented the further you scale your development organization. With many teams, discovering the needs that trigger tool selection can happen at different times, and without the knowledge that other teams have already solved the problem. Capturing and sharing decisions with other teams is hard in a large organization. You might also add teams as part of an acquisition, and they often bring their unique tools into the mix.

Whatever the reason, the need to reduce the number of tools that solve the same problem is often an inciting factor when development teams look to platform engineering.

Converging on a set of good practices is another popular reason internal developer platforms are built. Most development teams will share a set of requirements around security, compliance and cost control that can be solved by an internal developer platform. There is also the opportunity to create blueprints for good practices around source control and deployment pipelines.

As these practices become table stakes for professional software development, developers are keen to use platforms that make it easier to achieve them.

Reducing Duplication

Developers often find that other teams are inventing solutions to problems that they have already solved. They want to spend less time reinventing the wheel and more time working on feature development.

The nontechnical aspects of these solutions may be the crucial area of platform engineering. Creating golden paths simply adds another solution to the existing pile, so communicating the benefits will be as important as creating a great developer experience.

Shipping Early and Often

Though continuous delivery has many benefits, developers love it because it makes their work more satisfying. It feels good to get your changes to users quickly and safely. When you never have a large-scale merge, work in small, understandable batches, and can perform stress-free deployments, you no longer dread coming to work on a Monday (or deploying on a Friday!)

The Top Business Drivers

Process Consolidation

The theme of consolidation continues when business leaders look to platforms to reduce process differences across development teams. This subtly differs from standardization, as it’s not about forcing teams to adopt identical working practices. Instead, platforms can ensure that crucial process elements are achieved.

To illustrate, it wouldn’t matter if one team used scrum while another used Kanban: The internal developer platform would ensure the same policies were applied to changes as part of the deployment pipeline.

Speed to Market

Business leaders are also looking to platforms to improve speed to market. But while developers like shipping early, often because it increases job satisfaction, business leaders like responsive software delivery for different reasons. Features can be tested with users sooner, and fixes can be applied without a special process to expedite them.

Solving Problems Once

A large organization is likely to have solved the same problems many times in different ways. If you could put a monetary value on these efforts, the platform would likely pay for itself by eliminating that duplication. When every team is tasked with solving deployment pipelines, infrastructure automation and other shared concerns, it can add up to years of lost feature development.

That’s why business leaders want to create a future where these problems are solved well — and solved once.

Improve Reliability

One of the challenges for modern tech leaders is recognizing when things go well. In the past, individual skill in resolving critical situations was well rewarded, but we should now be rewarding setups that don’t require heroic behavior. If your deployments are stress-free and your application doesn’t regularly collapse, this might be your reminder to recognize the team’s efforts.

However, reliability is also a key reason business leaders are considering platform engineering.

Familiar-Sounding Needs

The business and technical motivations for platform engineering echo the same needs. Everyone wants to deliver software sooner and consolidate tools and practices. A platform that considers these needs will likely achieve further benefits, even if it was motivated by other factors.

You’ll need to normalize your technology stack before automation and self-service will be successful. By reducing the landscape, you reduce the complexity of improving and automating what remains. If you skip past the normalization stage, you simply shift the burden from the development teams to the platform team.

The forced standardization approaches of the past never stuck, and may be responsible for some of the chaos we see today. When the approved tool chain doesn’t work and there’s no easy way to challenge standards, developers are faced with the impossible choice of either delivering less or subverting the system.

Platform engineering encourages a more responsive collaborative approach, where golden paths encourage alignment but developers are never forced to choose between evils.

The Convergence of Opinion, Research and Practice

We are firmly in the research-backed era of software delivery. We’ve grown used to drawing inspiration from practitioners and expert authors, but we now have the opportunity to build and validate models — both as an industry and inside our own organizations.

It’s crucial to prevent this from becoming a purely academic pursuit. We have to ground the research in real-world experience. That means developing the grit to overcome survey fatigue and participate in valuable research programs like Google’s Accelerate State of DevOps survey.

Is Your Product Manager Hurting Platform Engineering?

Wed, 18 Jun 2025 10:46:24 +0000

Your platform engineering team needs product management, but that doesn’t mean it needs a product manager.

Almost everyone in platform engineering agrees that you should treat the platform as a product and the developers as customers. Great platforms will be ones where real-world problems are gracefully solved rather than those that scratch an itch for the platform engineers.

The common advice that goes along with this knowledge is that you should put a product manager in place. However, a recent conversation in the CNCF community challenged this cookie-cutter guide to product management for platform teams.

When people say you need a product manager, they mean your team must have certain skills and product management tasks are getting done. For example, you need to keep the platform focused on its users and be able to assess whether features bring the intended benefits. You need to take the platform to teams in the organization and show them how it could help them.

You don’t need a product manager to achieve product focus; in some cases, it may be counterproductive to add one.

Think Like a Startup

Startups are usually formed around a small group of people who are deeply interested in solving a specific problem. Many technology startups are created when developers find something frustrating and develop a tool to solve the problem.

A great product emerges when these developers can extrapolate their specific first-hand experiences to build empathy with others who have unique problems with similar shapes. They don’t just solve their own specific use case; they can solve a whole category of use cases.

These are the engineers with a product mindset. They can combine direct practitioner knowledge with information from others to find innovative ways to improve work for many people.

This is how Octopus Deploy was created. In 2010, Paul Stovell was frustrated that deployments were so painful when so many other software delivery tasks had been automated. Why was build and test automation a solved problem while deployments were such a mess?

The key to turning this personal frustration into a commercial success was a product mindset.

Paul said, “Customer feedback is like oxygen. It fuels innovation in the product development process. You ship something, listen to the feedback, and ship something else because you have built a deeper understanding of the users’ unmet needs. If you let something get between developers and this essential feedback, it suffocates innovation.”

Having a product manager from day one can lower oxygen levels for your platform team. Feedback may be filtered, delayed or misunderstood, massively reducing its value and making good outcomes less likely.

Platform engineers should bathe in the full, grainy details of the feedback and use it to enrich their understanding of the tasks their customers are trying to complete — and where they are underserviced when completing those jobs. This helps the platform team create innovative solutions that may solve multiple unmet needs.

You don’t have to use the Jobs To Be Done (JTBD) framework here. The crucial detail is that by immersing yourself in the customer’s needs, you can come up with ideas that solve many pain points instead of falling into the feature-factory trap of solving problem after problem.

You need to understand the broad set of problems to develop an appropriately abstract solution.

This is a compelling reason to delay or even avoid adding a product manager.

What Happens at Scale?

While it’s tempting to think ahead to what happens when your platform has achieved total adoption, been spun into a subsidiary organization, and had a conference named after it, it’s worth understanding that scale is not why you’ll add a product manager.

The goal of a platform team should be to solve valuable problems at scale while scaling sublinearly themselves. That means getting more developers interested in adopting golden paths, not trying to create paths for every conceivable scenario.

When teams make choices based on wanting the support your platform offers, you scale without having to encompass new technology stacks. This is more desirable than trying to gain further adoption by supporting esoteric team choices.

If customer teams expand, your platform team shouldn’t have to.

There is an industry-wide problem of software managers thinking it’s their job to stop programmers from being distracted, so they can spend more time typing code. As a result, increasing numbers of software developers never speak to a user or customer. This has led to disconnected roadmaps that don’t add value to the products being developed.

If you need to scale your platform team, preserving direct communication between platform engineers and the platform’s users is vital. You may find that reorganizing into path-based teams can help you grow without losing touch with customers.

Value Non-Coding Contributions

When a software team gets busy, non-coding tasks gradually erode. The outcomes can range from misguided productivity initiatives to just different celebrations for different activities. For example, when a team completes a feature, there’s cake; but when someone gets valuable insight from a customer, there’s silence.

When a team gets “commit myopia,” they start banging out features that nobody wants. This problem is compounded when the organization celebrates the rate of added features, even if they’re of no value. Individual contributors are sensitive to the kinds of work the organization values and will optimize accordingly.

With platform teams, non-coding contributions must be celebrated just as hard as new features.

A product manager is a sticking plaster if the problem is the work isn’t valued.

Maintain User-Centricity and a Product Mindset

The 2023 Accelerate State of DevOps Report confirmed that user-centric teams outperform feature-driven teams. This is a building block to take straight into your platform engineering toolset. Teams that maintain high-bandwidth feedback from their internal developer platform’s users will spend more time working on valuable features.

There are circumstances where adding a product manager is the right call, but sometimes this will disempower the team and wreck outcomes.

Product management is needed. That doesn’t always require a product manager.

Java Features You Didn’t Know Existed (But Should)

Wed, 11 Dec 2024 21:22:59 +0000

Java is a versatile and powerful programming language, evolving significantly since its inception. While many developers are familiar with its core functionalities, Java contains a treasure trove of lesser-known features that can enhance your productivity and code quality. In this blog, we explore 10 underrated Java features, complete with use cases and code examples, to supercharge your programming skills.

1. Text Blocks (Introduced in Java 13)

Text blocks simplify the handling of multi-line strings, eliminating the need for cumbersome concatenations and escaping.

Use Case:

Creating JSON, HTML, or SQL templates without excessive concatenation.

```java
String jsonTemplate = """
    {
        "name": "John Doe",
        "age": 30,
        "isDeveloper": true
    }
    """;

System.out.println(jsonTemplate);
```

Why It’s Useful:

Improves readability and reduces boilerplate when working with large strings.

2. Pattern Matching for `instanceof` (Introduced in Java 16)

No need for explicit casting after an instanceof check.

Use Case:

Streamlining object type checks and access.

```java
Object obj = "Hello, Java!";
if (obj instanceof String str) {
    System.out.println(str.toUpperCase());
}
```

Why It’s Useful:

Cleaner and more concise type-checking logic.

3. Switch Expressions (Introduced in Java 14)

Switch statements can now return values, making them more expressive.

Use Case:

Replacing verbose if-else chains for cleaner conditional logic.

```java
int day = 5;
String dayType = switch (day) {
    case 1, 7 -> "Weekend";
    case 2, 3, 4, 5, 6 -> "Weekday";
    default -> "Invalid day";
};
System.out.println(dayType);
```

Why It’s Useful:

Reduces boilerplate and enhances readability in decision-making constructs.

4. `Optional.orElseThrow()`

Provides a shorthand for throwing exceptions if a value is absent.

Use Case:

Enforcing mandatory fields or ensuring values are present.

```java
Optional<String> name = Optional.empty();
String value = name.orElseThrow(() -> new IllegalArgumentException("Value is missing"));
```

Why It’s Useful:

Promotes better error handling with minimal code.

5. Compact Number Formatting (Introduced in Java 12)

A feature of java.text.NumberFormat for formatting numbers in human-readable forms.

Use Case:

Displaying large numbers succinctly, e.g., for reports or dashboards.

```java
NumberFormat formatter = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT);
System.out.println(formatter.format(1000));  // Outputs "1K"
System.out.println(formatter.format(1000000));  // Outputs "1M"
```

Why It’s Useful:

Makes large numbers more user-friendly in UI and reports.

6. Records (Introduced in Java 14)

A concise way to create immutable data classes with minimal boilerplate.

Use Case:

Simplifying data-transfer object (DTO) creation.

```java
public record Person(String name, int age) {}

Person person = new Person("Alice", 25);
System.out.println(person.name());
System.out.println(person.age());
```

Why It’s Useful:

Reduces the overhead of creating getters, constructors, and toString() methods manually.

7. Parallel Streams

Enables parallel processing of data streams for better performance on multicore systems.

Use Case:

Speeding up computations for large data collections.

```java
List<Integer> numbers = List.of(1, 2, 3, 4, 5);
numbers.parallelStream()
       .map(num -> num * num)
       .forEach(System.out::println);
```

Why It’s Useful:

Efficiently leverages multi-core processors for compute-intensive tasks.

8. `String` Methods: `lines()` and `repeat()`

Java 11 introduced helpful utilities for string manipulation.

Use Case 1: Splitting a multi-line string into lines.

```java
String text = "Hello\nWorld\nJava";
text.lines().forEach(System.out::println);
```

Use Case 2: Repeating strings easily.

```java
String repeated = "Java".repeat(3);
System.out.println(repeated);  // Outputs "JavaJavaJava"


### Why It’s Useful:
Saves time and enhances code readability for common string operations.

---

## 9. **Stream Teeing (Introduced in Java 12)**
Splits a stream into two and processes each with a different collector.

### Use Case:
Simultaneously calculating the sum and count of a collection.

    ```java
    List<Integer> numbers = List.of(1, 2, 3, 4, 5);
    
    Map<Boolean, Integer> result = numbers.stream()
        .collect(Collectors.teeing(
            Collectors.summingInt(i -> i),
            Collectors.counting(),
            (sum, count) -> Map.of(true, sum, false, count.intValue())
        ));
    
    System.out.println(result); // {true=15, false=5}
    ```

### Why It’s Useful:
Simplifies complex stream processing pipelines.

---

## 10. **Sealed Classes (Introduced in Java 15)**
Allows you to control the inheritance of a class.

### Use Case:
Defining a strict hierarchy for domain models.

    ```java
    public sealed class Shape permits Circle, Square {}
    
    public final class Circle extends Shape {}
    public final class Square extends Shape {}
    ```

### Why It’s Useful:
Improves maintainability and enforces a specific type hierarchy in your application.

---

Java continues to innovate with features that make coding more concise, readable, and powerful. Whether you're dealing with data structures, improving performance, or simply making your code cleaner, these hidden gems can help you write better Java applications. 

### Which of these features are you most excited to try? Share your thoughts below!

5 Internal Developer Platforms You Need to Know About!

Mon, 25 Nov 2024 03:21:16 +0000

Gartner predicts that by 2026, 80% of software companies will have established platform engineering teams (source). As companies grow, so do the challenges of keeping things running smoothly, and developers want tools that make their work easier and more intuitive.

The main responsibility of platform engineering teams is to create and maintain internal developer platforms (or IDPs for short). In our last post, we gave a more in-depth look into platform engineering and IDPs, exploring how this new trend emerged and its benefits.

But when considering IDPs, you have two options: building one yourself or getting an off-the-shelf solution. Building one yourself is often too time-consuming and expensive for most companies, and that's why off-the-shelf platforms are an attractive alternative. There are a lot of such solutions available, and we will not cover all of them in this post, but let's look into five internal developer platforms you need to know about…

Cyclops

Developer-Friendly Kubernetes

Cyclops is an open-source tool that simplifies Kubernetes for development teams by hiding its complexity behind a customizable user interface.

Cyclops allows DevOps teams to quickly create custom UIs for their development teams and empowers them to create validations on developer actions to establish guardrails that reduce the risk of misconfigurations reaching production.

After a developer deploys their app, Cyclops provides an intuitive overview of the application running in your cluster. This allows developers to quickly spot and fix errors and easily access their app logs without ever having to onboard on Kubernetes.

Cyclops is cloud agnostic; as long as you are running a Kubernetes cluster, you can set it up with a single command from your terminal. It has a couple of predefined templates to showcase its customizability and enable you to quickly deploy your apps to K8s.

What makes it special: Cyclops' customizable UI allows DevOps teams to easily create user-friendly interfaces that match their organization's needs, giving developers the right level of abstraction over their underlying infrastructure. Because Cyclops dynamically creates UIs based on Helm charts, you can plug your existing Helm charts into it and have a fully functioning UI for your developers in minutes!

Humanitec

Build a Platform That Drives Change

Humanitec is a modular platform designed to help organizations build scalable, enterprise-grade internal developer platforms.

The product philosophy at Humanitec emphasizes flexibility and a code-first approach. Their tools are modular, ensuring there is no vendor lock-in while being enterprise-grade. This approach means there's no "black box" feeling.

Humanitec's product suite includes The Portal, which provides developers with an easy-to-use UI for configuring applications, checking container logs, and debugging errors. Additionally, Score allows developers to define their workload requirements in code, promoting consistency across teams.

The Platform Orchestrator is at the core of Humanitec's offerings. It is an engine that enables platform teams to define templates and establish golden paths for their developers. Resource Definitions serve as open-source building blocks that tell the Platform Orchestrator how to create/update infrastructure in a particular environment. ****

What makes it special: Humanitec's platform is highly modular, allowing organizations to build IDPs using its products as a whole or as building blocks in a larger platform. It easily integrates with existing infrastructure-as-code (IaC) setups, making Humanitec great for large teams looking to scale their operations efficiently.

Qovery

DevOps on Autopilot

Qovery is a DevOps automation platform designed to eliminate the need for dedicated DevOps hires by providing a comprehensive self-service infrastructure for developers.

It streamlines the entire process of infrastructure provisioning, transforming what is usually a time-consuming and manual task into an automated workflow. It can provision infrastructure assets into ready-to-run environments, whether for development, QA, or anything else.

In addition to simplifying infrastructure management, Qovery is designed to help organizations optimize their cloud spending. The platform offers various strategies for cost reduction (like automatically shutting down unused environments) and detailed insight into resource usage.

Qovery is built to integrate with your existing toolset and cloud accounts. It supports integration with a wide range of monitoring, CI/CD pipelines, and security solutions, allowing teams to continue using their preferred tools while leveraging Qovery's automation and management capabilities.

What makes it special: With Qovery, teams can provision and maintain secure cloud infrastructure in hours, not months. It offers features such as environment provisioning, developer self-service tools and cost optimization.

Mia Platform

The Leading Platform Builder for Cloud Native at Scale

Mia Platform is a comprehensive platform that aims to cover the full lifecycle of your applications on Kubernetes with smooth developer experiences.

Mia-Platform simplifies the development process with built-in CI/CD pipelines, eliminating the usual complexity of setup and automating processes to accelerate software delivery.

With a rich catalog of prebuilt microservices and built-in orchestrators for managing them, it speeds up development by allowing you to use the industry standard services out of the box and focus on developing your own product-specific ones.

Mia-Platform also provides clear API management, helping you with design, security, versioning, and retirement. With an API portal, you can simplify the process of establishing new partnerships by making APIs easily accessible.

With a built-in Developer Portal, your development teams have the entire lifecycle of their Kubernetes applications centralized in one place. The portal provides them with easy access to their app's health, resource usage, relevant documentation, etc.

What makes it special: Mia-Platform stands out by offering an all-in-one platform for managing the entire lifecycle of cloud-native applications. It simplifies development with a self-service Internal Developer Platform, built-in CI/CD pipelines, and a catalog of ready-to-use microservices.

Porter

Platform as a Service, Reimagined

Porter is a platform that deploys applications into your own cloud account with just a few clicks. It automates infrastructure provisioning on AWS, GCP, or Azure and makes it easy to deploy, manage, and scale applications on Kubernetes.

Porter simplifies infrastructure provisioning by connecting directly to your cloud account. With minimal effort, it spins up a Kubernetes cluster along with essential infrastructure like VPCs, load balancers, and image registries.

Deployment is equally straightforward - by linking your Git repository, Porter handles building your application using Dockerfiles or Cloud Native Buildpacks and setting up CI/CD via GitHub Actions, which can be customized later to fit your workflow.

Porter continuously monitors your Kubernetes cluster to ensure smooth performance and scalability, keeping track of both your application metrics and logs. If any critical issues arise, Porter will send alerts to notify your team.

What makes it special: Porter focuses on enabling startups and small teams to leverage production-ready Kubernetes infrastructure right out of the box, without needing deep DevOps knowledge.

Before You Go

Thanks for reading! I hope this overview helped you orient yourself in the developer platform landscape. While these are not the only players on the market, they are a great starting point for you to explore. If you enjoyed this article and are looking forward to more blogs on developer platforms, open-source and Kubernetes-related topics, remember to show your support by starring our repo ⭐

What is Platform Engineering?

Sat, 19 Oct 2024 10:22:52 +0000

Modern software engineering is becoming more and more complicated, especially in cloud-native environments like Kubernetes. There are countless moving parts and pieces and no two applications are built the same.

The larger the company, the more moving parts there are. With more moving parts, development cycles become stretched, onboarding developers takes longer, and the chances of mistakes increase. Because of this, companies stagnate and become slower to innovate and push new products and features.

The modern answer to this problem is Platform Engineering and, according to Gartner, 80% of software engineering organizations will establish platform teams by 2026.

In this blog we will discuss what platform engineering is and what can you do to stay ahead of the curve…

Support us

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is platform engineering?

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or DevOps.

Why platform engineering?

“The goal of Platform Engineering is to allow as much speed as possible, with as much safety as possible” ~ Jason Warner, CEO @ poolside, former CTO @ GitHub (source)

Platform engineering creates an abstraction layer that simplifies infrastructure management for developers. Instead of dealing with the complexities of infrastructure, developers can focus on writing code, leading to quicker onboarding and faster time to market.

A good IDP enables separation of concerns. Most of the time your DevOps teams and Product teams do not need to talk to each other and they can move independently. It also provides guard-rails and ensure standard and secure practices across the organization.

Fun fact: when Spotify built its own Internal Developer Platform (now known as Backstage) they realized that their developers were 5% more likely to stay at the company one year later. Developer experience matters!

Internal Developer Platforms (IDPs)

When it comes to Internal Developer Platforms (IDPs), you typically have two options: build one yourself or buy an off-the-shelf solution.

Building your own may seem like the ideal choice. You can tailor it perfectly to your specific needs, ensuring it integrates with your existing tech stack, workflows, and infrastructure. However, building an IDP from scratch is both time-consuming and expensive, it’s essentially a full product in itself. For this reason, custom-built platforms are typically reserved for larger organizations with the resources to invest in such an undertaking.

On the other hand, off-the-shelf platforms offer a quicker, more affordable alternative. These platforms are designed to cater to a wide range of users and needs, which can be both a blessing and a drawback. You may end up with features you don’t need or find key functionality missing. In the latter case, you’re dependent on the vendor’s roadmap, which may not prioritize your needs. While they provide immediate value and are a solid starting point, you have to keep in mind that your organization will eventually outgrow them as your requirements evolve.

But, at Cyclops, we are building something in between…

Cyclops

Cyclops is an open-source tool that bridges the gap between fully custom-built Internal Developer Platforms (IDPs) and off-the-shelf solutions. It enables you to build IDPs for Kubernetes in hours instead of months, providing the flexibility to tailor the platform to your specific needs without the high cost and time investment of building from scratch.

Cyclops enables your Platform teams to build custom user interfaces for configuring and deploying applications and services to Kubernetes clusters. It leverages Helm charts (learn more here) to generate these UIs. You can easily import any of your existing Helm charts into Cyclops as templates and create a user-friendly interface tailored to your specific needs.

The fields shown above are entirely customizable along with the validations. Cyclops allows you to define how much of configuration you want to expose to your developers, while the validations you put in place prevent them from making mistakes.

After a developer has configured the application, with a click of a button it is deployed to the cluster. Cyclops then displays all resources related to the application, offering easy access to relevant information, including logs, health checks, and status updates.

In a nutshell, Cyclops lets you provide the guard rails for your developers to safely deploy their application to Kubernetes and then overview the status of their apps.

Looking for more?

Thanks for reading! In future blogs you can expect us going more in depth on Cyclops and how you can create some pretty fun stuff with it. If you enjoyed this article and are looking forward to more, remember to show your support by starring our repo ⭐

Coder Legion - Recent posts tagged platform-engineering

LLM Serving on Kubernetes in 2026: What's Solved and What's Still Open

What's already crowded

Where the real gaps still are

1. Model-weight distribution as a first-class Kubernetes primitive

2. SLO-driven inference autoscaling that understands request heterogeneity

3. Multi-LoRA adapter lifecycle as a CRD

How I'd choose

Sources

The platform adoption shock

System Architecture: End-to-End Encryption in a Flutter-to-Microcontroller MQTT Bridge

Modern developer experience has deep roots

Betting on software

DevEx is economics, not hugs

You don’t need to make it easy

Modern DevEx and Platform Engineering

We Found 23 Abandoned Kubernetes Environments Running in Production. Here's What They Cost Us.

What We Found

How They Got There

What Idle Actually Costs

What We Did

The Result

The reality of GitOps application recreation

The real-world value of recreatable applications

The maturity journey

What to consider with complete recreation

The path forward

Building NeuroScale: Why I Document Production Failures Instead of "Happy Paths"

Avoiding golden cages in Platform Engineering

The wizard of ops

The golden path

Golden cages

Golden manacles

The silver slippers: Platform as a product

The End of Data Export: Why the Cloud is a Compliance Trap

The End of Data Export: Why the Cloud is a Compliance Trap

How many fintech backends still look

Sovereignty on the wire (and why it is not “no cloud”)

The stateless boundary in app/api/ai/chat/route.ts

Sovereignty versus residency

Where this architecture stops

Why persistence is leverage — and liability

Leveling up your deployment pipelines

Stage 1: Deployment pipeline

Builds

Test automation

Artifact management

Deployment automation

Monitoring and observability

Stage 2: Secure pipeline

Security scanning

Secrets management

Stage 3: DevOps pipeline

Documentation

One-click setup for new projects

Infrastructure automation

Evolving your platform's pipelines

Platform Engineering’s patterns and anti-patterns

Platform Engineering anti-patterns

Complex platforms

”Field of dreams” platforms

The skill concentration trap

Magpie platforms

Under-invested platforms

Stretched platforms

Other signs of trouble

Self-service cost problems

General-purpose DevOps platforms

Flexibility has two sharp handles

Platforms can’t solve culture

How to do Platform Engineering well

The internal developer platform is a product

Use DevOps to build the platform

Make good build or buy decisions

Create the network

Run like open source

Keep an eye on progress

Summary

Navigating Platform Engineering with the maturity model assessment

Platform orienteering

The stateless boundary in `app/api/ai/chat/route.ts`