The document discusses different approaches to refactoring a monolithic application architecture: 1. A modular monolith breaks the monolith into smaller modules but remains a single application, addressing complexity and communication issues but still having some downsides. 2. Using message queuing separates communication handling from application code but introduces single points of failure and more complex tracing across services. 3. A pipeline and nodes architecture isolates processing into smaller components that can scale independently but has difficulties with state management, databases, and consensus across nodes.

1. Refactoring the
Monolith?
Steven Hicks
http://theexceptioncatcher.com

2. Who am I?
Steven Hicks
http://theexceptioncatcher.com
@theexceptioncat

3. The Monolith
The monolith is a full application that encompases the entire life
cycle of a user’s interaction:
Web services
Web Rendering
Serving up static resources
Business Logic

4. Microservices
● Independent operations
● Small in context
○ Smaller Cognitive load
● Can embrace new technologies and
languages without a full cultural shift

5. What Happens In Reality
● Harder To Standardize
○ Multiple Code bases
○ Duplicated Code Bases
● Serialization and communication
overhead
● Lack of code reuse
● DevOps issues
● Tracing /Fragile system
● Overly Reliant on REST/JSON
● Client is up to the requestor
● Various instances of the same
microservice (WEB SCALE)
● Fiefdoms Develop

6. How did we get here?
What can we do about
it?

7. Popular Frameworks for Enterprise Solutions
Spring J2EE

8. Approach #1:
Modular Monolith

9. Modular Monolith
● Addressed the complexity issue that
microservices solves
● Makes smaller modules within the
system
● Addresses the network
communication problem
● Relies on the build to put everything
together
● It’s an easier step towards breaking up
the monolith
● Domain Driven Design approach
● Local builds are easy to run locally

10. Modular Monolith: Downsides
● Tooling is a bit difficult to handle
(multiple dependencies with auto
updates)
● A bit hard to extend and change
design
● It’s still a “monolith.” *
● Cognitive Load still requires system
level interaction

11. Approach 2
Message Queuing

12. Message Queuing
● Communication and Messaging is
handled by a central communication
service (the message queue)
● Separation of Responsibility
● Removes need for custom
serialization
● Storage of communication *

13. Message Queuing: Downsides
● Single Point of Failure
● Tracing (throughout the system)
requires a lot of logging
● Replying to a request may get
complicated
● Versioning becomes difficult

14. Approach 3
Pipeline and Nodes

15. Pipeline and Nodes
● Isolation of processing and service
delivery
● Handles the processing of requests
without slowing down other users
● Very Fast Requests
● Can handle complicated requests
● Easy to scale up
● Workflows-like design
● Smaller components to handle logic

16. Pipeline and Nodes: The Downsides
● Hard on databases
● Doesn’t handle state well
● Consensus and Split Brain Issues
● Large Memory Requirements
● Not great for round trips on live
requests for large transformations
● Still requires a bit of Devops setup
(Less so than microservices)

17. Questions?
Comments?
Experiences?
http://theexceptioncatcher.com
@theexceptioncat