A Preliminary Guide to Serverless Practice for Simple Psychology

How to leverage the characteristics of Serverless without losing control.

Reason

Simple Psychology’s main system, based on Ruby on Rails, has been running for over four years. As the business grows, the limitations of the monolithic application become increasingly apparent. Even with containerization that has greatly improved its load capacity and simplified the deployment process, for developers, over time, the coupling within the system is inevitably becoming more and more severe, and the development experience is getting worse.

Against this background, we first tried the microservices architecture. The high cohesion of microservices can solve the problem of severe system coupling under the current business complexity well. However, if time goes on, some complex microservices may still evolve into a monolithic application with severe internal coupling.

So we looked further ahead and started to try Serverless.

Serverless, in simple terms, is an event-driven fully managed computing service. You just need to write the business code, and the rest is handed over to the service provider.

It sounds very simple, and it is indeed very easy to get started. But the problem lies in its simplicity, which leads to a lack of paradigms to refer to for complex business needs.

There are many mature frameworks available for monolithic applications, and most of these frameworks can also be used in microservices. But when it comes to Serverless, you will suddenly fall into a situation where there is no framework available. Although you can upload an MVC framework as a “super function” that can handle multiple requests, this will lead to difficulties in development and maintenance.

Serverless advocates that a function should only solve one problem, allowing developers to focus on specific business processes and links, without spending a lot of time getting familiar with the entire system and business for a small business iteration. However, as the number of functions increases, if there are no constraints, developers will definitely let go, leading to a lot of fragmented problems. Our solution is to establish a set of artificial constraints to make all functions easy to understand and develop and maintain.

The main goal of this mechanism is to allow developers to quickly understand and iterate business links and to easily expand new businesses. (Because the daily tasks of Simple Psychology are mainly to optimize various business links and try new businesses).

Practice Guide

This practice guide is just an internal attempt of Simple Psychology, for reference only, and welcome to discuss and improve.

Firstly, this practice guide is based on Tencent Cloud construction, and may not be suitable for other service providers. We mainly use the following services:

• Serverless Cloud Function SCF
• API Gateway

To solve the problem of function fragmentation, the core idea of practice is:

Abstract functions as business links triggered by events.

At the same time, based on domain-driven design, we abstract business links into commands, and all functions are divided into two categories: command processing functions and event response functions.

The process of command processing is as follows:

1. Event response function transforms the event into a specific command and stores it in the corresponding command queue;
2. The scheduling function (essentially a timed command response function) takes the command out of the queue according to the set rules;
3. The taken command is asynchronously distributed to the corresponding command processing function;
4. Command processing function completes the command.

Finally, we have made the following regulations on the naming of functions:

• Naming format: <TypeName>--<BusinessDomainName>--<ResourceName>--<CommandName>, a total of four levels;
• TypeName is all uppercase, the rest is all lowercase;
• In the production environment, there are the following types:
  • PE Command processing function
  • PC Timed command response function
  • PI Internal gateway command response function
  • PO External gateway command response function
  • PW Front-end gateway command response function
  • PD Back-end gateway command response function
• In the test environment, the first letter of the type is T, such as TE, TC, etc.;
• In the development environment, the first letter of the type is D, such as DE, DC, etc.;
• If the name consists of multiple words, they are connected with -, such as PE--user--user-account--create.

So, the actual work process for developers is as follows:

1. If you need to cooperate with the client, first create or modify the mock data of the API gateway in the development environment.
2. Create or modify the function in the test environment and complete the test acceptance.
3. Synchronize the code from the test environment to the production environment and complete the acceptance of the production environment.

Under this development model, a function is allowed to be modified by only one developer at the same time. Developers can decide to change one or several functions based on the complexity of the requirements.