Hi, I recently discovered Radius and am trying to assess it's maturity and usefulness as a part of an IDP. To my surprise the platform tooling landscape lists it as a Infrastructure Control Plane and not as a Platform Orchestrator. Which means that I am probably missing what a Platform Orchestrator is supposed to do. AFAIU Radius supports describing an application in an abstract way, it provides a way to connect different Recipes to describe, connect and provision infrastructure to run that app and it supports different environments. Can someone help me understand what Radius is missing to be considered a Platform Orchestrator ?

maybe @Clemens Jütte can help with this one 😄

@Mallory Haigh I think you mentioned a couple of times that Radius is a possible choice for an orchestrator in the MVP course. If this is true then is there any chance to update the platform tooling landscape ?

Hey guys! Happy to chime in on this one, but please let me finish my vacation first :)

AFAIK It isn't on there as it hasn't been submitted by the Radius team - though @Sam Barlien may have some insight specifically

Alright - this one is tricky, as radius is for sure having the core capabilities of an orchestrator inside. I am not aware of another vendor agnostic, more current, definition of what a platform orchestrator is than the Thoughtworks one (linky here). The main two things in there, where it gets tricky are

enforcing organizational standards

and

self-service

. While radius can be used to provision standard recipes, there is no enforcement of that - matter of fact there is not enforcement of any kind. All questions of who can do what where? are being deferred to the platform you’re building. That might or might not be a problem for you, but generally speaking, orchestrators tackle that problem and enable self-service not only per possibility but also per enforced guardrails. That leads to the outcome always being predictable and as such to no manual reviews interrupting the flow - radius has no central components that help with governance or control and you need to devise all that on your own. For me this is the deal-breaker for categorizing radius as an orchestrator. That being said. I wouldn’t mind too much if radius started self-identifying as an orchestrator and as such changed categories - but they don’t (as of now 🙂). Their own definition of what they are is

Radius is a cloud native application platform. It enables developers and IT operators to collaborate on delivering and managing cloud-native applications.

This is my opinion - if the community thinks, that radius should change categories, we should have that discussion.

Hi

Hey @Michelle! What would you like to know?

@Clemens Jütte - Well lot's of things. I'm very curious about everything on this. What devs think about it and how it helps.

@Mallory Haigh or @Sam Barlien beyond switching categories, how do we suggest tools for inclusion generally? That's not clear on platformengineering.org

Just follow the link at the top of the page 🙂

Ah, "Where banner ads go things are invisible" 🙂

Thank you for your detailed answer @Clemens Jütte. It seems that my understanding of the responsibilities of a Platform Orchestrator was indeed limited, and I'm not quite sure I understand what

enforcing organization standards

means in practice. Is it RBAC (humanitec has it's own, Kratix can leverage kubernetes' RBAC O guess), or is it more, like a policy engine ? Something else entirely?