Stitching Application Models to Infrastructure Topologies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing blueprint approach for designing, provisioning, deploying, and managing cloud services lacks the ability to describe physical topologies and associate policies effectively, making it difficult to model application models and infrastructure templates, leading to reconciliation issues between these components.
Innovation Solution
The introduction of architecture-descriptive topologies that define the physical architecture of a cloud service, allowing for the association of nodes with relationships, properties, actions, policies, and lifecycle management actions, and the use of a policy-based framework for managing provisioning, deployment, monitoring, and remediation processes, while supporting both topologies and blueprints with a unified lifecycle management engine.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If the existing blueprint approach is used for designing and provisioning cloud services, then the service deployment can be automated, but the ability to describe physical topologies and associate policies is insufficient
Solution Approach 1:
The patent segments the cloud service model into distinct components: logical blueprints for service abstraction and physical topologies for infrastructure representation. This segmentation allows each component to specialize in its strength while the integration layer handles policy association and reconciliation between the two models.
Solution Approach 2:
The patent introduces an intermediary layer that maps logical blueprint elements to physical topology elements and associates policies between them. This intermediary resolves the contradiction by enabling policy association without requiring the blueprint approach itself to directly describe physical topologies.
2Ease of operation
If manual deployment steps are used to link application to infrastructure, then flexibility in deployment sequencing is maintained, but administrative time and resource consumption increase significantly
Solution Approach 1:
The patent applies preliminary action by pre-defining deployment sequences, dependencies, and policy associations in the blueprint and topology models before actual deployment. This allows the system to automatically execute the planned sequence without manual intervention during deployment, reducing administrative time while maintaining the flexibility of customized deployment sequences.
Solution Approach 2:
The system enables self-service deployment by automatically linking application models to infrastructure templates based on predefined policies and relationships. The automated reconciliation process eliminates the need for manual administrative steps while maintaining deployment flexibility through configurable policy rules.
3Adaptability or versatility
If separate models for applications and infrastructure are maintained, then model independence and reusability are preserved, but reconciliation issues arise between the two models
Solution Approach 1:
The patent implements feedback mechanisms through automated reconciliation processes that continuously verify and update the mapping between application models and infrastructure templates. Policy associations serve as feedback constraints that ensure consistency between the separate models, allowing them to remain independent while maintaining high reconciliation accuracy through automated validation and correction.
Data Source
AI summary
A method of stitching an application model to an infrastructure template, comprising identifying patterns in the application model, identifying patterns in the infrastructure topology, and matching the patterns in the application model and infrastructure topology using policies associated with the application model. A system for stitching an application model to an infrastructure topology, comprising a stitching engine, and a number of infrastructure topology sources, in which the stitching engine, identifies patterns in the application model, identifies patterns in the infrastructure topology, and matches the patterns in the application model and infrastructure topology using policies associated with the application model.