4 ms·
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://
by alexatkeplar 12y ago
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 12y agoGoamz 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.
- alexdean 12y agoI'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.
- deleted 12y ago[deleted]
- Rapzid 12y agoThe .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 12y agoGood 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-processor-app.html http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record...).
- vdm 12y agoThis Clojure library agrees with you, it reflects and post-processes the AWS Java library. https://github.com/mcohen01/amazonica https://github.com/mcohen01/amazonica
- wallflower 12y agoThe 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).
- codahale 12y ago(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 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.