Only 1% Need Microservices
--
$2b annual revenue.
That’s the scale at which companies studied had good reasons for Microservices architecture.
And before that?
A Monolith architecture evolving to a Modular Monolith, Service-based, and only then to Macroservices, Miniservices, Microservices make the job.
Why is that?
The solution with minimal efforts must be the preferred choice to provide the capability to adapt and grow the business.
What is Microservices Architecture?
A Microservices architecture is like the grain of sands in the desert, tiny but all together making something much bigger.
The key characteristics of Microservices are to be:
- Small and focused
- Performing narrow functions
- Manipulating only the data it needs
- Collaborating over service layers
- Usually reactive
- With data decoupled to scale.
And if done well, they have a fully automated provisioning process, are cloud-native, and with a good decoupling at various layers.
But they have trade-offs:
- Business flows are harder to map
- Services collaboration is hard
- Data states is difficult to reconcile
- Integration is much more complex
- Automation is more costly
- Complexity is harder to contain
- Observability is a challenge.
Reducing these trade-offs require an incremental approach to make things smaller while dealing with the additional complexity of distribution.
And for most of us, the characteristics of Microservices are not needed while companies are still making less than $2b of annual revenues.
How does architecture help the business?
Many organizations consider a move to a Microservices architecture rushing too quickly into the band-wagon of the latest trends.
