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

91–100 of 102 posts

Re: Decommissioning Otto

#91

Post by Leon »

morgante wrote: post #16
nixgeek wrote: post #12

Earlier quoted context omitted.

Seemingly every couple of days, someone on Twitter whom I follow will exclaim "Oh noes, Terraform did something bad". Seems like a 'principle of least surprise' violation. Is that something others have observed?

I've never run into that myself. I do always inspect the plan before applying, but fortunately Terraform makes that easy. Personally, I prefer it to alternatives like Boto/Troposphere because it's fully declarative and not coupled to a single cloud.

I'm going to throw one thing in here about terraform over boto / etc, it's actually really nice to have a way to put together your own modules. I think they could do a better job with some common libs to make it easier, but overall it's super powerful.

Re: Decommissioning Otto

#92

Post by woodhull »

0xmohit wrote: post #66
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…

It is unfortunate that all people can do is to complain. One should probably think that about sending a PR for a feature request or a bug report if it really impacts them. An attempt, even if in the wrong direction, would probably push the priority of the underlying issue higher for the core devs working on the project. If you can't do that, at least attempt to be constructive.

I've found that PRs against terraform tend to languish for months at a time with no feedback from hashicorp.

Re: Decommissioning Otto

#93

Post by [deleted] »

0xmohit wrote: post #66
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…

It is unfortunate that all people can do is to complain. One should probably think that about sending a PR for a feature request or a bug report if it really impacts them. An attempt, even if in the wrong direction, would probably push the priority of the underlying issue higher for the core devs working on the project. If you can't do that, at least attempt to be constructive.

[deleted]

Re: Decommissioning Otto

#94

Post by larrywright »

rdtsc wrote: post #40
pwelch wrote: post #33

Earlier quoted context omitted.

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.

I'm not the parent, but I've used both (Chef more heavily - going on 6 years, and I'm certified as a Chef trainer).

Your assessment is roughly correct, Ansible is definitely easier to get started with, and if you just want to manage a small number of nodes that you have SSH access to, it's a good choice. Chef has a larger ecosystem, and a different communication model (VMs under management communicate out to a Chef server over HTTPS, no need for inbound ports to be opened). The tradeoff is a slightly longer learning cycle. I'm biased towards Chef because it's what I know, but having spent some time with Ansible it's a good choice for some use cases.

Re: Decommissioning Otto

#95

Post by superswordfish »

JimDabell wrote: post #85
superswordfish wrote: post #71

Earlier quoted context omitted.

It doesn't take an expert sleuth to find things like https://www.hashicorp.com/blog/tags/case-study.html , so your "does anybody _actually_ use the HashiCorp stack" comes across pretty clearly as sniping.

Vendor-published case studies are pretty worthless IMO. I've seen plenty where the vendor was absolutely despised by anybody working for the client who had to deal with them.

Fair enough, I found parent's comment flippant because it suggests that HashiCorp's generous open source work is popular due to some hype conspiracy.

Re: Decommissioning Otto

#96

Post by nevir »

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…

Yes, we use the hell out of Terraform, Consul, and Vault - they're wonderful to work with

Re: Decommissioning Otto

#97

Post by eropple »

axelfontaine wrote: post #67
eropple wrote: post #65

Earlier quoted context omitted.

Speaking for myself, I've put enough tooling around Packer to make it tolerable in my build pipeline and I haven't found a better tool that does what it does (suggestions welcome!). I would be using Vault, except it's just on the far edge of usable for me (particularly around the aws-ec2 provider) and I am repelled sufficiently by Go that I'm not driven to hack it to suit my needs until I exhaust my other alternative…

If what you are after is generating AMIs for JVM, Node.js or Go apps, we at Boxfuse offer a great alternative to Packer with very fast creation of very small and secure AMIs https://boxfuse.com/blog/amis-in-30-seconds Disclaimer: I am the founder and CEO of Boxfuse

So I spent some time studying your product, and it looks like you'd like to charge me $100/month besides for a worse experience with more constrained features than what Packer gives me. At a very fundamental level it doesn't even look like it considers the notion that not everything is an app, that high-availability, fault-tolerant services exist and need to be run, that even "immutable" servers need a consistently updated method of service discovery and credential retrieval to be effective.

If I'm wrong, please let me know how I can write, as I would using Chef and Packer, a set of directives to install and prep Zookeeper, then discover other Zookeeper nodes in my cluster at runtime, while remaining aware of nodes that are replaced due to system failure. (If the explanation exists and involves "our proprietary, closed-source agent," or "our open-source agent that talks to a proprietary backend", you don't have an answer.)

Re: Decommissioning Otto

#98

Post by eropple »

seanp2k2 wrote: post #73
eropple wrote: post #65

Earlier quoted context omitted.

Speaking for myself, I've put enough tooling around Packer to make it tolerable in my build pipeline and I haven't found a better tool that does what it does (suggestions welcome!). I would be using Vault, except it's just on the far edge of usable for me (particularly around the aws-ec2 provider) and I am repelled sufficiently by Go that I'm not driven to hack it to suit my needs until I exhaust my other alternative…

Ever try https://github.com/Netflix/aminator/blob/master/README.rst ? Should work with Ubuntu as well.

A long, long time ago? It has been a while. But it also isn't what I'm looking for. Aminator is designed for pretty restrictive situations where you're deploying applications (in the form of single RPMs). And I do a lot of that in what Aminator considers a base AMI, and that's fine...but what do I use to build the base AMI? =)

Packer has a lot of user-friendliness problems (destroying build artifacts on failure, as the OP noted, being just one of them), but it does constrain the universe sufficiently that I can just run Chef and get on with my day.

Re: Decommissioning Otto

#99

Post by erichmond »

gameofdrones wrote: post #61
erichmond wrote: post #38

Earlier quoted context omitted.

Packer, Vagrant, Terraform, and we are working internally with Vault and Consul. Best devops tools (along with ansible) I've ever worked with.

What other deveops tools have you used/want to use?

I've been doing this professionally for 20 years, so that list is far too long to mention here.

Re: Decommissioning Otto

#100

Post by axelfontaine »

eropple wrote: post #97
axelfontaine wrote: post #67

Earlier quoted context omitted.

If what you are after is generating AMIs for JVM, Node.js or Go apps, we at Boxfuse offer a great alternative to Packer with very fast creation of very small and secure AMIs https://boxfuse.com/blog/amis-in-30-seconds Disclaimer: I am the founder and CEO of Boxfuse

So I spent some time studying your product, and it looks like you'd like to charge me $100/month besides for a worse experience with more constrained features than what Packer gives me. At a very fundamental level it doesn't even look like it considers the notion that not everything is an app , that high-availability, fault-tolerant services exist and need to be run, that even "immutable" servers need a consistently…

First of all thank you for evaluating our work. As I clearly stated in my post above, Boxfuse isn't intended as a general purpose replacement for Packer. If your usage falls within the usecases I highlighted it can be a very good fit though.

As for the notion of "immutable" servers, this industry term means servers that aren't updated in place, not servers without a read-write file system or read-write memory.

In the case of service discovery with client-side load balancing you can easily integrate client libs for services like Eureka or Zookeeper directly in your JVM application, or you can ship an agent (like Consul for example) and run that. You have a minimal Linux x64 system after all.

And no you don't have to pay $100/month. The licensing is based on a freemium model and your first app is free forever. And at the end of the day all you need to do is make the decision whether those monetary costs outweigh the value you get. And if it doesn't that's fine too. It simply means Boxfuse isn't the right fit for you.

You explicitly asked for suggestions for alternatives. All I did was provide one in case it may prove useful for you.

Post reply on HN