RLFO#31: Head in the Clouds

This post originally premiered on Random Links Found Online.

Long time ago, the cloud was “someone else’s server” — we got VPSes and maybe some fancy storage, but we still had to manage and maintain servers. But strong programming primates create good times, and good times came with Serverless services. And good times create weak primates, and with weak primates came hefty cloud bills which rival GDPs of small nations. This week, we're diving deep into the guts of Serverless platforms, peeking under the hood of AWS Lambdas and seeing how function calls end up actually being HTTP calls. We've also got some thoughts on why Kubernetes might be overkill for your two-server startup, and after the month-long hiatus of not writing any RLFOs, we’re so back!

?? Lambda on hard mode: Inside Modal's web infrastructure

[link] My favorite way to describe migrating a monolith to microservices is to say “migrating function calls to network calls”. What used to be a call stack away, now its a whole TCP/IP stack away… not very performant if you ask me, but that’s besides the point. With more people moving more workloads to Serverless platforms, this “function-to-network” mapping becomes a daily job for way too many people. Call stacks are simple though, and not having to think about the implementation details of the network underneath a Serverless platform is a luxury not everyone can afford. Modal is one of those Serverless platforms that hide away these implementation details. All the programming primate sees is a function call, which then gets transformed into an HTTP call behind the scenes.

?? How AWS Firecracker works: a deep dive

[link] I started this Firecracker dive myself when I was told that “somehow, our ZIP lambdas warm up faster than Container lambdas” and I realized I didn’t know how AWS Lambdas work internally. Firecracker is the Serverful infrastructure that powers your Serverless workload on AWS. It allows AWS to spawn extremely tiny VMs on demand — every time your Lambda has a cold start. While this article won’t show you why some lambdas load faster than others, it’ll demystify some of the magic behind your preferred Cloud provider.

?? Slashing Data Transfer Costs in AWS by 99%

[link] Cloud is cheap, until it isn’t. We have seen quite a few companies go away from Cloud providers recently, and we also have seen quite a few small startups go bankrupt because of hefty 6 digit cloud bills. Although every AWS training I’ve seen mentions ways to manage budgeting, I’ve seen way too many cloud enthusiasts and practitioners forget to set billing alarms. This article shares some tips on how to save yourself some money on AWS, which you will most likely still spend on other AWS services.

?? No, we don’t use Kubernetes

[link] K8s started as a tool Google needed to manage its way too many servers. It was developed when most companies didn’t have to deploy in many servers, let alone in way too many of them. This was before the Time of the Cloud. But now we’re living in the Time of the Cloud, and most cloud providers were providing K8s-like features even before K8s was open sourced. Things like load balancing and autoscaling, scheduled workloads, various deployment strategies, IaC, all these are provided by most cloud providers through non-k8s tools. So no, you don’t need Kubernetes.

?? Eating the Cloud from Outside In

[link] Somehow everyone I know is, to some extent, unhappy with AWS. Somehow everyone I know is content with Cloudflare. The reason seems to be that AWS tries to do everything, in every way you — or they — can think of. Cloudflare, on the other hand, does only one thing: CDN. But since they have the infrastructure, they allow you to do some other stuff. Like workers, their edge Serverless functions. But they didn’t stop with that. Cloudflare now provides object store (think S3) and Key Value store (think Redis) and SQL database… For people who prefer using Cloudflare CDN over AWS CloudFront, maybe using the full Cloudflare suite of products makes a bit more sense than spreading out in what is essentially a multi-cloud deployment.