Platform Engineering is evolving, but we should not confuse evolution with constant change. For example, what do PAAS and an internal developer portal mean. Many people I see on Linkedin or over here keep being super lost because of this pushing into re-writing the same 3 concepts over and over again… I think ThoughtWorks (see the link below) is getting it: Platform Orchestrators is on the Tech Radar now as a technology that goes beyond the traditional PaaS model and “offers published contracts between developers and platform teams”. It sounds like a lot of words, but in reality, it’s super simple: • Internal developer portals serve as the interface through which developers can discover and access Internal Developer Platform capabilities. • PaaS is basically an IDP-like experience with a limited tech stack and cloud provider options, and the lack of integration with industry standards. ....and don’t get me WRONG, I am not hating PaaS solutions. I think they excel in specific scenarios, such as greenfield and small teams setups, but they struggle to accommodate generalized enterprise setups, which is where the necessity for a genuine IDP arises. Thoughts? https://www.thoughtworks.com/radar/techniques/platform-orchestration

Agreed. Some further thoughts: • PaaS became about software hosting as much as it is about software patterns. Most PaaS vendors used the front end standards and interfaces to capture the backend workloads, and charged primarily for that backend. This was particularly frothy when k8s came out because most PaaS vendors couldn't deploy onto cloud provider services, instead they required dedicated VM's etc. • IDP is more akin to the front end standards (to your point) many PaaS vendors talked about, but neglected or pushed into lock-in territory • PE is about where DevOps was in 2012 in terms of it's maturity, to be expected there is confusion and ambiguity and will take time to align everyone Also as someone who's been neck deep in various PaaS over the years you nail a key point - they usually fail to scale. That failure almost always results in alternatives/shadow IT things happening, which kinda defeats a key purpose of adopting a PaaS in the first place. This is a major advantage to an IDP over a (or in addition to a) PaaS. Enough flexibility to accommodate different teams, departments etc.

My theory is that PaaS is a great platform if you can bend to the processes defined by the SaaS. I give a description in about how I see IDPs today as a move from the

Collaboration

interaction model between application and platform teams within an organisation to the

X-as-a-Service

model (as defined by Team Topologies). And PaaS is just X-as-a-Service without that collaboration since the SaaS vendor won’t have collaborated with your organisation when building their platform offering. To me that is the rub. It is great, if you can use their processes. If you can’t, then you need to find out how to create something for your own!

There's nothing magic about a platform. It's all about finding the right level of abstraction for where the team(s) and business are at any given time. For the vast majority of folks, the BIOS on the computer in someone else's datacenter is a part of the platform now. It used to be critical, now you never hear about it. As the teams and businesses evolve the right level of abstraction changes as well. Building a platform before you need it (or know what you need it to do) is over-engineering. For an MVP a flat CSV file as a data store might be enough. You don't need any platform for that. Eventually, if there's enough growth, you'll want databases and storage and compute as platforms. The more teams and requirements you have the more generic your base layer gets to support all of then. Then you start having multiple layers of middleware to handle more and more specific areas/teams.

I like this analogy @Leon Rosenshein - it’s spot on!

I wonder if the different between an IDP (platform orchestration, framework, etc.) and a PaaS is about extensibility. While most PaaS platforms are extensible, they tend to be more rigid (opinionated?) Where the orchestration / frameworks are aimed at making it easier for you to implement your own workflows, models.

Hmmmm in my opinion the extensibility is two fold. One is the organisations friendliness towards extension. That is IMO independent of PaaS vs IDP orchestrators. The other is extensibility as in access to new features without platform builder investment. IMO that is more of a SaaS vs self hosted question which can be true for both PaaS and IDP orchestrators.

As has been mentioned, PaaS and IDP optimise traditionally have optimised for different levels of organisational scale. Unfortunately, most PaaS do not allow you to “progressively disclose” complexity, and they don’t effectively grow with an organisations needs. Most commercial IDPs seem to have started out more as “information radiators”, which ingest and centralise other tools. This has a value in visibility, but does not principally do anything for the organisation, and becomes then merely a pointer to other systems that do the thing (this is a good start, but is precisely that, just a start). There is of course the situation where teams (and plugins) are building PaaS like functionality into their IDP… which then blurs the meaning of IDP into the realms of an internal PaaS. I believe some of the original thinking around the commercial IDPs is flawed. The IDP is trying to reverse-engineer standardisation out of socio-technical systems and ecosystems that were not built with standardisation in mind in the first place. I believe IDPs would benefit from aspects of PaaS and vice versa. I believe we are seeing this convergence. The recent article about backstage adoption, details this flawed thinking well.

Hmm, maybe I don't have a clear understanding of the definition of an IDP. I'd thought of Backstage as a developer portal, and it matches what you describe pretty well. I'd been thinking of IDP as more like Kratix or Humanitec (sorry Abby, lumping them together again 🙃), that are used to actually configure and run services, but in a more composable manner than a PaaS, which tends to be more prebuilt

Hmm, maybe I don’t have a clear understanding of the definition of an IDP.

That feels like the crux of the conversation, right? What is / who has the current canonical definition? 😄

I doubt there's a canonical definition (who decides?). But I did a search and came across this post https://medium.com/@rphilogene/internal-developer-platform-vs-internal-developer-portal-whats-the-difference-b7ce6351f195 by @Romaric Philogène

Thank you @Kief Morris for sharing 👍 Portals… Platforms… are still emerging concepts, and I think it’s difficult to clearly draw the line between one concept and another. It must be something done collectively. What is 100% sure is that the end user of any technology will always pick the one that better fits their need.

Agreed. Defining either clearly also gets a lot more complicated if we overload IDP^2 with PaaS and orchestration capabilities, but ultimately not sure how much strict definitions matter DevOps, Cloud Native and PaaS are all over the board when you ask for specifics after all

Yes, @Kief Morris, a Platform Orchestrator is the configuration engine (the brain) of your Internal Developer Platform. It is designed to be unopinionated and integrate with any tech and tools existing in the enterprise. It's the most important tool in the platform teams' toolbox to design the golden paths for their devs. A PaaS just forces you to use its own golden paths and abstractions, which won't fit well with all the different use cases in an enterprise.