The document discusses the advantages and considerations of using a microservices architecture compared to modular monoliths, emphasizing the importance of business capabilities and deployment flexibility. It highlights the influence of cloud services and frontend capabilities on this architectural choice and outlines a decision-making process for evaluating the need for microservices. The author also reflects on practical experiences in scaling services and managing product configurations within an API framework.

1. Manu Kadichapally
Oracle Code, Bengaluru, March 15 2019
When to Stay with
Modular Monoliths over
Microservices

2. Manu Kadichapally
• Engineering Manager @ Schneider Electric
• Twitter - @manupk12
• http://blog.manupk.com
• Developer, team leader and software architect
• Topics of Interests
• Modern Software Architectures
• Cyber Security
• Organizing Teams to build Digital Product

3. Microservices
Architecture
Approach to developing a
single application as a
suite of small set of
collaborating services.

4. Microservices architecture -
Characteristics
• Organized around Business Capabilities
• Independent
• Governance
• Technical Stack
• Deployment
• Consumer first interfaces
• Smart endpoints and dumb pipes
• Improved fault isolation
• Eventual Consistency for Data
Source: https://docs.aws.amazon.com/aws-technical-
content/latest/microservices-on-aws/characteristics-of-microservices.html

5. Evolutions of the
Ecosystem
The move towards microservices were highly influenced
by the changes in the disruptions in the ecosystems
• Cloud Services
• Powerful Frontend capabilities

6. • Re-think “Modularity”
• Is all monolith BAD?
• Big-ball of mud to
“distributed Big-ball of mud”
• How do we evaluate the
need?

7. The value of modularity
• Always be modular in the business context.
• Ability for vertical slice.
• Decide on source code tree / deployment
unit if required.

8. Just another
product!
Adding a new Product to the sales
platform

9. ROI – Speed of
execution
• System grew to 12+
products over the next 3
years.
• Every configurator was
developed as independent
project / service.

10. Public version
of an API
Change in the scaling requirement of
a service due to business decision to
allow everyone to access the tool

11. Business Context
- Using DDD
- Driven by stakeholder group
- Application / Team Size
Relative Scaling
- Significant difference in scaling needs.
- Impossible to use the same deployment
unit.
Over simplified version of decision
tree come down to two criteria's,

12. Microservices
Premium
Source:
http://martinfowler.com/bliki/MicroservicePr
emium.html

13. Thank you for
listening
@manupk12
Questions / Comments /
Feedback are welcome!