Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant (<a href="https://github.com/snowplow/dev-environment" rel="nofollow">https://github.com/snowplow/dev-environment</a>) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too.<p>The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Golang, Terraform is bounded by the functionality of Hashicorp's own AWS client lib (<a href="https://github.com/mitchellh/goamz" rel="nofollow">https://github.com/mitchellh/goamz</a>), which hugely (and inevitably, given it's not a blessed 3rd-party library like boto) lags the official AWS clients (compare to e.g. <a href="https://github.com/aws/aws-sdk-java" rel="nofollow">https://github.com/aws/aws-sdk-java</a>). It's going to take something radical for Terraform to be relevant to sophisticated AWS users.
A related TechCrunch story: <a href="https://news.ycombinator.com/item?id=8727842" rel="nofollow">https://news.ycombinator.com/item?id=8727842</a>.<p>We're probably going to build a way to group related stories more explicitly, but manually posted comments will have to do for now.
There have been some cool tools coming out of Hashicorp, but I haven't read any experiences with people using their "full stack". Does anybody want to give their own anecdote or maybe have a link to related article?
Great job, Hashicorp!<p>Exciting to see the shift from clunky, heavy-weight versioned Chef cookbooks/Puppet modules that attempt to prevent 'server drift' by walking the directed graph for all dependencies with server convergence to true service registries like Consul and build images.<p>Amazon CloudFormation is pretty clunky when it comes to updating user data in the CF stack template that is passed to the resources. Sometimes it even thinks you didn't update anything. Having the file-based template update itself via consul-template seems like a more sane approach.<p>I am curious how the 'Maintain' part of the autoscaling works given that Amazon AWS has pretty crude autoscaling mechanisms available if you use only what CloudWatch offers. Hoping that 'Maintain' can be given a set of inputs on server health/application responsiveness and decide whether to scale up or scale down.<p>Also, integration with some kind of historical/real-time cost engine would be a great feature to figure out future/past billing for cloud services.
As many have said, Hashicorp is awesome.<p>What I particularly like about their products and their sites is that they take time to properly explain (and explain clearly) how their products fit into your stack, and what their intended use case is. Rather than random "we're working on something that will change devops forever" or similar marketing speak, the Atlas site lays out exactly what their vision for dev and ops is. The "how atlas works" section is brilliant.<p>I know I'm just repeating what others have said, but as usual, great work.<p>I think a lot of the work that Amazon has released this past few weeks is trying to get into precisely this space. To be the only company behind your code from development to deployment. I might be wrong, but I think hashicorp is in that space right with them.
What is a node in terms of pricing?<p>Kinda/sorta feels like a stranglehold to have this remaining piece of the Hashicorp puzzle be free and then to start charging for it. :(
Great job Hashicorp. Couldn't find my favorited public boxes, but could discover new boxes here <a href="https://vagrantcloud.com/boxes/search" rel="nofollow">https://vagrantcloud.com/boxes/search</a>
It's hidden right now but if you'd like to search for boxes use <a href="https://atlas.hashicorp.com/boxes/search" rel="nofollow">https://atlas.hashicorp.com/boxes/search</a>
Just in case someone is looking for something that already works and is open-source, we have been working on ĵeto for over a year ( <a href="http://jeto.io" rel="nofollow">http://jeto.io</a> ). You can host it on your own premises and there is support for many providers out of the box(vmware, lxc, amazon). The idea is pretty much the same, you have your vagrant project which calls different providers.<p>You can checkout the dev version ( <a href="https://github.com/Pheromone/jeto-dev" rel="nofollow">https://github.com/Pheromone/jeto-dev</a> ) which prepackage everything.<p>Proper documentation/tests and a real Getting Started guide is coming.
Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs <i>to save time</i>. I would never use it or any tech built on top of it in development, let alone production.