This message was deleted.
# general
s
This message was deleted.
k
I think using visual tools to define infrastructure is an interesting area (I recently wrote a post comparing and contrasting what Winglang and System Initiative are doing to move Infra as Code forward: https://www.linkedin.com/feed/update/urn:li:activity:7090314121950150656/
But, I am strongly opposed to "let's build stuff by hand first, we'll go back and automate it later". It's an antipattern you can see with automated testing and deployment as well as infrastructure. A few reasons: 1. It is much more expensive and disruptive than you may think to bring automation into a system that was built without automation. In the end, it tends to require completely rearchitecting and often rebuilding your system from scratch. Code autogenerated from existing infra is not maintainable, and very difficult to refactor.
2. You miss out on the design benefits that automation brings. A big part of the reason adding automation afterwards is that automating infra, deployment, and testing needs the system to be designed for it. If you've ever tried to add unit tests to a codebase that doesn't have them, you see how this works. You can't automate a blob. This is a good thing - if you build your system with automation from the start, it forces you to design with loose coupling. I should say, this really needs to include testing - you can write spaghetti IaC code.
3. You miss out on the use of automation to accelerate implementation. When you have the tooling and practices in place, you can develop quickly, not so much because writing and applying infra code is faster than point and clicking, but because of the confidence you have when working with a cleaner codebase with tests.
I think "building by hand first" is appealing because building with automation takes a level of maturity and discipline. Setting up IaC with tests and all takes a good bit of work, and you tend to have to hand-roll it. And if your team hasn't already built up the habits, there's a learning curve.
It's a "sprint vs. marathon" thing. And obvs. most people are willing to sprint to start, but it doesn't take very long to end up with a huge mess that makes you go very slowly, and have lots of problems with reliability, performance, etc.
Forgot #4: You can't reliably repeat and replicate stuff you've built by hand. So as soon as you have a couple of environments (e.g. test & prod), it's super painful to try to keep them consistent, and you get the "worked in test, why not in prod?!?" problem.
(Lotta words - this is a hot-button for me, not just because infra as code is my "thing", but because I deal with so many clients who have built huge messes this way)
r
Hi @Kief Morris you are spot on and I can’t agree more with your points. I think there is a real middle land where it’s possible to do ClickOps in a clean way that is not impossible to turn into GitOps. I think I’ll make a very short video for you to illustrate it. (In a few hours when I’m out of my bed 😅 )
s
@Romaric Philogène b/w there's one confusion I notice in the community around regarding the term using ClickOps and GitOps together, but I admit my perception can be wrong here, many people use a combination ClickOps and GitOps when they refer to saying it as an antipattern if you declaration state is in GitHub you are manually changing the state via clickops using dashboards, for beginners at least they try to think like this way while they notice conjunction of term ClickOps and GitOps, but what you are referring here is what I can relate but for a bigger audience and especially when you read and notice a place saying ClickOps to GitOps they were to be for antipattern, but you use ClickOps and GitOps that can be opinionated but I want to know your experience of anyone say to you like this before for me it's more often.
j
I think using visual tools to define infrastructure is an interesting area
I love that Kief, check what we are doing at Brainboard, because you just define our solution 😄