Microservice Update System Using Selective Build
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional service updating techniques for microservices are inefficient, as they require rebuilding the entire code repository when a single microservice is modified, leading to long build times and resource consumption, which limits parallel build operations.
Innovation Solution
A microservice update system that uses a continuous integration engine to selectively update and test only the modified microservices and their dependent services, rather than the entire code repository, allowing for more efficient and resource-friendly updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional service updating techniques are used to update a single modified microservice, then the service code is updated, but the entire code repository must be rebuilt causing long build times and high resource consumption
Solution Approach 1:
The patent segments the monolithic build process into individual microservice build units. Each microservice can be built independently based on its modification status, rather than rebuilding the entire code repository. This is achieved by identifying modified microservices and triggering builds only for those specific services and their dependencies.
Solution Approach 2:
The patent extracts the build operation from the entire code repository and applies it selectively to only those microservices that have been modified. The build system identifies and isolates modified microservices, triggering rebuilds only for them and their dependent services, thereby excluding unrelated microservices from the build process.
2Reliability
If conventional service updating techniques are used to update a single modified microservice, then the service code is updated, but large amounts of computing resources are consumed
Solution Approach 1:
The patent segments the resource-intensive build process into individual microservice units, allowing resources to be allocated only to modified microservices rather than the entire codebase. This segmentation enables parallel processing of independent microservice builds and reduces overall resource consumption.
Solution Approach 2:
The patent applies partial action by performing build operations only on modified microservices and their dependencies, rather than executing a complete rebuild of all microservices. This partial approach consumes fewer computing resources while still ensuring that updated services are properly built and tested.
3Reliability
If conventional service updating techniques are used, then all code in the code repository is updated, but parallel build operations are prevented
Solution Approach 1:
The patent segments the build process into independent microservice units that can be processed in parallel. Each modified microservice and its dependencies form an independent build task that can be executed concurrently with other microservice builds, thereby enabling parallel build operations while maintaining update completeness.
Solution Approach 2:
The patent introduces dynamic build triggering based on modification detection. The system dynamically identifies which microservices have been modified and automatically adjusts the build plan accordingly, enabling flexible parallel execution of build tasks based on actual change patterns rather than following a static all-or-nothing build approach.
Data Source
AI summary
A microservice update system includes a build dispatcher system that receives a microservice modification request identifying first microservice(s) included in a plurality of microservices that provide a service. The build dispatcher system then triggers a respective microservice pipeline for each first microservice. A continuous integration system receives respective microservice modified code for each first microservice via the respective pipeline triggered for each, and update corresponding first portion(s) of service code. The continuous integration system then tests the updated service code in order to test the first microservice(s) that are provided by the first portion(s) of updated service code, and test second microservice(s) that are included in the plurality of microservices that provide the service, that are provided by at least one second portion of the updated service code that was not updated as part of the updating, and that are dependent on at least one of the first microservice(s).