I briefly mentioned serverless functions in my last post on Platform-as-a-Service (PaaS) and Backend-as-a-Service (BaaS). Specifically, how support for them in current BaaS offerings is rather crude.
Personally, I believe we’re going to see a lot more microservices implemented as serverless functions behind an API gateway, and as such, serverless functions deserve to be treated as first class citizens. The problem is solutions like AWS Lambda and API Gateway leave a lot to be desired in terms of deployment and management – and I just don’t like the UI.
Unlike current BaaS and PaaS offerings, we need a solution designed specifically for running backend services, whether it’s a web app with RESTful services, a microservice (think Quarkus or Moleculer), a function behind an API gateway or a combination of them all. But for the moment, I’m going to focus on functions as microservices.
We need a platform optimised for the configuration, deployment and monitoring of dozens, if not hundreds, of microservices implemented as serverless functions. This is one of the reasons why I’m not so sure current PaaS and BaaS offerings are the right fit. And, as I mentioned previously, BaaS offerings are limited to a database. A platform designed with microservices in mind needs to support message queues for orchestration and multiple databases for those who choose to implement a database-per-service architecture. That, and we would most certainly want to deploy functions that are triggered when a new message is published (not just via HTTP requests).
One thing I would expect to see is a way to group related microservices. Perhaps by creating an API (a logical container), and then adding microservices to it. For example, an order API consisting of separate payment, status and cancel microservices. Alternatively, it could be as simple as tagging payment, status and cancel microservices with “Order API”. Either way, it should be easy to organise and navigate them.
Further, I would expect to see dev, test and prod environments with CI/CD pipelines for pushing through new versions of serverless functions across multiple environments. We’ll need to come up with best practices for aligning Git repositories with deployments too. For example, do we want one project per serverless function (polyrepo), or do we want a single project with many serverless functions (monorepo)?
I imagine there is a lot that can be done in terms of instrumentation as well, providing serverless functions with connection information to backend components (e.g., databases) and monitoring real-time query and function performance come to mind first.
So, to recap my blog series thus far:
We need a platform optimised for deploying and running services
Current PaaS and BaaS offerings are not ideal and come up short
The solution needs to treat serverless functions as first class citizens
I think I’ll pivot back to services in my next post and focus on ways to improve dev productivity.
I’ll catch you on the flipside. Go watch Boondock Saints if you have seen it yet ;)