
Decommissioning Otto - zhenjl
https://www.hashicorp.com/blog/decommissioning-otto.html
======
Mizza
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/packer/issues/409](https://github.com/mitchellh/packer/issues/409)
\- no response from dev team whatsoever.

~~~
mitchellh
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 of
hobbyist and smaller company usage at dozen to hundred node scale. I only
don't mention specific names because I don't have explicit permission, but
you'll just have to trust I don't intend to lie here.

Vault as another example: if you interacted with a financial institution, your
transaction at some point likely hit a Vault cluster. Did you visit some
websites today? One of the world's largest CDNs has fully deployed Vault for
internal TLS cert management.

Those are just a couple examples.

Or, ignoring tech usage completely, we just had our first seven-figure quarter
after only three quarters of sales (and that was dozens of deals, not just a
handful). You just can't get those sorts of numbers without real world usage.

On completeness, I think the adoption speaks for itself. Tools don't get
adopted at the scale they're being adopted without being complete enough to
productively solve a real pain point. I believe we have a long way to go but
what we have already in most of our tools is relatively complete by measure of
being able to get real, meaningful, and productive work done.

Its unfortunate that we can't get to every open source issue and resolve every
problem for everyone, but please try to understand that the issue inbound
across our projects is massive in addition to trying to build enterprise
solutions for customers and run a business. We'd love to hire hire hire to
handle all the community inbound but that'd be irresponsible of us
financially. Our teams are slowly growing and we're also promoting more and
more community members to core committers who help out quite a bit, too.
Packer has ups and downs since we don't have a full team around it at the
moment but its on our radar of things to work on.

Ultimately, we can improve in every area and we'll strive to do so. In the
process, we're motivated and encouraged by our community and also by the
"serious work" we see our tools doing every day across various industries.

I'll follow up with you via email to see where we've fallen short for you. I
find these criticisms educational and would like to see where we went wrong.
I'm not doing that to hide anything from the public, but only because its hard
to have meaningful back-and-forth discourse in a few nesting levels of
comments. :)

~~~
Mizza
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.

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

~~~
JimDabell
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.

~~~
superswordfish
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.

------
ploxiln

        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 ...

~~~
yeukhon
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.

------
rdtsc
They did a good job at trying something, it didn't work as expected and they
were honest and decided to focus on something else. Those are all very good
qualities. I think that's commendable.

------
_bpo
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"

~~~
mitchellh
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 it
becomes challenging. On top of that, we always wanted Otto itself to be fairly
"thin" and delegate its difficult duties to the rest of the stack. This
required us to build a bunch of features we weren't ready to build into our
other products OR risk bloating Otto itself.

Overall, it was too early for us to do.

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

~~~
lstamour
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.

~~~
jacques_chester
> _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..._

I work for Pivotal on the Cloud Foundry buildpacks team. 4 of our buildpacks
(Ruby, Python, Go, NodeJS) are downstream forks of Heroku's.

We merge from upstream approximately weekly, but the pace has definitely
dropped.

We build all the runtime binaries we ship with our buildpacks. We also build
the rootfs it all runs on. Some of these pipelines are now fully automated.
For example, when a NodeJS tag lands, our pipeline will build the binary, add
it to a buildpack and put it through our battery of test suites. Our product
manager can make a release with a few keystrokes and a button press.

The difficulty of engineering really comes down to the nature of the ecosystem
you're turning into a buildpack. We did an article on writing buildpacks[0],
taking Rust as our example. It was a doddle, because of Cargo. Meanwhile our
PHP buildpack performs incredible gymnastics to make a 12-factor cloud
platform look like a shared host circa 1999.

[0] [http://engineering.pivotal.io/post/creating-a-custom-
buildpa...](http://engineering.pivotal.io/post/creating-a-custom-buildpack/)

------
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.

~~~
jacques_chester
Hear hear.

I work for Pivotal on the fringes of Cloud Foundry. Between us and other Cloud
Foundry Foundation members there are around 200 full time engineers working on
it.

Featuresome, robust, industrial-grade cloud platforms are hard.

------
apeace
Question for mitchellh or others at Hashicorp:

Will "zero configuration" be a feature/goal in your next attempts at this
abstraction? Was this one of the things that made building Otto so
challenging?

A few months ago when I tried Otto I found the "zero configuration" idea off-
putting. In fact, I couldn't even get a basic Python app to work because there
was no way for me to install libmysqlclient[0]. There really was no way to
configure anything in Otto.

FWIW, we ended up using Convox[1] and loved it.

[0]
[https://webcache.googleusercontent.com/search?q=cache:9QfCNX...](https://webcache.googleusercontent.com/search?q=cache:9QfCNXO52GsJ:https://github.com/hashicorp/otto/issues/400+&cd=1&hl=en&ct=clnk&gl=us)

[1] [https://convox.com/](https://convox.com/)

~~~
mitchellh
I'm still a big fan of minimal configuration through sane defaults, but not
advocating "zero configuration" in that sense that you have no power to change
those defaults.

One area I think we've done really well with this in the past year is the
"-dev" flag on Vault, Consul, Nomad. It is a zero-configuration way to get a
fully functional dev server up and running in one command though you can still
specify a config if you wanted. For non-dev, I just don't want to set dozens
of options just to get going, so we'll continue to strive for defaults that
work where we can.

All that being said, they are defaults, so you can always change them.

------
fn
I still use Vagrant every day. It's great for keeping separate projects really
truly separated.

------
manojlds
Considering the "progress" they were making, and the very lofty goals, this
was expected.

------
je42
Anybody using vault ?

~~~
otterley
Yes.

