Hi everyone, I have some may be stupid question but I would ask it anyway: why IDP is "Platform"? What makes IDP to be a platform? What properties "tool for developers" must have so it can be called "Platform"? I have some assumptions that may be we call IDP platform because it increases level of abstraction for users and helps move from IaaS to PaaS. Because IDP is PaaS so it has "platform" badge. Or may be IDP is platform because it connects platform teams as one group of users with stream-aligned teams as other group? Please help me to find the answer. Thank you.

It isn't. An IDP is a portal. Until it's providing value to end users, it's not a platform.

No it isn’t - and that goes to both of you lolsob @Aleksandr Koshelev @Scott Hiland It is important that we agree on the basic definitions of things in this community, because they define how we understand them and each other. Discussion and debate get tricky when we’re talking about different things. We have a pretty consistent definition of an IDP—it’s an internal developer platform. A platform will almost always contain many components, one of which might be a portal, but this is not mandatory. There are platforms that rely completely on API or CLI access and are still platforms. An IDP is NOT a PaaS. …as a Service is procurable on the market. The “I” for internal means it’s custom-built to match your company’s requirements, processes and rules because they’re too special to be cared for completely by something commercial of the shelf. It is however also common-sense to follow a build and blend approach methodology, where you don’t build the whole platform on your own but blend commercial or OSS components into what you’re building. A good hint on possible components is the platformengineering.org platform tooling landscape. The right place for a basic definition of platform engineering and an IDP would be Internal Developer Platform | Internal Developer Platform.

Platform is something that serves to deliver value end to end, with workloads delivering features to end users, irrespective of the underlying infrastructure, and it may or may not encompass a developer portal. An Internal Developer Portal and the tooling around it is about serving developers and is internal by nature. It delivers zero value on its own. It must make features available to end users through some other dependency, like a platform, before it even begins to earn its keep. Conflating the two encourages sloppy thinking because it assumes that if you have an Internal Developer Portal, you're also delivering value to end-users, which is often contrary to reality. There are a few websites asserting that this is all new, with high performing teams have using them for several years, when many organizations have been delivering better developer experience for well over a decade by applying devops principles to internal portals that provision resources, provide observability of those same resources, and assert common templated build paths...all in a self-service way. I've personally been enabling organizations to do this since 2012, and working in organizations that practiced the art of Platform Engineering since 2017, but I didn't invest in a marketecture website to talk about it, I generally just write screeds on LinkedIn instead.

Now I feel like you are just trolling,@Scott Hiland. In terms of Platform Engineering, I don't even have to agree with @Clemens Jütte, IDP is Internal Developer Platform. That is the entire premise of this Slack organization.

Conflating the two encourages sloppy thinking because it assumes that if you have an Internal Developer Portal, you're also delivering value to end-users, which is often contrary to reality.

THIS even tells you that the portal is valueless without the platform. I would also recommend watching this: https://www.meetup.com/platform-engineers-stockholm/events/301780570/

I don't think it's the entire premise of this Slack organization, and the definitions are definitely unclear, especially with marketing nonsense around it. Platform Engineering has a much broader scope than Backstage or even DevOps/DevSecOps. A platform is about abstracting a value stream away from the specifics of infrastructure and turning it into something that works for developers and end users in a uniform and reliable way. It can include some or all of the tooling needed to bring workloads to production and keep it there, with observability, management, lifecycles for various components, etc. An internal developer portal, if it exists, should live on that platform. That platform has internal and external components that service developer needs and the needs of end users, both. A good example of this is a multi-IaaS, multi-region solution based on kubernetes that abstracts infrastructure away from developers, that provides a place for the Internal Developer Portal to live. That's at least the technical side of a platform. My point is that if it's internal, it's not really meeting the definition of a platform and if it's serving end users, it's no longer Internal or Developer. It's an important semantic distinction, because words mean things. I've seen a lot of folks assert that k8s on its own, or Backstage on its own, or even a stack of hand-managed Jenkins VMs in an IaaS are all Platforms, when none of those things encompass the entirety of a capital P Platform. Cloud Foundry is a good example of a fairly fully fledged platform technology. Also, for the record, this naming thing is not really the big problem, just an indicator of other challenges. The really hard part isn't the tech, but the way it's operationalized as a product in service to developer, end user, and other stakeholder needs. Platform teams need to engage those folks and ask them what they need, prioritize what they see as important, measure, adjust, rinse, repeat. Both Platforms and Portals need to be operated as products.

Ufff - I contemplated answering again but there’s one thing that really bugs me. It’s throwing in the “end-users” with the developers. The problem with that is: you build a piece of software to tackle a business problem. That piece of software is what your end-users use and what is providing the value to them. Then you have an IDP. It enables developers to build better software faster and in a more reliable way - and partly that value proposition even flows into the perceived value of the end-users. But… end-users have nothing to do with (or even on) the IDP - their interaction surface are the applications and not the platform!

At what point does a PAAS stop being a PAAS and become an IDP? Can there be IDP as service?