In a world where competitive edge is everything and digital transformation is a priority, is being a monolith the safe thing to do? Or are microservices the panacea? Learn how you can have the best of both worlds using a domain-driven approach.
3. The hype of microservices
The fall of monoliths
| Monoliths or Microservices: Make both your Domain
4. No doubt about
microservice
advantages
Improved
modularity
Abstraction of
Business
capabilities
Light and
ubiquitous
communication
Products not
projects
Dev team
autonomy
Autonomous
CD / CI
Environmental
isolation
Independent
scale
Stack
independence
| Monoliths or Microservices: Make both your Domain
6. A fragmented / multi-stack system comes with a price
| Monoliths or Microservices: Make both your Domain
7. A fragmented / multi-stack system comes with a price
● Inter-process communication
network latency and hiccups,
data marshalling
| Monoliths or Microservices: Make both your Domain
8. A fragmented / multi-stack system comes with a price
● Inter-process communication
● Multiple transactions
committed independently
Transaction 1
Transaction 2
Transaction 3
| Monoliths or Microservices: Make both your Domain
9. A fragmented / multi-stack system comes with a price
● Inter-process communication
● Multiple transactions
● Fault tolerance
communication errors, service
consistency
Undo
| Monoliths or Microservices: Make both your Domain
10. A fragmented / multi-stack system comes with a price
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
in memory and limited to API’s
GetCustomers
GetOrders
correlate
and segment
| Monoliths or Microservices: Make both your Domain
11. A fragmented / multi-stack system comes with a price
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
credentials and access management
🔒
🔒
🔒
| Monoliths or Microservices: Make both your Domain
12. A fragmented / multi-stack system comes with a price
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
● Debugging & troubleshooting
the root cause may be deep inside the
chain of services
| Monoliths or Microservices: Make both your Domain
13. A fragmented / multi-stack system comes with a price
Monitor
&
Logging
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
● Debugging & troubleshooting
● Monitor & logging
effective monitoring & logging,
requires a centralized service
| Monoliths or Microservices: Make both your Domain
14. After a degree of service proliferation
● Essential benefits become burdens
● Teams move slow mired in exploding
complexity
| Monoliths or Microservices: Make both your Domain
16. #1 Adopt a single stack
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
● Debugging & troubleshooting
● Monitor & logging
| Monoliths or Microservices: Make both your Domain
17. #1 Adopt a single stack - hey, like OutSystems 11!
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
● Debugging & troubleshooting
● Monitor & logging
| Monoliths or Microservices: Make both your Domain
18. #2 Don’t be fundamentalist, expose a query model
● Inter-process communication
● Multiple transactions
● Fault tolerance
● Limited data mashup
● Security
● Debugging & troubleshooting
● Monitor & logging
| Monoliths or Microservices: Make both your Domain
20. Mkt
Fin
HR
SOFTWARE
COMPLEXITY
Small apps Medium sized
apps
Large monolith with a portfolio
of core systems, services and
apps
Modularize
UX
Scale
Strong reuse
app
grows
Degradation of -ilities
Teams hostage each other
Deployment is way too
complex and slow
The growth of a software factory
| Monoliths or Microservices: Make both your Domain
21. Mkt
Fin
HR
SOFTWARE
COMPLEXITY
Small apps Medium sized
apps
Large monolith with a portfolio
of core systems, services and
apps
Modularize
UX
Scale
Strong reuse
app
grows
SOFTWARE
COMPLEXITY
Modern digital platforms
organized as
microservices
Decoupled services
Independent teams
The moment to adopt microservices
| Monoliths or Microservices: Make both your Domain
23. 23
Domain Driven Design (DDD)
DDD drives the development of complex systems,
based in decoupled domains of technology
artifact
Independent CD/CI
pipelines for different
products/teams
| Monoliths or Microservices: Make both your Domain
24. 24
How to ensure domain independency?
Group concepts by functional area or LOB
[ business fit ] [ decision power ]
#1
Light and stable service interfaces
[ less impacts across domains ]
#3
Dedicated multidisciplinary team
[ ownership ] [ control ]
#2
| Monoliths or Microservices: Make both your Domain
25. 3 principles for a balanced architecture
2. Strong coupling inside a domain
benefit tight processes inside the domain
1. Be smart with your domain boundaries
base on functional area and CD/CI independence needs
3. Loose coupling across domains
ensures domain independence
| Monoliths or Microservices: Make both your Domain
Everyone wants to follow the hype of microservices, leaving monolith architectures to the abandon like old medieval castles
IT’s excellively adopting microservices soon found out that essential benefits of this architecture become burdens. Instead of enabling them to move faster, the small team found himself mired in exploding complexity.
Because it is much simpler, you start with strongly coupled...
With OutSystems 11 improved impact analysis, this moment can be further delayed
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping business processes within a problem domain into the technology artifacts of a solution domain.