To celebrate and kick-off the release of my new book Production-Ready Microservices, I'll be writing up a bunch of posts about microservices, microservice architecture, microservice standardization, and anything randomly or tangentially related that pops into my head. For this first post in the series, we'll be looking at the four-layer model of microservice architecture.
Introduction
Many of the frustrations and confusions about microservice architecture come from the lack of clarity around microservice architecture. For example, some people think that containerizing their application means that they now have microservices - which is not true: putting your application in Docker containers does not mean you are using microservice architecture. Others think that each microservice needs to be treated as a completely separate standalone application with its very own dedicated and unique infrastructure - which is also not true (as we'll see in a moment). Others get frustrated because it's not really clear what microservices are.
Whenever we run into confusions and frustrations like these in computer science and software engineering, it usually means that there isn't any clarity around whatever system we are working with. The way to achieve clarity in most cases is to come up with an abstraction of the system that fully captures all of the important structures and all the important things about the system without bogging us down in details and specific implementations. In an effort to create some clarity around microservice architecture, we can use an abstraction that I think works pretty well: we can split microservice architecture into four layers.
The four-layer model of microservice architecture. Image from page 12 of Production-Ready Microservices.
Layer 1: The Hardware Layer
At the very bottom of the microservice ecosystem lies the hardware layer, which is comprised of the actual machines that run everything in the layers above. These machines can be your own machines in your own datacenters or they can be (virtual machines running on) machines owned by cloud providers (like AWS's EC2, GCP, or Azure). In this layer we also find databases - both dedicated databases and shared databases. We also find the operating system, which in microservice architecture is usually some variant of Linux, like Debian or Ubuntu. On top of the machines and the operating systems we find all of the resource isolation and abstraction systems, like Docker and Mesos. On top of that, we have host-level monitoring as well as host-level logging, which is monitoring and logging that is done on these machines in the hardware layer (here "host" refers to the machine or virtual machine). Lastly we have configuration management tools (like Puppet or Ansible), which make sure that every host has the right applications running on it and the correct configurations installed.
Layer 2: The Communication Layer
On top of the hardware layer we find the communication layer. This layer is special and is sort of confusing, because it touches every other layer in the ecosystem. It's the layer that contains everything related to communication between applications, systems, and services. Here we find the network and DNS. This layer also contains any remote procedure calls (RPCs) or messaging that is used for communication between the microservices. All of the microservices' API endpoints can also be thought as being part of the communication layer, because in order for the microservices to communicate with one another, they need to both communicate over using the same protocol (e.g., HTTP) and send data in the same format (e.g., JSON). Traffic routing and distribution also belongs in this layer, which means that the communication layer also contains service discovery, service registry, and load balancing.
Layer 3: The Application Platform
Layer 3 of the microservice ecosystem is where all of the internal tools and systems and services and platforms that the microservices run on live. All of the things in this layer are built to be centralized, system-wide tools and services that the microservice developers can use. A good application platform is one that enables microservice development teams to only have to think about the microservice(s) they are working on, not anything below it. This layer contains good self-service internal development tools, which will be specific to the company's needs. It will also contain a standardized development process, which comes with (at the very least) a good version control system, a good collaboration tool (like github or phabricator), and a stable development environment. You'll also find all of the (hopefully automated) test, build, package, and release tooling in this layer. The deployment pipeline - the way which new code is deployed to servers - is also here. Finally, all microservice-level logging and monitoring can also be found in the application platform layer (the reason it's here and not in Layer 4 is that, in microservice architecture, logging and monitoring should be centralized and standardized, independent of the individual microservices).
Layer 4: The Microservice Layer
At the very top of the ecosystem is the microservice layer. This layer has all of the microservices, and everything specific to them (like configurations). This layer is almost completely independent of the layers below, and this is the only layer that almost all microservice development teams work with and interact with - everything else is abstracted away and lives in the layers below.
Summary of the Four Layers of Microservice Architecture
To summarize, here are the four layers of the microservice ecosystem and all of the things that they contain:
Layer 1: The Hardware Layer
- Configuration management tools
- Databases
- Servers
- Host-level logging and monitoring
- Operating Systems
- Resource isolation
- Resource abstraction
Layer 2: The Communication Layer
- DNS
- Endpoints
- Load balancing
- Messaging
- Network
- Remote procedure calls
- Service discovery
- Service registry
Layer 3: The Application Platform
- Deployment pipeline
- Development environment
- Microservice-level logging and monitoring
- Self-service internal development tools
- Test, package, build, and release tools
Layer 4: The Microservice Layer
- All microservice-specific configurations
- The microservices
Want to know more? I wrote a whole book about this stuff. It's called Production-Ready Microservices. Check it out!