Show HN: Terragen.dev – Automagically Generate Terraform for AWS
terragen.dev
terragen.dev
Maybe "Terragen" is going to try and "automagically" deploy all my GitHub projects into AWS or something nuts!
But we are often asked - why so many products that look so similar? After Digger we have also launched Lemon, Alicorn and most recently AWS Bootstrap to name a few. The answer is simple: we want every feature of Digger to be best-in-class. So we are making a product out of it and launch it and perfect it if people need it, or kill the feature if there is not enough demand.
Terraform generation is one of the most powerful features of the platform. Not only your AWS account is taken care of - you also get the underlying code that is fully customisable. So you are not limited by the UI and can literally build whatever you want as long as AWS supports it. It's easy with Terragen:
1. Connect your AWS account
2. Connect a GitHub repository for your infrastructure code
3. Terragen will push generated Terraform there
4. Then you can add more apps and services - and Terraform will get automatically updated!
5. And you can use the digger_overrides folder to add your own custom terraform
We believe that the only way to make a truly great platform is to listen to the users and ship things they need. Tell us what you think!
PS - we have also launched on ProductHunt today: https://www.producthunt.com/posts/terraform-generator-by-dig...
Do you generate Terraform code based on the AWS account, to help with a migration to Terraform?
Or is it that your platform works in that it "compiles" whatever is created in it to Terraform, to be run by the user on their AWS account? In other words, it's kind of a GUI DSL for Terraform?
my stuff uses terragrunt extensively. it would be really cool if this fit together nicely.
Really what a codegen would want to do in this case would be to make a terragrunt.hcl file that would make the accompanying terraform files callable.
It really wouldn't nessesitiate anything else unless you want to make it easy to parameterize values per CI environment. Then you want multiple terragrunt.hcls
- free for non comm
- subscription by month / year
- perpetual fixed version if you want
- maintenance subscription for perpetual if you want
- upgrade path from each to other
The users here have quite the options. I wonder what made Planetside choose this kind of licensing model.
We haven't yet put much attention into pricing. As a matter of fact the paywall is broken atm (don't tell anyone about it!) so technically nothing stops you from having more than one service or resource or whatever :)
Maybe flat per user + CI/CD (tf application) time? The latter grows with resources too.
The description and marketing are very mixed. It generates bespoke Terraform based on... vague descriptions? "Give me a postgres DB" seems to be the level of input from what I can tell. It then goes off to create one and give you the TF it used? I was really hoping this was "automatically generate Terraform FROM AWS" to import existing resources.
This sounds like the SaaS-ified version of Gruntwork.io, where they give you best practices templates and leave it up to you to fill in the particulars.
You might be interested in Terraformer. https://github.com/GoogleCloudPlatform/terraformer
[1] https://registry.terraform.io/providers/databrickslabs/datab...
They would love to sack some devops to replace them with juniors clicking stuff in UI.
Sooner or later real experts will be pushed out through SaaS solutions but overall the quality of solutions prepared will be crap.
I can already compare for example Datadog to our own dedicated Monitoring stack. Managers would never again allow us to build it, despite it being 10x better than generic solution.
Im bad at sensing this stuff during interview.
A DevOps Engineer should be a programmer focused on infrastructure, but we share toolkits.
With some level of empathy for our stakeholders we can be more effective as a team and customer-vendor and so forth.
I am not really concerned by developers figuring out that this is that easy partly because it frankly isn’t yet to help make systems scale. And the day infrastructure is legitimately brain dead simple I’ll breathe a huge sigh of relief that we managed to tame this mess of short sighted decisions and bits and bytes plaguing humanity. So sad to see how something so important to our society is this stupidly unnecessarily complex, but once we look into many other disciplines we can see how they have their issues as well and that we as engineers and laymen tend to just be blind to the inherent complexities of human systems.
I very strongly and fundamentally disagree with this sentiment. I know they don't, but they should!
Developers should understand how and where and why/why not their code is deployed. They should understand what their security model is AND HOW IT WORKS, because if they don't they will 100% without fail open their SG to 0.0.0.0/0 and embed hard coded passwords (usually "password", or "p@ssw0rd" at best). They should know what a VPC is, but maybe they don't need to know anything beyond "private network" and probably "NAT is involved".
Hiding these concepts is a double-edged sword. You get the simplicity of "make me a database" but don't understand why or how it works. You don't have to fiddle with security groups, until you do and then because you don't understand them you go with 0/0. You don't have to think about VPCs until you rack up a $10k bill because you never considered how you could route between instances vs round-tripping out of the VPC and back in through a LB - twice.
We've come full circle with the present-day cloud providers like AWS. 15 years ago they started as simplification, but today they are boxes of 200+ specialised building blocks that are anything but trivial to put together. A human specialist has to be involved. But why? This complexity is completely artificial, its sole purpose is to keep their customers locked in. This must and will be solved with better tooling. That's what we are trying to make.
1. Some of the stuff is genuinely complex.
2. The software engineers and development managers regularly ignore the user experience teams and their feedback.
At a basic level, I agree with you on the current state of IaC, but I feel like things such as CDK and Pulumi are attempting to address that issue more directly, so I'm curious why you decided not to use those instead. I believe it is much more difficult to get out of "cloud assembly" than these tools make it seem, and I think you have an interesting approach, but I agree with the sibling commenter who said that attempting to escape that completely is a bad idea.
One of the major problems solutions like this one tend to have is that they have sharp edges about what they can and cannot handle, and they also have places where there's a steep drop back into cloud assembly, for which the user attempting to avoid it in the first place is now woefully unprepared. This is true of AWS's myriad of simplification solutions, and this is also true of tools like Serverless. If I give a naïve user access to a service catalog that they have the ability to override at a low level, I might as well teach them how to handle the low level in the first place. It's not clear to me how you plan to address that.
Abstracting away the need to run Terraform directly is useful, but there are plenty of products that have made that their focus, including HashiCorp's, so I'm not sure how you differentiate yourself from those as well.
Looks decent. Good luck.
It’s important that there is a human understands how the stuff works that’s getting shipped to production. You can’t skip that step, or who knows what kinds of vulnerabilities and miss configurations will end up going live.
In my opinion, rather than building a tool for people who don’t understand the stuff, your target audience should change to instead be those who DO understand this stuff. This is not something that can be solved with automation-only if nobody understands how the pieces work.
I’m pretty sure your company can be sued for trademark infringement.
Are names automatically trademarked? Or did I search incorrectly? (I did only search on the UK and US pages though)