Hello, I'm one of the founders of HashiCorp! We're super excited about this. I'm really proud of the team that got us to this point, thankful to our communities, and just generally excited about the future for us.
The project that really kicked off HashiCorp was Vagrant, and I "launched" it right here on HN over 8 years ago: https://news.ycombinator.com/item?id=1175901 So its always fun to see things come back around. :) For those that are less familiar these days, HashiCorp now has many major OSS projects: Vagrant, Packer, Consul, Terraform, Vault, Nomad (in addition to lots of minor ones and libraries) addressing different areas.
For the HN crowd, there are a couple background viewpoints that I would also like to share that may be helpful on painting the backdrop on the product and business behind HashiCorp. A first quick one is my tweet on the four dimensions for "multi-cloud": https://twitter.com/mitchellh/status/1022162653618135040 At HashiCorp we're mostly looking at enabling #1 (workflow portability), though that has downstream effects of helping with the other dimensions as well.
While I'm happy to answer any questions, this post is rather late for me local time (past 10:30 PM here) and I'm leaving tomorrow to get married this weekend so I can't promise anything!
I would love to give Terraform a spin. However one thing our team needs is support for Ansible. If you look at https://github.com/hashicorp/terraform/issues/2661, radekg has worked on an Ansible Provisioner, but it looks like not many people know about it. Could some of your team maybe look at the following pull request https://github.com/hashicorp/terraform/pull/19021 and help radekq to ship the Ansible Provisioner? Thanks!
Congratulations! I've been a fan of Vagrant for a long time and have done some Vault as well. I haven't yet had a chance to try Terraform, but everyone says it is better than Cloudformation. :-)
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!
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. :)
Can you talk a bit about your password management bits? One of the other programs within our shop said they were going to use (or were doing a pilot) of password management with your kit.
I love Hashicorp products and i personally used most of them throughout my career, so big congratulations. The only thing i was always wondering is how are you planning to make money? It feels a bit like Docker - great technology, supported by big fundings, but the business side of things is very immature...
We're not comfortable talking about revenue publicly, but HashiCorp is an extremely healthy business at the moment. We've doubled revenue ( at least, maybe more ;) ) two years in a row and thats from a starting point of 7-figures. If we chose to halt hiring and growth, we could very easily be profitable today even with the 350 employees we have. But we're still seeing really strong growth and so we're continuing to invest!
Great news! The HashiCorp stack has really made my infrastructure work a much more enjoyable thing. Nomad and Consul in particular are wonderful antidotes to the complexity of Kubernetes for setups that don't require all of its features.
Terraform has become a big part of my professional life. It has become a force multiplier in my ability to solve large problems. I've liked it enough to regularly contribute to provisioners and make documentation improvements.
Terraform is the best you can get right now but it’s still so incredibly painful to use. Every team I’ve ever been a part of is ultimately building a custom framework on top of terraform to spit out .tf files. It’s so frustrating.
Except the fact that multi cloud doesnt work and I don't think it will. It adds too much complexity also costs are the big issue too since clouds price data transfer out quite heavily
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.
[+] [-] mitchellh|7 years ago|reply
The project that really kicked off HashiCorp was Vagrant, and I "launched" it right here on HN over 8 years ago: https://news.ycombinator.com/item?id=1175901 So its always fun to see things come back around. :) For those that are less familiar these days, HashiCorp now has many major OSS projects: Vagrant, Packer, Consul, Terraform, Vault, Nomad (in addition to lots of minor ones and libraries) addressing different areas.
For the HN crowd, there are a couple background viewpoints that I would also like to share that may be helpful on painting the backdrop on the product and business behind HashiCorp. A first quick one is my tweet on the four dimensions for "multi-cloud": https://twitter.com/mitchellh/status/1022162653618135040 At HashiCorp we're mostly looking at enabling #1 (workflow portability), though that has downstream effects of helping with the other dimensions as well.
Second, I often get asked "Why multi-cloud?" And I wrote up a fairly long answer on Reddit about that with real examples that I recommend: https://www.reddit.com/r/devops/comments/91afzz/why_multiclo...
While I'm happy to answer any questions, this post is rather late for me local time (past 10:30 PM here) and I'm leaving tomorrow to get married this weekend so I can't promise anything!
[+] [-] sritrisna|7 years ago|reply
[+] [-] pjungwir|7 years ago|reply
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!
[+] [-] tekacs|7 years ago|reply
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. :)
[+] [-] ManuelKiessling|7 years ago|reply
[+] [-] nojvek|7 years ago|reply
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.
[+] [-] heelix|7 years ago|reply
[+] [-] liveoneggs|7 years ago|reply
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
[+] [-] juddlyon|7 years ago|reply
Congrats on your wedding!
[+] [-] rad_gruchalski|7 years ago|reply
[+] [-] koolhead17|7 years ago|reply
[+] [-] luckylittle|7 years ago|reply
[+] [-] mitchellh|7 years ago|reply
[+] [-] matthewmacleod|7 years ago|reply
[+] [-] busterarm|7 years ago|reply
Thank you!
[+] [-] sitkack|7 years ago|reply
[+] [-] eeZah7Ux|7 years ago|reply
[deleted]
[+] [-] davidjnelson|7 years ago|reply
[+] [-] whalesalad|7 years ago|reply
[+] [-] scarface74|7 years ago|reply
The provisioners for Terraform are all specific to the cloud provider. If you changed providers you still have to change all of your templates.
[+] [-] zulrah|7 years ago|reply
[+] [-] amasad|7 years ago|reply
I only use Vagrant but it seems like it's in the process of being deprecated or at least de-emphasized.
[+] [-] mitchellh|7 years ago|reply
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.
[+] [-] jldugger|7 years ago|reply
[+] [-] PopeDotNinja|7 years ago|reply
[+] [-] BookPage|7 years ago|reply
[+] [-] setquk|7 years ago|reply
Please don't sell out to IBM in the future.