Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

Would we be better of say running our windows workloads on vms using something like KubeVirt?

If I understand correctly, in your gitops repository CI you create a new cluster to test the change?

In our gitops repo CI we primarily ensure that the change results in valid Kubernetes manifests.  This can be done by rendering the manifests similar to however ArgoCD is setup (Helm, Kustomize, etc), Then pass those manifests to <https://github.com/yannh/kubeconform|Kubeconform>. No need to actually deploy them into a cluster for this

If you want to perform some validation afterwards, I'd recommend deplying them into a kind of k3s cluster in your CI, then something like kuttle or kyverno to test against a policy

No windows specific knowledge  I can help you with thoug, sorry

Pretty sure for windows nodes you need to spin them up on hyperv not sure if they run on a Windows PC running docker desktop though :thinking_face:, think the vm that docker spins up is a Linux machine so ya probably wouldn't work

~<https://kind.sigs.k8s.io/>~
~this won’t work?~

<@U052XG2AAJX> please have look at that loom. This should help you with your the local side. <https://www.loom.com/share/09207d4ee1174295bda750807c966cbc?sid=93639857-4e5a-490d-8e6f-3e8f6284f42a|https://www.loom.com/share/09207d4ee1174295bda750807c966cbc?sid=93639857-4e5a-490d-8e6f-3e8f6284f42a>

<@U052XG2AAJX> I think our team is trying to do something very similar, where tenant "teams" can each deploy resources within their own namespaces using ArgoCD, possibly (likely) using Platform as well. Very interested in your lessons learned and outstanding problems with this.

Hi <@U064CTTTX53> current plans are around leveraging the App of Apps pattern in Argo so that we can declaratively have our ArgoCD `Application` resources in a git repo that Argo is sync'ing. Using Port we can offer a UI for a user to create a new application. i.e. commit a new `application` resource to this repo on their behalf. The `application` resource will point to the applications' gitops manifest repo. Currently avoiding any plans to making that repo opaque and go with transparent manifests. i.e avoid using Helm charts that would otherwise abstract the changes that are about to be reconciliated by the GitOps operator.

Plan to leverage things like Score to provide a declarative configuration and things like Crossplane and Atlas to bring the GitOps approach to non Kubernetes resource like cloud resources and dastabase schema.

We've burnt lots of time recently looking at being able to spin up our platform locally. The ball and chain for us has been that we need our k8s cluster to be hybrid meaning it has at least one windows node in the cluster. Not been a easy path to go down. Still not happy with it. Hoping our org can shift off the windows dependency in the near term.