Serverless at re:Invent 2020 — hot takes #1
By: Yan Cui
Tags: Cloud, AWS, Serverless, Cloud Computing, AWS Lambda

During this re:Invent, I’m sharing with you the biggest serverless-related announcements and what they mean for you in a series of hot-takes.

Starting with, the biggest announcements from today’s keynote, plus a bunch of other important announcements just before r:Invent.

1. Lambda changes billing to per ms

Lambda now bills you by the ms as opposed to 100 ms. So if your function runs for 42ms you will be billed for 42ms, not 100ms.

This instantly makes everyone’s lambda bills cheaper without anyone having to lift a finger. It’s the best kind of optimization!

However, this might not mean much in practice for a lot of you because your Lambda bill is $5/month, so saving even 50% only buys you a cup of Starbucks coffee a month.

Still, that’s a FREE cup of coffee!

Before, because Lambda bills in 100ms blocks, there’s no point in optimizing if your avg duration is sub 100ms.

NOW, you can micro-optimize and every ms saved is another $0.00000…X saved.

The question is, should you do it?

In 97% of cases, it’d be premature optimization.

As I discussed in this thread, don’t do it until you know your return-on-investment (ROI).

Ask yourself these questions:

how many times is this function invoked a month?

how much time (in ms) can you save per invocation?

how much memory does this function need?

From there, you can work out a ballpark figure for how much you stand to save.

Then estimate how many hours is it gonna take you to optimize the code.

Times that by 2 ;-)

Then look at your wage, how much you’re paid per hour?

Times that by 2, because once bonuses, pensions and everything is factored in, usually an employer ends up paying 2x your salary.

Now, you have both sides of the equation and can work out the ROI for doing this optimization work.

Let me invoke my inner Knuth and to make sure you see the 2nd half of his quote.

If you can identify that critical 3% of use cases (based on ROI, not by how excited you feel about optimizing that bit of code), then you should absolutely do it, especially now you have 10GB functions!

2. Lambda supports 10GB memory and 6 vCPU

Lambda now supports up to 10GB of memory and 6 vCPU cores.

This is another big one for those of you doing HPC or otherwise compute or memory-intensive applications such as training ML models.

Between this, and the AVX2 instruction set (see below), the Lambda team is really starting to look after the Lambda as a supercomputer crowd.

Would love to see more use cases around this, and if anyone fancy talking about what you’re doing then join me on the Real-World Serverless podcast.

3. Aurora Serverless v2

Aurora Serverless v2 was arguably the biggest announcement from today’s opening keynote.

Honestly, it sounds great!

But then again, so did Aurora serverless v1… the devil was in the details. So I’ll reserve my enthusiasm until I see it in action.

And I’m just as curious about what hasn’t been said as what has — there was no mention about cold starts, which was the thing that made everyone go “yuck, we can’t have that in production!”.

And what about data API? I imagine (and hope) that is still available on v2.

4. Lambda supports container images

Lambda also added support for container images as a packaging format.

This is another big announcement and I expect to see lots of excitement and confusion around this.

I’ve shared some details on how it works in this post, which also mentions some use cases and my thoughts on it, please go and check it out.

For better or worse, it’s what people have been asking for.

And for organizations with strict compliance and audit requirements, being able to use the same tooling as their container workload is a must. This is designed for them.

But what’s in it for the rest of us?

Well, it lets you ship a container image up to 10GB, so you can pack a lot of read-only data with your image. Like a giant Machine Learning model, which would have been slow and painful to read from EFS.

BUT, for functions that are shipped as zip files, the deployment package size limit is still 250MB unzipped.

When you use container images, you’re responsible for securing and patching the base image. Even if you use an AWS-provided base image, you still have to deploy their updates to your functions regularly. This is a big set of responsibilities to take on but Ben Kehoe has a great idea on how it can be fixed. It would address my biggest concern with using container images for sure.

However, you’re still much better off by keeping things simple as much as you can and stick to basics.

Using zip files = no building docker images = simpler pipeline (no need to publish to ECR) = no need to worry about function needing optimization again after 14 days of idle (see my post above for more details of the function lifecycle).

I keep saying it, keep it simple for as long as you can, and only reach out for more complex solution when you must.

5. AWS Proton

AWS launched the Proton service for deploying container and serverless applications.

Honestly, I’m not sure about this one… there are already lots of ways to deploy serverless and container applications on AWS with both official and 3rd tools.

And looking at the example in this thread, it’s doing deployment by clicking in the AWS console.

Didn’t we learn that was a bad idea 10 years ago?

Maybe I’ve misunderstood the intended target user for this service?

I mean, you have Amplify for frontend developers who don’t wanna know what AWS resources are provisioned.

You have the Serverless framework, AWS SAM, Terraform, AWS CDK and too many others to list here that caters for backend developers who want more say on what’s deployed in your AWS account.

But it’s not clear to me who is Proton designed for.

Surely not your DevOps team or sysadmins, they’re gonna want IaC for sure.

And according to this thread, the UX is not quite ready either (at least not compared to other solutions on the market).

6. AWS Glue Elastic Views

AWS also announced the preview for AWS Glue Elastic Views.

“Combine and replicate data across multiple data stores using SQL”

This sounds like it has some interesting possibilities! I mean, “materialized views” comes right out of the CQRS book, doesn’t it?

I have built this type of materialized views by hand so many times before. Either in real-time with Kinesis Analytics, or with some sort of batch-job against Athena (where all the raw events are dumped into). This could make all those home-grown solutions redundant.

The fact that it supports S3, ES, RDS, DynamoDB, Aurora and Redshift is pretty insane. I guess one challenge with mashing together all these data sources is that it’s impossible to guarantee ordering of data updates in those systems is respected during replication.

I think the devil is gonna be in the details for this one. But I’m excited about what it could do in any case.

7. S3 replication supports multiple destinations

You can now replicate S3 objects from one source bucket to multiple destination buckets.

This solves a pretty clear (and specific) problem here, that if you need to fan-out the S3 object from one bucket to multiple buckets.

It hasn’t come up a lot in my work, but it’s a blocker when you need that. The way I’ve solved it until now is to use Lambda to do the fan-out, which is a bit wasteful.

8. S3 adds read-after-write consistency for overwrites

S3 now supports read-after-write consistency for operations that overwrites an object.

This is BIG.

Before, read-after-write consistency was only guaranteed for new objects, not for updates. This causes SOOO MANY eventual consistency problems that you end up solving at the app level.

I think Gojko is really gonna appreciate this update. We were talking a while back on my podcast and this was one of the biggest problems he had with S3

9. Amplify launched admin UI

The Amplify team has launched admin UI, a way for you to manage your full-stack application in Amplify with an… well, admin UI.

I had a preview of this last week, and although I don’t use the Amplify CLI, I gotta say this looked pretty slick.

If you use Amplify, you should check it out.

10. S3 supports two-way replication for object metadata changes

S3 now supports bi-directional replication for object metadata changes such as tags or ACL list.

Notice that this is only for replicating object metadata changes (tags, ACL, etc.) and not the actual data objects themselves.

I’m honestly not sure about the specific use case here…

I get why there isn’t bi-directional data replication, but in what use cases would you be updating metadata in the replicated bucket (the backup/passive bucket, or whatever you’d like to call it)?