A question I get a lot, and a good one: how do developers use Internal Developer Platforms on a day-to-day basis? What does it do for them? Does it restrict them? To be honest, I figured it’s nonsense for you to listen to me. So I asked frontend developers, backend developers, QA engineers, and product managers how they use IDPs in their day-to-day work. If you have a minute, check them out! Let me summarize my learnings:
Every developer in a team uses their IDP on a daily basis. In 80% of the cases, it just runs in the background, updating and creating app config files and deploying according to preset automation rules. Developers use the IDP, depending on their focus area, whenever there’s something that goes beyond the simple update of an image. Frontend Aziz loves to run diffs to understand where errors were introduced. He rolls back, handles environment variables at scale, and spins up PR environments.
Backend Eugene loves how little time he now spends debugging and maintaining nasty scripts. He demonstrates how extremely complex things like promoting subsets of microservices into a new environment are now a thing of a single command.
QA Nils uses the single API of his IDP to build test automation, consolidating views across all apps and environments and real-life test environments. And product manager Susa has a single pane of glass to know exactly what’s happening where and how she can support her developers.
As more and more teams (from scale-ups to some of the largest enterprises in the world) roll out Humanitec, these stories just keep trickling in. In these organizations separation of concerns means developers can work only with Version Control, CI, and IDP. Everybody operates applications across the entire lifecycle with a single Platform API, while still leveraging the power of their entire toolchain. Transparent abstractions, golden paths, and the beauty of the IDP.
I’m already excited to hear your story. Let me know!
Kaspar
