The responses to Kelsey's tweet illustrate a fascinating disconnect between traditional and #serverless mindsets. If you approach "serverless" like any other compute platform, you're going to be disappointed. Here's why… 🧵
https://twitter.com/kelseyhightower/status/1481321151099854849
Let me start by clarifying what I mean by a "traditional" mindset. I don't mean "legacy", and I certainly don't mean "wrong". I think of it as the encapsulation and orchestration of compute processes within a single execution stack. This includes both VMs and containers.
The traditional mindset assumes some measure of vertical scaling (e.g. concurrency) within an environment, often relying on some form of statefulness/stickiness, and then graduating to horizontal scaling to achieve higher throughput. Again, nothing wrong with this approach.
There are, of course, limitations, especially as the size & scope of apps grow and certain workloads require specialized hardware. Multi-tier architectures separate out the data layer, and microservices break processes into smaller parts, but the compute mindset stays the same.
The serverless mindset approaches this differently. First of all, you must think of "compute" more broadly in terms of the platform and ecosystem's capabilities versus simply as a way to "execute code." There are lots of things FaaS can't do, because it doesn't need to.
A serverless approach should have you thinking about what's required for each discrete operation and how the platform/ecosystem can accomplish it. If the platform can't handle it, then (and likely, only then) should you write a discrete piece of custom business logic.
Discrete operations in a serverless application can then be orchestrated and/or choreographed into larger business workflows. Each operation can be scaled, secured, upgraded, and managed separately, allowing for tremendous flexibility and interoperability.
From a scalability perspective, each concurrent execution should be handled horizontally. This means that each invocation has the same resource allocations, theoretically providing the same predictability of performance. No noisy neighbors, shared memory, or CPU bottlenecks.
There are plenty of tradeoffs with this approach. Most notably the fact that each discrete operation becomes its own distributed application. This can introduce latency, additional points of failure, idempotency issues, etc. However, more mature platforms mitigate these for you.
There's also the developer experience issue. Managing and understanding hundreds or thousands of configurations for different services (all with their own limitations) along with the need to organize custom logic, maintain/monitor workflows, ensure security, etc., is non-trivial.
Also, while the "traditional" mindset doesn't exclude an event-driven approach (popular w/ containerized apps), serverless apps are *entirely* event-driven. Some events are processed synchronously, but the vast majority are asynchronous, disconnected from the client-server model.
This is why arguments like "Lambda only runs for 15 minutes", "cold starts take too long", "there's not enough CPU/RAM/Storage", etc., become mostly irrelevant when a serverless app is properly designed. Not because there aren't limitations, but because you design around them.
If you try to run a 4 hour ETL job in a Lambda function, that won't work. And here's the thing, it's not supposed to. Instead, the constraints force you to think in distributed patterns, like fan-out or scatter-gather. It's not as simple, but it's incredibly fast and scalable.
But this brings us to the wider industry problem. Most of the big players approach serverless with a traditional mindset, which IMO, is wrong. "Serverless" solutions that are backed by container orchestration systems like Kubernetes are 1 step away from becoming fully-abstracted.
That is to say, most people don't want/need to run their own K8s cluster, which is why EKS, AKS, & GKS are so popular. And once this happens, you've essentially just built a less efficient version of AWS Lambda that relies on dozens of abstractions to execute a few lines of code.
This may allow for less initial constraints, but ultimately moves your application further away from the metal. Alternatively, "microVMs" built with @awscloud's FireCracker or the isolates being used by @Cloudflare are much more interesting and will unlock new efficiencies.
There's a dissonance created by providers trying to meet customers where they are, but also hedging their bets on a wildly different future. I'm not criticizing them for that b/c you need to go where the gravity is. I just hope it's a means to an end, not a long term strategy.
Anyway, I truly believe "serverless" will eventually overtake container orchestration once more CSPs build microVM orchestration into their platforms like AWS Lambda. Until then, we'll need to live with a patchwork of solutions hopelessly trying to avoid "vendor lock-in". 🙄
• • •
Missing some Tweet in this thread? You can try to
force a refresh
