Microservice Architecture

Previously, we discussed Monolithic Architecture, which effectively means building an application as a single (coherent) unit that is deployed and developed as a whole. Microservice Architecture, on the other hand, refers to building an application as a set of services that can each be developed and deployed separately and that communicate with each others using some sort of APIs.

Perhaps one of the more well known moves towards using microservice architectures was conducted by Amazon in 2002, where (at least by hearsay), Jeff Bezos sent the following mandate to developers in the company.

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

Microservice architectures address some of the issues of monolithic architectures. Namely, when an application is composed of smaller independent services that can communicate with each others, developing and maintaining a single service can become easier as the codebase likely remains manageable. Similarly, when a developer works on functionality provided by a specific service, one can only deploy that service without the need to deploy the whole application. In addition, when a new service is created, one does not need to use the same technology stack that the previously created services use; it is also easier to change the technology stack of, including completely rewrite, smaller services than it would be for monolithic architectures.

On the other hand, building an application out of microservices adds a premium to the cost of developing the application. Using microservices demands, at least at first, additional overhead for designing how the services should communicate, how the services should be deployed, how they should be tested, how faults should be identified and so on.

As a concrete case, this course platform has been developed using a microservice architecture. There are over ten services that each are responsible for a small part of the platform. These include (1) a service for managing users and authentication, (2) a service responsible for retrieving and receiving submitted assignments, (3) a service responsible for grading (some of the) submitted assignments, (4) a service responsible for managing help requests, (5) a service responsible for managing course points, (6) a service (or a few) responsible for managing the embedded (DartPad) editor that provides an easy starting point for HTML and CSS editing, (7) a service responsible for serving the materials, and so on. The main orchestration responsibility for directing the requests made by the browser to the correct service is given to a reverse proxy service, which is effectively a thin redirection layer that helps maintaining the illusion that the course platform is a single unit.

Most of the services in the course platform communicate with only a few other services. For example, the service responsible for help requests communicates with the user management service to verify that the user who is asking for help has authenticated. Similarly, the service responsible for receiving submitted assignments uses the user management service to verify the user and then directs assignments to the service responsible for grading of assignments; this is followed by a communication of the grading results to the service responsible for managing course points. Overall, only one of the services is used by almost all other services -- the user management service that is used for verifying that the user has been authenticated. Bearing this in mind, it is perhaps not surprising that there exists quite a few commercial user management services (e.g. auth0, Clerk, FusionAuth, okta, ...) that one could use as a part of their application.

How would one then start developing a microservice application? The first answer likely is to really consider if a microservice application is needed, and consider whether it would be meaningful to approach the application first as a monolith.

The second answer would be to start by carving out logical components of a monolithic application, and work on making (one) of them a separate application. This separate application would then provide an API that the remaining application could use. Good logical components to carve out include such that perform slowly and influence the performance of the rest of the application, ones that have very few dependencies, and ones that are used by many users. For further discussion see e.g. How to break a Monolith into Microservices.