#29 of 39: Three (3) Architectural Patterns for Hybrid Cloud Management
There is no “one-size-fits-all” solution for hybrid cloud management. Experience indicates that there are three design patterns that are used to build a hybrid cloud management solution. These patterns can be used alone or in combination.
Three (3) Patterns for hybrid cloud management solutions check it:
The “Dual Pattern” is the starting point and it is based on the assumption that cloud service customers use two different management stacks/tools: those used to manage on-premises resources/workloads and those provided by the CSP. Both need to be integrated at the management process level.
An advantage of the dual pattern is that it can be a simple starting point. If cloud customers are able to gather, consolidate and integrate management data manually, then there is a good opportunity for automation.
The downside of this approach is that it requires customizing management processes with manual steps or investing in developing automation.
To summarize, you can use dual pattern if you want to integrate a few management capabilities across on-premises and cloud workloads and for scenarios that cannot be implemented with the other methods (for example, operating system patch management when the OS is completely managed by the service provider).
The “On-premises pattern” extends the scope of the on-premises management tools to manage the cloud resources and workloads, usually by installing management agents on the cloud resources/workloads. The management of cloud resources/workloads is typically done above the service responsibility line since commercial management tools do not have visibility of what happens below the service responsibility line.
The advantage of this pattern is that it’s relatively simple to implement and does not require big changes to cloud service customers’ management processes.
The downside is that the installation of additional management agents increases management costs (the agents themselves need management) and there may be additional license costs. Another drawback is that on-premises management tools might not integrate well with cloud service provider capabilities (e.g., agents might not intercept infrastructure or middleware events) and some scenarios might not be covered (e.g., alarms/tickets automatically created in an IaaS cloud service cannot be intercepted).
To summarize, the on-premises pattern is recommended if cloud customers rely on the cloud service provider to manage the cloud resources/services below the service responsibility line and they want to manage a limited amount of workloads (VMs or services). Consider that in many cases cloud customers may need to implement a manual process (see dual pattern) to realize those management scenarios that cannot be implemented because of limitations of the on-premises management tools in managing the cloud environment.
The “Integrated pattern” is an evolution of the “dual pattern”; it leverages both the on-premises and cloud-provider management services using existing APIs to automate the gathering, transfer and consolidation of management data from both environments.
The advantage of the integrated pattern is that it provides a single point of management from the on-premises tools while it does not require installation of management agents on the cloud services. In some cases APIs allow deeper integration.
The downside is that it needs a new bridge component between on-premises tools APIs and cloud service provider APIs.
To summarize, the integrated pattern can be more cost-effective to manage a certain number of cloud services; the number depends on the costs of creating and maintaining the integration code. There could be cases where this approach cannot be used because the cloud service provider or the on-premises management tools do not provide appropriate APIs.