A microservice is an independently deployable component of bounded scope that supports interoperability through message-based communication.
The focus is on building applications that balance speed and safety at scale, primarily through replaceability.
From the outside, a single microservice is treated as a black box.
It hosts business functionality on one or more network endpoints(for example, a queue or a REST API), over whatever protocols are most appropriate. Consumers, whether they’re other microservices or other sorts of programs, access this functionality via these networked endpoints.
This means microservice architectures avoid the use of shared databases in most circumstances; instead, each microservice encapsulates its own database where required.
Microservices embrace the concept of information hiding. Information hiding means hiding as much information as possible inside a component and exposing as little as possible via external interfaces. This allows for clear separation between what can change easily and what is more difficult to change.
A microservice design model comprised of five parts: Service, Solution, Process and Tools, Organization, and Culture.
A framework for microservice system designs:
-
Antifragility
Netflix works to strengthen their internal systems so that they can withstand unexpected problems.
Their Simian Army set of tools, which “enforce architectural principles, induce various kinds of failures, and test our ability to survive them”.
-
Immutability
The principle of immutability is used at Netflix to assert that auto-scaled groups of service instances are stateless and identical, which enables Netflix’s system to “scale horizontally.”
-
Separation of Concerns(SoC)
Each team owns a group of services. They own building, operating, and evolving those services, and present a stable agreed interface and service level agreement to the consumers of those services.
So just how micro should a microservice be?
Instead of trying to find some quantity to measure, we find most companies focus on a quality of each microservice—the use case or context in which the component will be used.
There are many ways to decompose a large system into smaller subsystems. In one case we may be tempted to decompose a system based on implementation technology. Alternatively, we can divide a large system based on team geography.
We may also apply **domain-driven design **to model services around business domains.
Microservice components only become valuable when they can communicate with other components in the system. They each have an interface or API. Just as we need to achieve a high level of separation, independence, and modularity of our code we need to make sure that our APIs, the component interfaces, are also loosely coupled.
Two practices in crafting APIs
The notion of messaging as a way to share information between components dates back to the initial ideas about how **object-oriented **programming would work.
For example, Netflix relies on message formats like Avro, Protobuf, and Thrift over TCP/IP for communicating internally and JSON over HTTP for communicating to external consumers (e.g., mobile phones, browsers, etc.).
That takes the notion of message-oriented to the next level.
The messages passed between components contain more than just data. The messages also contain descriptions of possible actions, for example, links.
Amazon’s API Gateway support responses in the Hypertext Application Language (HAL) format, which defines hypermedia such as links to external resources within JSON or XML code.