There have been some really interesting posts in the last week after re:invent around Serverless. I’ve already talked a bit about some of this, so won’t go over it, but the thing that has definitely come to the fore in discussions is Events.
I’ve talked a little bit about Events before as well, but the thing that surprises me is how this part of the development is missed by many people.
The focus is on Lambda or FaaS instead of events and the message bus.
And I think that’s a mistake.
Because the FaaS part of the solution is the relatively simple part of the whole.
The hardest part is understanding and connecting up the events.
Events and Message Buses
In the world of distributed systems, these words are relatively well known.
Outside of the world of distributed systems, these words often seem alien and especially alien to web developers (which is odd given how much of a distributed system the web is).
It seems that all the talk around frameworks and servers and having cloud providers do “autoscaling” has meant that people have stopped trying to understand the underlying technologies.
To keep it simple, an event is emitted (produced) as a message on the message bus to event consumers. See Event Driven Architecture for a bit more info (other and better links will be available — was the first one I found that vaguely explains it)
Event producers and consumers.
Which is where FaaS comes in.
These are the primarily event consumers (and sometimes producers too).
And the events come via both external and internal producers (e.g. an API call)
And they are asynchronous.
Because the event emitters should not even know if there is a consumer at the other end.
And the Message Bus? It is usually other services provided within the system. We’ve used a number of them internally — SNS, SQS, S3, DynamoDB + triggers to Lambda — and you also within AWS have AWS IoT which has some value too.
And the Message Bus has a purpose to decouple the messages consumers and emitters.
Event based != node.js
I’ve seen a few people get very confused because they think that just using node.js means they are event based which just isn’t true unless you run your own server (which means you’re not Serverless).
The thing is that to build something with FaaS and utilising an event based architecture needs a change of approach to your code and infrastructure, so just switching out a rails app on heroku for an express app on Lambda doesn’t really make it serverless. It’s still PaaS at that point.
The value of FaaS is in the scalability of tiny portions at a time without scaling the rest of your application.
So even the examples that AWS provide of a switch/case statement, in my view, are not really serverless, and neither are solutions based upon graphql. They may be an improvement on your current setup (that’s not in dispute) but any time you have conditional processing like that at the top level of a Lambda function means you can almost certainly break it down further.
And when you break it down, you can provide even greater maintainability, solidity and scalability to your app.
Which in my book is a good thing.
Get your head around events to get the most out of Lambda
Understand events, and start to process them and work with a Message Bus.
It’s a big leap if you’ve only ever done web programming, but it’s a worthwhile one.
We still haven’t established coding patterns within a Serverless philosophy to really make this easy, but we’re beginning to see some best practices emerge (slowly) which will make this space ever more interesting.
And I predict we’ll also have both AWS competitors and more AWS tools to make use of these elements.
The next few years, we will be seeing some very large companies evolving from tiny tiny codebases and heavily reliant on these architectures.
And they could well be the ones that win.