Hacker News Reader

Comment by alexatkeplar | Hacker News Reader

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant (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), 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). It's going to take something radical for Terraform to be relevant to sophisticated AWS users.

View on HN

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.

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

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.

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.

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

This Clojure library agrees with you, it reflects and post-processes the AWS Java library. https://github.com/mcohen01/amazonica

The sequence at AWS seems to be:

  1. Announce something in a blog post (sometimes get everyone really excited)
  2. Add access to that feature/setting in the AWS Web UI
  3. Add access to that in the official API
  4. Add access to that in aws-cli
  5. Add access to that in cloud formation stack creation

It seems sometimes weeks and months lag between steps (e.g. steps 2 to 3).

(Apologies for the self-promotion, but it's at least on-topic.)

I just opened up this repo yesterday: https://github.com/stripe/aws-go.

It's really raw, but it uses the JSON API descriptions from botocore to generate Go clients for all 40 public AWS services.

Reply on news.ycombinator.com