TL;DR
The Serverless and Cloud Native movements are here to stay. So, they will eventually be the same thing.
Also - I'm heading to re:Invent! If you're in town for the conference (or otherwise) reach out let's get together.
What I'm Writing
Thread-of-threads with wild guesses about what AWS will announce at re:Invent this year: A lot of my guesses are jokes, but you can bet your socks if I get any of them right I'll scream.
ML Engineering on AWS SageMaker!!! Over the past couple months I've been heads down working on part of this nanodegree from Udacity, and it was a ton of fun. I'll write up my experiences in more detail later.
In the Buffer
Introducing SLSA, an End-to-End Framework for Supply Chain Integrity: SLSA certainly seems to have gained mindshare since this announcement five months ago. Increasingly, the roads and bridges of our digital lives are becoming a complex web of open (and closed) source packages, build servers sprinkled across the globe, and release pipelines that end in a pipe to bash. In the wake of high profile supply chain attacks, a prescriptive and hierarchical set of practices to secure our supply chain was badly needed.
If You Want To Transform IT, Start With Finance: A funny corollary to Conway's Law.
IPv6 On AWS White Paper and the related IPv6-only VPC blog post: Network topologies are ridiculously sticky in the short and medium term, but incremental changes like this are how slow, boring transition happens in infrastructure. First IPv6-only has to be possible, then it can be the greenfields default and/or a migration target.
BEHAVIOR: An impressive simulation and benchmarking suite for "embodied AI" agents to perform household tasks. Reminiscent of OpenAI Universe but appropriately more audacious (Universe was released in 2016). Over time, our game-making competence has become core to AI-building (more on this in a future blog post).
Serverless and Cloud Native At Odds
In a recent appearance on aws.fm, iRobot Cloud Roboticist Ben Kehoe said something that struck me:
S3, DynamoDB had been around for a long time. So all the other parts were sort of already there as the compute layer that was new. So then people started trying to figure out, okay, well, how do we do this? And that was happening in sort of 2015 and 2016. And in 2016 was the first Serverlessconf where some people organized a warehouse in Brooklyn that had no air conditioning in the summer. And we got together and we all talked about, okay, well, none of us really know what we're doing, so what's happening?
And from there we all had high hopes that this was the immediate future. I think then Kubernetes came along and presented something that's very much the faster horse. It says, we can solve a lot of these problems that are present in server-full technologies without changing the paradigm. And so people I think were attracted to that to say, "Oh, I don't need to rethink how I build things. This things solve those problems." And so it is doing helpful things, which is solving those problems for people, but it's still, there's still a gap from there to Serverless technology where you take them and say, none of those are your problem anymore. And so that set back Serverless adoption by several years.
[...] And so it's, it's unusual. I think if we look back and sort of the history of technology where something has come out, the eventual future has come out earlier and then something that says, well, we can solve this for a while, and so we'll end up in a place where in 2015, 2016, we saw what 2025 looks like, but we thought it was going to be 2020.
The entire discussion is fascinating, and Ben is a great follow if you're interested in Serverless, IAM, iRobot, and other topics. This part of the discussion continued to bounce around in my head, though, and it took a little while for me to realize why. I agree with Ben that Serverless will be the future, AND I believe that Cloud Native, probably in the form of Kubernetes, will be the future too.
A few key ideas behind this view:
Serverless the future that you should give to builders.
Kubernetes will be the future control plane for platform resources.
Serverless and Cloud Native are already melting into each other.
Let's dive into each of these points and where I think the future of these movements are going.
The Future Experience and Control Plane
Serverless: "Serverless" characterizes a way of building workloads and applications that - you guessed it - offloads concerns about the server to the platform. Serverless applications still run on servers, it's just that you shouldn't have to care about them. When they need to scale, when they need to be geographically distributed, and when they need to consume resources, the platform takes care of that for you.
As a result whole orders of operational concerns (like upgrading servers or dependencies) get offloaded to the platform, and the Serverless app can enjoy consumption-based pricing at a granular level. In practice, "the platform" I'm referring to is often a cloud vendor like AWS, GCP, Azure, Vercel, Cloudflare, Netlifly and so on. It can also be an internal "platform" team who makes the Serverless Experience available to your team (by running the underlying servers and abstracting them away from you.)
There certainly seems to be a growing consensus that Serverless is great for builders who want to focus on solving business problems. The product launch of AWS Lambda was probably the inciting incident that kicked off the Serverless movement, and since then the community has steadily accreted.
Cloud Native: The Cloud Native Computing Foundation (CNCF) defines "Cloud Native" here. The Cloud Native movement has really taken off in approximately the same period as the Serverless movement. The crucial phrase in the CNCF definition that I want to call your attention to is this:
Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify [the Cloud Native] approach.
The explosive adoption of containers (particularly Docker) as a packaging format for code seemed to be the inciting incident behind the Cloud Native movement. Kubernetes featured prominently in the announcement of the CNCF in 2015, and it’s a technology that brings together all those exemplars.
Having said that, I still come back to Joe Beda's "platform platform" talk. He outlines how Kubernetes allows you to continuously reconcile the current state of your system with your desired state, and how it lets you define custom cloud resources declaratively, and how these properties make Kubernetes great for anybody seeking to build their own platform.
There’s much to be said about the cognitive load, complexity, and distributed system problems that this ecosystem brings with it. Still, Kubernetes, and Cloud Native approaches in general, seem to be "winning" (for better or worse). So we can at least say there’s a growing consensus that some Cloud Native control plane, probably Kubernetes, is the future for platform development.
The Quickening
So will Serverless be "the eventual future"? Will it be Cloud Native in the personage of Kubernetes? Is it inevitable that one of them will win out over the other? "There can be only one?" I don't think so.
Beyond the enduring nature of popular infrastructure abstractions, I think the other reason to expect both Serverless and Cloud Native to endure into the future, is that they're melting together. There's a growing and maturing stable of Serverless-on-Kubernetes and Kubernetes-on-Serverless.
Serverless-on-Kubernetes
There is actually a Serverless section in the infamous CNCF Interactive Landscape page, including an "Installable Platform" section. Generally speaking, those tools tend to be a good starting point for the Serverless-on-Kubernetes space. In this way of melting together, the team responsible for running the tool does not get a Serverless experience. They still have all the challenges, costs, complexity, operations, headaches, and chores associated with running Kubernetes in production (more on that in Kubernetes-on-Serverless).
The upside, however, is that every other team can be provided a Serverless experience, and they can focus on building. This "cognitive offloading" is the crucial benefit I see, and this offloading could occur across any sort of organizational or corporate boundary (caveat emptor).
To give you some examples:
Installed Serverless tools, like OpenFaaS and Knative. There's a lot of differences between these tools, but they generally strive to provide teams with a way to offer Serverless experiences downstream of them, by installing on Kubernetes (or in the case of faasd, just single modest computer).
Knative actually appears to be the basis for Google Cloud Run, further showcasing how Serverless and Cloud Native are melting into each other.
KEDA is an interesting tool to consider in the category because it's actually just a load balancer with event-driven scale-to-zero capability. Still, scale-to-zero is so foundational to the Serverless experience and that it's hard to look at KEDA and not see it as part of this trend.
All the WASM things. The use of the Chrome V8 Engine as a substrate for delivering Serverless experiences seems well-proven by Cloudflare Workers. There's also Krustlet, a Rust project that lets you run WASM modules on Kubernetes. It'll be interesting to see how WASM enables new Serverless experiences/products, and how its growing adoption in the Cloud Native ecosystem plays out.
Finally, it should be noted that the merits of running your own instance of, for example, Knative, are up for debate, and very very contextual. For many businesses, going straight to AWS-native services makes perfect sense. The point here is instead that the ecosystem for delivering Serverless-on-Kubernetes is maturing, as part of these two movements melting together.
Kubernetes-on-Serverless
Managed Kubernetes offerings get more mature each year. All the major vendors will now spin up a Kubernetes control plane and nodes for you on demand. So it makes sense to ask: can more of Kubernetes itself be delivered in a "Serverless" way? A pretty straightforward example of this is Fargate on AWS Elastice Kubernetes Service (EKS).
In a nutshell, Fargate gives you a (somewhat) Serverless experience for running containers. Integrating with Fargate, EKS allows you to treat Fargate as a pool of Serverless compute available to your Kubernetes workloads. Scale-to-zero, consumption based pricing, fully managed runtime, and many other Serverless capabilities apply, it just so happens that Kubernetes manifests are defining the workload instead of AWS Serverless Application Model or States Language.
Melting Together
Perhaps the clearest example of Cloud Native and Serverless melting into each other today is Google Kubernetes Engine Autopilot. It's a veritable Ouroboros of Kubernetes-on-Serverless and Serverless-on-Kubernetes. Definitely peruse the overview and docs, but the headline here is that you get the Kubernetes API as a Serverless function, and then your workloads run in a Serverless manner (including consumption-based billing).
Over time I think we'll continue to see Cloud Native and Serverless communities not only thrive, but blend and learn from each other. This is A Good Thing, because it encourages us to use Serverless and Cloud Native for what they're respectively good for. I'm looking forward to seeing more of these communities melting together, and, who knows, maybe we'll be hearing some announcements along those lines this year at re:Invent...
Thanks for joining me on this edition of The Slip Box! If you enjoyed this post you can subscribe or check out the previous posts here. Until next time.
Photo by Cookie the Pom on Unsplash