My tip of the day :slightly_smiling_face: All Inte...
# general
r
My tip of the day 🙂 All Internal Developer Platforms include a Platform Orchestrator, but not all Platform Orchestrators are Internal Developer Platforms. So, do you need a Platform Orchestrator or an Internal Developer Platform? The answer lies in what you need to achieve. 1️⃣ If you are a Platform Team that needs to unify the infrastructure pieces with one single API - then you might need a Platform Orchestrator. 2️⃣ If your Platform Team wants to provide Self-Service to your developers, then an Internal Developer Platform is your best option to achieve 95% of what you need and then build on top of it. Agreed? What’s your thoughts?
d
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 do hear what you're saying about getting started, though (and any potential upfront cost with implementing a PO). I think a group of 5 developers or an SME/SMB might get the most benefit from starting with an IDP
Let me know if you want to chat more via Zoom, as I am keen to learn more about this!
r
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.
k
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)
m
There is already a good platform orchestrator open source ?
j
kubevela and crossplane are some of the more popular FOSS options
namely the latter
d
Don't forget Kratix 🙂 (and as a disclaimer, I'm working with the Syntasso team behind this tech)
I've got a blog post I aim to finish this week, and I've mentioned kubevela (and the Open Application Model) and Crossplane. I see the former as more application/developer-focused and the latter as more infrastructure/operator-focused.
The good folks from Humanitec also have an orchestrator (that's included as part of their reference architecture), but I'm not sure if this is open source?
c
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.
k
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).
I also have questions, it doesn't seem to distinguish between CD pipelines and application deployment
c
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.
I also have questions, it doesn’t seem to distinguish between CD pipelines and application deployment
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 honestly never thought about distinguishing there and would like to understand better!
j
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
for my own personal initiatives, i’ve used a custom built orchestrator and the options i originally listed above. perhaps they were a good fit for the scope and use case we had on hand at the time when we were building our platform. good to see that there are more general purpose options for this out there
there is a small typo in the bottom right corner on this link - `kafTa.`not sure what the best way around fixing it but i thought i’d mention it
same with
Synk
m
Thanks guys, i’ll study some of this options
really appreciate!
c
Thanks @Jordan Chernev for spotting those. I’ll pass it on to someone who can fix it.
f
Should be fixed
k
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)
c
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/