Amazon introduced AWS Lambda last year at ReInvent. I believe Lambda is a game-changer, but it doesn’t go far enough. Let’s begin by reviewing what AWS Lambda is …
With Lambda you start by writing a microservice. You then specify the conditions under which you want your microservice to run. Examples of events that could “trigger” your microservice include such things as something changing on Amazon S3, a specific condition in an Amazon DynamoDB or a specific condition in an Amazon CloudTrail audit log.
AWS then watches for the event and executes the trigger, at which point it spins up and runs your microservice.
It might be easier to understand with a real-world use case. Netflix uses Lambda to process new media uploaded by studios. The studio uploads content to S3 (for example, the latest episode of Sons of Anarchy). AWS Lambda fires up Netflix’s encoder to encode the media into the required format.
This means that Netflix no longer cares how or when studios upload media files. Studios can upload from any platform entirely independent of Netflix’s systems. This vastly simplifies the process for Netflix.
Why Lambda Matters
There are a slew of advantages to Amazon’s new Lambda approach, but before I describe those, let me describe why this matters right now. When systems are simple, it is easiest to place all logic in a single, monolithic programming stream. A lot of existing corporate apps running in your data center use this model.
However, as systems become increasingly complex one eventually reaches a tipping point where your monolithic code becomes overwhelmingly complex as it tries to account for every situation it may encounter.
Let’s go back to our Netflix example. Without Lambda, Netflix would have had to deploy infrastructure with services that would watch for uploads from various studios. On seeing a new upload they would fire up the appropriate encoder to work on that content. Since there would be a lot of uploads, Netflix will need a scalable server architecture for this layer.
With AWS Lambda, Netflix was able to eliminate an entire layer of infrastructure. The studios upload their media files however they want, and a simple microservice does the encoding once it appears in S3.
That’s the essence of Lambda: It removes complexity. First, there is much less coding (you only code the essence of what you need). Second, you have no infrastructure to buy and manage. Plus, you end-up with zero-touch administration. Amazon takes care of security, availability and issues of scale. All you do is write the microservice and set-it up within Lambda.
One additional benefit is you can tie your microservice to events generated by devices that don’t allow running of programs (for example, a motion detector connected to an ip-addressable thermostat in your warehouse).
The bottom line is that Lambda is brilliant. Much of the industry is justifiably excited about Lambda. But as I said at the top, I don’t think Lambda goes far enough. Just as with AWS Lambda, there are hundreds of use cases that make sense for an on-premises event-based microservice architecture. All that is missing is the platform. More on that in future posts, but what’s your view? Are you using (or planning to use) AWS Lambda? Do you have similar use cases for on-premise apps? Let me know.