https://platformengineering.org logo
Join Slack
Powered by
This message was deleted.
# platform-blueprints
s
This message was deleted.
b
Can you give more context? What do you are looking for about APIs problem space?
r
Sure 🙂 . The authors of the Team Topologies book author recommend to use team APIs to reduce the amount of hands-offs. On the other hand, there is the concept of "Platform as Product", so my question is what APIs do create Platform teams to build that "Platform as Product"
g
We use REST APIs. Those APIs can handle the management of our resources (mostly infrastructure resources). For example, our internal client can request a database to our API and it will be properly created & configured based on user input and some default values (due to compliance and security reasons). Was it what you were asking?
r
Thanks @gabriel. Yes!
and from where those APIs are consumed? Slack, CI/CD pipelines, command line tools?
g
Today, CLI. For the future, we don't know. Maybe we can create web UIs, slack bots, any kind of interface that the user wants to use to interact with us
r
How those APIs/service connect with GitOps? My guess is that they should produce a Terraform configuration or something
b
I will circle back here soon. Sorry for dump questions and didn't have the time to get back @Raquel Pau Fernandez
👍 1
g
They are connected with GitOps natively, because we created our APIs extending the kubernetes API (by using CRDs). So resources will be created with YAML manifests stored in Git
r
@Gabriel Ferreira Therefore, are those APIs pushing yaml files to Git repositories?
g
The API isn't pushing YAML files, the API is Kubernetes, therefore we push files to Git, that will be deployed to our "Control plane" cluster, and this cluster (our API) will create the resources
b
CRD right?
👍 1
g
We are extending the Kubernetes API, not deploying our API to Kubernetes as if it were a regular workload. Our users could just use 
kubectl
to interact with us, but we built a CLI to "wrap the complexity" about understanding 
kubectl
CRD right?
Yep
b
Kube API can be you universal API for IDPs
You can create an interface with Backstage or CLI to push things though, if is what you want @Raquel Pau Fernandez
👍 1
r
@Gabriel Ferreira but those application repositories need to reference/consume your CRD somehow, no? (I am not an expert in CRD, I understand the main concept, but not the details)
So, for instance, if you need a postgres database, a CRD is hiding all the details, but the corresponding parameters for a particular application exists in their own git repository. My question was if those REST APIs where also pushing changes to those application repositories. But from your commend, if your API is Kubermetes, this is not the case. Ok 👍
g
We are in early stages of this platform, so things can change quickly. For now, we don't push CRD manifests to the application repository, there is another repository where these manifests are stored. So our client is coding in one repository, and the infrastructure resources are in another
👍 1
b
If I can give a suggestion: try to put everything in the hands of the application developers. This can be game changing to quick adoption because you are focusing in their developer/user experience
➕ 1
🙌 1
Even if is a abstraction layer such as jsonnet or Pulumi that can transpile afterwards to CRDs
r
correct me if I am wrong, because I am lost in translation here 😅 : CRD (the one whose 
kind: CustomResourceDefinition
) defines the implementation (changes in K8s) and applications reference this using the CRD name 
kind: Postgres
. So, what 
kind
of manifests are in the infrastructure repo?
g
The CRD (
kind: CustomResourceDefinition
) is created in the "platform repository", the repository where the platform lives. The 
kind: Postgres
is stored in the infrastructure repository (this Postgres is the kind that the CRD in the platform repo created) The client application uses this Postgres. They just need the connection string, which may be in some secret store. The Application code (for example, .NET) doesn't need to know anything about CRDs, just need to connect with the database that is created in the cloud
r
Thank you @Gabriel Ferreira!
g
There is 3 repositories in this: The repository where the platform API lives, the repository where the user/client application lives (Application that was created with the platform), and the IaC repository that contains the infrastructure resources for the team of the application developer
r
yes, now I can follow it
g
That's how we divide things here, but nothing stops you to use the same repository for the Application code and the infrastructure resources that it uses
👍 1
r
So, during the deployment process, of an application the pipeline accesses to the infrastructure repo, right?
g
Nope, we have different pipelines for these as well. The application pipeline is responsible to deploy the application to a K8S cluster The infrastructure pipeline deploy the manifests to create infrastructure resources in the cloud
In your example, the Application pipeline would know how to extract the connection string secret of Postgres in some Secret Store (Vault, for example). The Postgres CRD implementation creates and pushes the connection string to this Vault.
We don't need (for now) the application pipeline accessing the infrastructure manifests that it depends on. The Application just uses the infrastructure components, because they are already created. If the application needs some information about them (a Secret for example), it will extract from environment variables or something like that.
👍 1
r
because you are deploying to production straight away?
g
It can be deployed to production, yes. But that doesn't interfere with this flow Production or NonProduction follows the same flow (well, kinda. There is some specific compliance issues that is different for each environment, but it is specifically to our organization)
r
but, you can't deploy your application changes until the infrastructure is in the same environment than your app, and it is difficult to correlate/coordinate changes, isn't?
g
NonProduction Applications needs NonProduction database, and Production Applications needs Production databases
I don't know if I'm answering what you are trying to understand
r
yes, yes, sorry. I have had a really complete answer
g
Sure. The interesting part is that it is just the way that we do here. We may have problems that our platform needs to solve that you doesn't, so you can take a completely different implementation for your platform, as long as it solves your users problems 🙂 @Bruno Dias can have different answers for the same questions here
👍 1
h
If you want a video that sort of explains this methodology I suggest this one

https://www.youtube.com/watch?v=eEcgn_gU3SM&t=667s▾

helped me understand how the pieces might fit together ( its missing backstage for the UI piece )
👍 1
@Raquel Pau Fernandez
b
Another video that can help. Watch out for the tool trap. The important thing is the concepts behind it.

https://www.youtube.com/watch?v=Ii-lpLuzPxw▾

👍 2
❤️ 1
r
Thanks @Hugo Pinheiro @Bruno Dias
👍 1
h
I agree with Bruno, it also helps having management buy in and to survey the teams your building for to see what they are looking for
👍 2
h
@Diego Fernando Luisi

https://youtu.be/Ii-lpLuzPxw▾

Great video 🙂 !! & Waiting your next step video which explaining in deep dive how to design and deploy this IDP with Backstage + ArgoCD + ArgoCD Autopilot + Crossplane. Thank you again 👌
✅ 1
d
Thanks @htwalid
maybe in this weekend i ll record a new video
🙌 1
41 Views
Open in Slack
PreviousNext
Powered by