@Daniel Bryant If you make your platform accessible my UI mostly, how do you make sure that the setups are reproducible? We for example strive to have everything in code, so we provide mostly API or specific code fragments (interpreted by our platform and translated to infrastructure components). With stuff clicked in the UI, we would have the same issues just like e.g. doing this in the AWS console 🤔

Would suggest having a look at talks like @Taras Mankovski to see how you can have UI's that still produce 'as code' setups.

@Dirk Jablonski If you keep the UI thin and source your data from repositories then should be able to get best of both worlds. Backstage out of the box uses GitOps practices. It’s just a matter of maintaining that functionality as you add more features to the frontend.

+1 to @Taras Mankovski’s comment. In the product I work on, Ambassador Cloud, we take the same approach mentioned above. e.g. you can create routes/mapping for your Emissary-ingress API gateway via the UI, and when you click apply a PR is opened against the target repo with the K8s YAML changes

In this case we would need to implement a separate auditing system, since with code changes done by the devs themselves, we automatically have audit trail in Git. But maybe this is a specific challenge due to our auditing requirements.

I don't think you would, Dirk (but I may have misunderstood?). In my example, when a human user triggers an action via the UI we open a PR with the generated YAML changes, and so the only difference is that a bot makes the PR rather than the human

Maybe that could work 🤔 Currently we have the commit by the dev, and, where four-eyes-principle is required,the approval. Thanks a lot for the discussion, I'll have a closer look at this solution 🙂

Happy to help! And please reach out if you want to chat -- I can jump on a Zoom and we have CX experts that can deep dive, too

@Dirk Jablonski you might find this video interesting it’s an example of using UI that writes via GitOps

We are also doing a similar thing in Gimlet. The dash only writes the gitops repo, just faster and more convenient than doing by hand in many cases. Flux then delivers the changes to the cluster. Clickops.. over gitops.