5 Critical points to consider before going Serverless
Let’s be honest, Serverless architecture is everywhere right now thanks to AWS Lambda, and other service providers as well. However, being boldly out there doesn’t mean that you need it or you should just go for it without considering some critical points I’ve learned the hard way.
Before diving into more details I should mention that Serverless is not Cloud hosting. The latter (Cloud hosting) is just like any other hosting service with the fact that servers are in the Cloud. This means that your server is always running and available for you. While Serverless means that your Server is only alive when you receive a request, and it’s going to be terminated after sending a response or after some period of time depending on the Service provider you are using.
With that cleared, let’s talk about some critical points to consider before going Serverless.
1- Microservices
There might be a connection between the rise of Microservices and Serverless Architecture, which is still valid until today.
If you want to use Serverless, make sure you are using it for small applications, a microservice that does a certain task. You can wrap your Application inside a Lambda function and run it without any issues, but that means it needs more computing minutes, memory resources and there will be a lag in responding, which makes it more expensive in some cases.
2- Cold Starts
Using the term expensive in IT is not related to finance only, performance and computing resources are in the scope as well.
In Serverless Architecture there is something known as Cold Start, in which the service provider create an instance for your Application once it receives a request. So if you your application needs to connect to a remote Database, open a Socket connection and ping some other 3rd party services when starting for the first time, then you already know it, the request will take some time before being handled.
This fact shows why Serverless is better with Microservice which boots in a couple of microseconds, do the job and return a response without the need to initiate a huge amount of other services as well.
3- Production Ready
To give some context, my experience with Serverless was with a Platform consisted of a Core built with Nodejs in addition to Web & Mobile Clients. We took the decision to go Serverless quickly without even having proper tests in place.
Having a Dev environment to test the harmony of these applications together is something and having a Production environment is totally another thing. You should consider rendering and building your product for Production to test it before going Serverless, this will save a lot of your time when you face issues on Serverless, because you know that your Apps are working without any issues.
In my experience, Apps were good in Dev, in our local machines, and then we rushed to deploy Production on Serverless, and that costed us a lot of debugging time because we were lost between fixing Serverless issues and bugs in Our Apps, Rookie mistakes I know.
4- It’s not there to Stay!
Remember, an instance of your application will be alive as long as the request is alive, once it’s fulfilled, that instance will have some extra minutes before being terminated.
With that being said, if you have any Cron jobs, or a Module that requires an always running server, you should find alternatives or workarounds before going Serverless.
For Cron jobs, there is something called Schedulers in almost all Service providers, I didn’t use them, but I guess you need to have another Microservices to be triggered.
In my case I was using Agenda for Nodejs to schedule some tasks like sending mails using AWS SES. Well you have already guessed it, it was not working as expected because the App was not always alive.
5- Monitoring
AWS provides what is known as CloudWatch, a service to monitor your Apps, check logs & create alerts for some events. But if you don’t have a good error handling Middlewares this will be useless.
Make sure that you have a good monitoring for your App which notifies you when something happens regardless of the hosting architecture. From there, any other options such as CloudWatch will be an extra layer for a better debugging and health checking.
There are some solutions for the aforementioned points which didn’t work in my case, but that doesn’t mean it’s not effective. Also worth to be mentioned, understanding Serverless Architecture and the restrictions which vary from one provider to another is a good start. Don’t just go for it because you saw someone did, or because you were told so, Apps have different use cases.