$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 made extreme for the 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 performing multiple functions that cannot find in the head easily.
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.