Live data from Hacker News

Decommissioning Otto

hashicorp.com

31–40 of 102 posts

Re: Decommissioning Otto

#31
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

I found found packer to be quite useful for building VM images for my team. It's a little hacked together, but far better than the manual process it replaced.

Packer was great when I was doing immutable infrastructure with VMs, but for Docker it doesn't offer a compelling story anymore.

I still think Terraform is great though.

Re: Decommissioning Otto

#32
post #2

It's too bad (and uncharacteristic of mitchellh) that this post is so light on specifics. Were the "previously unknown challenges" simply that not enough people adopted Otto? Or were there actual technical hurdles? The premise of Otto isn't clearly flawed, so it would be interesting to see specific challenges - even if it's just "the problem space is way too big and not enough people wanted it"

I'm happy to answer myself. Previously unknown challenges are just the various facets of building and deploying an application. Its not so much that they were unknown problems so much as the abstraction we designed for doing so proved challenging to solve those problems. Ultimately, Otto was trying to be a masterless PaaS (Heroku, etc.). When you frame it that way and think about all the things you'll have to solve i…

Thanks for your comment/insight. I understand what a PaaS is but what does the 'masterless' qualifier mean?

Re: Decommissioning Otto

#33
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

Yes!

TerraForm has been huge for us. Packer has been great. We plan on rolling out Vault fully and consul to our entire infrastructure.

The tools I listed above are essential along with Chef, ansible, and git are essential for our tools stack.

Re: Decommissioning Otto

#34
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

Ouch! My feelings are hurt. :( Everyone has a different experience and perception I suppose. I agree we have a long way to go, but I disagree that our tooling is "very incomplete" OR "un-battle-tested". Ignoring Vagrant as you did, Consul is used at multi-thousand node (per datacenter) scale by dozens of companies and a couple specific companies are using it at an even larger scale. And that's ignoring the thousands…

I, for one, think your tools are brilliant and have made my life as an engineer in a highly regulated environment much easier. I don't make many comments here, but I feel taking the time to thank you and your team for your hard work is needed.

To be sure, there is always room for improvement. HashiCorp does an incredible job at providing active support for the tools they create, and the active community that they've built up over the years is proof of their dedication to their ecosystem.

Keep doing what you're doing, Mitchell!

Re: Decommissioning Otto

#36
post #5

Otto, the successor to Vagrant 772 points agonzalezro a year ago 177 comments (https://www.hashicorp.com/blog/otto.html) Me at the time: Are you kidding?! Me now: Oh, I even forgot about that, the world of software engineering isn't always insane after all, I should lighten up ...

I don't know why people are downvoting you. I seriously think this should be at the top.

The trend of complete replacement but discontinue about a year later is very discouraging trying anything new.

Re: Decommissioning Otto

#37
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

Consul is probably one of the best pieces of software I've ever used and is the category leader for service discovery

I'd be interested in any data which backs this up.

Things like ZooKeeper have been around a lot longer and are definitely also in widespread usage.

Re: Decommissioning Otto

#38
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

Packer, Vagrant, Terraform, and we are working internally with Vault and Consul.

Best devops tools (along with ansible) I've ever worked with.

Re: Decommissioning Otto

#39
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

At work we use Packer, Terraform and Consul across all of our apps, and little smatterings of other stuff in some places. A little on each:

- Packer: Not my favorite, honestly. I can't argue that it's doing the job, but it feels inflexible and hard to integrate into a coherent workflow. It seems that Hashicorp Atlas can smooth this over in principle; we don't use it, because it didn't seem to fit with our use of Terraform at the time we got started, and we have a semi-home-grown alternative now.

- Terraform: We're using Terraform not only for low-level infrastructure stuff (VPCs, subnets, etc) but also for application deployment. I'd say our success with Terraform was due to a couple things. First: we picked up Terraform at a time when we were in the process of a total infrastructure rework in our org anyway, so we were effectively starting from scratch. Second: I spent a few months using Terraform for toy things and learning what it was good at, what it was less good at, and building a "pattern library" of techniques that had worked out. Once we started applying it to real problems, we just cherry-picked suitable patterns from that library and used them. I expect that Terraform is tougher for someone who already has significant infrastructure deployed and is trying to manage it with Terraform with few changes, since there are definitely approaches that are harder to model in Terraform than others.

- Consul: I really enjoy the simplicity of Consul. Getting a cluster up and running is pretty straightforward. Once you have it running, you get a highly-available, datacenter-aware key/value store and a service registry. We honestly don't use the service registry very much, but we have made extensive use of the consul-template utility in conjunction with Terraform's consul_key_prefix resource to have applications/services announce where their endpoints are for consumption by their clients.

We actually decided against using Vagrant because it was "more bulky" than our app developers were willing to tolerate. Instead we continued with our previous solution (running the apps direction on the users' laptops with a README in each app describing how to get it running) being optimistic that the new Docker for Mac and Docker for Windows would be awesome enough to get the good parts of Vagrant in a lighter package.

Vault showed up a bit late for our "architecture remix" so we solved our Vault-ish problems in other ways. I like its design in theory, and would probably give it a try if the opportunity arose.

Similar story with Nomad: too late for us, and we'd gone down an alternative path before it showed up. Can't really speak to it, since I only dabbled with it very briefly.

I'm sad but honestly not surprised to see Otto phased out. I was initially excited when it was announced last year but I could never really figure out how to get it to behave in the way I expected... I always felt like I was fighting it, and doing things in a way it didn't expect. I think there's room for the Hashicorp family of tools to "tessellate better", but Otto seemed like a very coarse, heavy solution -- essentially wrapping and templating the complex tools underneath -- where I was more hoping for the tools themselves to grow features to close the gaps.

This turned in to a bit of a rant, so I'll stop. :D

Re: Decommissioning Otto

#40
post #33
post #8

Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…

Yes! TerraForm has been huge for us. Packer has been great. We plan on rolling out Vault fully and consul to our entire infrastructure. The tools I listed above are essential along with Chef, ansible, and git are essential for our tools stack.

You mentioned Chef and Ansible. Using both? What are you thoughts on one vs the other? Chef seems more powerful / flexible, ansible maybe a bit simpler.
Post reply on HN