https://platformengineering.org logo
#platform-design
Title
# platform-design
d

Dirk Jablonski

06/10/2022, 12:33 PM
@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 🤔
m

Martin Sperrin

06/10/2022, 2:01 PM
Would suggest having a look at talks like @Taras Mankovski to see how you can have UI's that still produce 'as code' setups.
t

Taras Mankovski

06/10/2022, 3:12 PM
@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.
d

Daniel Bryant

06/10/2022, 4:43 PM
+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
We do the same for canary releases via a UI, which generates Argo CD/Rollouts YAML. Under the covers it's effectively "config generation"
d

Dirk Jablonski

06/10/2022, 4:48 PM
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.
d

Daniel Bryant

06/10/2022, 4:51 PM
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
You still have the human approval/merge step and the history in git
☝️ 1
d

Dirk Jablonski

06/10/2022, 5:04 PM
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 🙂
d

Daniel Bryant

06/10/2022, 5:05 PM
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
t

Taras Mankovski

06/20/2022, 5:12 PM
@Dirk Jablonski you might find this video interesting

https://www.youtube.com/watch?time_continue=653&v=L_x7z4CXHDw&feature=emb_logo

it’s an example of using UI that writes via GitOps
l

Laszlo Fogas

08/24/2022, 11:53 AM
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.
20 Views