Monoliths to Microservices: Untangling Your Spaghetti
Using AI and automation to refactor monolithic applications into microservices.
Join the DZone community and get the full member experience.
Join For FreeThe Pain
-
Long test cycles
-
Long release cycles
-
Inability to meet business requirements
-
Difficult to ramp up developers
-
Poor customer and user experience
Technical debt has a people effect as well. Developers don't want to work on legacy code, they want to work on greenfield projects. Another pain is that engineering velocity has slowed. Monolithic applications do not scale and have zero elasticity. This results in out-of-control costs, downtime, and poor user experience.
Microservices are more cost-efficient than monolithic applications. Microservices take advantage of cloud on-demand services like serverless. They also scale. The goal is to break monolithic applications into pieces. Modularize the components into containers. Doing this enables you to see how the code interoperates with each other. Seeing how things connect is a key architecture issue.
Migration to Modernization Strategy
The four stages of a migration to a modernization strategy are:
- Re-host
-
Re-platform
-
Refactor/Rearchitect/Rewrite
-
Continuous Modernization
-
Code modernization
-
Technical debt removal
-
Architectural changes
-
Scalability/elasticity
-
Accelerated engineering velocity
-
Accelerated engineering velocity
-
Shorter test and release cycles
-
Increased scalability and elasticity
-
Increased innovation
-
An accelerated rate of change aging all applications faster
-
Today's apps will be legacy tomorrow
Use Cases
The three most common 2022 app modernization use cases are as follows.
- Broad legacy application estate
-
A large number of applications to assess
-
Unsure what to retire, rewrite, refactor, etc.
-
Need to rank and develop data-driven business cases
- Several key apps identified
- Business-critical. selective and iterative refactoring required
- Architects have identified specific services but need tools and acceleration
-
Monolith is already in the cloud either lifted and shifted or gen 1 cloud apps
-
Costs are rising, agility is falling, and the business is affected
-
Need to realize cloud benefits of agility, release cycles, innovation, velocity, and scalability
Two Types of Monoliths
-
Typical size: Up to 2,000 classes
-
Arrive at the desired microservices architecture in 1 to 2 iterations
-
90% of monolithic decomposition is automatic
-
Quickly distribute tasks to dev teams
-
Start modernizing services
-
Typical size: 10,000 classes and higher
-
Initial target architecture may differ from the originally desired microservices architecture
-
Refactor sources of complexity
-
Create a common library for monolithic services (90% automatic)
-
Redeploy monolith
-
Reevaluate target architecture
Assessment and Modernization
-
Technical debt: the level of debt in an app affects the rate and cost of innovation. It is a key business measure for modernization decisions.
-
Risk: analyze how a change in one part of the application will affect another part of the application.
-
Complexity: understand the degree to which class dependencies are entangled. This reduces the level of modularity of the code.
-
Graph complexity of highly connected communities (e.g. infrastructure)
-
Graph complexity of other communities (e.g. service)
-
Connectivity between communities
-
Level of connectivity between service communities
-
The average number of dependents and length of dependency chains
Strangler Fig Pattern
Opinions expressed by DZone contributors are their own.
Comments