$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 function
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.
Independently from the technological architecture, businesses want to grow leveraging the paradigm of Quality at Speed software:
Deliver value to users
Fast for testing new ideas
Adaptable in short timeframes
Remain manageable
Support increasing traffic
Profitable.
From that list, the next stage is to identify how technology is a business limiting factor to clearly differentiate the problem from the possible solutions.
All solutions will usually require high-availability of critical features, more modularity to adapt better to more changes, and the ability to test ideas on small scopes.
What will differ are the limitations depending on the context:
Which scope has to change most?
Are there critical areas unstable or at risk?
Which parts accumulate more complexity?
Where collaboration limitations are reached?
Which resources are available to change?
These questions are the starting point to define the minimal architecture evolution requires from the initial architecture—that may not have to change that most.
Architecture grows with the business
The software industry evolved to the concept of socio-technological ecosystem recognizing links between people, processes, organization, culture and technology.
That interdependency requires an alignment of each domain to make it move in the right direction to grow the business with minimal efforts.
Based on that model, examples to avoid are:
Microservices architecture with 3 software engineers
Modulith with 500 developers lacking a shared animation
Each software team doing 50% of run tasks without shared support.
That list goes on, but you get the need for alignment.
The study of more than 50 companies revealed the following macro-model:
Monolith: $0-2m revenue up to 10 FTEs.
Modular monolith: $2-20m revenue up to 50 FTEs
Service-based: $20-200m revenue up to 500 FTEs
Macro to miniservices: $200m-2b revenue up to 5000 FTEs
Mini to Microservices: >$2b revenue more than 5000 FTEs.
Here’s the picture.
The analysis also revealed that companies saying to implement Microservices are actually implementing a service-based or Macroservices architecture.
For example, a “Basket” service in a context of digital e-commerce is of a Macroservices rather than Microservices as perform
The key technology differences being on the granularity of services to be higher, and the data to be shared between services instead of externally decoupled.
Align the ecosystem with minimal effort
Different architectures will require different socio-technological ecosystems at different stages of the business evolution.
The goal is not about technology—it’s about the minimal alignment that will support the business to adapt and grow fast.
There may be less fancy buzzwords in the day-to-day jobs, but much more efficiency and delivery of software that will make the difference.
So make the right choice for your business first, in the meanwhile “Modular monolith” and “Minimal architecture” are becoming mainstream again.
And they are all part of Quality Engineering.