Skip to main content

Gradually Replace the Legacy System

Context​

The system (called the legacy system) shall be migrated to a microservice-based architecture.

Problem​

  • A reimplementation of the whole system is not feasible due to too high risks and a too long break in return of invest.

Solution​

Gradually replace the legacy system. This approach reduces the risks of a migration in comparison of a complete re-implementation that runs in parallel to maintaining the old system. However, the overall time for the migration might be longer to abandon the legacy system. This approach also leads to a higher complexity in comparison to starting over on the green field.

Some strategies focus on implementing all new features and extract changing functionality as new microservices. Other approaches deliberately identify and prioritize funcationality and components to be extracted as microservices.

The following techniques might help to migrate towards microservices incrementally:

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L4:

  • Most orgs started with sth bigger and then split up into microservices
  • Netflix and Amazon as examples

L17:

  • Context: different migration approaches
  • third approach
    • implement new features as microservices
    • replace external services by 3rd parties
    • develop features that need important changes (considered as new features)
    • => gradually eliminate the existing system
    • applies not to all using this approach
    • advantages: lower migration consistency
    • disadvantages: longer time required to abandon legacy system
    • at some point if some features do not need to be redeveloped: decide if leave legacy system side-by-side or re-develop

L22:

  • User interface as point of decoupling
  • Switch from old version to new version => eventually deprecate the monolith
  • Leads to an increased overall complexity until migration is finished

L59:

  • Context: migration scenario
  • Use old application as service when switching to new architecture by inserting microservice components

LN21:

  • Example: system that contains microservices and monolithic modules; migration still incomplete

LN42:

  • Context: microservices to modernize legacy applications
  • Use of refactoring to incrementally modernize the legacy application
    • less risky than complete redevelopment in microservices
  • Prioritize components for migration
    • Develop your own criteria
    • Do risk analysis before final adoption and migration

LN43:

  • monoliths have their place: easy to develop, deploy, dest, and scale an application when the size of a codebase is small
    • => thus, most apps have monolithic architecture
    • but: easier to accidentially introduce tight coupling
  • Refactoring existing monolith is too demanding
    • hard to break up tight coupling and requires lots of time and understanding
    • spend more time at start of process to evaluate the architecture
  • => refactoring into microservices should be done in small parts
    • new functionality should be added as microservices rather than adding them to the monolith
    • add new microservices to replace the old monolithic code
    • => slowly move most of codebase towards microservices

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C2-S3
    • existing monolith is replaced and extended piece by peace
    • new system: 10 Java services
    • monolith too important and complex to be replaced at once
    • => operate two systems concurrently
    • additional functionalities: new microservices
      • strangler pattern
  • C9-S13
    • migration of a system to cloud-native architecture
    • traditional WepSphere to Liberty in Docker; service cut postponed
    • instead: strangler pattern for ongoing development
    • Java as exclusive language for all service
    • SOAP + JMS replaced by RESTful HTTP + AMQP
  • compatibility
    • ability to co-exist and integrate with legacy system perceived positively
    • requirement for many companies during migration phase

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • Mainframe still running, but functionailties will be implemented as new microservices over time
  • Recommendation: start with PoC and then generalize into replicable process
    • instead of starting with several services, start with a single one
      • get to uniform vision, understand approach and coding standard
      • the rest will come naturally

Interview A:

  • Consideration of how to move to microservices
    • big bang with parallel development not feasible from economical perspective
      • no return on invest for 3 years with 40 people
    • rather go for a incremental approach to "enucleate" the monolith
      • identify different functionality and then decide agile on architecture
      • gradually migrate towards microservices

Interview F:

  • Microservices are suitable to integrate with a legacy system
    • e.g. SAP application if it is the best tool for the job