Original text in my blog: blog.zlb37.xyz/2018-04-20_…

There is currently very little discussion of small projects. For most entrepreneurial teams, the initial project will not be too big, and the development speed and cost are usually lower than the development quality. In addition, the technical leaders of most entrepreneurial teams have the ability to solve specific problems quickly, but they do not have good architectural design ability. The maintainability of the whole project becomes worse and worse when the project is huge to a certain extent. When I joined my last company, I was faced with a typical unmaintainable project, and it took several times as long to modify any one part as to rewrite it. I chose to leave after knowing that the technical leader did not want to rewrite the whole project.

There are several thorny issues for startups:

  1. ** personnel quality is low. ** startup teams need to save money, so they often like to hire programmers, or even interns, below market rates. The quality of these personnel are intermingled, but generally speaking, code quality is worrying, normative do not understand, SAO operation is a lot of.
  2. ** High turnover of personnel. ** Entrepreneurial teams tend to have fast growth of employees. When the salary cannot keep up, employees are easy to quit, and even some leaders will quit. Leave behind code that no one else wants to maintain.
  3. ** Demand changes quickly. ** Not to mention the habit of product managers, even the boss has new ideas from time to time. For speed, or for developers to run errands,

These objective problems exist and are difficult to solve. As a technical leader of a small project, he/she needs to make use of these limited resources to complete various tasks with high quality as quickly as possible.

The last project I was in charge of was completely RESTFul, with each API URL corresponding to a Resource that called Service (third-party services) and Model (database operations). However, with the increase of the project, the number of resources is increasing. Up to now, our internal code-named “LSB” project background code has 153 resources. Although the function of each Resource is relatively simple, so many resources make the project more and more difficult to understand. Due to the repeated modification of some requirements, some resources have been changed beyond recognition.

The ability to scale horizontally in a RESTFul way is so strong, but scaling too much feels like a behemoth.

So we decided to split the project as a microservice.

The first emphasis of microservice architecture is that business systems need to be thoroughly componentized and servitized. The original single business system will be split into several small applications that can be independently developed, designed, operated and maintained. These small applications interact and integrate with each other through services. Each small application from the front, to the background, database access, database is completely independent of a set.

So, according to this standard, we can divide a company’s system into the following parts:

  • Personnel Management Services
  • Customer Management Services
  • Content publishing service

These three services have their own independent database, background programs and UI, among which the personnel management service stores the information, permissions and credentials of all employees of the company, and provides RESTFul interfaces for the other two services. The UI provided by the company allows the personnel department to manage employees and employees to change passwords themselves.

There are four basic operations for RESTFul operations: POST, DELETE, PUT, and GET. The design of RESTFul operations is not detailed here (you can see my article “REST – How to Abstract As a RESOURCE”).

  • Staff resources
    • Add: New employees
    • Delete: Delete employees
    • Modification: Modify employee information
    • Search: Find employees by conditions (open)
  • Employee rights
    • P: Authorization for employees
    • Delete: Unauthorize an employee
    • Check:
      • Query whether an employee has certain permissions (open)
      • Example Query the employee permission list
  • Access the resource
    • Check: View the permission list

The rBAC-like permission model is used here, so you can skip it if you don’t understand

There are only three resources per service, and if the company is hiring full-stack programmers, this is a one-man job, which is very easy to track (ugh).

After being divided into micro-services, it is very easy to develop a single micro-service. It is not difficult to deploy and develop the service according to the quantity even if the staff has limited ability. It’s also very easy to understand internally and maintain even when people change. And disassemble into this kind of degree, if there is really a change in demand, throw away the micro service to rewrite the cost is not very big. Microservice architecture better solves the three pain points in the development of small projects for start-up companies.

However, I feel that the business programmer in the future is no longer like a technical position, but like an assembly line worker, only above the requirements design sorted out, obedient to make good.