Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decommissioning Otto

hashicorp.com

Post reply on HN
Print view View original

51–60 of 102 posts

Re: Decommissioning Otto

#51

Post by troymc »

nullcipher wrote: post #19
Mizza wrote: 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…

We tried terraform and gave up. We do use vagrant a lot though. How does HashiCorp make money?

They have enterprise versions of Terraform, Vault, Nomad, and maybe more. You can get them all in "Atlas". They'll also host it all for you, if you want (for a fee). They charge enterprise prices for all that.

Re: Decommissioning Otto

#52

Post by killbrad »

Mizza wrote: 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…

Yep, many people do.

Re: Decommissioning Otto

#53

Post by roman_sf »

mitchellh wrote: post #25
Mizza wrote: 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…

Hi Mitchell,

You guys rock! Hashicorp's tools are fantastic and pleasure to learn and use.

We're a small company and we're going to officially purchase Atlas in few weeks - because it saves tons of time. Also, every developer in our company (rather small company, where people have great flexibility what tools to use) has been cheering and clapping when we demoed CI/CD flow in Atlas. It's so easy to deploy and run services.

Cheers! Roman

Re: Decommissioning Otto

#54

Post by roman_sf »

apparentlymart wrote: post #42
apparentlymart wrote: post #39

Earlier quoted context omitted.

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 Terr…

Realized I missed a key point on Terraform: I advise anyone using Terraform in production to wrap it up in some sort of automation. Hashicorp would of course like you to use Atlas :D but you can get a long way with CI/automation tools like Jenkins, Rundeck, ... We have a wrapper script which: - configures the remote state in a predictable way (setting up remote state properly is one of the more fiddly parts of Terraf…

Just set remote with versioned s3 bucket, usually it's enough for insurance.

Re: Decommissioning Otto

#55

Post by colemickens »

Mizza wrote: 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 (qemu builder) is a huge step up from manually orchestrating image builds with qemu by hand.

Terraform seems to be a fully unique product. No CloudFormation isn't really the same thing, nor are Azure ARM Templates. Terraform has solved multiple problems for me that were not solvable any other way except for lots of manual orchestration done with bash scripts.

I haven't used Nomad yet, but I've heard good things and am happy Kubernetes/Mesos has some competition (no I don't consider Swarm Mode a real competitor yet).

Re: Decommissioning Otto

#56

Post by Mizza »

mitchellh wrote: post #25
Mizza wrote: 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…

Hey Mitchell, sorry for sneak dissing. I wasn't trying to hate on your efforts, which are greatly appreciated, I was more just trying to poll the community if people actually use the stack in production. Will follow-up in email.

Re: Decommissioning Otto

#58

Post by bashtoni »

Mizza wrote: 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…

We do pretty heavily

- Packer for production workloads for > 2 years

- Consul for production workloads for > 1.5 years

- Terraform for building production (and all other) infrastructure for > 1 year

Re: Decommissioning Otto

#59

Post by code_research »

Mizza wrote: 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…

unfortunately even vagrant is buggy and very slow and I would like to see a better alternative.

consul and vault are very nice for devops.

Re: Decommissioning Otto

#60

Post by gameofdrones »

bsuh wrote: post #28
Mizza wrote: 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…

Heck I found the same to be true of vagrant. Big promises, short on delivery. While mostly usable, it's definitely not as seamless across various guests, providers, and provisioners as their docs might have you think. Stray off the beaten path even the tiniest bit and expect to spend hours looking at github issues for workarounds (submitted by other users not the dev team). My experience. Windows guests: buggy FreeBS…

Abstractions-on-top-of-abstractions which promise to reduce complexity by adding more levels of indirection, when the UX of the underlying tools need to be better.

(Having wrote a multihypervisor disk-cloner in Ruby.)

Post reply on HN