In some previous articles, I was writing about the Azure Functions, which is the Microsoft Serverless solutions. After joining Microsoft, I got the chance to work on this great product for many business cases and I found it was really great 🥳
Recently, one of my Facebook friends asked me to write a blog post about what is Serverless architecture ? 🤔 what is for ? 🤔 and especially, what are the scenarios that are not suitable for Serverless ? 🤔
Maybe I had to write this post before starting the Azure Functions tutorials series. But, as we say “It’s never too late to set things right” 😁
Serverless computing is an architecture that aims to delegate the execution of a piece of code to the cloud, where necessary resources will be dynamically allocated. Dynamic allocation means always the pay-as-you-go model when we are hosting the code on a Public Cloud Provider.
The Serverless application is composed by functions triggered by some event like an HTTP Request, a Message (Kafka for example) or even a Scheduled event. That’s why, we refer to the serverless applications as “Functions as a Service” or “FaaS”.
my code will be running without a server ?
NO ! The naming for Serverless is just to say that you dont need to care about where the code will be running. You have just to write your code, based on the templates/practices guide provided by your cloud/serverless provider.
Generally speaking, the most of the cloud providers serverless platforms take as input the source code packaged with some dependencies in a JAR file.
So, you just you take care of implementing your business logic in the code and the cloud provider will be taking care of running, scaling and even for monitoring your Serverless Application.
When do I need to use serverless architecture ?
It’s good to start by asking this question. For sure, the serverless architecture is not the key solution for every project.
You should adopt serverless architecture for some (can be all) components of you application, in case:
- high latency application
- having specific heavy frequent solicited components unlike all the rest of the application components
- not permanent running application
- stateless applications
There are other cases that can fit into Serverless, like IoT and Big Data applications and batchs.
If you have this use cases, you can start thinking about Serverless Architectures. Making tests and PoCs will give you a better idea if your components can go to the Serverless world.
When I SHOULDN’T use serverless architecture ?
For sure, you shouldn’t adopt Serverless architecture if your application doesn’t satisfy the previously listed requirements, especially if:
- you expect to have a response with a somehow defined latency like real-time applications
- you have a permanent running application without IDLE time
- you have a very long executing processes
WHAT IS THE ADVANTAGES OF ADOPTING THE SERVERLESS ARCHITECTURE?
- Cost effective: the billing model is only pay-as-you-go 😁 you don’t need to pay for the IDLE time of your application.
- Highly scalable: serverless application are scalable automatically. When there is a high load, your application is highly available without any need for special clustering or any manual operations. 🤩
- Fast time to market: just time is consumed for writing code – no administration boilerplates 🥳
- Light responsibilities: you don’t care about runtime and maintenance of the environment. You just focus on implementing the business logic in the code.
Life is great when we are lazy 😁
- Easy monitoring: everything needed for monitoring and tracing the serverless application is provided by the vendor out of the box 😎
WHAT IS THE DRAWBACKS OF ADOPTING THE SERVERLESS ARCHITECTURE?
- THE COST OF THE FIRST CALL 😱🤯😭I personally consider that as huge drawback for the serverless. Serverless applications go always to the idle state (as by design they are made to run occasionally and not permanently). To bring them up from the idle state, when triggered, the application will take some time to start which cannot be afforded by some client needing low latency.
- You lose control of your application: you don’t administer you application as everything is managed 😤
- Complexity for development: developing and testing locally is no so evident – it’s very hard 🤯
- Cloud provider lock-in: your code is packaged based on your vendor templates – so no easy or evident portability 🥵
- Security risks: your vendor can have security flaws that will directly impact your components 😱
Serverless architecture is a very innovative paradigm in the software engineering ecosystem, which comes with a very wide variety of advantages, and certainly with drawbacks. The compatibility of this architecture with your application has no magic answer, you need to audit, test and try it to be sure that you can fit on. 🤔
I suggest that every developer give it a try and to gather its practices and skills. I am sure that the serverless will be a mandatory skill required in the market the same as the microservices architecture became nowadays. 😁