Thanks for another great video! That's actually the "beginning of the end" for other internal developer portal implementations, even with the current downsides it's still very usable! So we've seen how to build the portal, how to create Crossplane Compositions, and many other things; but what about the GitOps part? How do we define the structure of the GitOps repo to bootstrap the cluster addons? How do we support overrides for multiple environments for these addons? Is it something you have already covered in another video?
Does it allow to define "Day 2 operations" for such custom resources? For example, if we speak about databases, as a DBA I'd like to have an ability to run administrative operations (table vacuuming, reindexnig, etc) against databases provisioned from Crossplane provider. I'd like to be able to configure, which cluster the operation should run against, database name, table name and maybe some other flags. Is it possible in Port? And is it possible to link such operations with Crossplane claims?
You can add all those operations to crossplane compositions. Port, in the context of that video, generates forms based on composition schemas which you can use to submit to GitHub actions (or any other pipeline) where you will push manifests to git and let argo CD or flux take care of synchronization, or execute any other tasks. On top of that, port feeds the data from the cluster back to it's UI so that you can see what's going on. So, the short answer is yes 🙂
IF only this was not tightly coupled with K8s. K8s should be treated like any API provider, think Terraform structure. Port should have its own open schema and API. Not everything sits on k8s or should sit on it. But i would still want to offer these services to devs and more. Although Viktor wanted self discovery to the UI, please allow presenting the UI in a json for the structure, and the data, think adaptive cards.
Port is truly my choice for portal consoles. The alternative is backstage that is great only for those being able to have a dedicated team to manage it.
What do you think about "discovery" in Port? How important do you think that feature is?
For me, probably the most useful feature for a Dev Platform. I was always wondering why it didn't exist.
awesome and love your improvement suggestions. Especially the observability part. Developers must have insights to their resourses they created.
Awesome video, thanks :)
great video!!
Thanks for another great video! That's actually the "beginning of the end" for other internal developer portal implementations, even with the current downsides it's still very usable!
So we've seen how to build the portal, how to create Crossplane Compositions, and many other things; but what about the GitOps part? How do we define the structure of the GitOps repo to bootstrap the cluster addons? How do we support overrides for multiple environments for these addons? Is it something you have already covered in another video?
I'll add it to me Todo list for one of the upcoming videos.
Does it allow to define "Day 2 operations" for such custom resources? For example, if we speak about databases, as a DBA I'd like to have an ability to run administrative operations (table vacuuming, reindexnig, etc) against databases provisioned from Crossplane provider. I'd like to be able to configure, which cluster the operation should run against, database name, table name and maybe some other flags. Is it possible in Port? And is it possible to link such operations with Crossplane claims?
You can add all those operations to crossplane compositions. Port, in the context of that video, generates forms based on composition schemas which you can use to submit to GitHub actions (or any other pipeline) where you will push manifests to git and let argo CD or flux take care of synchronization, or execute any other tasks. On top of that, port feeds the data from the cluster back to it's UI so that you can see what's going on.
So, the short answer is yes 🙂
IF only this was not tightly coupled with K8s. K8s should be treated like any API provider, think Terraform structure.
Port should have its own open schema and API.
Not everything sits on k8s or should sit on it. But i would still want to offer these services to devs and more.
Although Viktor wanted self discovery to the UI, please allow presenting the UI in a json for the structure, and the data, think adaptive cards.
is this sponsored? why are you showing a paid solution? kind of disappointing..
Port is truly my choice for portal consoles. The alternative is backstage that is great only for those being able to have a dedicated team to manage it.