Yeah. Actually, part of me thinks, you know, every time I look at a new serverless service, you know, I think whoever coined the term serverless was a marketing genius. When you say, “Hey, I’m moving to the cloud,” you know, the kind of, you know…almost the kind of reactions I get span the spectrum of, “Oh, I love it,” to, “I have no clue what that is.” And there’s a really funny video, you know, on Indian television from about a decade and a half ago where one of the government officials is trying to explain what the cloud is and he’s literally confused with the cloud-cloud, okay. And it is an absolutely hilarious, hilarious video. But I think the idea of serverless at its core is that you’re making simpler, fewer tradeoffs. And literally to the name serverless, when you talk to somebody and say, “Look, you have servers now. What if you did not have the servers and you had the same service, right?”
It’s such an easier…it’s so much easier to have that conversation than try to, A, explain to them the concept of the cloud, B, explain to them how they’re gonna get there. You know, it’s much easier to say, “You have a server today. Tomorrow, you don’t need the server and it’s still gonna be the same.” That’s a much, much easier conversation. So, whoever designed it or whoever coined the term serverless I think was an absolute genius from a communications and marketing standpoint. And back to Aurora serverless, yeah, I mean, back to the concept of tradeoffs that they were making. The first tradeoff they said was, “Hey, it’s hard to manage partitions and scale up and scale down and get it right every time. So why don’t you let us do that for you where we will just, you know, put all your servers in autoscaling group.”
Kind of that’s the impression under the hood where you can just keep adding instances or removing instances and you get your, you know, horizontal scalability out of the box where AWS manages it for you. You could manage the same thing yourself by creating an autoscaling group and then, you know, adding that to the cluster and then creating your CloudWatch metrics to move it up or down. you could do that. But AWS has made it easier and said, “Hey, here is few things we will take care of for you. If you wanted to, set a max limit, set a min number of instances. We’ll do the rest for you.” That was great. That was the first version of tradeoffs that they reduced for us. And with serverless v2, they went a step further. They’re like, “All the increments can be a lot more granular, literally at the VCPU level.” So, they have something called the ACU or the Aurora Compute Unit.
And they were like, “Why don’t we turn that down to a .5 ACU so you can move up or down incrementally in .5 units and we will make all the tradeoffs for you so you don’t have to worry about it? You would just put in your load and let it run.” Traditionally, how we used to manage it was we used to have to worry about the CPU load. We had a DBA…I mean, we had dedicated DBAs that would worry about CPU monitoring, memory monitoring, network IO, disk IO. God forbid one of the disks failed, you know, figure out a swap strategy. And then if you put in RAID, then the performance of the IO kinda went down. So, they had kind of some voodoo magic that they would do where they’d run RAID 0, but then have some mechanisms of doing backups so that they didn’t lose everything if something went wrong and then they had to work out all kinds of scaffolding for restoring, you know, all the data when things happened.
AWS is basically saying, “Let us manage it and we’ll give you guarantees around it so you don’t have to deal with it and don’t build one-offs reinventing the wheel in every organization,” which I think is tremendous value for most organizations. And there may be a handful of organizations in the world that require that level of control for pieces of infrastructure like this, but for the vast majority, I think those tradeoffs are super easy to make because they’re so simple.
