The document discusses the transition from a monolithic architecture to a container-based (microservices) architecture, explaining the benefits and core principles of microservices. It emphasizes a gradual modernization process through strategies like the strangler pattern and the identification of bounded contexts to incrementally refactor applications. Key principles include maintaining single responsibility for services and ensuring independent deployability through appropriate API and container management.

1. Modernizing the monolithic architecture
to container-based (microservices)
architecture
Vinay Kumar
@vinaykuma201

2. • ORACLE ACE
• Head of Application & Integration Architect
• Author of “Beginning Oracle WebCenter portal 12c”
• Blogger- http://www.techartifact.com/blogs
• https://www.linkedin.com/in/vinaykumar2/
• @vinaykuma201
2
About me

4. Agenda
4
• What is monilithic
• Why modernize the monolithic
• Microservices vs Monolithic
• Microservice core principles & patterns
• Modernizing a monolithic
• Implementig new features as service.
• Extracting modules into service.
• Modern High level architecture.

5. A monolithic application is self-contained, and independent from other
computing applications. The design philosophy is that the application is
responsible not just for a particular task, but can perform every step needed
to complete a particular function.
Monolithic

6. Monolithic
6
Client
Business logic
Data Access Layer
Database
ADF/WCP
Oracle SOA Suite
OSB DS
Database
WebLogic

7. Traditional server side app architecture

8. A monolithic per se may
not be bad thing at all.

9. Why (not) modernize the monolithic

10. Microservices
1
0
Microservices is a software development technique
that arranges an application as a collection of lossely
coupled services.

11. 11Document Title - Name - Function - Business Unit DD/MM/YYYY

12. Microservices vs Monolithic
1
2

13. Where you stand?
Monolithic
PeopleProcessTechnology
Digital
Alignment
Fast
waterfall/Agile
API- Driven Early Agility Integration Agile

14. Closer look of microservices architecture
1
4

15. 1
5
Is the Change Worth It?

16. 16
Microservice architecture patterns
Ref:https://microservices.io/

17. 17
Microservice core principles
1. Single Responsibility (Bounded Context)
2. Domain Driven Design
3. Encapsulation (Black Box)
4. Service Discovery
5. Decentralisation
6. Independently Deployable
7. Culture of Automation
8. Standardized API Mechanism with a Published Contract
9. Highly observable
10.Resiliency and Failure Isolation
11.Appropriate Security

18. 18
Modernize the monolithic application
Monolithic
Service Service
Service Service
Microservice Architecture

19. The Big Bang rewrite guarantees is a
only Big Bang!

20. Best way – incrementally!

21. 21
Strangler pattern

22. 22
Strangler pattern
• Build an abstraction layer
• Stop digging the grave.
• Rewrite/replace existing features
• Remove the release cycles

23. 23
Strangler Application pattern
• Transform
• Coexist
• Eliminate

24. Modernize the monolithic application – reroute request to
services
Monolithic
Feature
M
Monolithic
Service
API GW

25. 25
Common terms in Domain-driven design
• Domain driven design - is an approach to software development that centers
the development on programming a domain model that has a rich
understanding of the processes and rules of a domain.
• Domain- Represents what an organization does
• Sub Domain - DDD implies domain decomposing into sub-domains, to ease
their modelling and comprehension.
• Bounded context- Bounded Context is a central pattern in Domain-Driven
Design. It is the focus of DDD's strategic design section which is all about
dealing with large models and teams.

26. 26
Slice the monilithic into microservices
• Identify the Bounded Contexts in your application design : A Bounded Context is
a shared conceptual framework that constrains the meaning of a number of entities within a larger set of business
models. In an airline application, flight booking would be one Bounded Context, while the airline loyalty program
would be a different Bounded Context. Although they may share terms (such as “flight”), the way in which those terms
are used and defined can be quite different.
• Find out the Bounded Context that is the smallest and least costly to
refactor : Rank your other Bounded Contexts in order of complexity from least complex to most complex. You’ll
want to start with the least complex Bounded Contexts in order to prove out the value of your refactoring (and shake
out any problems in adopting the process) before you take on the more complex (and potentially costly) refactoring
tasks.
• Conceptually plan out the microservices within the context- Plan out a rough
URL structure and overall responsibility of your microservices by applying the Entity, Aggregate, and Service patterns.

27. 27
Slice the monilithic into microservices- contd…
• Analyze the relationship between the pages in your existing UI—: Need to
group screens together into a set of logical Flows. A Flow is a simple concept—it’s a group of screens that connect
from one to another to perform a single user task like booking a flight in a travel website, or checking out a cart in a
retail website. The notion here is that you have a limited number of Flows in your UI and that each Flow will
correspond to a small set of microservices that represent the concepts that are being manipulated.
• Follow the principle of least surprise to the related aspects of the model
manipulation: Try making some simple assumptions that apply this principle; for instance, if you have flows
that query a particular domain aspect, you can assume that it is likely that this domain aspect should also be updated,
even if you don’t have a flow for that.
• Size your Chunk: Plan out a rough URL structure and overall responsibility of your microservices by
applying the Entity, Aggregate, and Service patterns from.
• Decide whether to develop an entire chunk at a time, or each chunk as a
series of service

28. Traditional Banking system
Contact
History
Account
Booking
Order
Credit
offer
Debit
card
Customer
Interest
Credit
card
Rating
Setting
Credit line
Installment
Direct
debit
Credit
contract
Direct
debit
Transaction
Account
Statment

29. Find out bounded context candidates
Contact
History
Account
Booking
Order
Credit
offer
Debit
card
Customer
Interest
Credit
card
Rating
Setting
Credit line
Installment
Direct
debit
Credit
contract
Direct
debit
Transaction
Account
Statement
Customer
Credit
Card Account

30. Bounded context candidates
• Card
• Customer
• Account
• Credit
# Decompose your bounded context further

31. Choose Sub-domain
Rating
Contact
History
Setting
Customer
Interest
Booking
Transact
ion
Account
Credit
order
Direct
debit
Statement
Sub-Domain?? Entities??
Support Sub-
Domain/Context

32. Bounded contex == microservice?
Sub-domain == microservice?

33. Domain & Events

34. Big Monolithic application
Monolithic App
Customer Card Account Credit
Virtual Machine (s)

35. Slice with service and APIs
Monolithic App
Virtual Machine (s)
Customer
Service
Card
Service
Account
Service
Credit
Service
API
API
A
P
I
M
a
n
a
g
e
m
e
n
t

36. Modern High level container based architecture
Event Management (Pub/Sub)
Customer
Service
Card
Service
Account
Service
Credit
Service
API
API
A
P
I
M
a
n
a
g
e
m
e
n
t
vContainer 1 Container 2 Container 3 Container 4
Container Management platform
User
interface
Container
x

37. 3
7
Process of container-based microservice reconstruction
Plan to slice monolithic

38. Summary
3
8
• Monolithic is not always bad but think to modernize if you requires.
• Dont rewrite fully, change incrementally.
• Make the split right – Bounded context.
• Decompose Domain , sub-domain and bounded context.
• Bounded context is not a microservices.
• Service should follow single responsibility principle.
• Services should also conform the common closure principle (Things
can changes and pack together.)
• Have indepedent deployable unit as container.
• API and container management platform is required.

39. Questions?
3
9