Transition Service Broker for Monolithic to Microservices Migration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Legacy software systems, such as monolithic applications, face challenges in transitioning to modern microservices-based architectures due to their outdated design and dependencies, making it difficult to adapt to cloud and hybrid deployment models, and support continuous delivery and scalability.
Innovation Solution
A transition platform is introduced, featuring a transition service broker with a service registry proxy and facade, enabling interaction between legacy core components and external services, facilitating the transition by registering services, managing state recovery, and providing a protocol-independent interface for service proxies, which allows for the gradual migration to a microservices-based architecture.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a monolithic application architecture is used, then the system can execute legacy code with millions of lines distributed over hundreds of components, but the system becomes outdated and difficult to adapt to cloud deployment models and continuous delivery
Solution Approach 1:
The patent segments the monolithic application into multiple independent microservices, each handling specific business functions. This segmentation enables individual services to be deployed, updated, and scaled independently, thereby improving adaptability to cloud deployment models while managing the complexity of the legacy system through modular decomposition.
Solution Approach 2:
The service gateway acts as an intermediary layer between the legacy monolithic system and the new microservices architecture. It manages service registration, routing, and communication protocols, allowing the system to transition gradually while maintaining compatibility with existing legacy components and enabling cloud deployment flexibility.
2Productivity
If microservice-based architecture is implemented, then continuous enhancement of functionality and parallel code lines are enabled, but transition from legacy architecture is difficult due to outdated design and dependencies
Solution Approach 1:
The service gateway is established in advance as a central coordination point before fully transitioning to microservices. It pre-configures service registration mechanisms, communication protocols, and routing rules, thereby simplifying the transition process by having the infrastructure ready to manage the complexity of migrating legacy dependencies to the new architecture.
Solution Approach 2:
The service gateway provides universal functionality by handling multiple aspects of the transition simultaneously: service registration, request routing, protocol adaptation, and legacy system integration. This multi-functional approach reduces transition complexity by consolidating management responsibilities in a single component rather than requiring separate solutions for each transition challenge.
3Reliability
If service proxies are introduced to enable interaction between legacy core and external services, then integration during transition is maintained, but system complexity increases with service registry proxy and facade components
Solution Approach 1:
The service broker combines multiple components (service gateway, service registry, service proxies, and facades) into a unified infrastructure that manages service interactions. By merging these elements into a cohesive system with centralized service registration and unified communication protocols, the patent reduces the apparent complexity while maintaining reliable integration between legacy core components and external services during the transition period.
Data Source
AI summary
Methods, systems, and computer-readable storage media for providing a transition service broker, the transition service broker including a service registry proxy, and a service registry, the service proxy registry registering service proxies, each service proxy enabling interaction between at least one core component of a legacy core, and one or more external services, the service registry registering services available for consumption by core components of the legacy core, each external service of the external services including a service facade that maps between a legacy architecture, and the service, during a transition period between the legacy architecture, and the microservices-based architecture: establishing a connection between the at least one core component, and an external service through a service proxy, and receiving input from the external service through the connection, the input being processed by the at least one core component during execution of the software product in the legacy architecture.