Read on Twitter
Microservices are distinct from Services, although they are commonly confused.
Services, as an approach to software design, have been around for many decades. Service Oriented design was popular in the 1990s and early 2000s.
2/14
Services, as an approach to software design, have been around for many decades. Service Oriented design was popular in the 1990s and early 2000s.
2/14
The big difference is not the size, despite the name, it is the independence of the service from other services.
Most definitions of Microservices include:
Independently Deployable
Loosely coupled
Organised around business capabilities
Owned by a small team
3/14
Most definitions of Microservices include:
Independently Deployable
Loosely coupled
Organised around business capabilities
Owned by a small team
3/14
Notice how this definition says nothing about technology and completely focusses on something else, the degree to which these things are independent of one another, that is we can change a Microservice, without affecting other code that interacts with that service.
4/14
4/14
If you think about it, all of these properties are focused on that.
They are "Owned by a small team" so that team can make progress without collaborating with others.
5/14
They are "Owned by a small team" so that team can make progress without collaborating with others.
5/14
They are "Organised around business capabilities" as a means of decoupling them naturally. We can change the SalesTax service independently of changing the CustomerRegistration service.
6/14
6/14
They are "Loosely coupled" so that we can make changes to one service without forcing changes on other services.
7/14
7/14
...and all of these things are mechanisms to allow us to achieve the last.
Microservices are "independently deployable"
This allows each small team to make progress independently of others, and when they have made a change, they can release it without affecting others.
8/14
Microservices are "independently deployable"
This allows each small team to make progress independently of others, and when they have made a change, they can release it without affecting others.
8/14
Microservices are primarily designed to be an "organisational scalability" tool.
They free large orgs to make progress in many small teams, with each team working separately from the others.
9/14
They free large orgs to make progress in many small teams, with each team working separately from the others.
9/14
So if you build your microservice, but before you release it into production, you need to test it with the current version of all the other services, it *isn't a microservice* it's something else.
10/14
10/14
The whole idea here is to prevent this coordinated, in-step, process of change, where teams can only make progress in lock-step with other teams.
11/14
11/14
"Independently deployable" is hard, but that is the game.
12/14
12/14
If you can't deploy your uServices independently, then you probably have "Services", and your services, however they are stored in repos, or built, are part of a monolithic system, because they need to be tested together before release.
13/14
13/14
Microservices are the most scalable way to build software, but if you don't need to scale, they are often a less efficient way to organise your work.
This video explains my thinking a bit further...
14/14
This video explains my thinking a bit further...
14/14
• • •
Missing some Tweet in this thread? You can try to
force a refresh
