I recently did some research on the state of “serverless” application development. It turns out that most organizations are fully ok with locking their codebase, database, and file storage onto a single platform. There are many potential pitfalls to such a decision. Several scenarios could make a person or organization choose to switch platforms only to find that the decisions made within their codebase have locked them onto their existing platform pending a significant refactor or, worse, a total code rewrite.
What does a typical web application actually need? Basically, the ability to execute code, some sort of database storage, and often file storage. I have found a number of tools that could allow a serverless application to be written that uses all of these services without any hard ties to a specific provider. I’ve actually taken it a step further and ensured compatibility with a major open source alternative for each service.
Serverless Application Structure
The Serverless framework allows deploying your “serverless” code for execution on each of the major cloud service providers as well as the open source alternative Kubeless.
Limited Language Support
The next issue is deciding upon a programming language. The Google Cloud seems to be the most limiting platform supporting only Node.js and Python.
Language options are limited to Node.js or Python in order to deploy to all of the major cloud providers. If Google Cloud Functions is taken out of the equation, then C# and PHP could also provide a good set of deployment options.
Cloud Relational Databases (SQL)
Next let’s assume that you need relational database access, you know, since we are all supposedly done pretending NoSQL solves the same problem. If you were to just go writing raw SQL you would very quickly vendor lock yourself because almost none of the popular cloud platorm database have any kind of meaningful SQL standards compliance. A good way to avoid dealing with the various differences between each database is to use an ORM. The state of cloud database support within ORMs differs widly. If you don’t want to write your own ORM then choosing one will be a major consideration.
ORM Cloud Database Support
I took some time to check which of the popular ORMs support the most cloud databases. Here are my findings.
| ORM | Amazon Aurora | Microsoft SQL Database | Google Cloud SQL | CockroachDB | Mysql/Postgres |
|---|---|---|---|---|---|
| Python: SQLAlchemy | x | x | x | x | x |
| Python: Django ORM | x | x | x | * | x |
| Node: Knex ORM | x | x | x | ** | x |
| C#: Entity Framework | x | x | x | x | x |
| PHP: Eloquent ORM | x | x | x | x | x |
**Limited Support
Lastly, we have file storage. The following libraries attempt to abstract file storage away from any specific platform.
Unified Cloud File Storage APIs
| API | Amazon S3 | Google Cloud Storage | Microsoft Azure Storage | Local Files | Minio |
|---|---|---|---|---|---|
| Python: cloudstorage | x | x | x | x | * |
| Node: Zenko | x | x | x | x | x |
| C#: TwentyTwenty.Storage | x | x | x | x | |
| PHP: Gaufrette | x | x | x | x | ** |
Summary
According to the libraries and APIs that I have been able to find, Python with SQLALchemy ORM and the Cloudstorage API deployed with the Serverless framework would be the perfect combination of available tools to allow you to create an application that can deploy to every major provider. Any other stack seems to require compromising deployment targets. If Google Cloud is eliminated as a deployment target, then C#, Node, or PHP could also be used but each will have its own limitations related to ORM and cloud file storage.