Microservices architecture style has been a prominent talking points over the last few years. Microservices is by no means a silver bullet though, and the design thinking required to create a good microservices architecture is the same as that needed to create a well structured monolith. This talk briefly covers characteristics of microservices, monoliths and modular monoliths. We will discuss the topics like, does microservices suits all problem domains? Where does it fails? Can we re-look at the existing styles and look for continual improvements in architectural style? By (re)visiting various styles, we will look at the guidelines which can be used to choose between a modular monolith and microservices.
When to stay with modular monoliths over microservices
Oracle Code, Bengaluru, March 15 2019
When to Stay with
Modular Monoliths over
• Engineering Manager @ Schneider Electric
• Twitter - @manupk12
• Developer, team leader and software architect
• Topics of Interests
• Modern Software Architectures
• Cyber Security
• Organizing Teams to build Digital Product
Approach to developing a
single application as a
suite of small set of
Microservices architecture -
• Organized around Business Capabilities
• Technical Stack
• Consumer first interfaces
• Smart endpoints and dumb pipes
• Improved fault isolation
• Eventual Consistency for Data
Evolutions of the
The move towards microservices were highly influenced
by the changes in the disruptions in the ecosystems
• Cloud Services
• Powerful Frontend capabilities
• Re-think “Modularity”
• Is all monolith BAD?
• Big-ball of mud to
“distributed Big-ball of mud”
• How do we evaluate the
The value of modularity
• Always be modular in the business context.
• Ability for vertical slice.
• Decide on source code tree / deployment
unit if required.
Adding a new Product to the sales
ROI – Speed of
• System grew to 12+
products over the next 3
• Every configurator was
developed as independent
project / service.
of an API
Change in the scaling requirement of
a service due to business decision to
allow everyone to access the tool
- Using DDD
- Driven by stakeholder group
- Application / Team Size
- Significant difference in scaling needs.
- Impossible to use the same deployment
Over simplified version of decision
tree come down to two criteria's,