Feature: Leveraging IDPbuilder for Empowering Developers with Self-Service Cloud Provisioning

[dshamanthreddy]

Have you searched for this feature request?

• [X] I searched but did not find similar requests

Problem Statement

Currently, the idpbuilder patterns are limited to showcasing local development capabilities. To expand its reach and functionality, we need to incorporate patterns that enable a self-serving portal for developers where Platform team would set governance. This self-serving portal would empower developers to access and leverage the idpbuilder patterns seamlessly, fostering a more collaborative and efficient development experience.

Possible Solution

The potential solution lies in by leveraging the IDPbuilder as a self-service provisioning tool for infrastructure resources in the cloud. This transformation would significantly benefit platform development teams by streamlining their workflow and empowering them with a centralized, automated approach to manage and provision cloud infrastructure resources.platform development teams would gain access to a unified platform that abstracts away the complexities of cloud infrastructure management. This platform would enable developers to define and provision the required infrastructure resources through a user-friendly interface or declarative configuration files,

Alternatives Considered

No response

[nimakaviani]

Thanks @dshamanthreddy.

To clarify the ask here, we want to provide example patterns for idpBuilder that showcase how multi-account infra deployment can be enabled from within an idp.

Most likely this will involve patterns that utilize Crossplane or Terraform, receive account credentials from users, and deploy resources to the given accounts.

cnoe-io/backstage-terraform-integrations already provides some examples but we will need better documentation, clarifications around multi-account setup, and examples with Crossplane as well.

[csantanapr]

I'm interested in contributing a ref-architecture stack that includes backstage templates that deploy Muti-Cluster environments, for example deploy a Fleet of Clusters using EKS on AWS cloud. Which project are you looking to deploy the clusters with? Crossplane or ACK?

I have a design in mind to show as a demo in the ref-architecture for fleet management

1. Admin will use a backstage template to "Create K8s Environments", this will deploy 3 EKS clusters (they can be in different accounts) cluster would be "dev", "qa" and "prod" (ie. clusters as a service), they will be registered back to the ArgoCD in idpbuilder as remote clusters, then using gitops-bridge pattern using application sets the cluster would be configured with addons and namespaces (namespaces as a service) for onboarding a tenant/team.
2. Developer wil use a backstage template to "Create an App on K8s Environment" idpbuilder will deploy a git repo with the app, and the repo will have 3 targets using kustomize or helm to deploy to "dev", "qa", "dev" the App will be deploy to the Clusters that the Admin created in step 1

[cmoulliard]

As mentioned separately, we should certainly look to what the kratix project did : https://docs.kratix.io/ as it supports the same concept/idea as proposed here like also how to compose, define component/package to be deployed.

HighLevel features of kratix (and i'm perhaps missing some)

• A stack which describes a component/package to be deployed = Promise and dependencies
• Composition: a stack can include stacks - https://docs.kratix.io/main/guides/compound-promises
• A workflow/pipeline to execute some steps top of a component/package to be installed. Example: https://github.com/syntasso/promise-postgresql/tree/main
• An approach to provision a cluster or clusters and more (= destinations) - https://docs.kratix.io/main/reference/deployment-topology
• The promises catalog is populated on backstage as templates (aka Service catalog) - https://docs.kratix.io/main/reference/backstage/intro#how :slightly_smiling_face: Remark: I dont like the fact that their stack definition is tight to a Kubernetes CRD (OLM), not pluggable using adapters (Crossplane, Helm, Terraform, Argocd, etc) and requires to build an image about the promise to install = dependencies + pipelines, etc (edited)

[nimakaviani]

thanks @cmoulliard ... we discussed it during the community call too, you can listen to the conversation here (pin pointing the exact time). Might be closer to the Kratix model but curious to hear your thinking when you get a chance to go over the recording.

[cmoulliard]

What kratix suggest is more in line with what I'm thinking about. I deeply recommend to watch the 2 introduction video from kratix and this one to see the integration with backstage: https://www.youtube.com/watch?v=gdMNS3V-ogo

The biggest challenge around anything we will do is not at all around the composition, provisioning (see table hereafter) but is about the definition of the concept: environment.

Why: From a user point of view, we can easily and quickly figure out what an environment is: earth, ocean, forrest, etc but when we have to describe it, what the components it is composed are, then the tricky work will start: a forrest is composed of trees of species: a, b, c ... e, f where river flows, where foxes, wolves, deer are living etc

If you transpose such an environment definition to what we try to achieve here, then you also understand how difficult it will be to define that for a team; they need a CI/CD of type ArgoCD version x.y.z; Git server, Backstage within plugins and configs ....

Ideally an environment should be also decomposed into the underlying systems it is composed, their version, configurations etc. Such an abstract level do not exist top of Kratix (I think) or maybe using a resources ...

Remark: Kratix proposes a more elaborated solution than us until now ;-)

Concept	Kratix	CNOE
Environment required by a user and to be provisioned on a platform. Such an environment is designed around common bricks (e.d: CI/CD/ArgoCD, IDP/Backstage, DB/PostgreSQL, OID/Keycloak, Git/GitLab or Gitea, Certificate Manager, ServiceBinding, etc) but are tailored according to the use cases.	Promise	Package
Composition	Compound promises	group of packages
Customization of the environment	Workflow & pipeline. The steps to be executed sequentially are not managed by a Pipeline engine (aka Tekton, etc) but are scripts mounted as volumes + env variables	n/a
Provisioning	Destination corresponds to a target machine where resources can be pushed and where a tool will consume them (Crossplane, Kubernetes, Terraform, Backstage	n/a
API	Platform API	n/a
Admin console/UI	n/a	n/a

Do you want that we extend the discussion with Kratix folks ?

@nimakaviani @nabuskey @csantanapr

[nabuskey]

Thanks for writing it up!

Ideally an environment should be also decomposed into the underlying systems it is composed, their version, configurations etc.

I do agree that these information are very useful and would be great to surface them to end users.

In idpbuilder, we define package as an ArgoCD application and do not provide any guidance or framework for interactions between them. Meaning package implementations can do whatever they want through features supported by ArgoCD. So when we talk about Compositions, we are essentially talking about app of apps in ArgoCD.

As for Kratix, I've looked into it before and things did make sense other than the name promise (JS PTSD).

I have some concerns around Promises in Kratix though. They provide a clear contract between producers and consumers in the form of CRDs. But I often think having to define and maintain CRDs involves too much effort when you eventually have to support all kinds of applications. As you start to support different kind of environments and applications, your interface and abstractions become blur and nuanced.

I think it works well for new applications, but bringing existing applications is more important when doing something like this. What do existing applications gain from moving to this kind of model? At what cost?

I do like the concept of describing environments, but providing a definition for environments or applications is not something I want to get into. With the number of different applications in the wild, I don't think it's a good idea to try and abstract them to a definition unless there are something major we gain by doing it. There are many attempts at defining applications already. As far as I am aware, there has not been a clear winner that gained a major adoption.

I don't want end users to write applications for yet another KRM. I want them to write applications for something they are already using.

Can we surface information about an environment / applications without creating a definition for them?

I would love to hear what others think.

[cmoulliard]

In idpbuilder, we define package as an ArgoCD application and do not provide any guidance or framework for interactions between them. Meaning package implementations can do whatever they want through features supported by ArgoCD. So when we talk about Compositions, we are essentially talking about app of apps in ArgoCD.

We use today ArgoCD as the tool to define what a package is Application CRD but also as the technology implementing some of the features we need to fetch the resources (=> Helm, Kustomize, static files, etc), to deploy them on a cluster BUT it could be possible that, in a near feature, users will request to support a different adapter like FluxCD, etc This is why we need an abstraction layer able to tell to the idpbuilder what a package is (= a capability), etc (see my excalidraw diagram)

[cmoulliard]

I have some concerns around Promises in Kratix though. They provide a clear contract between producers and consumers in the form of CRDs. But I often think having to define and maintain CRDs involves too much effort when you eventually have to support all kinds of applications. As you start to support different kind of environments and applications, your interface and abstractions become blur and nuanced.

I'm not a big fan to use CRD (except to declare according to a standard openAPIV3Schema the fields to be used) and would prefer to have a true API on the platform exposing services (REST, etc) that users/cli/tools could use to select a package, configure it (= in/out parameters), specify potentially pipelines to be applied on the package post installation, etc

[cmoulliard]

What do existing applications gain from moving to this kind of model? At what cost?

There is always a cost to pay to use technology a + b + c and that will be the case too for new ArgoCD, FluxCD, etc users ;-)

[cmoulliard]

Can we surface information about an environment / applications without creating a definition for them?

To define a package/capability in a more abstract way and which finally can be translated into an ArgoCD Application (or whatever CR depending what IDPbuilder could support) it is needed to capture some metadata information:

• Name: The name of the capability
• Category: IDP category to which it belongs
• Version: Package version to be installed
• Adapter: Helm, Kustomize, OLM, etc and to be mapped with the technology: ArgoCD, OLM, Crossplane, Terraform, ...
• Parameters (validated against a schema):
  • List of k/v pairs
  • YAML file
  • etc
• Repository: where the package is available
• Labels: TBD
• Flow engine: Tekton, ArgoCD, etc
• Job description (to customize/enhance the configuration of the capability)
  • Name
  • Image of the task's executable
  • Reference of the Task: git, oci, etc
  • Params
  • Env variables
  • Workspaces (aka pvc)
  • Script or command + args

[nabuskey]

To define a package/capability in a more abstract way and which finally can be translated into an ArgoCD Application (or whatever CR depending what IDPbuilder could support) it is needed to capture some metadata information:

I am ok with something like this to define our packages instead of using ArgoCD application directly. Obviously the first thing we will support is ArgoCD. As long as we are only dealing with metadata about things that get installed, I think we are in a good spot.

Overall, I am trying to avoid getting into the business of orchestration. I don't think that's where we can deliver the most value. There are many existing tools out there already. If we do support customization of packages (I think we'll need to do it), we have to be careful about what we support. Installation order? modifying the same configmap from different packages? etc.

I also want to see more tightly integrated solutions deployed by idpbuilder other than the ref implementation. I am sure there will be a lot of duplication between them but I think they will help us refine what we want to do.

[nimakaviani]

I also want to see more tightly integrated solutions deployed by idpbuilder other than the ref implementation.

+1 on the above. I am still of the belief that a series of more tightly integrated solutions is what construes the notion of a CNOE stack. I dont mind the duplication actually.