This message was deleted.
# general
s
This message was deleted.
h
Tools like OPA will still be needed in the workflow engine that powers the exposed self service workflow for developers. For example - if the user belongs to a team, then disallow the request. 🙂
s
Thanks for the reply @Himanshu Mishra (Spotify). I wonder how much the frontend system such as backstage can do to provide some policy. For example, can't we use RBAC in backstage to only expose services depending on the logged in user and their group or team?
h
Kind of, yes. You still need strong RBAC in the backend to prevent API calls. Backstage also doesn't have RBAC, it has a permissions framework which lets you build your RBAC solution by writing code.
Sam, for full transparency, I am the person behind https://www.harness.io/products/internal-developer-portal If you're not looking explicitly to build your developer portal yourself, check us out. Happy to chat more!
s
Thanks @Himanshu Mishra (Spotify). I'm still educating myself on Backstage and its limitations. Trying to understand the value that humanitec, Port, and now harness bring to the table beyond ease of use. I'll take a closer look at harness. Didn't know you had an IDP.
d
@Sam Gabrail Hey Sam, just chiming in here. Couple of thoughts: 1. It feels that you are looking for a way to make your platform more enterprise ready (e.g. by enforcing a clear RBAC model), correct? a. If so, Humanitec's Platform Orchestrator is actually well positioned to help you do that, as it lets enterprise teams (even very large ones) enforce RBAC on 3 levels (org, app and env type) 2. We have just published a couple of articles in collaboration with portal vendors (you mentioned Port, so here's the one with them), you'll see there we are quite different. TLDR a portal is a UI on top of your platform, the orchestrator is the core configuration and permission engine For full disclosure as well, I am with Humanitec. Hopefully this breakdown is helpful though, let me know if you have any questions.
s
thanks a lot @Djordje Sumenkovic, will take a closer look!
r
Hi Sam, if you are looking to check out multiple IDPs solutions I’d recommend this article: https://www.qovery.com/blog/10-best-internal-developer-platforms-to-consider-in-2023
s
great, thanks Romaric!
k
Hey @Sam Gabrail, adding to the conversation that we published set-up-specific reference architecture earlier this year (the one I am posting as an image, for example, is for AWS). That could help as well with your search. Here you can find the ones for GCP and Azure: https://humanitec.com/reference-architectures
a
@Sam Gabrail - I think you should still use OPA as it really solves a different set of requirements OPA for me is the codification of good practices / standards (e.g. only allow images signed by the org to run in k8s) IDP simplifies the consumption and creation of the resources however you still will OPA as a guard rail for automation engineers E.g. if they start to use untrsuted docker images etc
s
makes sense @Andrei Hawke so platform engineers are the ones that will use OPA in this context.