Show HN: Terrabook – Replit for Infrastructure(terrabook.io)
terrabook.io
Show HN: Terrabook – Replit for Infrastructure
https://terrabook.io/
12 comments
Feedback from someone that started with traditional datacenter infrastructure and is now dealing with cloud-infra automation.
I don't see Terraform as the best IaC framework for lowering the barrier to put infrastructure into developers hands (personally I think that product developers should develop and not worry about infrastructure, but that's a different conversation).
The difference in state management is pretty much the biggest difference between Ansible, Puppet, and Terraform - the first two you don't have to worry about it. With Terraform you do. You can't just rewrite code and give resources new names, if you do during a plan it will tell you that it wants to delete the old named resources and deploy the resources with new names.
I don't see Terraform as the best IaC framework for lowering the barrier to put infrastructure into developers hands (personally I think that product developers should develop and not worry about infrastructure, but that's a different conversation).
The difference in state management is pretty much the biggest difference between Ansible, Puppet, and Terraform - the first two you don't have to worry about it. With Terraform you do. You can't just rewrite code and give resources new names, if you do during a plan it will tell you that it wants to delete the old named resources and deploy the resources with new names.
I'm not sure how this is really useful. It's just a snippet library?
It still requires you understand terraform and AWS constructs, and if you understand those, you probably don't need this.
It still requires you understand terraform and AWS constructs, and if you understand those, you probably don't need this.
i think the value here is more to small teams where only one person may know aws and terraform. a tool like this democratizes things a bit.
you could use terraform cloud or atlantis or custom ci pipelines, but all of that is more complicated depending on your perspective. you need to install a local toolchain for your editor, etc.
a dedicated infra team or a group of folks well versed in this stuff doesn’t need this tool.
you could use terraform cloud or atlantis or custom ci pipelines, but all of that is more complicated depending on your perspective. you need to install a local toolchain for your editor, etc.
a dedicated infra team or a group of folks well versed in this stuff doesn’t need this tool.
[deleted]
[deleted]
I understand Digger's philosophy of "always keep launching". You guys launch products on what seems like a weekly basis to see what might stick. All the products lead back to Digger. That being said, how is this specifically different than using Terraform modules? Is the big selling point just being able to click and generate terraform code? Is it different than what Brainboard is doing?
Yes indeed, we are launching lots of new things, sometimes brand new UIs altogether, or significantly reworked frontend plus big changes on the backend at a minimum. Our biggest fear is to build something that no one needs. Launches allow us to roll it backwards from the top of the funnel to mid-funnel (retention) to revenue and narrow down the value prop further and further. So it's not so much a monte carlo search, more of a binary search where each launch cuts off an entire family of potential directions our product could take. So if there are 10M possible solutions then it'd only take us 23 launches to zero in on the right one.
With Terrabook our hunch is that Terraform can be made much easier if it's generated in small chunks. The language itself is trivial, lightweight json basically. Nothing to learn there. But the AWS part is hard. What are the options? What should you write? And then having spoken to many users from previous launches we learned that people google TF snippets and copy-pasting them and tweaking just a bit. It's much easier to change if the bulk is already there. So we made this snipped generation pice with a UI inspired by Jupyter / Google Colab / Replit to basically lower the entry barrier into Terraform.
With Terrabook our hunch is that Terraform can be made much easier if it's generated in small chunks. The language itself is trivial, lightweight json basically. Nothing to learn there. But the AWS part is hard. What are the options? What should you write? And then having spoken to many users from previous launches we learned that people google TF snippets and copy-pasting them and tweaking just a bit. It's much easier to change if the bulk is already there. So we made this snipped generation pice with a UI inspired by Jupyter / Google Colab / Replit to basically lower the entry barrier into Terraform.
I am curious about your ROI for all those products you have launched.
On one hand it might devalue a lot your brand if users find the products halfbaked or somewhat bad on the other one you might capture some market and increase your revenue.
I am definitely more interested in the economics of all of this.
On one hand it might devalue a lot your brand if users find the products halfbaked or somewhat bad on the other one you might capture some market and increase your revenue.
I am definitely more interested in the economics of all of this.
why not just terraform snippets... in the snippet manager of your IDE?
The way it works for me is that I Google the TF module to get to the TF docs, it's faster to get to the exact resource... soni can see the docs for a field or see all available options. The snippet is not the main reason people google TF, I suspect
The way it works for me is that I Google the TF module to get to the TF docs, it's faster to get to the exact resource... soni can see the docs for a field or see all available options. The snippet is not the main reason people google TF, I suspect
hmm yes you are right, I've never thought of it this way actually.
my thinking with Terrabook was like, what stops non-devops-savvy developers from starting to use TF? And the hypothesis is that it's a bunch of things that need to be set up prior to getting to something working, like a VPC and so on. And then having that, how do I get a database? The fastest way seems to be just find someone's github and copy from there, assuming I'm not familiar with the TF world. So I thought, why not build this right into the tool
my thinking with Terrabook was like, what stops non-devops-savvy developers from starting to use TF? And the hypothesis is that it's a bunch of things that need to be set up prior to getting to something working, like a VPC and so on. And then having that, how do I get a database? The fastest way seems to be just find someone's github and copy from there, assuming I'm not familiar with the TF world. So I thought, why not build this right into the tool
> my thinking with Terrabook was like, what stops non-devops-savvy developers from starting to use TF?
That they can provision using a GUI console without having to understand all of the underlying AWS components required behind the scenes for a common setup.
I've seen a few takes at tools that attempt to "export your live infra to resources using standard providers in HCL files" but I haven't seen anything that's really good at that yet. Hmm...
That they can provision using a GUI console without having to understand all of the underlying AWS components required behind the scenes for a common setup.
I've seen a few takes at tools that attempt to "export your live infra to resources using standard providers in HCL files" but I haven't seen anything that's really good at that yet. Hmm...
The harder part for non-devops is not the TF side, but the cloud architecture and known best practices in design. After that the TF is pretty easy and mechanical
Another point to consider is that most devs don't want yet another tool / SaaS to do a bit of bootstrapping. Also, the move towards exposing non-devops to devops without guidelines / constraints is ill-advised. So many cost / security issues to clean up after by the devops team
Another point to consider is that most devs don't want yet another tool / SaaS to do a bit of bootstrapping. Also, the move towards exposing non-devops to devops without guidelines / constraints is ill-advised. So many cost / security issues to clean up after by the devops team
And then it hit us. With python, there's a huge difference in ease of use between a Jupyter notebook and locally run python code, even though the code is the same. So we don't even need to hide the code, as long as it is easy to write. Replit demonstrates the same concept even more vividly; but we thought we'd borrow the blocks idea from Jupyter / Google Colab.
This is how Terrabook came to be - just blocks of Terraform really. The key thing is that they are pre-filled, and you can write whatever you want.
a. Mix and match pre built terraform. b. Modify pre built blocks to create your own custom terraform c. Deploy to AWS in one click.
We also added templates for frontend, backend & databases - so you just click a button and get a working piece.
HN has been a constant source of constructive feedback for us, and we would be extremely grateful for insight on how you feel TerraBook is. Feel free to drop your harshest feedback in the comments below!