Pieter HumphreyDid you ever wish you had persistent storage for your serverless functions? Storage that was as easy as an idiomatic API call in your favorite language? What if you could even handle JSON data with no upfront schema definition? Functions as a service (FaaS) are excellent containers for business logic. With functions, you can:
- Run backend code without managing any infrastructure whatsoever.
- Run short-lived code that starts FaaST, runs and shuts down when complete or unused.
- Run your code in a specific framework or library of your choice.
- Trigger a function based on events that are defined by the FaaS provider.
That’s great, but what happens to the application state? Yes, you could run an in-process cache, session store, or use the modest filesystem allocated to the function. But these workarounds will be as short-lived as the function, so it’s not what most people consider persistent storage.
Using APIs and or Drivers, you can get data out from your functions and into a database, but not many databases employ data API gateways or offer easy ways to surface a fluent data access layer in APIs like REST, GraphQL or gRPC. Perhaps you have JSON data and you simply want a document-style NoSQL option that skips defining the schema upfront – just JSON and go.
So let’s assume getting to your database is easy with APIs, drivers, and schemaless JSON for a moment. Why then, would a serverless, autoscaling database be the preferred choice for persistent storage for your serverless, autoscaling functions? First off, it’s important to understand that serverless and FaaS are not quite the same thing. The key thing that makes FaaS and Serverless DBaaS so great together is autoscaling.
If you've invested in DBaaS and FaaS, you're probably not interested in managing infrastructure. Running serverless functions that have the potential to autoscale up rapidly is dangerous if connected directly to a back-end database that cannot auto-scale.
Scaling up the application dynamically could put an unpredictable and increasing load on a data service or database that doesn’t use a similar (auto) scaling mechanism. The industry spent years trying to solve this problem in the application server era with connection pools and database connection conservation techniques. Most of those techniques are antithetical to FaaST-startup-and-terminate style serverless functions because there’s no connection to preserve!
Pairing an autoscaling application tier to a data tier that doesn’t autoscale drags down a system that could have otherwise been fully automated. Manually running a terraform script, or worse, waiting for an operations ticket to be created and serviced for scaling the database instance up or down would kill 50% of the automation value between application (function) and database. No Bueno.
So how can we wire together an autoscaling DBaaS like DataStax Astra DB, with serverless functions without having to write a ton of REST services to expose the database functions you need? Let us show you how!
In this livestream playback, Alex Ellis and Stefano Lottini show you how to pair FaaS with a serverless, autoscaling DBaaS for end-to-end automated scaling.
To get the most out of the event replay, be sure to check out the OpenFaaS blog first!
Learn More:
Follow the DataStax Tech Blog for more developer stories. Check out our YouTube channel for tutorials and here for DataStax Developers on Twitter for the latest news about our developer community.
