Developer Preview of AWS SDK for Go(aws.amazon.com)
aws.amazon.com
Developer Preview of AWS SDK for Go
https://aws.amazon.com/blogs/aws/developer-preview-of-aws-sdk-for-go-is-now-available/
7 comments
We use this library at work and although keeping up with the constant API changes is annoying, it works well. My main complaint is that this library is very "un-Go". Everything is a pointer, even required parameters. I understand that this is a result of automatic code generation used meet the needs of various APIs with different semantics, but Go's lack of pointer literals makes it hard to use (you can't write something like &"hello world"). So I consider this a low-level library, and wrap it with more Go-friendly code.
The devs are definitely aware of this issue, and I thank them for getting rid of map pointers. I don't think there's an easy solution.
The devs are definitely aware of this issue, and I thank them for getting rid of map pointers. I don't think there's an easy solution.
Worth noting that they provide helpful functions for pointer-ization:
https://github.com/aws/aws-sdk-go/blob/master/aws/types.go
https://github.com/aws/aws-sdk-go/blob/master/aws/types.go
I hope they will rewrite awscli with it. Today it's quite painful to run it on coreos (python/pip ran in a container)
Why is it painful?
Because if not run in a container, you should put things that upgrade Requests in a venv at least otherwise you may end up breaking apt.
But shouldn't you always use a virtualenv anyways?
Project-wise? - Most definitely! Globally? - Not common practice, but also preferred to avoid collisions.
You might consider taking a look at Twitter's pex. Python supports importing and running code from zip files. pex aids in bundling python code and its dependencies into an executable zip file.
Unfortunately that's simply not the same. Python libraries many times still require header files to be present, which means on a host you want to install PyOpenSSL you must also install libssl-dev, which means you also much install python-dev... etc etc. Don't get me started on using gevent.
A container is the only sane way to package a python service, but that's not _nearly_ as convenient as a statically compiled binary.
A container is the only sane way to package a python service, but that's not _nearly_ as convenient as a statically compiled binary.
Legacy CentOS too
Quality, comprehensive client SDK code and documentation is a major competitive advantage for any cloud computing platform.
It's good that Amazon seems at last to be taking SDK development seriously.
Amazon spent a very long time apparently not realising that AWS features only exist if they are supported in client SDKs. Instead it went wildly ahead building vast numbers of features for AWS, leaving behind a trail of incomplete, out of date, poorly implemented, poorly tested, and poorly documented client SDKs. The outcome being that when a new AWS feature was announced, chances were you couldn't use it because it didn't exist in any SDK for your programming language of choice - unbelievably frustrating to have to read feature announcements knowing there was no way to use them. Features aren't complete until all the client SDK's include code to drive it.
Amazon has fixed this as far as I can tell now has excellent SDKs for a wide range of languages and appears to keep them up to date for the most part with the features in AWS. The AWS SDK documentation is excellent and the SDK code appears complete, tested and reliable. Woo hoo. Thanks be to the gods and thanks to Amazon for comprehensively addressing this critical requirement.
So it is very gratifying to see that Amazon appears to be getting serious about covering all the AWS features with modern, up to date, documented and tested client SDK's.
In fact Amazon leaves Google far, far behind in the dust in the area of client SDK quality. Google is so far behind Amazon in programming SDKs for its cloud computing platform that its hard to see that they could catch up any time soon.
Google is still scratching its head wondering why it is so far behind in cloud computing and still without a clue that client SDK's matter. Google doesn't even have a Python 3 API for its cloud computing platform, let alone an official, complete, tested, documented and supported Go API. Google internally uses Python 2 and Java so that's what its cloud computing platform primarily supports. Google seems a little puzzled at the idea that you might not use the same programming languages that it does. As for documentation, the Google cloud computing platform documentation is worse than bad - it's often wrong, which translates into hours and sometimes days or even weeks of wasted effort (from personal experience).
It's good that Amazon seems at last to be taking SDK development seriously.
Amazon spent a very long time apparently not realising that AWS features only exist if they are supported in client SDKs. Instead it went wildly ahead building vast numbers of features for AWS, leaving behind a trail of incomplete, out of date, poorly implemented, poorly tested, and poorly documented client SDKs. The outcome being that when a new AWS feature was announced, chances were you couldn't use it because it didn't exist in any SDK for your programming language of choice - unbelievably frustrating to have to read feature announcements knowing there was no way to use them. Features aren't complete until all the client SDK's include code to drive it.
Amazon has fixed this as far as I can tell now has excellent SDKs for a wide range of languages and appears to keep them up to date for the most part with the features in AWS. The AWS SDK documentation is excellent and the SDK code appears complete, tested and reliable. Woo hoo. Thanks be to the gods and thanks to Amazon for comprehensively addressing this critical requirement.
So it is very gratifying to see that Amazon appears to be getting serious about covering all the AWS features with modern, up to date, documented and tested client SDK's.
In fact Amazon leaves Google far, far behind in the dust in the area of client SDK quality. Google is so far behind Amazon in programming SDKs for its cloud computing platform that its hard to see that they could catch up any time soon.
Google is still scratching its head wondering why it is so far behind in cloud computing and still without a clue that client SDK's matter. Google doesn't even have a Python 3 API for its cloud computing platform, let alone an official, complete, tested, documented and supported Go API. Google internally uses Python 2 and Java so that's what its cloud computing platform primarily supports. Google seems a little puzzled at the idea that you might not use the same programming languages that it does. As for documentation, the Google cloud computing platform documentation is worse than bad - it's often wrong, which translates into hours and sometimes days or even weeks of wasted effort (from personal experience).
I checked this out when it was part of Stripe. I found it worked very well for my limited use-cases.
Personally I just prefer python and boto for most of my AWS tools, but times where I've switched to go is to take advantage of static compiling and concurrency:
1. Listing all of my AWS instances in all accounts in all regions (lots of api calls!) 2. Downloading/uploading large files via multipart API 3. Various server-side configurations
Personally I just prefer python and boto for most of my AWS tools, but times where I've switched to go is to take advantage of static compiling and concurrency:
1. Listing all of my AWS instances in all accounts in all regions (lots of api calls!) 2. Downloading/uploading large files via multipart API 3. Various server-side configurations
No credit or good words for Stripe where this originated?
Both were supplied when we first announced the SDK! See https://aws.amazon.com/blogs/aws/coming-soon-aws-sdk-for-go/
Didn't see that, but I think it would be nice to give credit until the first stable release.
Very exciting to see an official SDK for AWS. We'll be looking into using this for Juju.
The ability to build a container that clocks in at under 10MB (vs ~700MB for a ruby aws-sdk stack) based on a minimal busybox container and a standalone go binary makes it an ideal use case for presence or short-running cron-type containers.
Also, the quality of the existing AWS sdk clients (especially with the most recent major versions) has been excellent (at least in my experience with the ruby and PHP libraries).