Cloud Service Discovery via Dynamic Configuration Files
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing monitoring platforms for cloud service providers require time-consuming code modifications and separate release activities to accommodate newly introduced services, lacking a generic mechanism to discover and support these services without disrupting existing operations.
Innovation Solution
The solution involves an extensible configuration file in XML, YAML, or JSON format that allows end users to update monitoring service instances without modifying code, enabling runtime updates and eliminating the need for separate release activities, using a monitoring platform with a discovery engine that matches service details from a configuration file against metric data from the cloud service provider's API.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If code modifications are made to accommodate new services, then the monitoring platform can support new services, but the process becomes time-consuming and requires separate release activities
Solution Approach 1:
The system transitions from a static code-based service definition to a dynamic configuration file-based definition. The configuration file can be updated at runtime without code changes, allowing the monitoring platform to adapt to new services dynamically through file updates rather than requiring time-consuming code modifications and releases.
Solution Approach 2:
The invention changes the parameter of service definition from hardcoded code to external configuration files. By using configuration files in formats like YAML, JSON, or XML, the system allows parameter changes (service definitions) to be made without modifying the core code, thus reducing the time required for adaptation while maintaining full functionality.
2Adaptability or versatility
If code modifications are made to accommodate new services, then the monitoring platform can support new services, but the complexity of release activities increases
Solution Approach 1:
The system segments the service definition from the core monitoring code. By separating service configurations into independent configuration files, the invention allows new services to be added by only updating the configuration file rather than modifying the core codebase, thus reducing the complexity of release activities while maintaining adaptability.
Solution Approach 2:
The configuration file acts as an intermediary between the new services and the monitoring platform code. Instead of directly modifying the code to support new services, the configuration file serves as a mediator that translates new service definitions into actionable monitoring parameters, simplifying the release process.
3Adaptability or versatility
If code modifications are made to accommodate new services, then the monitoring platform can support new services, but existing services may be disrupted
Solution Approach 1:
The invention segments service definitions into independent configuration files that can be updated without affecting the core monitoring code or other service configurations. This segmentation ensures that adding or modifying new services does not disrupt existing services, as each service is defined independently in its own configuration file.
Solution Approach 2:
The system allows preliminary configuration of new services through configuration files before they are fully integrated into the monitoring platform. By preparing service definitions in advance through configuration files, the platform can accommodate new services without disrupting existing operations, as the changes are applied incrementally rather than through disruptive code modifications.
Data Source
AI summary
Metrics corresponding to services provided by a cloud service provider can be received via a first API responsive to queries specifying identifiers of the services. A configuration file can be maintained that includes mappings between the identifiers of the services and the metrics corresponding to the services. An identifier of a new service provided by the cloud service provider can be received via a second API. A mapping between the identifier of the new service and a metric corresponding to the new service can be received by the configuration file. The metric corresponding to the new service can be received via the first API responsive to a query specifying the identifier of the new service.