Nowadays Microservices is perceived as the bulletproof software architecture choice. Monolithic applications are considered old fashioned. Isn’t there a sweet spot? What really makes us migrate from Monoliths to Microservices?

1. Isn’t the Monolith Just Enough?
Petru Flueras
Software Architect - Visma Software
@pflueras
Codecamp, April 2022

2. Thank you!

3. Journey: follow the lifecycle of a project starting from the
startup/inception phase all the way to a matured product
Would you go microservices architecture from the very beginning?

4. Monolith First
Most successful microservice stories have started with a monolith
Products started as a microservice system from scratch, ended up in a
serious trouble
It may be hard to scale a poorly designed but successful software
system, but that's still a better place to be than its inverse
source: https://martinfowler.com/bliki/MonolithFirst.html

5. Monolith First #2
You shouldn't start a new project with microservices, even if you're
sure your application will be big enough to make it worthwhile
source: https://martinfowler.com/bliki/MonolithFirst.html

6. Design of the monolith
Modularization: strong encapsulation, well-defined
interfaces, explicit dependencies between modules
(stable boundaries between modules)
Simon Brown: if you can’t build a well-structured
monolith, what makes you think microservices is the
answer?

7. Modularization done right
As project grows, don’t use layers (e.g.
presentation-domain-data) as the top level
modules, instead make you top level
(domain oriented) modules be full-stack
which are internally layered
https://martinfowler.com/bliki/PresentationDomainDataLayering.html

8. Make each program to do one thing well. To do a new job, build afresh rather
than complicate old programs by adding new “features”
UNIX Time-Sharing System: Forward (Douglas McIlroy - 1978)
Bounded Context (Domain Driven Design): a way to mark boundaries and
relationships between different domain models
It is almost always incorrect to begin the decomposition of a system into modules on
the basis of a flowchart. Instead, each module is designed to hide difficult design
decisions.
On the Criteria To Be Used in Decomposing Systems into Modules (1972)
How to get the right shaped modules?

9. Before migrating to Microservices: More Complexity?
Image: https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/

10. Complexity #1: Data Consistency
Database transactions (ACID), Referential integrity
Monolith
Eventual consistency (BASE), Distributed transactions - 2PC,
SAGA Pattern
Microservices

11. Complexity #2: Network fallacies
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

12. Complexity #3: CI & CD
Monolith
Microservices

13. Complexity #4: Monitoring
Monolith Microservices

14. Complexity #5: Integration Testing

15. Complexity #6: Security
● Authentication: some sort of single sign-on (SSO)
○ End users
■ Single sign-on gateway & identity provider
■ OpenID Connect
○ Service-to-service
■ Basic Auth, OpenID Connect, Client certificates, API keys
■ Service accounts
● Attack surface area is increased
● Don’t repeat yourself

16. https://martinfowler.com/bliki/MicroservicePrerequisites.html

17. The Seven (More) Deadly Sins of Microservices (Daniel Bryant)
Microservices Highway to hell (Broutin Mathieu)
Avoiding Microservice Megadisasters (Jimmy Bogard)

18. Conscious decision!
(Customers don’t care about your tech stack)

19. ● Scalability: independently scalable microservices
○ Time and cost efficient (auto)scaling
○ Fast startup time & low memory footprint
○ CPU / memory intensive applications
● Autonomous teams
● Deliver faster business value (slow CI/CD pipelines)
● DevEx is bad - hard to maintain
Why migrating to Microservices?

20. How small can a microservice be?
How big a monolith can go?

21. Scaling #1: Horizontal scaling (stateless)

22. Scaling #2: Database read replica

23. Scaling #3: Data partitioning - Sharding (Z axis)

24. Modular monolith!

25. Summary
Level 1: Monolith First & The right design!
Level 2: Horizontal scaling
Level 3: Database read replica
Level 4: Database sharding
Level 5: Microservices - conscious decision!