Serverless application stacks have been stuck in a dilemma: Most applications need some kind of state store, but most state stores aren’t serverless. Rich-data applications like payment apps, buy online/pick up in store services, and real-time online sports betting are incompatible with fully serverless architecture simply because, at some point, the database becomes a bottleneck. Why?
With a serverless application, your scalability depends upon your cloud provider’s ability to spin up more nodes as your load grows. Without a scalable database to receive the load from the application, though, a point can come where there is not enough data handling capacity to accommodate the current volume of traffic. When this happens, the bottleneck shifts directly to the database and the flow of data is impaired, or even stopped entirely — with potentially disastrous results.
There are, of course, distributed databases that can scale out automatically to meet increasing demand. The problem? Almost every distributed state store on the planet has a minimum scale required to operate. This is fine for users who already know they have a large-scale problem. But, when you’re just getting started, the cost in both time and money to ensure your application can scale out later is prohibitive when what you need most is to build an MVP as rapidly as possible.
Resolving the dilemma between scaling vs. starting when building a stateful, ground-up serverless application required a serverless distributed database with true “scale to zero” capability. One that can automatically scale up and down to accommodate workload demand, while charging only for the amount of compute actually consumed. First to deliver the ability to build fully stateful applications in a fully serverless way was CockroachDB Serverless.
Hello, CAKEstack
Building fully stateful serverless applications requires a new approach to your application stack, and so today we introduce CAKEstack.
C - CockroachDB Serverless A - Authorization, Authentication, Session, and User Management K - Kubernetes E - Event-driven serverless platforms
C is for CockroachDB Serverless
To power these next-generation serverless applications, we need a database that solves your scale up and scale down problems. And it needs to be a consistent data store so you can use it for your most business-critical applications. CockroachDB Serverless does all of these things and more, all while giving you a generous free hosted scale with your workload Serverless offering.
A is for Auth*
To enable all those different endpoints to have common access controls, we also need next-generation Authorization, Authentication, Session, and User Management. Platforms like Keycloak and Authzed enable distributed session management for centralizing access across multiple front ends, all in a container-native way. When using CockroachDB as the backing store, it becomes resilient and redundant across instances with no potentially complex backend configuration changes required.
K is for Kubernetes
Distributed systems are inherently complex, and so we need a way to orchestrate all the moving pieces. The essential anchor of our new stateful serverless stack is Kubernetes, since the big K8s vendors are offering dynamic, low-friction scaling mechanisms for our orchestration layer. This allows us to move away from any serverless platform that would lock us into a specific IaaS. With and instead gives our stack full portability across datacenters, cloud regions, or even cloud providers so we can spin up resources as close to our users as possible.
E is for event-driven serverless platforms
Of course, we need to host and deploy our serverless, event-driven architecture. At this point in the stack there are two moving pieces to select: serverless frontend and backend frameworks. For our presentation layer, we need a distributed hosting and content delivery platform to operationalize our data and make it available over APIs for ease of use. A platform like Directus or Vercel (both of which have added native CockroachDB support to their offerings recently) enables centralized data access across multiple consumption modes — native application, web, mobile, IoT, etc. — and built-in serverless functions. Put another way, it makes it easy to just code against the data in our database instead of having all our microservices talk to the database directly.
On the back end, platforms like KNative enable our serverless deployment workflow — allowing individual event processing pipelines and functions to scale elastically as required to meet user demands. No more tightly-coupled application monoliths or even complex services that still require intervention to scale. Now, each atomic function or workflow can scale up, and down, as necessary. No more overprovisioning for burst events and no more paying for unused capacity.
(Bonus: M is for Modular)
The great thing about the CAKE stack is that it’s fully modular. Don’t like KNative? Use Lambda or Cloud Functions. Not a fan of Keycloak? Integrate with your favorite Authentication platform. Now that we have the missing-link power of a truly serverless database at our fingertips, we can unlock the full potential of fully serverless applications. Let’s look at an example.
Imagine you’re building a platform that enables florists to work with local delivery drivers to supply fresh bouquets and flowers to local homes and businesses. This business is very bursty: Valentine’s day is going to bring peak workloads, as are mornings on most business days. But you really don’t need much running overnight.
To start, you might just be working with a handful of drivers and florists in a single town. Your MVP certainly doesn’t need the infrastructure to run this nationwide during your initial launch. But, if you don’t build it that way from the start, you’ll have to re-architect when your business catches on coast-to-coast and you need to scale out. Using the CAKE stack, though, means that your apps, your data, and your location all scale right along with your business and your usage — all in real time with no intervention, and also without running a bunch of infrastructure you don’t yet need in the meantime.
Architecting an app for scale from the start used to mean choosing between starting fast now vs. scaling fast later. Either taking on the complexity and cost of distributed architecture before you even have your first customer…Or starting out with an enormous amount of technical debt that can cause you to fail to scale once your customers do begin pouring in, or requires massive rearchitecting.
Now, however, the serverless universe has matured to the point where you can start with a configuration that will meet your needs for the long term. All of the elements of the CAKE stack we have named here are even free to get started with, with costs eventually incurring once your usage goes up rather than having to pre-pay for a bunch of dormant infrastructure. Building an application using the CAKE stack means performance and costs scale so you can focus on onboarding the most important asset of all: your users.
