In the first part of the Hybrid Cloud Discovery trilogy, I introduced some of the reasons for the necessity of Hybrid cloud discovery. In this part, I will look at some of the considerations in hybrid and multi-cloud discovery.
Once moving to public cloud, there are many choices to be made. The first one, of course, is the identity of the cloud provider. While in 2018 AWS is still the leading public cloud provider, there are many other options: Azure (Microsoft), Google Cloud, Oracle Cloud, Alibaba, IBM, and many smaller providers. When looking into public cloud discovery, the first question to ask is whether the discovery tool can support you in this journey.
Does it have the discovery for the above public cloud providers? Does it has good content coverage for these public providers? Does it has a flexible deployment model and APIs to extend the discovery of public cloud, to providers that are not yet been discovered or to services that are not yet discovered? For example, for "Universal Discovery" discover out of the box the main cloud providers like AWS, Azure and Google Cloud (and more), services are being added on a constant basis.
Ensuring that you have a broad coverage to discover multiple cloud providers is important as most organizations might leverage more than a single public cloud provider (for example, different lines of business standardize on a different cloud provider). Even if you currently leverage a single cloud provider, new ones can be added (like in an event of M&A) and transition from one public cloud provider to another might happen (with cost as a main drive for this). Your discovery should be able to be flexible enough to support you through this journey.
However, just having the generic discovery capability to the cloud is not sufficient. You must ensure that your discovery of the public cloud resources is also capable of delivering the business results that you are looking for. For example, if you chose to deploy your own software into the public cloud (‘Bring your own license’), you will want to ensure that you are in compliance with your software entitlements. While some discovery tools will claim that they can discover your cloud resources, looking deeper into them will reveal that they only can discover what the cloud providers are actually exposing via their public APIs; however, this will not be sufficient for this use case. In this scenario, you will need to actually connect directly into the resources that are deployed in the cloud, and understand which software is running on them. Thus, when choosing a public cloud discovery provider, you need to ensure that it does not only rely on the public API provider by the cloud provider, but that you can complete this information to several other important use cases.
A good discovery tool should be able to connect to all resources as in the below diagram:
In last part of this blog, I will cover some of the things to look for in public cloud discovery capabilities:
- Ability to schedule public cloud discovery on one hand, and ability to get events on changes in the public cloud deployment.
- Deploy and operate the discovery solution into the cloud provider, to enable the right access to resources.
- Some thoughts on the future of cloud discovery