Unveiling Amazon’s hidden plans for AWS Lambda

Adriano Raiano
codeburst
Published in
2 min readJul 21, 2017

--

Disclaimer:
All claims and ideas described in this post are pure personal opinions.
Similarities with Amazon AWS’s official or strategic plans would be accidental and unintentional.

Lambda and serverless architecture in general is so hot right now

Today most of the people who are getting in touch with serverless technologies are immediately catched and impressed how easy and fast it is to build something new.
You can do really A LOT with Lambda and the surrounding serverless ecosystem of AWS.
Personally the fact that you don’t need to spin up a VM (or a Docker container) on your own is my favorite advantage.

But all this hype is just the beginning…

Lambda functions everywhere

  • AWS S3
  • AWS DynamoDB
  • AWS Kinesis Streams
  • AWS Simple Notification Service
  • AWS Simple Email Service
  • AWS Cognito
  • AWS CloudFormation
  • AWS CloudWatch Logs
  • AWS CloudWatch Events
  • AWS CodeCommit
  • Scheduled Events (powered by AWS CloudWatch Events)
  • AWS Config
  • AWS Alexa
  • AWS Lex
  • AWS API Gateway
  • Other Event Sources: Invoking a Lambda Function On Demand
  • Sample Events Published by Event Sources
  • AWS Step Functions
  • AWS IoT
  • AWS GreenGrass
  • AWS CloudFront (Lamda@Edge)
  • etc…

Seems like Lambda functions are expanding rapidly in the AWS ecosystem.

The next step

I think the next step for Lambda will be something called ”AWS Lambda unleashed” or ”AWS Lambda everywhere” or ”AWS dynamic Lambda”.
What do I mean with that? — Imagine writing a couple of Lambda functions and AWS automatically figures out which function type it is (catch the intension) and where to be best executed (i.e. in the evening more in the centralized cloud and during the day more at the edge locations or directly on IoT devices).
Or something like “follow the sun execution”. The functions are not bound to an AWS region anymore but are defined globally and AWS figures out in which region the function should be executed at which time, etc…

The whole orchestration will be a new value proposition and a new USP, which will attract many customers.

Centralization -> Decentralization

I don’t think there will be a total decentralization, but there will be at least more decentralization strategies and services as today.
So having distributed functions around the world and the layers, Amazon can start building or adapting services for it.
With that much edge computing… what about an own blockchain? Imagine AWS Cognito and other services making use of this blockchain… The next disruption?

Ubiquitous language

To best realize the upper described scenarios Amazon will need to have at least one programming language that can cope with these challenges.
And in my opinion this is JavaScript (node.js).
An other way to look at the job description “Full Stack JavaScript Developer”. ;-)

What do you think?

--

--

Founder, CTO, Software Architect, Bachelor in Computer Science #serverless #nodejs #javascript Always in search for #innovative and #disruptive stuff