Rant: can we please stop pretending that serverless in 2022 is the same thing as serverless in 2016?

Avatar

Share

 • 

3 months ago

 • 

View on Twitter

Rant: can we please stop pretending that serverless in 2022 is the same thing as serverless in 2016? We're intellectually masturbating about what "serverless" means and we're confusing people, all while we're like on serverless v3! Of course v3 products don't fit in v1 boxes!

TL;DR: Serverless v1 came in with a bang but failed to capture most of the market. Serverless v2 is an effort to apply serverless practices to things most people already know and do, but "it's nOt TruE sERvErLeSs". At the same time, Serverless v3 is exploring what's next.

Pretending that everything has to be pure Serverless v1 is bullshit. It's false, it's confusing people, it's pushing broken practices to people that don't know better, and it hurts the developer community. Please stop it! Thank you!

Before we get into it: serverless is a spectrum, not a binary thing. Say you want a database. The most serverful option is running your own DB on EC2s. The most serverless option is say DynamoDB. In between there's a whole spectrum of options, all of them more or less serverless

Serverless v1 is what we all tried to do with AWS' Lambda: the Function-as-a-Service-focused architectures. This was a thing from 2016-ish to 2018-ish. After multiple failed experiments and projects, we all agreed it does not work for most teams and most companies.

Serverless v1 failed. Ahem. No. That's unfair. It whimpered out. Serverless v1 only captured a small share of the market — it did not create a serverless revolution. It a valid approach and it is wildly successful, but only when it's applied to a (debatably) small area.

Serverless v1 works long-term in exactly 2 tiny scenarios: - you have a team full of AWS experts (or you're trying to get there) OR - you are only doing one or two tiny specific tasks There are of course exceptions, but they're exceedingly rare. That's it! Two scenarios!

The problem of how complex Serverless v1 is and how adopting it is hard was discussed by the fabulous @iamstan and @QuinnyPig on the LastWeekInAWS podcast. They covered this way better than I can. Go listen or read the transcript! https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/severless-hero-got-severs-in-his-eyes-with-ant-stanley/

It would be really cathartic for me to get on a rant-y aside here about how there are several "dead cat bounce" efforts to convince people that don't know better (why Serverless v1 failed) that Serverless v1 works and is amazing, but I won't go into that here. Maybe another time

Let's jump from Serverless v1 directly to the end: Serverless v3. Serverless v3 is experimental. It's a bunch of stealth startups and stealth initiatives in large companies, @VendiaHQ, and maybe Cloudflare. It's interesting, but not widespread or mature, but it is here!

Serverless v3 is a fascinating area to research and explore. We live in a different world (hint: undersea cables and economics) and we should build different apps, but that a whole 'nother topic. For most, it's not something to build on yet, so we can ignore it for now.

Between Serverless v1 and v3, in the middle we have what I decided to call Serverless v2: the widely useful Serverless! Serverless v2 is realizing that Serverless v1 had some awesome ideas but also limitations, and compromising for the reality we live in. THAT'S A GOOD THING!

<rant> Oh wow, not everybody wants to re-write their apps in Typescript? Oh wow, not everybody wants to move from fully-featured and battle-tested frameworks to a new 1-year old thing? Oh wow, not everybody wants to spend 3+ years learning AWS and AWS' quirks? </rant>

Serverless v2 is (debatably) serverless for the real world. We saw v1 failed, so we're applying the good things from v1 to the whole spectrum. Most people do relational DBs? Sparkle some serverless on it. Most people barely do VMs? Sparkle some serverless on it. And it works!

Serverless v2 is compromising, but it's getting adopted and revolutionizing workloads! But nooo, instead of celebrating how we're empowering developers and offloading boring stuff, we're yelling that "It iS nOT 100% sERverLESs so IT DOEs NoT Count" and telling people not use it.

Serverless v2 has many examples, but let's look at two 🌶️ ones: Fargate and Aurora Serverless v2. "It iS nOT sERverLESs", they don't scale to zero, they're slow and have weird limitations, and so on. They're full of compromises and yet everybody is on the way to use them!

First example of widely-useful Serverless v2: ECS on Fargate Windows. It was a world-changing event for everybody doing Windows .NET! In an instant folks went from errors and 45-minute feedback cycles to serverless containers and 10-minute error-free feedback cycles! AMAZING!

ECS on Fargate is full of compromises: slow, no GPUs, no high-bandwith option, small container sizes, and so on and so forth. Still, it is a massive improvement over the alternatives! Yes, we want it to be better, but damn, it's miles ahead of where we were previously 🚀

The second example of widely-useful Serverless v2 (and why the internet is cranky right now): Aurora Serverless v2. It is terrible, full of compromises and everybody's up in flames about it. Nonetheless, it's a widely useful option that is solving real problems!

Compromise #1 that Aurora Serverless v2 did to be widely useful but "nOT sERverLESs": no scale to zero. Yeah, no shit. It was a thing in Aurora Serverless v1 and it was horrible. I could not find anybody that really used that — and I asked around a lot!

Turns out that relational databases cache things in memory A LOT and scaling to zero destroys that cache. Sure, it takes 1 minute to come up, but then you get 15 minutes of shit performance due to caches being re-filled and stuff. Everybody I talked to disabled scale to zero!

It turns out people would rather pay $2/day rather than get shitty slow apps for even 5 minutes due to database scaling to zero. Aurora Serverless v2 compromised and decided to have consistent performance which is widely desired! Hence, no scale to 0 and "nOT rEAL sERverLESs".

Compromise #2: that Aurora Serverless v2 did to be widely useful but "nOT sERverLESs": no Data API. Awesome idea and lots of power, but it's new tech in a new-tech-reluctant field — with no ORM support, Data API barely gained traction. Almost nobody used it.

Maybe with more time Data API would've been integrated with more ORMs (we saw a couple OSS projects starting up) and would have grown into something successful. Maybe. Maybe not. Using the widely-supported RDS Proxy and improving that service is... an easier path for most.

Aurora Serverless v2 compromised to be Serverless-v2-widely-useful for the real world — not exclusively for greenfield Lambda development done by AWS experts. Look at RDS and Aurora Serverless v2 and things improved so much! Heck, we can even compare Aurora Serverless v1 and v2!

No more single-AZ! No more requiring 30 minutes of zero access to scale! No more server maintenance! No more somebody deciding how many servers need to make a database cluster! No more deciding how many read replicas and how many writer servers! No more static scaling!

Aurora Serverless v2 solves the scaling problem! "Hey, I've got this app and it scales from running on 20 EC2s to 150 EC2s and the DB can never handle the load. Please gimme another option than paying $$$ for a huge-ass RDS instance" That's widely useful and desperately needed!

Serverless v2 compromises. A lot in some cases. That's ok! We need to be ok with that, because only 4% of IT spend is in the cloud and most people still run VMs with hour-long feedback cycles. Gatekeeping things because they're not 100% Serverless or 100% Lambda helps nobody.

We all created a mental model for what "serverless" means. We made assumptions and tried to define the world "serverless". Reality has changed and we need to adapt to it. Let's please focus on not caring about servers and offloading boring stuff to cloud providers!