Microservices are dead!! Serverless is for some time, the new hype in the infrastructure world.
One of the main advantages of a Serverless Architecture is that it frees developers from having to worry about server maintenance, scalability, etc, as these will be handled automatically by the Serverless platform provider, so they can focus entirely on building great products.
This is great, mostly for single devs and small teams as server management, even at a small scale, can become a complex and time-consuming task.
One particular type of Serverless, and perhaps the most popular one, to the point it´s often mixed up with the concept itself, is Functions as Service (FaaS), also known as lambdas, due to AWS Lambda, which is one of the most popular providers of this technology.
The main idea behind lambdas is that you build small independent functions, each one responsible for a small part of your application.
Considering a traditional REST API, you can imagine that any Controller Action would be a separate function.
So now, instead of having 50 Microservices, you have 1000 functions! ;)
It´s true that with a FaaS platform, you won´t need to worry about managing the servers, scalability, etc that would take a lot of effort to do it right, in a big Microservices Architecture.
But you still have to deal with all the coordination between the functions.
You will also have extra complexity for devs to develop and test locally.
And because each provider implements its FaaS platform differently, the lock-in is very high.
Besides, the application will have to be designed in a specific way, tied, to a specific deployment style, so you really can´t move back from a full FaaS architecture to another kind of architecture that easily.
The idea of this article is not against Lambdas. There are lots of great use cases for them, like Event-driven applications, very specific tasks like Image Processing, Sending emails, and even as a small backend for static sites.
What I would like you to remember from this article, is that Lambda´s != Serverless and there is Serverless beyond Lambdas!
I have seen devs, trying to squeeze existing applications into Lambdas, like it´s the only way to deploy applications.
Or people creating issues on Open Source projects like Strapi, asking to make it run on Lambda. Or discussing ways to run Laravel on Lambda, or Rails on Lambda.
I understand the appeal. no server maintenance, almost zero cost for small/medium size projects. But we don´t need to be constrained by FaaS limitations to enjoy the benefits of Serverless. There are alternatives.
One great example is Google Cloud Run.
Google cloud Run fits perfectly my vision of Serverless.
You just need to have a Docker image and you can deploy it with a single command:
gcloud run deploy --image "myimage" --platform managed
No need to change the way you build applications. No limitations on technology. If it can be containerized you can deploy it on Cloud Run.
With Cloud Run, you get all the main selling points of serverless:
- No need to worry about server maintenance.
- Automatic Autoscaling (including scaling to zero, when the application is not in use)
- Pay only for what you use.
Without the limitations of Lambdas.
I think we need more platforms like Cloud Run, with I feel like an evolution of more traditional PaaS like Heroku.
Cloud Run, is build on top of Knative. which is an open-source Kubernetes-based platform to deploy and manage modern serverless workloads, so others could use the same foundations.
I know AWS has Fargate, which seems to require some more configuration but should be the closest equivalent of Cloud Run in AWS.
I am also looking forward to what comes out from the DigitalOcean/Nanobox integration.
Conclusion
Serverless is a great concept and I believe will keep maturing in the next years.
It won´t replace traditional servers for more complex applications or when more control is needed.
But, for smaller teams and single developers, who want to build a product without having concerns about scalability and server maintenance and with the extra benefit of only Pay for what is used, is perfect.
It´s important to understand that Serverless is not just FaaS. Platforms like Google Cloud Run are a great example and might be a much simpler alternative for deploying your applications instead of trying to squeeze them into a Lambda.
Top comments (8)
I think Serverless is not FAAS and it can encompass leveraging host of different managed services to build applications on top of that . Some of the use cases here. Serverless at this point of time for me is about API Gateway , Lambda and other Managed services like Pub- Sub provided by cloud providers like AWS and others that I can leverage to build without managing infrastructure.
jeremydaly.com/making-the-case-for...
Yes I agree. I didn't talk about other managed services besides the deployment of the application, but they are of course a very important part on the Serverless world. Pub Sub, Managed Databases etc.
IMHO container runtime services are underrated. I personally use ECS, and compare to Lambdas it is a breeze to configure.
Functions are great too, but there is very limited amount of thing you can do, without completely redesigning an average app.
Completely agree.
We need more platforms offerrimg that, instead of just focus on functions.
So what is the best approach for small/medium companies in terms of development and having a stable test environment?
Going with a monolith (if you don't have a ton of users/functionality you are going to be fine with it) and maybe with a couple of Lambdas?
Seems to me like every systems development veteran out there recommends the loosely coupled monolith approach for 90% of use cases (the other 10% is for cases where you know from the start that your system will serve possibly hundreds of thousands of users concurrently, or more).
There's nothing wrong with monoliths if they are done right (DDD, SOLID, CQRS (which has nothing to do with event-based architectures), Patterns, etc.).
If the monolith is loosely coupled (CQRS, Mediator pattern, Interfaces) and generally well tested, then when it's REALLY NEEDED, for scaling and cost reduction reasons, refactoring to another architecture SHOULD BE EASY and should be possible to do in gradual steps (one endpoint/resource/feature at a time), thanks to the loose coupling (outside-in dependency injection, and other great patterns).
Software, if it continues to enjoy constant use, should evolve, and refactoring is how that happens. So it's not a bad thing if you gradually start to evolve your software application to another architecture style, if that is made possible by having designed the system with this thought in mind from the start.
So it really seems to me like knowing good software design patterns, especially those pertaining to loose coupling and CQRS, is more important than what software architecture style you're going to start with.
Really good article. Serverless with lambda and API gateway taken into consideration is a perfect fit for microservices implementation. Based on my understanding almost 75%-80% of the current enterprise use cases can be easily refactored or moved into AWS lambda based serverless implementation. Recently I was going through a product called Kumologica (kumologica.com) which is focused on building integration and microservices on a low code approach over AWS lambda and they are taking usage of lambda beyond FAAS.
I agree Google Cloud Run is an awesome technology which mitigates many issues from Lambda.