wtf is platform engineering? [IDP vs TVP vs IDP]
Build-a-Bare Workshop đ§¸đ How 2 build a "bare" minimum IDP
What is the difference between a TVP and an IDP?
Internal Developer Portal is the interface. Usually what PaaS providers want to hang their hat on. Too often the GUI is undifferentiated from one another. Just more mental mazes to make DevOps scurry through like rats.
These are the 3 possible interfaces:
CLI (command line interface_) âFor power users that can smell the cheese and donât have time for the mental maze of a Gooeyâ
API(Application Program Interface) âExecutives leadershipâs old favorite buzzword before blockchainâ âThe perfect pipedreamâ
GUI(Graphical User Interface) âThe Gooeyâ. âFor ClickOps, script kiddies, and selling SaaSâ
https://medium.com/@rphilogene/what-is-an-internal-developer-portal-6bcbe2481300
The UIUX for IDPâs has still yet to find a category king IMHO.
Internal Developer Platform as defined by a group who bought the domain name:
https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/#developer-portal-service-catalog-ui-api-or-cli
Hot take:
I think that IDE extensions might have the biggest shake up in this. its the omni-present feature in the developer experience.
Backstage templates are still confusing. Epinio was a great portal as well that went dark(BREAKING: the beloved tool is being reguvinated by CNCF lead Colin Griffin). There are/and will be a zillion other interface abstractions popping up because the Developer experience is hard to define and optimize for. It's also estimated that platform engineering will be adopted by 80% of enterprises by 2026 which reinforces the notion that all these teams will be unlearning old habits as they try to foster ne "golden pathways".
It's weird that golden paths seem to be some undocumented SOP (standard operating procedure) that ought to be a field manual of technical documentation. Kind of like a script kiddie tutorial. Not exactly a GUI, something more likely to be a IDE plugin that utilizes a bespokely trained LLM that would enable all walks of like on the engineering team to ask the company spcific technical documentation outlined by the platform team and have the output suggested changeds embedded within the context of their file.
Kinda like the Cursor IDE that is like training wheels for the developer experience. having a omni chat bar that ties back in the right information at the right time will be far more sufficient that nagigating a GUI has ever been.
The precursor to that I think will be "Documentation as Code". Technical documentation platform engineers ought to create a byproduct out of doing a deep clean of all the technical debt they've piled up in silos across across international lines and team cultures under the same roof.
Think a gitbook or obsidian.md publish instance, or anything that permits you to copy to clipboard a chunk of boilerplate that is intended to be nestled into. Something that can Retrieval Augmented Generation or whatever else will end up as the best way to retrieve the right suggested pathway from this platform team's bible to the dev's IDE.
What I'm getting at is that developers dont want to go to a portal, they want the portal to come to them. At least I do. Otherwise fixating on the UIUX for a IDP will result in just ClickOps with a facelift.
Coming soon: [the best platform teams have the best documentation. how to write good documentation]
Until we have my dream extension, or until you team can define technical documentation in such a way that it outlines all the avaiable goldpath ways, you are at the mercy of the hodgepodge of architecture decisions made 5 years prior. But that doesnât mean you should just sit on your hands. You should figure out what your thinnest viable platform looks like. Youâll back into what a good IDP can look like after youâve given your team the liberty to experiment with the latest tools the CNCF has to offer.
TVP is the architecture or âstackâ.
Not a silver bullet, but certainly a blueprint that you can modify/adapt to suit your teams needs. The only catch is that it must be built using opensrc. Typically looking for established software that hopefully grants you 3-10 year incubation before changing licenses to revert to closed source. So even if a component does you dirty like that. You should always be able to swap it out with a compatible solution, reevaluate existing solutions, then rebase. Tough, but thatâs just the way the cookie crumbles.
So get your team together for an internal hackathon, or call Krum so we can set you up a private workshop.
Thatâs all.
Quit procrastinating and get started building your own Thinnest Viable Platform! No seriously! Here take this:
https://github.com/krumIO/krum-appdev-platform-starter