Serverless approach in the context of microservices
In this article, I will talk a little bit about the different serverless options you have and how they relate to microservices
Introduction
Microservices advent has happened more or less in parallel with serverless cloud services offers becoming mainstream. Simple coincidence? Are microservices a concept that matches especially well with serverless? Let's see it.
Micro sounds like "function"
One of the most famous services serverless provides is the so-called "functions". Google Cloud Run, AWS lambda, and Azure functions are only three of the most famous in the market, but these kinds of services have become very famous these days. And, if you think of microservices as little functions distributed in the network, it seems like there is an obvious match. You'll see that this is not exactly true.
Let's put an example: a microservice for authentication. It has a RESTful API from which the front end authenticates users into the system. Is this a match for serverless functions? Well, considering that the APIs should be up 24/7, you need to pay for these functions to be up 24/7. What happens then with the cost? It is almost 3 times as expensive as a regular virtual machine.
And you may think, ok, but what happens with the free -understanding free like effort-free, not cost-free- scalability of serverless functions? Use Kubernetes with node autoscaling and it will be still 2 times cheaper.
The event-driven approach: a perfect match for cloud functions
But, what happens when you have daemons listening to events? Again, it depends, but in general, this is the best match for serverless functions. With services like Google Cloud Run, you can relate messages in queues with functions, so as soon as you fire an event, a function is run. But the rest of the time the function is down, so you are not paying.
If the amount of events you listen to is not constant -so you can have the functions down like 2/3 part of the day- then you can save money and serverless can make sense for you.
And what about crons?
Is event-driven, but driven by time. Is a very good use case because traditionally you need to have resources provisioned to run crons when the time arrives. With serverless functions, the system just runs the function when needed and that's it. But be aware of crons that are running most of the day -minute-based ones, with long runs-, because, again, they can be more expensive than the traditional options.
What about app builders like Google Cloud App Engine?
They are more expensive than regular virtual machines, but you need to consider the costs of maintaining those machines. If you have a dedicated infrastructure team, probably these services don't worth it. If not, maybe you can give them an opportunity.
Conclusion
Costs are important when we scale. For companies paying 3 digits, paying three times more is just a big thing. Serverless is not a silver bullet and, in my opinion, is not that much of an innovation. We've had managed services for quite a long. For me the difference now is that they scale much better these days so, depending on your time, you can partially consider it for your microservices architecture.