-
Notifications
You must be signed in to change notification settings - Fork 0
Serverless
The Devtranet (formerly The Dynamics) application is supposed to be elastic with minimal manual effort. We are expecting thousands of users. But we don't have a good idea of how many concurrent users would be using the application at any point. Factors like marketing, events (Codetivate), etc can result in unexpected quantity of users on the application.
Instead of building the application as a monolithic server, we are implementing a serverless architecture. Serverless will allow us to deploy our application with minimal deployment configurations, while being highly elastic. The provider can spin up exactly as many containers are needed to fulfil the load on the application without manual intervention, and scale down to as few containers as needed when user load decreases.
We are using Vercel as our choice of deployment platform for the main application, because it supports both serverless functions for the backend, and server-side rendering of our client-side application through Next.js.
Serverless deployments are optimized for inconsistent or unexpected usage of applications. If at some point in the future we are able to predict our user load, we should migrate to a more controlled deployment approach.
Using Next.js allows us to keep almost all of the core business applications in the same project. Even though the application is split into server-rendered components and lambda functions, they can reuse a lot of the infrastructure logic.
This approach also requires an application design that is optimized for serverless deployment. The traditional monolithic design is forgiving to highly coupled designs (also called Big Ball of Mud) because it's deployed as a single unit. This is a highly unoptimized approach for serverless as each function invocation might require loading most, if not all, of the application code before the function can be executed. We need to properly split up the application code into microservices that are isolated and reuse only as much code as is needed.
We also need to optimize database connections. If each function is allowed to create a new database connection, we will end up with hundreds of ephemeral database connections. To solve this, we will need a database pooling solution.
Finally, logging and monitoring needs to be improved to have good insights into serverless deployments.