Comment by igorzij | Hacker News Reader

Comment by igorzij | Hacker News Reader

Parent Full thread

Thank you for these points! I respectfully disagree :)

A raw Terraform module is quite hard to reuse out-of-context for someone who isn't familiar with devops / sysadmin concepts. What's a VPC? Security group? ACL? Each service exposes a bunch of config options that won't make sense to people who are facing it for the first time. TF mimics AWS interface, and it's more like a pilot's cockpit than a car interior. All tools imaginable out there, but you got to know what you are doing to use it.

Targets on the other hand are exposing high-level concepts only. How many services? Is it container or a function? Enable or disable database? Got it, starting building. More like a car interface or a phone UI which you can figure out by doing.

Current implementation of Targets is very simplistic. It just does the job but not much more. In Targets v2 we are planning to introduce proper dynamic generation with a "stack state" API that would allow to create truly incapsulated, smart components that would adapt to a number of environments.

I'm not sure I get your point - Terraform modules[0] are a generic way to encapsulate a set of Terraform resources. What variables you expose to the outside is up to the module developer - You can expose high-level variables like "service type" and "add a database" in your module as well. No need to understand VPCs, security groups, ACLs, either. The question whether there are high-quality Terraform modules that do that is a different one, that's why I think your service might still be of value _if those modules you maintain are of high quality and do reasonable things, which I haven't verified_.

Maybe you have great ideas for this target concept, but the claims in your documentation[1] that this is new and the inference that Terraform isn't capable of this don't hold up:

> it describes a particular architecture that can produce many possible variations for a wide variety of stacks, depending on configuration.

You can do exactly that, with Terraform modules, today, no digger needed.

[0] https://www.terraform.io/docs/language/modules/develop/index...

[1]https://learn.digger.dev/overview/how-it-works.html#understa...

Thanks again! This viewpoint has a lot of merit for sure. Please let me defend my claim on Terraform capability though. The real question isn't whether doing X is possible with TF; it's whether it's likely to be done in practice.

I am speaking from my own experience as a former front-end dev and making a bold assumption that there are many others like me. Whenever I'm using Terraform, even ready-made modules, I find myself thinking of things that I neither want to be thinking about, nor I need to be thinking about. Most of my brainspace is occupied by frontend intricacies; however I still do want to get control of the entire stack. The further some tool is from my primary competence the less capacity I have for various details about it. I want my webapps and containers to work somewhere, that's all. But when I'm facing a problem - a specific problem - I also want it to be solvable. Like autoscaling or load balancing. And I want it to be solvable in a way that's not against industry best practices. Because today I may have a team of 3 but in a couple years that may be a team of 300. I don't want to have to rebuild from scratch half way through. But I also don't want to waste time building something future-proof on day 1.

I get what you're saying and I think it's a valuable discussion to have (I remain skeptical whether handing off your infrastructure design is a good idea or not; but as someone working in the space I might be biased), but that's not my really my point to be honest.

I think that the documentation is making several technical claims (from the quotes I've provided) that are factually false. You're agreeing that it CAN be done with Terraform. Best practice isn't what is being discussed in the documentation, it claims that reusing isn't possible.

Granted, I'm not your target audience, but I would recommend to a) rephrase those claims so they're closer to the truth and b) start documenting the architecture of your targets and the quality of your Terraform code (does it pass tfsec tests for example).

If someone asked me to review this product for their startup, I would primarily see Terraform modules with unknown quality or architecture.

That's superbly helpful! Thank you so much!! We've taken note and will be working on improving docs and architecture transparency.

Reply on news.ycombinator.com