Maksim Kabakou - Fotolia
What are the most essential microservice design principles?
Don't hinder a microservices architecture because of a faulty design. Keep these five design principles in mind to build the proper components for your microservices architecture.
A microservices architecture requires a carefully constructed group of individual components that work together with efficiency. Modular components depend on each other to build a larger application.
But when a developer boils down microservices to its most singular part, a microservice needs to be built to function in only the most essential way for the application's overall benefit.
The five essential microservice design principles are:
- It has a single concern.
- It's discrete.
- It carries its own data.
- It's transportable.
- It's ephemeral.
Dedicate the entry points into a microservice to a single purpose. For example, let's say a car trading organization wants to build an application that connects prospective traders with each other and the organization itself. One microservice component will deal exclusively with exchanging cars either by buying, selling or trading them. It has no other purpose.
Car payments are the focal point for another component in the overall design. While the two microservices may be used in conjunction with one another, the services aren't blended. Each element handles something different and can stand alone.
Another term for this microservice design principle is well encapsulated. All logic and data that a microservice requires to do its work are internal and isolated from other microservice components.
While a microservice will most likely require its own configuration for the internals to operate properly, this configuration shouldn't interfere with the configuration of another microservice. This microservice design principle is particularly important when developers need to scale up or down to accommodate load demands.
Carries its own data
Not only should a microservice carry its own data, but its data should also remain independent of all other microservice components. In some cases, a microservice will ideally have its own database. In others, the microservice will share a database with others, but each microservice will have its own tables within the database.
Typically, developers use database sharing to reduce costs. However, this violates the spirit of the microservice design principle.
Developers often must consider both data independence and redundancy in their designs. While developers often support the principle that each microservice carries its own data can result in data duplication at the application level, they have also come to accept data redundancy as part of their microservice design pattern.
An easy way to understand accommodating data duplication among various microservices is to consider customer data stored at various online retailers. For example, a given user might be registered with Amazon and Walmart. Both websites will have a duplicate of that user's data, but each website is discrete and well encapsulated. Thus, neither website knows about the user's existence on the other website unless it's granted permission to that website's data.
When a microservice is transportable, it means that it can be "packaged up" into a deployment unit -- such as a container image or a serverless function -- and deployed at any time to a given target via a CI/CD process.
For example, a developer can deploy a transportable microservice to a cloud provider such as Google Cloud at one moment. However, if a situation arises where the microservice needs to be deployed to a different provider, it shouldn't take more than a little effort for a developer to transport the microservice to AWS.
An ephemeral microservice means that it can be destroyed at any time and then resurrected to its last known state immediately.
The ephemeral nature of a container has implications not only for how to manage application state when a given container could go offline at any moment, but also has implications on how to manage active threads and ensure thread-based dependencies don't exist in the code.
These five microservice design principles should be at the heart of any architecture discussions. Consider each element carefully to create an architecture that works efficiently for your application.
Dig Deeper on Software development best practices and processes
Related Q&A from Bob Reselman
Kubectl apply vs. create: What's the difference?
The Kubernetes command-line tool, kubectl lets you control your Kubernetes clusters. But two of its operations -- apply and create -- can often be ... Continue Reading
Vagrant vs. Docker: How these cloud-native tools differ
Both Docker and Vagrant are important parts of a cloud-native stack, but they have very different roles when it comes to supporting containers and ... Continue Reading
Is a Docker or Kubernetes certification worth it?
Some DevOps professionals shun industry certifications. But in the cloud-native world, Docker and Kubernetes certifications make prospective job ... Continue Reading