SQL is from 1970, meaning it’s now half a century old. Does it still have a place in 2020’s cloud-based serverless implementations?
Conventional wisdom
Recognize first that plenty of voices teach that serverless architectures and NoSQL go together nicely, for a range of reasons. Serverless computing emphasizes scalability, statelessness, flexibility, thrift, and ease of deployment, among other virtues. NoSQL advertises a similar line-up of benefits. A natural conclusion is that serverless and NoSQL partner well.
And they certainly can. Showcase serverless applications sometimes leverage NoSQL persistence that, from all appearances, plays its role well.
Cloud industry is only in its infancy, though, and best practices remain far from clear. We’re not yet certain whether the association between serverless and NoSQL is a necessary one, a matter of fashion, a historical accident or something more nuanced. While serverless and NoSQL have teamed successfully, so have serverless and SQL — leading cloud providers offer Cloud SQL, Amazon Relational Database Service and so on.
Principles
Perhaps the most certain result for now is that serverless computing is compatible with a variety of implementation technologies. Serverless computing can succeed with NoSQL, but also with SQL, if the latter is managed nimbly and with such modern conveniences as on-demand provisioning, SSD-backed storage and IPsec isolation.
Accept for a moment that both NoSQL and SQL have the potential to complement serverless — how do we decide between them? Think architecturally: Consider where the value of the processing lies. Do a variety of different applications need to retrieve precise, objective data and present that data in different perspectives, as is common in fintech and some kinds of IoT work? Those are jobs where SQL has been in the lead. Is the emphasis on filtering massive collections of approximate data with experimental queries in search of actionable results? Does the programming team think only of objects, and never of structured queries? NoSQL better fits those situations.
Inevitably, as soon as we generalize usefully about what differentiates these technologies, clever innovators hybridize constructions that promise the advantages of both sides. ArangoDB, for instance, is a “multi-model” database that allows graph, document and key-value stores. It is resolutely NoSQL, yet to express all that it does requires a unified query language, AQL, that most closely resembles SQL.
Build, Test, and Deploy with Confidence
Scalable build and release management
Serverless for success
The way to win with serverless starts by expressing requirements without reference to an architectural choice; let the architecture be part of the solution, rather than the problem. Identify the abstract nature of the data, their transactions, types and life cycles.
Do customers receive value because they can retrieve precisely what was earlier captured about them, or does value arrive from relatively stateless algorithms applied to newly collected data? The latter is likely to fit naturally with artificial intelligence components, often backed by NoSQL technologies. When data is highly transactional, though, or when security requirements are complex and “least privilege” is an essential, and especially when data needs to persist far beyond the manipulations of one particular application, cloud-savvy SQL starts with several advantages.
Another way to think about customer value is how tightly data is bound to a particular application. If data belongs to a small number of closely related applications, NoSQL is a natural choice, and much of the design likely emphasizes stateless programming. If state is primary, though, and different applications are perspectives on that long-lasting state, SQL probably is the vehicle of choice.
Does the data admit a persistent model? That suggests SQL, perhaps managed by a dedicated database administrator. Is it more important that the relations in an instance be flexible and easy to change throughout the lifetime of the data? Several NoSQL technologies emphasize this kind of flexibility.
Whatever the database technology, security deserves care from the first design. Make sure secrets — access passwords, resource tokens and so on — are always rigorously protected. Even one accidental commit of secrets to a version control system or a transient password-free exposure of a datastore to all employees can have devastating consequences. Barricading all data accesses behind an explicit API gateway, for instance, gives a welcome extra layer of security.
Be ready for change. However perfect last year’s choices of technologies, and however large the investment in those technologies across an entire enterprise, new business circumstances can make migration to a different technology appropriate and desirable.
Ultimately, SQL assumes a role with serverless that’s small but certainly greater than zero. Analyze the true business requirements of your serverless work with care, and any decisions about datastore technology should follow with a minimum of controversy.
All-in-one Test Automation
Cross-Technology | Cross-Device | Cross-Platform
