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

41–50 of 102 posts

Re: Decommissioning Otto

#41

Post by richardknop »

jcoby wrote: post #20
morgante wrote: post #17

Earlier quoted context omitted.

Have you considered starting your own stack from the ground up? I definitely find it a lot easier to manage and reason about if I mostly avoid third-party Terraform modules. Out of probably a dozen different Terraform projects, I've never run into a situation which I needed to manually resolve. This includes both projects which I started myself and cases where I'm helping to improve/manage client deployments. > I was…

> Have you considered starting your own stack from the ground up? Yes. I'm actually in the middle of trying that now. I want to set up a vpc, a few web servers (1-10) with an autoscaling policy behind the vpc along with a bastion server and a cron server, a code deploy setup to work with autoscaling, cloudwatch logging and monitoring, a load balancer, an elasticache instance, and an rds instance. I've been working on…

What you are describing is pretty trivial with Terraform so shouldn't definitely take months. A week or two.

You can look at my github.com/RichardKnop/coreos-cluster as an example (that one sets up a CoreOS cluster but you can take just the VPC, RDS, security groups, subnets and NAT bastion from there. I also have couple more terraform repos on my GitHub that deploy AWS infrastructures like you described.

Also look at the GitHub of Government Digital Service (GDS), I think it's alphagov. They have a lot of nice terraform stuff there from their experimentation with different PaaS.

Re: Decommissioning Otto

#42

Post by apparentlymart »

apparentlymart wrote: post #39
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…

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 Terraform usage) - takes a snapshot of the current state - runs "terraform plan" to produce a plan file - takes a snapshot of the current state, which has now been refreshed by Terraform - pauses here and waits for human approval of the plan - takes a snapshot of the current state one more time, even though it's usually just another copy of the last state we snapshotted - runs "terraform apply" to apply the plan created earlier - takes a snapshot of the final state

All that state-snapshotting is an insurance policy against Terraform getting itself confused. There are definitely some gotchas in this area[1] but honestly we've only actually made use of these zealous state snapshots on two separate occasions, and they were both on our pre-production staging environment (which we deploy to more carelessly, as a dry run for production) rather than our production environment.

I have thought about open sourcing that wrapper script but sadly it has some assumptions about our environment built into it (e.g. locking using a specific service in our world, so that two deploys can't run concurrently) and I've not had the time to scrub them out and generalize it.

[1] https://gist.github.com/apparentlymart/657885e730d1e5abc6ea

Re: Decommissioning Otto

#43

Post by lstamour »

newsat13 wrote: post #32
mitchellh wrote: post #22

Earlier quoted context omitted.

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?

Well, in Heroku proper, you feed its git repos an app, it figures out what type of app it is, and applies the right build pack and hosting environment for it. Keeping build packs up to date, keeping all the scripts running, and making sure an app has associated dependencies, etc--I imagine that's the difference between an independent setup you can self-host quickly and easily and one that's very dependent on an ecosystem of Heroku maintainers, tooling and existing server infrastructure...

It's a very hard problem to solve, and one which will likely only catch on as devops tooling improves and becomes expected for apps, and as app runtimes standardize. Alternatively, you could look at the myriad ways operating systems package applications, and the ways applications allow themselves to be packaged, let alone store data in production, and ... basically give up on this ever happening in an easy, hands-free automated way.

Re: Decommissioning Otto

#44

Post by ChartsNGraffs »

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…

Random positive comment. Thanks for what Hashicorp is doing. You all do a great job with many of the crucial pain points in the SW Dev lifecycle. We're using several of your products to solve some deployment/delivery issues and I can't even imagine how we would go about it without your tools.

Re: Decommissioning Otto

#45

Post by adamb »

Kudos to HashiCorp for realizing that the complexity of the project was getting away from them and for having the guts to pull the plug in such a public way.

Re: Decommissioning Otto

#46

Post by nixgeek »

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…

Mitchell, I appreciate what you do with Consul and Vault. Starting with Vagrant, you've made the world a little bit better and your sales growth is no surprise.

I've not had much luck with Terraform, I never really "got it" with Otto, it feels like Packer is unloved, and I'm also struggling to understand Nomad (vs. Kubernetes, Mesos, et al).

Hopefully constructive feedback -

There's some disparity between the level of "marketing polish" and "technical polish" with HashiCorp - almost all of the software had hype surrounding the announcement and they have slick websites but launch maturity has varied, and several products have felt like they lacked follow-on investment. Sharp edges haven't always been identified.

Keep pushing. :-)

Re: Decommissioning Otto

#47

Post by doh »

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…

In my experience all their tools have a pretty high barrier of entry as they require to learn in most cased a new language or at least alter your thinking. But once you master it, most of them are kicking ass.

For example we use Packer daily and it's just fantastic. Yes, once you need to debug it, it's a pain in the ass. Also it makes some basic assumptions for you (for instance it turns off project wide ssh keys while provisioning [in GCE], so you have to manually add them anytime you want do something).

We also use Terraform daily and it works well. Couple of bugs now and then, but it does things so effectively that once it works, you save a ton of time.

Re: Decommissioning Otto

#48

Post by daurnimator »

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 use terraform and I've gotten a few other people on to it.

Re: Decommissioning Otto

#49

Post by toddnni »

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/I use

- packer, that is a really nice and simple image building tool. It saved lot's of headache compared to tools like oz, because packer fails fast and saves debugging time.

- terraform, that is comparable to OpenStack Heat or AWS CloudFormations. Each have their own issues. But terraform being platform agnostic is an advantage for me.

- vagrant is not modern anymore, but it's ubiquitous.

Re: Decommissioning Otto

#50

Post by Dobbs »

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 use Conusl, Terraform, Packer and (sometimes) Vagrant.

Terraform is probably my favorite you have to be a bit careful running it against live infrastructure but it is so nice to be able to figure out who did what to your machines rather than clicking having people click around in the AWS dashboard.

Post reply on HN