Imo, one really killer bit is the first piece they mentioned:
"Google provides an SDK that enables users to run a suite of services along with an admin interface, database and caching layer with a single command."
I really wish AWS had a decent local dev story, rather than relying on 10 separate half-baked OSS solutions
Did AWS just pay them to write this? I was hoping for an interesting article exploring the complexities of a massively distributed and high-throughout system, but I just read “we connected these managed AWS services together and it’s cool”
Hopefully further instalments might actually talk about the problems they faced building this out, and their unique challenges.
I got to preview this service (the code review service) a few weeks ago.
The best thing about it was the recommendations on how to use the AWS SDK better as that's probably got the most potential to drift or make mistakes on
Great to see article putting it all together. Also going to be great to send this to people who think that using AWS cloud means that you can skip hiring people with skills in systems administration.
Eh, I have to point out that AWS has many services that receive such scant updates that they are effectively dropped products.
There are a lot of things that AWS produces which never receive adequate polish or timely updates. I’ve been in betas for more than a few new offerings and was stunned at how incomplete and buggy these offerings were. More than a year later, they remain in a half usable state.
Google dumps things it’s not committed to making great. AWS maintains numerous things which are half usable, poorly documented, and incomplete. It all depends on the context, but in some ways I prefer drops to half-assed products.
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).
I didn’t see anyone else mention AWS, so let me add: AWS is a tire fire of bad API design, in both v1 and v2. Just awful, awful stuff. Read it and weep.
Author here - I haven't updated this in a while, but am always grateful for the appreciative comments and emails I get when it gets rediscovered.
There's also usually two other comments:
1. Why isn't it funnier / meaner? (an early version had a couple more pointed descriptions).
2. Why aren't these names more accurate?
The answer to both is that I was trying to be help people form a rough mental model of what / how and in what context they would use the services - that they could then take as a jumping off point for doing their own research into.
Nobody is relying on my jokey 2 sentence description of these services to make deep architectural choices about their apps. What I have heard many many times though is: "Oh! I didn't realize that's what AWS Service X did."
Interesting. I’ve always found it befuddling as a generalist with a relatively high learning curve. I gave it the benefit of the doubt until Google Cloud started rolling out its updates with far better documentation and interfaces. That said, AWS has way better customer support.
As a seasoned AWS developer, I love this feature. However, I wonder how the increasing complexity of AWS affects new devs as they try to grok the offered services. AWS typically does a pretty good job hiding advanced features from beginners, but I wonder how long they can do that.
Would be nice if TechCrunch applied some skepticism or talked to experts or potential users about this idea rather than just summarizing Amazon’s presentation. Some of the claims being made about what this could do are pretty ridiculous, and clearly overstatements of the actual functionality. It can summarize existing AWS docs—one of the only actual concrete examples in the article says that it could list EC2 instance types and their properties in response to a question about where to host an app. And it will certainly encourage its users to use more AWS services to solve their problems. But it’s not going to be “transformative”. It’s a way out of doing the real work to improve their own documentation.
"Google provides an SDK that enables users to run a suite of services along with an admin interface, database and caching layer with a single command."
I really wish AWS had a decent local dev story, rather than relying on 10 separate half-baked OSS solutions
reply