HashiCorp has raised $100 million in Series D funding

Congrats on your wedding!

We're going to be getting deep into multi-cloud (via acquisition), so your thesis on the topic was interesting to read.

I remember reading that original post all those years back and have built with all of your tools, so it'll be a thrill to dig into using Hashicorp as we do this. :)

I'm curious what you think of this crazy idea?:

With databases, some ecosystems use declarative migrations, where you keep a description of your schema, and the system automatically takes you from here to there. I've heard .Net people say how nice this is. On the other hand with Rails & Django you have delta scripts that give imperative directions for getting from here to there, rather than a declaration of the end state. I like that solution a lot, because sometimes you need more control over what to do. (For example, changing a one-to-many relationship to many-to-many, and moving the existing data.)

It seems to me that Cloudformation and Terraform take the declarative approach to cloud management, and there is no tool for the imperative approach. (Cloudformation has Change Sets but you can't write those or edit them; they just tell you its plan.) Resizing your database's EBS volume may be an example where you want to give careful instructions. Try that in Cloudformation and it will destroy the old volume and attach a new one. :-)

I'd love a tool that lets you keep a history of "cloud migrations", where you write both the "up" and the "down". It could be as simple as some organization around a bunch of fog/boto/aws-sdk scripts, although it would be even nicer if it had helper methods like in Rails, e.g. add_autoscaling_group, and those would usually know how to reverse themselves.

The really great feature would be to have "transactional DDL" for cloud migrations. With database migrations you get this for Postgres but not MySQL, and it's really nice. I know this isn't 100% possible, but CloudFormation comes close already with its rollback attempts. You'd definitely need your own layer of helper methods for this, because I can't imagine implementing it without something like a Command pattern. (The way AWS auto-generates their API tools, maybe it wouldn't even be that difficult to generate an identical API that just records what you want to do.)

I've pitched this idea a few times to AWS people, but maybe you should do it instead. :-)

Anyway, Hashicorp has contributed a ton to my developer happiness, so I wish you great success. Oh, and congratulations on your wedding!

Please please please make terraform imports automatically generate .tf configs.

I love Terraform. I’m glad it exists. Platform as a config. A fantastic idea and execution.

I don't want to dream up names for every little thing when 98% of them already have 'name' attributes and look almost exactly the same

The provisioners for Terraform are all specific to the cloud provider. If you changed providers you still have to change all of your templates.

Consul, Nomad, Terraform, and Vault are the only products that have associated enterprise products (in addition to being open source). Different products have different impacts different quarters but all of them are contributing many millions per year individually.

Vagrant and Packer do not have enterprise products and we don't try to monetize them much (Vagrant Cloud has some paid plans for box hosting but primarily so that we remain cost neutral). However, we're fully committed to them and both teams have full time engineering and management assigned to them. They're not deprecated in any way.