This message was deleted.

Hey Romaric, I like your phrasing about "All Internal Developer Platforms include a Platform Orchestrator", but I may argue on a technicality that "all IDPs include [some form of] platform orchestration, but not necessarily a platform orchestrator" The "platform orchestrator" category is still very much emerging, but I think the focus on day 2 operations may have been missed in your two bullet points. It could be relatively easy to "orchestrate" the platform (infrastructure) on day 1, but the actual value with a platform orchestrator is the platform lifecycle management that occurs on day 2+

I agreed, Platform Orchestration even Internal Developer Platform are just emerging. I’m pretty sure they will converge (with Internal Developer Portal too) at some point. The distinction is much more on use cases they address and how and by who they are used. But at the end they are here to serve the same purpose - providing self-service experience to [someone]. I’d love to chat over zoom / meet (the cheap version of zoom I’m using 😛 ) - I’ll DM you.

Orchestrator is a tool for Platform Engineers to better serve Developers. And the services provided by Platform Team can be triggered via Portal (can, not must be. Portal is not 100% cases a necessity imo)

There is already a good platform orchestrator open source ?

kubevela and crossplane are some of the more popular FOSS options

Don't forget Kratix 🙂 (and as a disclaimer, I'm working with the Syntasso team behind this tech)

I think the discussion start is mixing the terminology a bit around @Romaric Philogène. What you always build is an IDP - an Internal Developer Platform. Which components make up that IDP and if you buy or build them is an individual choice per IDP. Despite the clever wordsmithing a Matryoshka doll will only come together in one order and not the other way around 😉 If you’re looking for components to fill a specific role, like a portal or an orchestrator, then the platform tooling landscape is a great starting point that’s maintained by the community. I would neither sort Kubevela nor Crossplane as an orchestrator. Both have different scopes that fit better in other categories. Kubevela tries to cover more of the scope, or in their own words

KubeVela shares the same goal with the traditional PaaS to provide full application deployment and management capabilities and aim to improve developer experience and efficiency.

which would’ve been an “iPaaS” or “installable PaaS” in the past and Crossplane identifies as a control plane.

Pulumi is a pretty conspicuous absence from that image. What community maintains it? I don't see a github link. There is an exhaustive form that seems aimed at vendors to fill in (I don't work at Pulumi).

Hey @Kief Morris - it’s maintained by this community 🙂 The reason for the form is that only having the logo would be a bit anaemic - there are detail pages, which are linked form the searchable list below the wallpaper. All that info needs to come from somewhere and if you want your favorite tool to be on the list, you need to put in that bit of effort - essentially giving back to the community - to make it happen. Take a look at the Calico detail page as an example.

cool, i didn’t know about kratix, learn something new every day. that at-a-glance infographic around components jay shared is also a super useful reference

Thanks guys, i’ll study some of this options

Thanks @Jordan Chernev for spotting those. I’ll pass it on to someone who can fix it.

Should be fixed

What is the question? Or - what is the suggestion? How would distinct categories for those two concerns benefit the overall picture? Which tool do you see missing or being sorted wrongly?

I would suggest splitting application deployment and pipeline. A pipeline tool or service gives you a way to promote code from one environment to the next, run tests, get approvals, etc. An application deployment tool only has the features to deploy software into a single environment. ArgoCD and FluxCD, from what I understand, don't actually give you a way to build pipelines with multiple stages and environments. I've heard of them needing to be used in conjunction with a pipeline tool or service, or else only used in a setup with a single environment. So the point is, if you use ArgoCD or FluxCD, you need an additional tool for pipelines. (Their product naming seems ironic to me)

Ah, okay! You should probably check on the feature set as both are capable of achieving that. If that is as easy as it is with a tool that is dedicated to only providing an opinionated workflow is a different thing - in the end both Argo and Flux want to be driven by GitOps which complicates things also for pipeline tooling. Argo even has a dedicated project for workflows https://argoproj.github.io/workflows/