This message was deleted.

I'm not sure what you mean by 'unified API for all infrastructure resources'. Given the wide range of resources, and I'm not just talking about infra but also app config, what does unify mean? Let's take the example of showing the build status in the IDPortal. To get this information you need to connect to your CI system (e.g. GitLab). How does this work in your IDPlatform API? Do you create an abstraction for this? Do you proxy the call? Usually the 'integration' in the IDPortal is nothing more than a set of credentials or token, and the proper network security settings. Usually the IDPortal has a plugin with all the know-how about how to interact with backend system, it wouldn't understand your unified API unless you create plugin/portal yourself. Maybe I'm looking at it all wrong but would be glad to hear your answer. Nice blog series btw, enjoy reading them 👍

Your comment just highlight something I forgot to add in my article that was the fact that the IDPlatform is supposed to only focus on infra orchestration. (cf schema in attachment). IMO The Platform can provide a build system but again it’s not its purpose. Let me know if it’s clearer. (Thanks for your kind words 🙏 )

Yep, this makes sense to me! One more thought, you've now put kubernetes behind your IDPlatform API but I can also see Kubernetes being that IDPL API. What's your thought on that? Then the IDPO would just talk to the Kube API for all state.

I think Kubernetes can be a Platform Orchestrator but not an Internal Developer Platform by itself. An Internal Developer Platform should be potentially usable by Developers (Self-Service). Kubernetes exposes its API which can be ultimately used by an Internal Developer Platform that will abstract it to Developers. I make a clear distinction between an Internal Developer Platform and Platform Orchestrator. Kubernetes can (and should IMO) be the Platform Orchestrator of today and tomorrow.

Why do you reckon the abstraction of the Kube API is needed? If you have the CRD/Operator pattern you could create pretty friendly API's for the dev. Sure you could use an IDPO to give them a nice UI and the IDPO would talk to the Kube API, or perhaps a CLI to make the UX more friendly but ultimately what, in your opinion, does the IDPL API do very differently from the Kube API?

I think we talk about the same thing, the Kube API can’t hardly be consumed by a nice UI directly. You need an intermediary piece that will allow the UI (and other interfaces) to chat with the Kubernetes API. This abstraction piece for me is the Internal Developer Platform. This piece can run on Kubernetes itself or anywhere else - and use Kubernetes as a Platform Orchestrator. BTW that’s the way at Qovery we use Kubernetes.

I created an integration with Backstage (via its proxy mechanism) that allowed me to talk to the kube api directly from the UI with full authn/z via an Identity Provider. So yes, there is an intermediate piece but it doesn't have to be big or contain abstractions/business logic. So potentially: IDPO + Kube API = IDPL? 😁 As always, many roads to take but it's nice to discuss them here. Also, offering a commercial product vs an internal only product changes the decisions potentially.

Hey Romaric! I took the liberty to fix your diagram 😜 according to your own definition from your blog here

An internal developer platform (IDP) is a comprehensive collection of tools and technologies that empower developers by providing self-service capabilities for tasks such as configuration, deployment, provisioning, and rollback. It structures development toolchains and workflows, allowing developers to focus primarily on their core development tasks rather than dealing with infrastructure and IT complexities.

I think it really doesn’t help to draw boxes less inclusively - because according to your diagram the “platform team” would either be misnamed or care for a small piece of the golden path. Both are antipatterns, in my opinion.

Hi @Clemens Jütte 👋 thanks for your input and I appreciate the collaborative work 👍 I got your point and I think your diagram reflect what will be an Internal Developer Platform in the 3 to 5 next years - where the Portal will be part of the Internal Developer Platform but I think there is still a clear distinction between an Internal Developer Portal and Platform. We could ultimately call everything a Platform but I think it can be confusing at this stage of ecosystem maturity because there is no platform covering the full spectrum. Do you see what I mean?

We could ultimately call everything a Platform but I think it can be confusing at this stage of ecosystem maturity because there is no platform covering the full spectrum.

A platform is an architectural concept and not a thing. You design it and you build it. What capabilities it contains and what spectrum it covers are largely dependent on what you’re doing. An IDP for a webshop will be VERY different from one built for a company that is working on integrated systems. Non the less both are IDPs that are designed and fit for purpose - building a golden path for the developers that use them to achieve actual outcomes quicker and more reliably. If you want to have a full platform in one product, that’s a PaaS and usually tailored to a specific use case or target audience - which again defines what scope it covers and how.

If those “Monitoring and Obs”, “CI/CD” and “Ticket Management” systems are used to provide developers with an easy interface in the IDPo (summarised information, quick actions, etc.) to help them gain insights into how their apps are running/progressing then you could argue that these systems are in fact part of the internal developer platform. It reduces cognitive load for them by not having to go dig through those systems unless you need (very) detailed information.

I got your points but what is not part of the Internal Developer Platform then? I agree that every developer touchpoint can potentially be part of the developer platform but some of them have not been designed to be used by them - that’s why I will be careful to not go too fast and define everything as being part of a developer platform

That sounds interesting. Can you give an example of such a component?

I agree that every developer touchpoint can potentially be part of the developer platform but some of them have not been designed to be used by them

For instance - the way most CI/CD are designed - I explain my point of view here https://romaricphilogene.substack.com/p/platform-tips-13-whats-the-future

Hmmm. You’re making a point there that CI/CD could become part of a platform and that this would be beneficial to developers. Which leads to that capability being inside of the box as in my sketch, right?

This is what could be the future. Not what’s going on today. So I think it’s important to make clear distinction otherwise we’ll have what happened to most of IT ops solution that just rebranded them as being DevOps solution without changing anything. You see what I mean? 😅

Actually - no 🙂 If you integrate CI or CD capabilities into your platform and how deep you do - is up to the platform’s design. Generally, stating that it doesn’t belong there because it’s not done yet is not what architecture or design is about. It is actually hard to imagine that there is a modern CI or CD solution that has no API and because of that is not available for integration, if you’re up to the task - please name one if you know one, my memory doesn’t spit one out. Without wanting to dilute the original topic - the problem for developers is not YAML and also not the existence of a pipeline. It’s rather once again that in case of CI they need to care for more than building their software - to name a few examples code scanning, quality gates, image/package distribution. For CD it’s the infra looming again - how to create infra and dependencies and maintain them and how to deploy to a target platform that is not like their dev estate at all. In the end we’re talking cognitive load and learning curves of topics that do not belong into the core coding domain. Those challenges can™️ be solves by a platform and make the remaining CI/CD part trivial because then it’s about the core domain of the developer again.

I think we’re talking the same thing but we also have different vision 🙂