Serverless != microservices

It’s about pricing and scaling, not architecture

Not sure whether TJ Holowaychuk was the first to point this out or not, but this tweet triggered an epiphany for me about serverless:

There’s nothing that demands that you write your AWS Lambda functions as tiny one-off components that are composed into a cloud of synchronized microservices. A serverless function is an executable piece of code, nothing more. You can easily write a traditional monolithic web app and deploy it as a lambda, so long as it fits within AWS’ rather generous limits (or the limits of your serverless provider of choice).

I’m currently working on a website rebuild using NestJS for the back end as a traditional MVC-structured monolith. Why not go with microservices from the get go? For a hundred reasons that have already been debated ad nauseam, but in my particular case the operational overhead of a fully distributed architecture doesn’t make sense for what is currently a very low-traffic website.

And guess what? I’m hosting the rebuilt website on AWS Lambda without any problems. (Here’s a template if you want to try it.) I’m saving an appreciable amount of cash over Heroku because of how infrequent invocations are. Best of all, with CloudFormation templates and the Serverless framework, I’m able to give my engineering team an easy way to deploy their own copies of the website’s stack in a snap, allowing them to spin up their own staging/dev environments in the cloud.

Microservices is an architectural pattern and tooling ecosystem whose popularity seems to be derived in equal parts from its usefulness in specific cases as well as the way it seems to jibe with our current “decentralize and distribute all the things!” zeitgeist (e.g., finance, governance, energy production, agriculture). The general push toward decentralization in our society seems to be correlated with a perception that decentralization leads to “leanness” and efficiency, which are big selling points for serverless. I believe that this imprecision/confusion is the root cause for why people assume that serverless and microservices must go together.*

Leanness and efficiency, however, are relative. There’s always the question of what exactly you are trying to make more efficient. Most of the time as a consumer-facing startup, you should be trying to optimize for developer efficiency. As an early-stage startup, it’s rare that microservices will increase the number of features that your engineers ship. But even if you avoid microservices, if you still conflate it with serverless, you may end up depriving yourself of a stable, available and practical technology that can help minimize costs and infrastructure management.

*Note: Consider OpenFaaS, which allows developers to write microservices on top of managed servers. Their approach is the inverse of mine (write monoliths on top of serverless), yet their project is another demonstration of why serverless != microservices.