Ajay on why most IDPs fail (workshop this Saturday)
A short Q&A with Ajay Chankramath on when teams are ready for an IDP, how AI workloads break the standard patterns, and a workshop worth your Saturday.
Most weeks you get a technical deep dive from me on Fridays. Today is different.
I want to put a workshop on your radar that I think is worth your Saturday.
Internal Developer Platforms have been the dominant platform engineering conversation for two years now. Most teams I talk to are either building one badly, buying one they do not fully understand, or avoiding the topic because they have seen too many failed platform projects.
The pattern is consistent. Teams start with a portal (usually Backstage) and work backwards into the underlying platform. That order is wrong. It is why so many IDPs end up as another bottleneck instead of a force multiplier.
Ajay Chankramath runs Platformetrics and previously led Platform Engineering at Thoughtworks. He is running a two day workshop on April 25 and 26 on building an AI powered IDP from scratch. I asked him a few questions on the stuff most teams get wrong.
When is a team actually ready to build an IDP?
Ajay: When you can name your top three developer friction points based on data, not gut feeling. If you have not watched a developer go through onboarding end to end, you are not ready to build the platform. Do not start building a platform just because you learned about a solution. Start when you truly understand the problems.
How do IDP patterns need to evolve for AI and ML workloads?
Ajay: AI workloads break three assumptions baked into the standard IDP: resource primitives, lifecycle, and failure modes.
IDPs need to treat GPU pools as first class resources with their own abstractions. They need to build golden paths for ML workflows, not just microservices. They need to integrate model registries and experiment trackers into the service catalog. And they need observability for inference latency, confidence scores, and data drift.
The standard Backstage style IDP was not designed for workloads that can fail by giving confident wrong answers for weeks.
What will engineers walk away understanding?
Ajay: How the layers connect to each other.
You can learn about each tool from its documentation. This workshop teaches what happens when a developer submits a service request in the portal, which triggers a golden path scaffolder, which provisions a namespace with RBAC and quotas, which applies policies via OPA, which is monitored by an SLO driven alerting stack, which feeds into an AI powered alert correlator.
That end to end chain, from portal click to production insight, is the platform.
Workshop details
Building an AI Powered Internal Developer Platform from Scratch
Saturday April 25 and Sunday April 26, 2026 11 AM to 3 PM ET each day 4 PM to 8 PM UK / 8:30 PM to 12:30 AM IST / 7 PM to 11 PM Gulf
Hosted by Deep Engineering by Packt.
What’s included:
Live hands on sessions with Ajay across two days. Working code for AI platform features that runs locally without API keys. A 30 to 60 minute one on one Platform Journey consultation with Ajay. Certificate of Completion plus a Credly digital badge you can add to LinkedIn.
Refunds available up to 3 days before the event. Seats are limited.
Why I am sharing this
I am selective about what I put in front of this list.
Ajay’s answer to the AI workloads question landed for me because it names a real gap in how most teams are thinking about ML platforms today. GPU pools as first class resources. Model registries in the service catalog. Observability that covers data drift, not just p99 latency. Most IDPs I have seen do none of this.
If you are on a platform team, a DevOps team going through an AI transformation, or an SRE figuring out how to support ML workloads, this workshop will save you months of trial and error.
Disclosure: This is a paid partnership with Deep Engineering by Packt. I only promote things I would send to a friend.
Regular Friday content this week covers the production Kubernetes debugging framework I use on our clusters. More on that in a few days.
Sharon