What Makes a Microservice?

Microservices were pioneered by Netflix over a decade ago. Fast forward ten years later and they are the preferred technology for scaling a software business to web scale. But what makes a microservice a microservice?

Microservices did not appear out of thin air. Like many concepts in software engineering, they are an evolution of concepts that preceded them. In the case of microservices, that concept was the good ol’ module.

Modules

A module is a software component that is self-contained and that can be plugged into a larger system. In essence, the larger system is a collection of modules fused together into a greater whole. A good analogy are hardware components put together to form a bigger machine.

Modules embody a couple of important engineering principles.

Information hiding is one of the most important principles in computer science. It states that the implementation of a module should be obscured behind an interface. The implementation of the module’s logic is internal and should be considered a black box. The module’s users should rely only on the interface which is the binding contract that the module commits to uphold.

State isolation means that a module is the sole owner of its data and that no other module is allowed to read it or alter it, except via the public interface. This is the first principle of information hiding, applied to the state of the module.

Modules are small and specialized in order to increase the appeal of their reusability. They encompass a set of related functions but do not attempt to be everything for everyone. Unrelated functions are better left to other modules.

In Java, Modules can be thought of as a class where the public functions and variables are the interface, the private functions are the internal implementation, and the private member variables are the state.

public class Module {
    private int internalState;
    public int exposedStateIsPartOfTheInterface;
    public void exposedFunctionsArePartOfTheInterface() {
    }
    private void implementationLogicIsNoneOfYourBusiness() {
    }
}

Microservices

Microservices differ from modules in their runtime properties: while modules are linked into one executable, microservices take a decentralized approach in order to be horizontally scalable to web scale. That necessitated that they introduce a few principles of their own.

Microservices are independently deployable, which is to say that it is possible to replace one microservice with another without having to shut down the entire system. The new version must of course uphold the commitment of the public interface of the old version, in accordance with the principle of information hiding.

Microservices are independently scalable, which means it is possible to deploy multiple replicas of a microservice and have the workload distributed among them. Scaling the number of replicas of one microservice should not necessitate doing the same for other microservice. As with deployability, scaling is possible while the system is kept running.

Runtime isolation shields one microservice from the failures of another. A common practice is to run each microservice in its own process so that if one crashes, it doesn’t bring other microservices down with it.

Microservices must be able to interoperate while upholding the aforementioned principles. The requirement to scale horizontally mandates that this communication is done over a network rather than in-process. This is perhaps the most impactful difference between microservices and modules because it is the source of most of the challenges with microservices.

Because communication is done over the network, all input arguments and return values are passed by value, rather than by reference. This is a strong constraint that guarantees state isolation and minimizes unwanted side effects.

In the next editions we’ll explore how these principles translate to both benefits and challenges when using microservices.