
Amazon API Gateway – Build and Run Scalable Application Backends - strzalek
https://aws.amazon.com/blogs/aws/amazon-api-gateway-build-and-run-scalable-application-backends/
======
fosk
This is very interesting, and I am surprised it didn't happen a long time ago.
The Lambda function integration opens up lots of new ideas when building API
backends ready to be consumed by clients apps like, for example, a client-side
Javascript application.

On the other side it seems like other extra functionality is limited and very
AWS-oriented. If you are looking for an open source gateway that can be
expanded with extra functionality, and potentially sit on top of the AWS->
Lambda integration, take a look at
[https://github.com/Mashape/kong](https://github.com/Mashape/kong) (I am a
core maintainer too, so feel free to ask me any question). Kong is accepting
plugins from the community
([http://getkong.org/plugins](http://getkong.org/plugins)), which can be used
to replace or extend functionality beyond any other gateway including AWS
Gateway.

~~~
jively
I think AWS is going after the Parse / Heroku market here, the combination of
Lambda and this gateway make it more suited for that kind of implementation,
they are missing out on the larger features that enterprise needs - the blog
post doesn't really go into detail on how SOAP conversion works, and I doubt
it's a cakewalk.

It's in legacy API services that places like Mashery and Apigee make all their
real money, and I can't see large enterprises shifting their legacy services
to EC2. It's quite forward looking. The satire on how EC2 may be deprecated is
really not far off from where things are heading.

I always find it quite funny when only single OSS projects are mentioned as
alternatives, there's so many more full-featured projects out there: Tyk
([https://tyk.io](https://tyk.io)) API Umbrella
([http://apiumbrella.io/](http://apiumbrella.io/)) and ApiAxle
([http://apiaxle.com/](http://apiaxle.com/)) to name some. For more fine
grained approaches there's also Vulcan
([http://vulcanproxy.com/](http://vulcanproxy.com/))

~~~
culo
apiaxle and apiumbrella have few features actually. vulcan is not for api
management and beside that quality > quantity.

~~~
ersoft

      vulcan is not for api management and beside that quality > quantity
    

What do you mean ? With vulcand you can implement your own middleware similar
to kong. Also, it is written in go and you can use all existing go libraries.

Also, how can you gracefully reload kong if you need to add/remove/change a
plugin ? With vulcand you just replace the binary, and send an USR2 signal to
the running process. It will fork, wait for all connections to drain, and
remove the old process

For deployment, again, you need to sync all lua files, with vulcand you just
ship a compiled binary.

Kong doesn't have a notion of servers for each API, you need to forward
requests to a haproxy or another load balancer for this. Also, I can see that
backends are added by their DNS hostname. In order to achieve HA (backend
redundancy) is there any way you can do it, assuming that nginx is caching the
upstream dns values ?

About performance, I can see you are advertising about 1000 r/s using kong,
and you need 3 machines for this (kong, cassandra, haproxy). I benchmarked
vulcand and obtained about 12000 r/s on a more modest hardware.

~~~
sciurus
"What do you mean? With vulcand you can implement your own middleware similar
to kong."

Nginx is not an API management layer, right? It doesn't have the necessary
features, but it's extensible so someone could build them. Mashape did, and
they released the result as Kong.

Vulcand is in the same position as nginx. It could be a good choice for
building an API management layer on, but it doesn't provide one out of the
box.

------
andybak
I've not tried very hard but I'm not sure I get it.

I've got an API already running. What does this buy me?

Caching? I can see some benefit there it's read heavy.

Auth and access control? Feels like that's part of my app code but maybe
there's a benefit I'm missing

A lot of the other benefits also feel like it would be hard to cleanly
separate them from my app code.

What's the elevator pitch and who's the target market?

~~~
jively
API Managmeent market is quite big, makes sense for Amazon to get on board.

Imagine this: You are BigCorp USA Inc. and have a bunch of internal SOAP-based
web services that are 10 years old and cost a fortune to maintain.

You hear someone will pay you to use them, but SOAP sucks. So you could either
go and change your APIs (and probably break a bunch of internal processes) OR
you could use a gateway to sit in front of them and translate in bound /
outbound requests. Now you can charge people for your APIs!

Scenario 2: If you're an indie dev/ startup but dont want to run EC2
infrastructure, Lambda + Gateway = Cloud service, without any heavy lifting,
servers and cost effective. It's development lego. Kind of like Parse.

Scenario 3: You have an API for your app, now you wnat third party devs to use
it.Your API is not set up for that kind of access (multi-user security,
throttling, quotas, analytics etc.) - solution: shove a gateway in front of
it.

~~~
WaxProlix
#1 is exactly what I'm working on right now; turns out there's a huge market
for this sort of thing. We're using an API gateway (Axway/Oracle) to build an
"API Mullet" (all SOAP in the back, all REST in the front), and while I have
some qualms with the tooling, the _idea_ of an API gateway is very sound.

~~~
oblio
Heh, I never thought I'd meet an Axway product user on HN. What are you using?
Gateway? Integrator?

~~~
WaxProlix
Gateway, under oracle branding.

~~~
oblio
May God have mercy on your soul :o)

~~~
WaxProlix
;_;

------
jamiesonbecker
AMAZON DEPRECATES EC2

November 3, 2017, SEATTLE

At the AWS Re:Invent in Las Vegas today, Amazon Web Services today announced
the deprecation of Elastic Compute Cloud as it shifts toward lighter-weight,
more horizontally scalable services. Amazon announced that it was giving
customers the opportunity to migrate toward what it claims are lower cost
"containers" and "Lambda processes".

"We believe that the cloud has shifted and customers are demanding more
flexibility," tweeted Jeff Barr, AWS Spokesperson. "Customers don't want to
deal with the complexities of security and scaling on-instance environments,
and are willing to sacrifice controls and cost management in order to take
advantage of the great scale we offer in the largest public cloud."

Barr went on to add that since their acqui-hire of Heroku last year, AWS has
decided that the future of the cloud was in Platform as a Service (PaaS) and
is now turning its focus to user-centric SSH key and user management services
like [https://Userify.com](https://Userify.com).

Amazon (AMZN) stock was up $0.02 on the latest announcements.

~~~
hitekker
A little anal: Heroku is already owned by Salesforce.

~~~
sneak
Skype used to be owned by eBay.

------
cdnsteve
There goes the rest of my workday :D

I was looking for something like this. Lambda functions are _amazing_ but
restricted because they weren't easily consumable externally. This is they
key.

~~~
cddotdotslash
This is definitely a game changer. Probably 80% of our apps can move to API
Gateway > Lambda and we can get rid of scores of EC2 servers.

~~~
Marazan
In onl fly in the ultra-low cost ointment is caching

To put the minimum cache in front of your API costs more than running an
EC2.micro

For my projected use where my volume are going to be so low that I will fall
under the Free lamda tier and the very first API tier I don't need to worry
about caching but for those that do the price will start to rack up.

~~~
tracker1
As an interim step, you could always put a small/micro ec2 using whatever you
like as a gateway to your lambda services.

I'm not sure about the costs involved with the caching options... just the
same, I think this option is pretty cool.

------
vlad
I'm working on ApiEditor.com, here's a screenshot:

[http://i.imgur.com/wSEKeVb.png](http://i.imgur.com/wSEKeVb.png)

I originally built it for the Swagger Spec 15 months ago, as the first visual
Swagger Editor. Let me know if you guys are interested in using something like
this.

Notice it has the code side-by-side. Also, it scrolls to and highlights the
section of the spec you're editing. Notice the dropdowns are aware of custom
models (e.g. "User", "Order") in the documents and suggest them to make it
easy to use.

~~~
ayushgta
Also see [http://editor.swagger.io](http://editor.swagger.io)

~~~
vlad
I'm not mentioned on that site or their launch blog post, but my code to
ApiEditor was shared privately with the Swagger Editor folks who went on to
create that editor, also in AngularJS.

~~~
mohsen1
I built the Swagger Editor from scratch. I didn't use your code at all.

We used SwaggerUI for rendering in the beginning but that was replaced with
it's own renderer. I blogged about it here:
[http://azimi.me/2015/04/23/swagger-editor-
talk.html](http://azimi.me/2015/04/23/swagger-editor-talk.html)

~~~
vlad
Hi Mohsen,

Interesting! Re: SwaggerUI, it already existed as CoffeeScript and
Backbone.js.

I built "Swagger Editor" for Tony, the creator of Swagger, as a paid OSS
project; the screenshot shows the Swagger Editor back in Apr 2014 before yours
existed.

I notice that a month later, you created "Swagger Editor" using the same
technologies I chose (Yeoman, AngularJS, Ace Editor, etc) and took over the
name.

I imagine the people who shared the private repository, including your
employer Apogee, saw how fast I made mine and wanted to do their own from
scratch, but I don't know.

I just took a look at your slides, looks like you've worked on yours for a
year since, and use AST to understand where errors are, nice.

------
ecopoesis
This looks incredibly slick. Speaking as someone who is implementing all the
ceremony (security, logging, etc) around a new API right now I would use this
in a heartbeat.

Of course, in a couple years, assuming success, the AWS lockin will suck. But
given the odds of success I think I'd take the chance.

~~~
jively
You could always use an open source gateway like Tyk
([https://tyk.io](https://tyk.io)) or API Umbrella (full disclosure: I run
Tyk.io, and this news is... disheartening).

~~~
alexbecker
The analytics on Tyk look amazing, definitely a step up from the internal
tools I've built.

Is Tyk HIPAA compliant? I'd definitely like to use something like Tyk, but I
manage an API that transmits health data, so lots of tools have turned out to
be off-limits because of HIPAA issues.

~~~
jively
I shouldn't see why not. Tyk has a pretty small footprint and supports SSL
end-to-end so transmission of data is safe. It obfuscates API keys so they
can't be pulled if you keystore is compromised and all analytics also use the
obfuscated keys so that security is ensured in log data.

However, we'd probably need to do an audit. Worth a check though.

~~~
harryh
HIPAA pretty much requires dedicated physical hardware. If my code is running
on the same machine as someone else's code then I'm breaking the rules.

~~~
IanCal
It appears to be open source and you can download and run it on your own
hardware: [https://tyk.io/v1.7/download/](https://tyk.io/v1.7/download/)

------
pea
This looks really interesting -- I think the abstraction of the server away
from a bunch of development cases is gonna happen pretty quickly.

We're hacking on something really similar to this at
[https://stackhut.com](https://stackhut.com), where we are building a platform
for Microservices which are powered by Docker, can be run wherever through
HTTP/JsonRPC, and are really simple to build/deploy. Think "Microservices as a
service"... ;)

To give you an example, here is a task which converts PDFs to images:
[http://stackhut.com/#/services/pdf-tools](http://stackhut.com/#/services/pdf-
tools), and here is the code powering it [https://github.com/StackHut/pdf-
tools](https://github.com/StackHut/pdf-tools) which we `stackhut deploy`d.

We're about to open up the platform and would love to hear what, if you had a
magic wand, you'd wish upon the product.

------
estefan
Please can people give examples of what they're using lambda for. Everything
I've seen has been really basic (like image scaling), but most things I think
of require a database.

~~~
trevordixon
Compiling LilyPond scores ([http://lilybin.com](http://lilybin.com)). Usually
we have at most 1 user at any time, but we can also handle bursts, like when a
classroom of 30 students all use it at the same time. Ends up even cheaper
than running one VM that can only handle 2–3 simultaneous users.

------
traek
Google has a similar offering for apps running on App Engine, called Cloud
Endpoints[1].

[1] [https://cloud.google.com/endpoints/](https://cloud.google.com/endpoints/)

~~~
culo
that's not similar. there is no API management in there.

~~~
TheIronYuppie
What are you looking for in API management? There's key management, DDos
protection, etc.

------
jstoiko
I am surprised that Amazon did not add support to more API description formats
like RAML or apiblueprint. It is such a key feature. If I wanted to use this
service in front of existing APIs, even only one API, I would not want to go
through the work of having to redefine all my endpoints through a web form!

Shameless plug: after working on several API projects, I have been researching
ways to not have to "code" over and over again what goes into creating
endpoints, it became so repetitive. Lately, I turned to RAML (Yaml for REST)
and, with 4 other developers, we created an opensource project called Ramses.
It creates a fully functional API from a RAML file. It is a bit opinionated
but having to "just" edit a Yaml file when building a new API simplified my
life. As a bonus, I also get a documentation and a javascript client generated
from the same file.

EDIT: forgot the url
[https://github.com/brandicted/ramses](https://github.com/brandicted/ramses)
and url of a quick start tutorial: [https://realpython.com/blog/python/create-
a-rest-api-in-minu...](https://realpython.com/blog/python/create-a-rest-api-
in-minutes-with-pyramid-and-ramses/)

~~~
vlad
Check out this screenshot, what I may release as ApiEditor.com

[http://i.imgur.com/wSEKeVb.png](http://i.imgur.com/wSEKeVb.png)

It would be nice to have one place to edit routes with a good UI, better than
what Amazon released today.

------
tootie
For heavy users of AWS services (not just EC2, but fancy SaaS/PaaS stuff) do
you ever regret being locked in to a hosting provider? Does it restrict your
ability to develop locally? Have you been bitten by problems that you can't
resolve because you don't own the product? Or do you pretty much just love it?

~~~
eric_h
We moved our whole stack from manually managed Linode instances to AWS
Opsworks, Elasticache, RDS, etc. We are currently somewhat tied now to the AWS
stack, though through a large collection of our own Chef scripts I imagine we
could move to a manually setup chef setup ourselves.

Largely we've been very pleased with AWS, but the black box nature of a number
of products (particularly Elasticache and RDS), has caused us some minor
grief. Also, the higher frequency of single instance failures (which our stack
can handle pretty gracefully) is somewhat annoying.

EDIT: We were also able to fairly significantly lower our bill with reserved
instances while also significantly increasing our ability to handle peak
capacity with AWS.

~~~
tootie
I would think Elasticache and RDS would be the least of your worries since
they're just fully managed versions of readily available software. You can
always host your own Redis and SQL database. Something like DynamoDB would be
way more complicated.

~~~
eric_h
Really the issue with Elasticache and RDS is that when they go down and fail
over to new hardware, we have no idea what happened to cause an (admittedly
brief) outage.

Basically, we just open a support ticket and say "what happened", and they
just say "oh, the machine failed and was rebooted"

------
mpdehaan2
I get the web UI for understanding it, but this is often not how people want
to work...

What tools are there to allow me to keep my code/API layouts in source control
when uploading to this?

I'm sure they exist somewhere, so mostly curious about pointers. (A sample
node project using this would probably go a long way)

~~~
athrun
The blog post mentions that you can describe your API using Swagger and then
import that. I suppose it means you can keep your Swagger definitions under
version control.

~~~
mpdehaan2
thanks!

------
joeyspn
Seems like a great product to quickly get started with a mBaaS in a powerful
cloud like AWS. The concept looks _really_ similar to StrongLoop's loopback
[0] with a big difference: vendor lock-in. I like the openness that StrongLoop
is bringing on this front... IMO the best solution is one that allows you to
move your containerised API from cloud to another cloud.

That being said, having this as an option in AWS is pretty cool and
potentially time-saving. I'll probably give it a shot soon.

[0] [https://strongloop.com/node-js/api-
platform/](https://strongloop.com/node-js/api-platform/)

~~~
culo
There is also api umbrella or KONG which is the most popular OSS API gateway:
[https://github.com/mashape/kong](https://github.com/mashape/kong)

------
brightball
One of the other benefits of using Cloudfront based endpoints is that your app
servers behind it can avoid the TCP handshakes that add some latency. Amazon
did an interesting presentation at re:Invent on the performance improvement
from using Cloudfront ahead of dynamic requests that was eye opening.

------
acyacy
I wish Lambda would allow listening to a socket [it helps binaries communicate
with node]. This would move our team to use this without any further doubt.

~~~
fooshint
For me, I need either socket support or go support.

~~~
IanCal
Go support? You can run binaries on lambda, as long as they're small enough.

[http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-
go/](http://blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/)

------
jonahx
Would someone knowledgeable mind answering a few questions:

1\. What are the differences between this + AWS lambda and parse? Is there
additional functionality or freedom with this route? Is it cheaper?

2\. What kind of savings could one expect hosting an API with this vs a heroku
standard dyno?

------
jakozaur
Isn't it yet another case of AWS doing a cheap replacement of existing
company: [https://apigee.com](https://apigee.com)

I doen't have experience with their product, but on surface they look similar.

~~~
daigoba66
They is also [http://www.mashery.com/](http://www.mashery.com/). I've run
across a lot of companies using Mashery to manage their API.

------
clay_to_n
For those interested, the creators of Sails.js (a node-encapsulating
framework) have created a sorta similar product called Treeline[1].

[1] [https://treeline.io/](https://treeline.io/)

------
zenlambda
I just tried this out with a Lambda function; I was wondering why you can't
serve HTML with this (Yes, I know this product is aimed at enterprise ReST API
stuff... one can try at least).

Well, it seems that authentication for the client is mandatory. This makes it
unsuitable for rendering markup and serving it directly to clients.

Can anyone confirm this can only serve JSON content? I suspect were anonymous
requests allowed, I'd see my markup rendered as a JSON string.

~~~
jwatte
If you absolutely must build a website on this, you can serve the bootstrap
HTML page out of S3 and use the JSON to populate it, single page app style.

------
serverholic
How do you develop for these kinds of services? It seems like you'd need to
setup a whole development cluster instead of developing locally.

~~~
jively
Therein lies the rub - if you are working with AWS' key-value store, and then
also their Lambda system, then you don't really develop server side - you
develop everything client side (mobile app) and just use the cloud as a dumb
logic store.

~~~
plicense
Well, you are still free to write resource consuming operations and deploy it
to an EC2 instance and call it from Amazon Gateway. Lambda is just an example.

Moreover I feel Lambda can do pretty good stuff. I am sure it will integrate
with other AWS services pretty soon and once there is connectivity to an RDS
instance, then it solves the use case for half the developer population out
there.

------
agentgt
I can't help but notice that this looks more like an enterprise integration
tool (think mulesoft) than API management (think apogee.. or I think that is
what they do).

Speaking somewhat from experience (webmethods, caml, spring-integration and
various other enterprise integration tools) they always want you to use
"their" DSL which is often not even stored on the developers filesystem (ie
webmethods... you submit the code to the "broker" or "rules engine" or
"router"... lots of words for thing that does the work). Which leads to very
awkward development.

Consequently I wonder if they will have git integration because writing code
even snippets in a web form no matter how nice gets old fast.

~~~
jively
Prediction: Amazon buys a cloud IDE platform.

------
dangrossman
API is an acronym, and the product is called "Amazon API Gateway". This
submission title is bugging me more than it should. Sorry for the meta-
comment.

Edit: The submission title has been changed since this comment was written.

~~~
dragonwriter
> API is an acronym

Actually, its an initialism (an abbreviation from first letters where each
letter is pronounced as a letter) rather than acronym (an abbreviation from
first letters pronounced as if it were a word.) Were it an acronym, many style
guides ( _particularly_ British ones, IIRC) would support presenting it as
"Api" rather than "API".

------
avilay
I had built a command line tool for a similar purpose to generate REST APIs
running on the MEAN stack. It creates "user" and "account" resources by
default with user and admin authn/authz built in. It then deploys to heroku -
creating a mongodb instance and a web dyno. Putting this out here in case
anybody finds it useful.

[https://bitbucket.org/avilay/api-labs/](https://bitbucket.org/avilay/api-
labs/)

------
ramon
[https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)
up and ok here :), great!

------
jwatte
Service as a Service - we've reached Serviceception!

------
intrasight
They say "If you already utilize OAuth tokens or any other authorization
mechanism, you can easily setup API Gateway not to require signed API calls
and simply forward the token headers to your backend for verification." It
would be nice if AWS would stand up an authentication service that could
handle oauth. Or do they already have such a thing?

~~~
fosk
Kong[1] is releasing OAuth 2.0 support in a week or so (when 0.4.0 will be
announced). You will see it appear in the plugin gallery[2]

[1] [https://github.com/mashape/kong](https://github.com/mashape/kong) [2]
[http://getkong.org/plugins/](http://getkong.org/plugins/)

------
vlad
I posted a 10 minute video overview for those who'd rather listen than read:

[http://ratemyapp.com/video/VIqZFaU1PhQ/Product-Preview-
Amazo...](http://ratemyapp.com/video/VIqZFaU1PhQ/Product-Preview-Amazons-
newest-Gateway-drug-API-Gateway)

------
adamkittelson
It'd be cool if they'd use this to wrap their own XML-only APIs to provide
JSON wrappers.

------
anoncoder
Do some math. It's expensive. 100 r/s for one month is about $900. Plus your
bandwidth and EC2 charges (unless your using Lambda). For simple Lambda
functions, you can get 100 r/s on a micro for $9.

------
dougcorrea
[https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway)
is down for me

~~~
iamflimflam1
Me too - 404 page

------
kordless
Given the current market direction with containerization and decentralization,
I think using something that is vendor specific is probably a bad idea.

------
machbio
I was trying this API gateway out, unfortunately there is no way to delete the
API created..

------
kpennell
For someone who doesn't understand this that well, is this similar to
firebase?

~~~
jively
Not really, firebase is a database that has a RESTful interface (and events
and all kinds of other cool stuff). with this you set up endpoints, point them
at cloud functions that may or may not interact with AWS' DynamoDB and your
own services to provide functionality but I think you need to worr it all up
yourself.

------
fiatjaf
How do you test these things?

------
culo
Smart move for AWS, but they are not innovating nothing here, just following.
Late.

Companies like Apigee/Mashape/3scale/Mulesoft have been doing cloud API
management in various forms since 2008. Even Microsoft Azure has an API
management offering since two years.

Nowadays all those API gateway features are commodities and doesn't make sense
to pay for it anymore. Indeed Open Source projects such as KONG [1] are
getting tremendous tractions. Same things happened in search with all cloud
solutions and then ElasticSearch came out and was game over.

[1] [https://github.com/mashape/kong](https://github.com/mashape/kong)

~~~
oblio
AWS has a lot of pull. And they iterate quickly. Plus AWS is probably still
the most complete cloud offerings, and integration is always great.

~~~
culo
the more complete is the integration, the more locked in you are.

~~~
oblio
That hasn't stopped people from getting locked into Windows, iOS, Internet
Explorer, Office, MacOS X, etc.

There's value in integration and a lot of people want that.

------
graycat
Okay, at Google I found that IAM abbreviates Amazon's _Identity and Access
Management_.

So, the OP has an undefined three letter acronym.

Suspicions confirmed: The OP is an example of poor technical writing.

Why do I care? I could be interested in Amazon Web Services (AWS) for my
startup. But so far by a very wide margin what has been the worst problem in
my startup? And the candidates are:

(1) Getting a clear statement of the business _idea_.

(2) Inventing the crucial, defensible, core technology.

(3) Learning the necessary programming languages.

(4) Installing software.

(5) System backup and restore.

(6) Making sense out of documentation about computer software.

May I have the envelope please (drum roll)? And the winner is,

(6) Making sense out of documentation about computer software.

And the judges have decided that uniquely in the history of this competition,
this selection deserves the Grand Prize, never before given and to be retired
on this first award, for the widest margin of victory ever.

No joke, guys: The poorly written documentation, stupid words for really
simple ideas, has cost me literally years of my effort. No joke. Years. No
exaggeration. Did I mention years?

At this point, "I'm reticent. Yes, I'm reticent." Maybe Amazon has the
greatest stuff since the discovery and explanation of the 3 degree K
background radiation, supersonic flight, atomic power, the microbe theory of
disease, electric power, mechanized agriculture, and sex, but if Amazon can't
do a good job, and now I insist on a very good job, documenting their work,
which is to be yet another layer of documentation between me and some
microprocessors, then, no, no thanks, no way, not a chance, not even zip,
zilch, zero.

What might it take me to cut through bad Amazon documentation of AWS, hours,
days, weeks, months, years, then from time to time, more hours, days, or
weeks, and then as AWS evolves, more such time? What would I need to keep my
startup progress on track, 500 hours a day? More? All just to cut through
badly written documentation for simple ideas, and worse documentation for
complicated ideas?

First test: Any cases of undefined terms or acronyms?

Result: About three such cases, and out'a here. Gone. Done. Kaput. I don't
know what AWS has, but I don't need it.

Sorry, AWS, to get me and my startup as a user/customer, you have to up your
game by several notches. The first thing I will look at is the quality of the
technical writing in your documentation. And, I have some benchmarks for
comparison from J. von Neumann, P. Halmos, I. Herstein, W. Rudin, L. Breiman,
J. Neveu, D. Knuth.

Amazon, for now, with me, from your example of writing here, you lose. Don't
want it. Can't use it. Not even for free. I'm not going to invest my time and
effort trying to cut through your poor technical writing. And, the next time I
look at anything from AWS, the first undefined term and I'm out'a here again.

Yes, I'm hyper sensitive about bad technical writing -- couldn't be more
sensitive if my fingers and arms were burned off. Whenever possible, I will be
avoiding any chance of encountering bad technical writing, ever again. Period.
Clear enough?

More generally, my view is that bad technical writing is the worst bottleneck
for progress in computing. Come on, AWS, up your game.

I don't want to run a server farm and would like you to do that for me, but
neither do I want to cut through more bad technical writing -- for that work,
my project is already years over budget.

~~~
NathanKP
When you were a child you started out learning simple one syllable words, and
speaking one word sentences.

When you were toddler you started stringing those words together, and learning
how to form extremely basic sentences.

And eventually you learned to form complex sentences with complex ideas.

The same thing applies to learning computing terms. AWS is now 9 years old,
and has 9 years of development and features to catch up on if you are just
starting. Yes, it will take some effort to learn everything, and if you don't
see the benefit in doing so then you don't have to.

But if you want to be an "adult" engineer rather than a "toddler" engineer it
is necessary to be willing to learn some things, even if it isn't easy.

~~~
graycat
I strongly disagree: I'm under no obligation to have _followed_ AWS for the
past nine years. Instead, in each field, we should write in ways as self
contained, and make the minimum assumptions, possible. In particular, in
technical writing, we should not have undefined terms.

The research libraries are awash with single texts that start with meager
prerequisites and get to some quite advanced and challenging material. AWS can
do so, also.

I've been in computing for a long time, but there's no hope for me to know all
the jargon of all parts of computing. Mostly jargon is not conceptually
difficult, and the solution to the challenge of jargon is simple -- just
define it.

Parts of computing have long enjoyed having a closed _priesthood_ that spoke
in three letter acronym gibberish. IBM used to do this with PCP, MFT, MVT,
MVS, JCL, DCB, IMS, DB2, CMS, SQL, and many more. And there were some four
letter acronyms -- CICS, DASD, REXX.

The concepts were mostly simple; the gibberish was a secret language. Once I
gave a grad seminar on computing and had a lot of guests from industry. IBM
talked in their gibberish, but none of the other vendors did. The students
caught on: IBM wanted to intimidate people and otherwise invite people into
their priesthood where they, too, would understand the gibberish. IBM was the
least popular of the vendors.

~~~
NathanKP
AWS has documentation at varying levels. If you are looking for documentation
that starts at the absolute basics, without acronyms then you are probably
wanting the "Getting Started" section of their documentation site:
[http://aws.amazon.com/documentation/](http://aws.amazon.com/documentation/)

The linked article is basically a changelog for devs who have already been
using the ecosystem for years, so no its not newbie friendly.

~~~
graycat
Thanks.

They would have been doing better for their business if they had made that
point clear.

Again, my gripe is, better writing is needed. Why? The writing now too often
results in absurdly high costs for absurdly poor reasons. The costs to me have
me torqued.

We're just talking about bad writing.

