
Atlas by Hashicorp - danielsiders
https://atlas.hashicorp.com
======
alexatkeplar
Great to see the Hashicorp vision coming together across the individual tools!
We are huge fans of Vagrant ([https://github.com/snowplow/dev-
environment](https://github.com/snowplow/dev-environment)) and Packer at
Snowplow. Just starting to experiment with Serf and potentially Consul. The
"Hashicorp way" of devops has really helped us too.

The only real weakness I see in the stack is Terraform. The elephant in the
room is CloudFormation, and being built in Golang, Terraform is bounded by the
functionality of Hashicorp's own AWS client lib
([https://github.com/mitchellh/goamz](https://github.com/mitchellh/goamz)),
which hugely (and inevitably, given it's not a blessed 3rd-party library like
boto) lags the official AWS clients (compare to e.g.
[https://github.com/aws/aws-sdk-java](https://github.com/aws/aws-sdk-java)).
It's going to take something radical for Terraform to be relevant to
sophisticated AWS users.

~~~
eikenberry
Goamz suffers from the same problem that all the libraries that try to hide
the actual API do... that they can't keep up. Even boto has this problem as
keeping up with the latest version isn't always easy.

IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the
auth, the API and results are up to you. This requires more work but means you
never have to worry about the lib keeping up with the API. With something that
moves as fast as AWS this is great.

~~~
alexatkeplar
I'm not sure that's true of all the client libraries - I'm pretty sure that
the Java library is used heavily internally within Amazon to leverage AWS
services. Just look at the release history: [https://github.com/aws/aws-sdk-
java/releases](https://github.com/aws/aws-sdk-java/releases)

But you're right, maintaining even a blessed third-party library like boto is
a massive undertaking: 437 contributors, 431 open issues, 192 open PRs.
Competing against CloudFormation using anything other than the Java client
library is crazy IMO.

~~~
Rapzid
The .NET sdk is pretty fantastic as well.

But anyway, goamz is "Hashicorp's" AWS Go SDK in that Hashicorp forked it and
refused to work with the larger community because it's "critical" to their
business. This has, at least until super recently, stranded certain
functionality into the different forks and severely fractured the AWS Go
offerings. True story.

Ultimately, what the Go community probably needs most is Amazon to step up and
support a Go SDK officially. The Java, Ruby, .Net, and even Python SDK's are
very robust at this point. I can't speak to the others.

~~~
alexatkeplar
Good to hear about the .NET library. I hadn't heard the story about goamz,
that's unfortunate. I do know that there are SDKs which Amazon _only_ make
available in Java and Python, e.g. the Kinesis Client Library
([http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-
record...](http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record-
processor-app.html)).

------
dang
A related TechCrunch story:
[https://news.ycombinator.com/item?id=8727842](https://news.ycombinator.com/item?id=8727842).

We're probably going to build a way to group related stories more explicitly,
but manually posted comments will have to do for now.

~~~
kolev
Maybe we should establish a linking convention so that these can be converted
later more easily. For example, <url> #related.

------
jzelinskie
There have been some cool tools coming out of Hashicorp, but I haven't read
any experiences with people using their "full stack". Does anybody want to
give their own anecdote or maybe have a link to related article?

~~~
tonglil
\- Vagrant is a given, wonderful.

\- Packer is for syncing VirtualBox, AWS AMIs, and what not for quick and
stable starting points, also wonderful.

\- Consul is great for monitoring and running a services oriented
architecture, haven't pushed it to its full potential though.

\- Serf: n/a, haven't tried yet.

\- Terraform: n/a.

We are still using Ansible as the provisioner.

Overall, good ecosystem, would recommend.

~~~
porker
> \- Vagrant is a given, wonderful.

It's really useful, but on my MBP I've found using it abysmally slow
(VirtualBox backend, website code shared using NFS, DB and everything else
stored in VirtualBox VM and not shared folders) - page load times taking
upwards of 20s (sometimes even a minute) when running direct on my MBP would
be under 0.3s.

Never figured out the issue, in spite of extensive research and tweaking.
Replace VirtualBox with VMWare Fusion? But without a trial available of the
Vagrant addon, bit of an expensive gamble.

~~~
jesseendahl
Apparently syncing file changes between the VM and host via rsync leads to a
lot better performance than using NFS. Worth a shot at least:

[https://www.vagrantup.com/blog/feature-preview-
vagrant-1-5-r...](https://www.vagrantup.com/blog/feature-preview-
vagrant-1-5-rsync.html) [http://www.midwesternmac.com/blogs/jeff-geerling/nfs-
rsync-a...](http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-and-
shared-folder)

------
keithchambers
We use Vagrant, Packer, and Consul with multiple SaaS products here at Cisco.
We love the Hashicorp product family and team!

------
wallflower
Great job, Hashicorp!

Exciting to see the shift from clunky, heavy-weight versioned Chef
cookbooks/Puppet modules that attempt to prevent 'server drift' by walking the
directed graph for all dependencies with server convergence to true service
registries like Consul and build images.

Amazon CloudFormation is pretty clunky when it comes to updating user data in
the CF stack template that is passed to the resources. Sometimes it even
thinks you didn't update anything. Having the file-based template update
itself via consul-template seems like a more sane approach.

I am curious how the 'Maintain' part of the autoscaling works given that
Amazon AWS has pretty crude autoscaling mechanisms available if you use only
what CloudWatch offers. Hoping that 'Maintain' can be given a set of inputs on
server health/application responsiveness and decide whether to scale up or
scale down.

Also, integration with some kind of historical/real-time cost engine would be
a great feature to figure out future/past billing for cloud services.

------
hardwaresofton
As many have said, Hashicorp is awesome.

What I particularly like about their products and their sites is that they
take time to properly explain (and explain clearly) how their products fit
into your stack, and what their intended use case is. Rather than random
"we're working on something that will change devops forever" or similar
marketing speak, the Atlas site lays out exactly what their vision for dev and
ops is. The "how atlas works" section is brilliant.

I know I'm just repeating what others have said, but as usual, great work.

I think a lot of the work that Amazon has released this past few weeks is
trying to get into precisely this space. To be the only company behind your
code from development to deployment. I might be wrong, but I think hashicorp
is in that space right with them.

------
tobz
What is a node in terms of pricing?

Kinda/sorta feels like a stranglehold to have this remaining piece of the
Hashicorp puzzle be free and then to start charging for it. :(

~~~
mitchellh
Unlike our open source projects, Atlas is not shipping any foundational new
functionality; it is unifying our open source projects into a single solution
with a UI, security (ACLs, audits), workflow, etc. This differentiates it in
being a commercial product and we feel this is a really clean way to do it.
We've avoided any open core awkwardness and our business model is clear.

To put it another way, we use an analogy internally here at HashiCorp: our
open source are our "nuts and bolts" that you can grab off the shelf and be
very successful with in building robust systems, but Atlas is the complete car
or house (built up from these nuts and bolts) that you can purchase.

------
tapsboy
Great job Hashicorp. Couldn't find my favorited public boxes, but could
discover new boxes here
[https://vagrantcloud.com/boxes/search](https://vagrantcloud.com/boxes/search)

------
coreylane
It's hidden right now but if you'd like to search for boxes use
[https://atlas.hashicorp.com/boxes/search](https://atlas.hashicorp.com/boxes/search)

------
eaurouge
Any plans to support other providers, like DigitalOcean for instance?

~~~
mitchellh
Many, many more providers are along the way. The providers already exist in
the open source so its just a matter of enabling them one at a time in Atlas.
But we have some surprises planned for some of them as well. :)

------
ishbits
I wonder if there will still be a free tier, a place to drop decent base nodes
or images demoing open source and so on.

~~~
mitchellh
There will, across all the features.

------
akurilin
Looks very interesting! Would be great to get an idea of what a typical
workflow with this paradigm would look like.

~~~
kfish
There’s a getting started guide to walkthrough a typical workflow:
[https://atlas.hashicorp.com/help/getting-started/getting-
sta...](https://atlas.hashicorp.com/help/getting-started/getting-started-
overview)

In short:

\- `vagrant up` to bring up a development enviornment and make application
changes

\- `vagrant push` to send application code

\- `packer push` to package software requirements to produce an artifact (AMI,
Docker container, VMware image, many more)

\- `terraform apply` to deploy artifacts

Important to note that each of these commands can be executed by different
people in different sequences, and all changes are tracked in the Atlas
Dashboard/UI.

~~~
mitchellh
I want to add to what Kevin said here (and disclaim that he is a HashiCorp
employee) by saying that in a few months all of these steps will be possible
via the web UI and without a command line interface or any knowledge of our
open source at all. That is the direction we're heading.

The current form of Atlas requires usage of our open source and is a tech
preview showing what is coming and the direction we're heading. It is very
much functional but we're going to make it a very slick system that does all
of this for you without a CLI. For example, Atlas currently already runs
Packer for you on our servers. We're going to extend that to everything.

------
niclupien
Atlas as a project name seems very popular these days (Facebook Atlas API,
o'Reilly Atlas platform, etc).

------
tsukassa
Just in case someone is looking for something that already works and is open-
source, we have been working on ĵeto for over a year (
[http://jeto.io](http://jeto.io) ). You can host it on your own premises and
there is support for many providers out of the box(vmware, lxc, amazon). The
idea is pretty much the same, you have your vagrant project which calls
different providers.

You can checkout the dev version ( [https://github.com/Pheromone/jeto-
dev](https://github.com/Pheromone/jeto-dev) ) which prepackage everything.

Proper documentation/tests and a real Getting Started guide is coming.

------
joesmo
Vagrant has so many bugs in development (network issues, file syncing issues)
that I switched to manually building my own VMs _to save time_. I would never
use it or any tech built on top of it in development, let alone production.

~~~
robinricard
For all of the issues I have been facing, most of them were actually triggered
by virtualbox. Those issues can be quite annoying but can be solved quite
easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I
had major issues with those) does the job. On the other side, Vagrant has got
some minor issues but let's face it: doing what Vagrant does manually is huge
and I prefer composing with those issues than being on my own. When VB works
well and don't cause any problem, you can do quite complex setups with
Vagrant. I already created a swarm of 5 VMs on my machine to test my
deployments locally: Vagrant may not be imperatively useful for developers but
I think it's essential for everyone working on deployment and having the devs
using it too can greatly improve the life of those deploying the apps. One
last point: Vagrant is not made for production and I think Hashicorp has been
pretty clear on that. I never tested packer/terraform or consul so I won't say
anything on the production-side of what they're doing but I won't judge it
until I actually used it. Vagrant may have evolved since the last time you
used it, you should give it another chance !

~~~
joesmo
I would consider using it again if I really had to for more than just quickly
testing a VM, but to be honest, after wasting days with problems (which the
vagrant team is aware of) and then having it fail again and again, I'm not
very inclined to. I can see why vagrant encourages a workflow where one
destroys the VMs regularly as that would likely avoid a ton of issues at the
expense of time wasted.

My VMWare machines have been problem free for many months (as well as my
manual VBox ones for years) and the only way I'd even consider using it daily
again by choice again is to try out their VMWare support ... which is
unfortunately paid so I doubt that will happen. On the other hand, using
vagrant did point out some severe weaknesses in VirtualBox itself, especially
the file syncing support, and made me realize VMWare is worth the money for
that alone. I still use vagrant once in awhile if I only need to test a
project out for an hour or two.

As far as deployment, I could see the potential time savings when dealing with
multiple VMs but those would only be realized if they're not offset by a
longer time spent dealing with bugs. Still, I may give it another shot in that
context when the need arises next.

