In this post, I will introduce Serverless architecture and the application of it in out FitMi Backend.
Traditionally, most of the dynamic website uses a 3-tier client-oriented system with server-side logic, like what we have learnt in CS3216 Assignment 3:
(image credit: CS3216.com)
For the assignments, we are in charge of implementing our client logic, server business logic, and the connection to a backend database. The server will be up-and-running all the time as it should be able to handle any client request, at any time, at any where. It also means you, a humble backend developer, may also need to be in charge of everything related to your server: domain hosting, maintaining, error handling, process management, scalability and performance tuning, etc. “I am a backend developer!”, you argued, “why should I take care of the server?”. Then your teammates would inform you, “server is a part of backend, so shut up and get it done or else our front end will be blocked by you!”. You are upset, but you have to Google around, ask on Stackoverflow, and even spend a night to make sure your server is running normally, and be ready to handle all sorts of weird server issue during the development (given that you are unfamiliar about an Linux server).
This is a problem. Developers write code that implements business logic, but now, they also need to handle those infrastructure things as well.
With PaaS (Platform as a service), we no longer need to buy expensive infrastructure to support our system, and we can only focus on the system development. With container technology like Docker, we solve the problem of environment dependency of a system, a.k.a “it does work on my machine!”. And recently, the concept of Serverless becomes more and more popular, which aims to solves the above-mentioned issue to free developers from server management issue and purely focus on code.
The term ‘Serverless’ does not mean that there is no server in the system, but it does reflect the idea that server is of an less important role in the development of application. Many definition exist for Serverless, but I quoted the one from Mike Roberts:
“some amount of server-side logic is still written by the application developer, but unlike traditional architectures, is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party”
Firstly, it is stateless. Secondly, it is even-triggered so it is not always online. Thirdly, you implement your logic and deploy your code to a 3rd party service, and they will take a good care of the reset of it.
With Serverless, the development focus would be on a single function or module rather than a service with a complex structure. In fact, if we calm down and think about it, many backend logics we implemented are indeed in the form of a function. For example, register and login, could be done in one function; a RESTful API, is just a set of individual functions; a normal API backend, is actually just a set of modules containing different functions, isn’t it.
AWS Lambda is such serverless service. You upload your functions to Lambda, and when it gets triggered, AWS will manage all compute resources for you, like CPU, memory and disk spaces. You could implement your RESTful API with Lambda by triggering it with AWS’s API Gateway HTTP events. You could run a scheduled job with Lambda by triggering it with a cron job. Apart from that, another reason why Lambda is popular is it is much cheaper than a EC2 instance. Lambda is billed based on number of invocation per month, and it is perfect for hosting services that is used on-demand than wasting it on a bill-by-hour EC2 instance.
In FitMi, since we implement our own hot-update system, we don’t need to go through App Store every time a new set of skills or actions is release. In this process, a most used API call is to check if the local resources are up-to-date with the server resources. This API will be call every time the user launch the FitMi app. The implementation is just a single function to compare the client provided timestamp with the latest resource update time. If an update is needed for the client, return it the link to the latest resource file stored in AWS S3 storage. We expect this API to have high traffic, but it’s not necessary to keep it running 24x7 as it could be just available on-demand. Therefore, we decide to give Lambda a try. We use a framework called Serverless to simplify our deployment and configuration process. The result is quite satisfying. The code we deployed works well. We could also deploy different stage of the function like production, staging, testing by just changing a config parameter, which is not so easy to achieve with traditional backend application. In addition, we don’t need to worry about scalability as AWS handles it well for us, which is pretty useful for hosting an high-traffic API. A detailed monitoring system is also provided in Lambda console to help use analyze the API usage. These are benefits what we can’t easily receive if hosting it on our own server.
But Serverless may not always be suitable for every kind of applications. For instance, long-running application may not be suitable for it, such as web crawlers (AWS has a 5-minute runtime limit). Also, real-time application may not be suitable as well because, for example, all Lambda functions are actually loaded into a compute container every time it gets triggered, so it will have some extra startup latency before it actually get executed. Furthermore, once you use an AWS service, it means you have to use other AWS service for gateway, storage, monitoring… In other word, over-depending on Serverless may lock you in a service provider.
As a conclusion, so far, our experience with Serverless application is quite good. Even though FitMi still has its own API running on a separate VPS for handling user management, we believe it is worth a try to migrating our whole backend with Lambda when the semester ends. I believe Serverless would be a good helper for developers as it can save a lot of time and efforts for production-ready services. I would like to give it more try in my future work to appreciate the beauty of it.