The 2018 AWS re:Invent conference has just finished. If, like me, you were unfortunate enough not to get to Vegas, you may having been following it closely on Twitter with an acute case of FOMO.

There were many exciting announcements (comprehensive list here), so many in fact that I felt slightly overwhelmed trying to figure out what it all means for the future cloud development landscape.

So I took a few hours today to go through the multitude of conference blog posts with a view to answering the following questions:

What type of apps/workloads would this new thing work well with?
Should (and how would) I migrate my (or my clients') existing apps to use this new thing?
Does this new thing enable developers or organisations who previously didn't feel ready to use serverless to reconsider?

Let's dive in to the main announcements...

Lambda now supports any programming language and reusable libraries via "Layers"

This is a huge boon for large web dev communities such as Ruby and PHP who will now be treated as first-class citizens when running their functions in the cloud.
While I don't expect an immediate mass influx (frameworks such as Rails and Laravel aren't a good fit for Lambda), I do expect to see many developers trying out small use cases (e.g. building a Lambda website contact form) and new workflows and libraries/frameworks growing from there.

The multi-language support works via a new feature called Lambda Layers. Layers will also deliver benefits to those of using an already supported language. While previously a function was the sole unit of deployment, layers now provide dependent artifacts, in a similar way that AMIs do for EC2 instances. The official blog post states that you can now:

Enforce separation of concerns, between dependencies and your custom business logic.

Make your function code smaller and more focused on what you want to build.

Speed up deployments, because less code must be packaged and uploaded, and dependencies can be reused.

This looks good-to-go as the Serverless Framework already supports using Lambda Layers 💪, so I expect to be trying it out very soon for things such as making FFmpeg commands from inside a function.

I can see potential for misuse of Lambda Layers and expect that best practices will emerge on their use. I'm not the only one:

Easier migration to Lambda architecture from EC2/containers via Application Load Balancer

Application Load Balancers now support Lambda functions as their targets.
On the face of it this may seem a strange pairing as Lambda functions are usually invoked from API Gateway in web API-based use cases. In a greenfield serverless project, you probably wouldn't go near ALBs. However, if you have an existing EC2-based web app which runs behind an application load balancer, then migrating to Lambda can be a huge task.

This new capability allows you to migrate away from your existing app architecture in tiny chunks. Such a chunk could be as small as a single verb on a single route on a single endpoint. For example, you would just write and deploy a new Lambda function which implements the GET /api/accounts/:account_id/products route, and then configure it to be triggered from your existing load balancer. You wouldn't touch your existing production app code at all. Rinse and repeat for your remaining API routes until your server goes away!

This is available immediately with no pricing impact on top of the usual ALB and Lambda charges.
My own SaaS product still uses a container-hosted Express.js API behind an ALB for its back-office portal which I've been meaning to move to Lambda for ages. With this announcement, I now have a low-risk way of beginning a staged migration process 👍.

Lambda VPC cold starts should be improving

I was sort of hoping for more than this, but it seems that AWS will be releasing something in 2019 to help address a deal-breaker for many — the sloooow cold start time of VPC-enabled functions:

📖 Related: Scaling Lambdas inside a VPC

Aurora Serverless Data API

A particular use case which is affected by VPC cold starts is connecting to a relational database inside RDS. However, with the announcement of the Aurora Serverless Data API, you can now make calls to your database over HTTP rather than over the native SQL protocols. This will have 2 key benefits:

You don't need to connect your Lambda to a VPC, so won't experience slow cold starts
Since it's just a HTTP API, you no longer need to worry about dealing with SQL connection issues that Lambda functions (being effectively stateless) suffer from

This is still in beta and only supports MySQL right now so you won't want to use it in production just yet.
Jeremy Daly posted a great in-depth first look article if you'd like to explore further. He found that the performance is pretty poor right now (it is a beta after all), but is hopeful this will improve as the service matures.

DynamoDB On-Demand

DynamoDB has always been touted as the go-to database for serverless applications in the AWS ecosystem. However, I've always felt it fell slightly short of many people's definition of serverless, in that you still have to do some capacity planning and setup auto-scaling rules. I've been stung in the past by throttling of under-provisioned tables.

However, with the announcement of per-request billing, DynamoDB's scaling is much more on auto-pilot again. It will probably require some calculations on your part to plan your future costs before switching over, but this is much more inline with the Lambda pay-for-what-you-use billing model and reduces the need to over-provision read and write capacity to handle busy periods.

There's already an article showing you how to turn this on using the Serverless Framework.

A Netlify alternative

The new AWS Amplify Console was released and it seems to be in the same space as Netlify:

"The AWS Amplify Console is a continuous deployment and hosting service for modern web applications with serverless backends. Modern web applications include single page app frameworks like React, Angular, and Vue, and static-site generators like Jekyll, Hugo, and Gatsby."

I use 5 of the above 6 mentioned technologies and love a simple, automated dev workflow. I'll definitely be checking this out.

Other items to keep an eye on

I've covered what I believe to be the major serverless news items, but there were a few other announcements worth mentioning:

You can now use transactions to update your DynamoDB tables
A new fully managed time series database called AWS Timestream was released. Could see this being useful for click-stream analytics.
API Gateway now supports web sockets:

AWS Outposts ~~empowers fools to run their own hardware~~ "bring native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility." 🤨

AWS Firecracker was announced as a "Lightweight Virtualization for Serverless Computing". There was quite a lot of excitement about this on Twitter, but I was bit "meh" as it's too low in the stack for me to consider using it. However, if having the fallback option of being able to run your own FaaS execution environment helps to lower the perceived lock-in of using Lambda in conservative-minded organisations, then this could be a good thing.

Wrapping up

There are many other new products and features I haven't mentioned if you want to take a look for yourself through the full list.

To round things up, these announcements have solidified my belief that serverless is the future for building apps and is the path I would recommend any greenfield project start out on. And the migration path for existing apps is making switching to serverless a realistic option.
Dealbreakers are being solved and barriers to entry are being lowered.

This tweet from Simon Wardley sums it up nicely:

💌 If you enjoyed this article, you can sign up to my weekly newsletter on building serverless web apps in AWS.
You also might enjoy:

Originally published at winterwindsoftware.com.

What new use cases do the re:Invent 2018 serverless announcements open up?