AWS Lambda made a mistake

This is a Post Scriptum to the blog The Miracle of Apcera and AWS Lambda

Chad Lung AWS Lambda tutorial

Chad Lung is one of the gurus from EMC Cloud Services Group.  On January 12, 2016, he published a Lambda Tutorial Build a Python Microservice with Amazon Web Services Lambda & API Gateway

He wanted to show how simple is to build a microservice. Normally he uses Python 3.x, but AWS does not support it. So he used Python 2.7x.

My guess about 20% of the readers were coders. They probably said: "Wow" and and felt the urge to try themselves later duplicating the demo.

80% were people like me: no coders. We said; wow! this is from Amazon, then it must work, with so meany big names using already AWS . (Some people say the same about Google or Facebook or any other sacrosanct name)

The review ends

That’s it! Once you’ve worked through this a bit and play around its actually very easy to work with. 

 3 Reasons AWS Lambda Is Not Ready for Prime Time

This is the title of a blog from DataWire by @_flynn published less than a month later on February 9, 2016.

When we at Datawire tried to actually use Lambda for a real-world HTTP-based microservice shortly before Lung’s tutorial came out, though, we found some uncool things that make Lambda not yet ready for the world we live in:

• Lambda is a building block, not a tool
• Lambda is not well documented
• Lambda is terrible at error handling

Lung skips these uncool things, which makes sense because they’d make the tutorial collapse under its own weight, but you can’t skip them if you want to work in the real world. 

You better to read the article. Yet see the amount of manual work you do with Lambda today

It’s not just Lambda, even: AWS’ model is that they provide building blocks, and they expect others to wrap real tools around them. If you try to interact directly with AWS, it’s absurdly manual.

To wit, Lung’s tutorial shows us that manually setting up a Python Lambda is a twenty step process – and that’s a service with exactly one endpoint that uses GET and takes just one argument on the query string. Mind you, about half those steps (8-10, depending) are things you’ll have to repeat for every endpoint you create. If you have even five services, you’re looking not at 20 steps, but 50-60. Imagine 100 services. Imagine how often you’ll have to do this if you’re using versioned endpoints. Does 8-10 manual configuration per endpoint, every time you roll out a new version, sound like fun?

The root of the problem here is that we want a tool (our microservice) but AWS gives us building blocks, and leaves connecting them up to us. 

Nice to know Amazon Web Services makes a boo-boo sometimes. AWS appears more human. The only problem is that their boo-boos are huge boo-boos, proportional to their reputation and size

The ATM machine in St. Petersburg, Russia 

In 1996, I was working for small banking software  company in Toronto, Canada. I went to Russia, St. Petersburg, to sell software for  ATM to a local bank 

At that time the only ATM was at  the central Post Office and they had no financial switching software or a network

Central Post Office San Petersburg< today

The ATM was operated by a bank employee sitting behind the wall, delivering the cash to the machine, who, in turn, delivered it to the customer through a slot.

Generating 100 microservices using 5,000 manual steps is somewhat similar to this ATM story. This is a boo-boo and AWS will fix it. Just don't take their words for granted.