Why Theo Ditched Serverless (And Does It Make Sense?)
Date: 2024-09-21 | create | tech | serverless | system-design | cloud | aws |
Theo (t3dotgg on YT) announced in a new video "We stopped using serverless. The results are insane.".
In this video we'll go over what Theo was building, what the serverless migration entailed (including results), and whether serverless had anything to do with it.
What is Theo Building?
Theo is building Uploadthing - one of several products under Ping Labs. The tagline is "Better file uploads for developers" and they're basically building a better S3.
Theo has been (in)famous for using and promoting serverless technologies so this move away from serverless seems like a new direction and follows a more widespread trend of ditching serverless for more traditional options (like a server).
Why did UploadThing ditch Serverless?
The exact reasons for the move are not shared but we can look at the overall goal of the product and its end results to get an idea. (source: uploadthing)
The goal is: "Make UploadThing the best way to upload files[sic]. Which means moving away from S3 direct uploads."
So clearly there was an architectural issue here preventing them from further evolving (S3 direct uploads).
And the results led to much faster uploads when comparing v6 to v7:
- Multiple images: 4.7s -> 1.3s (3x faster)
- Single image: 3.7s -> 0.7s (5x faster)
So we can infer that the reasons were:
- Unlock new capabilities
- Be more competitive (w faster uploads)
What did the Migration entail?
The migration itself was really a rearchitecture of the upload flow.
Old Architecture (v6):
- 7 individual requests
- 3 different services (customer, UploadThing, S3 Lambda)
New Architecture (v7):
- 3 individual requests
- 2 different services (customer, UploadThing)
The main differences between the two is the request flow:
- No initial presign request (-1 request)
- UploadThing acts as an upload proxy (-3 requests, remove lambda, remove client polling)
So technically UploadThing did remove its serverless component (lambda) and in doing so got 3-5x improvements in e2e upload speed which is pretty sweet.
But is the move off serverless actually what led to these improvements?
Were these improvements attributable to the move off serverless?
Really the biggest change is the lower count of requests (network hops) and services involved.
- Network hops are notoriously one of the most expensive operations in a webapp so going from 7 to 3 is a huge win
- The removed lambda (serverless function) may have been a bottleneck itself. Serverless functions may have variable latencies based on cold starts, priority in infra and there's some implicit operations that have to run before it's even called: S3 -> SQS / SNS -> lambda which could've caused hidden bottlenecks itself. (conjecture - have no data on their architecture)
My guess though is that these were the biggest improvements to latency, not a strict move from serverless to server.
This is a bit easier to see if we simplify UploadThing's architecture. Here we can see that the UploadThing service really just needs to be able to receive requests, proxy uploads, and make new requests. This should be achievable on both serverless and server architectures - whether a VPS, serverless functions, or serverless containers.
So yes the removal of the serverless function likely helped but it's likely the rearchitecture itself is the bigger win.
Next
I like system design updates like this because it's always interesting to peak inside how people build and run their systems. Thanks to Theo for making this deep dive and congrats on 3-5x improvements - that gets increasingly hard to do as your software matures.
I personally lean towards monolithic containers (whether server or serverless) as I find them to be a Simple Scalable System for running most workloads. I think their decision to move off of serverless functions will probably work well for them (and personally think most ppl should ditch functions) but it always depends and think both server / serverless have their place and are here to stay.
If you liked this post you might also like:
- Cloud Migrations: Why Zig is Migrating from AWS to Self-Hosted
- Serverless horrors: How this Developer’s Side Project racked up a $100k Cloud Bill on Netlify - and 5 ways to avoid the same fate
- How I like to build webapps: The HAM Stack - A Simple Scalable Tech Stack for building modern web apps fast and cheap
Want more like this?
The best / easiest way to support my work is by subscribing for future updates and sharing with your network.