What is a “Microservice” and why?
The answer depends on the perspective from which it is being looked at:
Business & Project Management
Arguably this is the one that matters to most developers and IT people because building a microservice which fits the bill in the context of business and project management is what keeps us gainfully employed:
A microservice is a single-purpose piece of code which keeps on running and working correctly if the rest of the world is switched off.
From a project management perspective, the value of a microservice is that it can be delivered and keeps operating without direct dependencies on other systems. For example, because it has it’s own data store and does not make any calls to external APIs in order to get information it needs to function, it does not care if a shared database is up or down or if it can access an API. This dramatically cuts down coordination overhead with other teams because the team which owns the service can meet its objectives a lot easier without being blocked by other dependencies. QA effort is much reduced as well because a service which is entirely self-contained can’t be broken by side effects from other code which (e.g.) updates the same shared database and vice versa. In terms of food & drink, the reason for creating a microservice is that it’s handy to know that your coffee grinder will continue to operate no matter if the toaster is plugged in or not.
For the business, a correctly implemented microservice architecture means better options for productization:
- If you sell widgets online and build an invoicing service, it will be possible to offer invoicing for any other products or services, not just widgets.
- Stand-alone microservices are much more versatile when entering new markets. Your microwave oven will be completely independent from the dishwasher. Although originally intended for use in houses it will work just fine on yachts and spacecraft whether they happen to come with a dishwasher or not.
A microservice is a state machine. Its state represents a transactional boundary.
Imagine a traffic light:
The color it can change to depends on its current state, i.e. the color it currently has: If “currentColor=green”, a “Switch to next color” command can only work correctly (… by transitioning the state to “currentColor=amber” …) if no one else is switching the light to the next color while the “Switch to next color” command is being processed.
Because of this, any “microservice” which doesn’t represent a transactional boundary would be prone to side effects from other components of the system and would therefore no longer fit the business- and management rationale for building microservices.
Any single purpose piece of code that can be treated as a black box where the only way to communicate with it is via its API could be seen as (… turned into? … deployed as? …) a “microservice”: When the microservice evaluates business rules, the only sources of information available to make decisions are what was provided in previous API calls and by the parameters of the current API call.
Example of a microservice in an event sourcing or event collaboration based architecture. Publish-subscribe is an attractive solution for coordinating information flow between services because it leads to looser coupling than other alternatives.
The (infamous?) Bezos memo basically spells it out, for entire teams as well as “microservices” of any size. For (likely) reasons why see above, “Business & Project Management”.
Do not read the central heating thermostat setting to regulate the temperature of your freezer.
Networking & Infrastructure
A microservice is a set components (e.g. containers, logical or physical database, etc.) which provides a specific piece of business functionality. It can be created, destroyed, scaled and monitored as a unit. It continues to operate correctly even if all other services are down.
A good litmus test for the quality of a microservice implementation and infrastructure design is whether it’s possible to monitor, alert and scale based on business impact instead of technical criteria: “Payment processing is down (… but order fulfilment continues to operate normally)”.
What does “Operating Normally” mean?
If payment processing is down, how can things be “operating normally”?
Operating normally means no errors and no faulty decision making due to incorrect data. This can be achieved via eventual consistency. For example, fulfilment of an order is triggered by a PaymentProcessed event. None of these can occur if payment processing is down, so fulfilment will complete orders for which payment processing happened prior to the outage, but no further ones. When payment processing is back online, the fulfilment service will start receiving PaymentProcessed events for missed orders and will gradually catch up. From a UX perspective, this means that the business has options for designing apps which gracefully degrade when failures occur: Instead of a full-on outage, features handled by unaffected microservices can remain available to users.
A “microservice” is no different from many of the components which make up the complex machinery which surrounds us every day:
- Minimal dependency on other machinery (“It needs 12V from the car battery and a connection to an antenna.”)
- A clearly defined API as the only way to interact with it (“The only way to adjust the volume is with that knob.”)
The reason why it’s done like this in more mature industries: It makes division of labour easier, machines are easier to understand and can be built faster and with less errors.