IDC’s recent survey has found that 85% of cloud adopters are using multiple cloud platform vendors, with 58% leveraging at least four different cloud service providers. As multi-cloud architectures become increasingly popular, the demand for DevOps and IT Ops teams to map services across hybrid, multiple clouds is growing.
It’s easy to understand why. When you depend on cloud services that span more than a single cloud provider or when you make use of similar cloud services (like AWS S3 and Azure Storage) from different cloud vendors at the same time, you need to keep track of these cloud services in order to use and manage them effectively.
In this article, I explain how building a multi-cloud service mapping strategy can address this challenge.
What Is Service Mapping, and Why Does It Matter?
Your IT service management team needs to track the impact of incidents, problems, and any proposed changes across your infrastructure and distribute this information to stakeholders within the affected business units. Business units talk in terms of the applications they use, but they should not have to know the details of the IT infrastructure that supports each app.
I have worked in organizations that over-communicated detailed technical information to business units, and it led to confusion. It might be obvious to a network technician that replacing router ASPHX02 means that the corporate endpoint for ExpressRoute for all the Southwest offices will be offline and Office 365 will be unavailable, but the average claims analyst won’t (and shouldn’t) need to know this.
Service mapping offers capabilities to map IT infrastructure resources to applications and then map dependencies between applications and IT services. When you replace that same router, the service map will quickly highlight the apps impacted downstream and business units can be properly informed about the impact.
The Cloud Takes Hold. What's Next?
In any modern enterprise, a plan to extend or migrate workloads to a cloud-based infrastructure should be in place. Whether Alibaba Cloud, Microsoft Azure, a private VMware vCloud, or any other combination of cloud platforms, as you extend services and move to these providers, there needs to be a service map that tracks all the additional components and dependencies which are being added to the mix. (We’ll call this day one—moving day.)
Day two happens after moving to your chosen cloud providers. Once the migration is complete, there is pressure to leverage the features sold as benefits to justify making the investment to move to the cloud. One of the biggest of these benefits is the ability to dynamically add and remove resources based on load or scheduled events. Examples could be anything from the IRS’s additional capacity requirements during the second week of April (because no one files taxes early), to the ability to spin all but one instance of your biggest business application on the weekends (because there is no one in the office).
Multi-cloud architectures increase the complexity that public clouds introduce. You now have resources in more facilities that you need to track and you also have to deal with each platform provider’s unique set of terminology and metadata for each of these resource types.
Service Mapping For A Multi-Cloud Architecture
The single biggest action an infrastructure team can take when deploying on multiple cloud platforms is to create a consistent set of labels that you can assign to each resource for identification. There doesn’t need to be a huge formal taxonomy in place—It could be as simple as adding a label to identify the name of the component.
Organizations often standardize multiple labels and include them in the deployment scripts so they are always populated. These labels are not only useful for identification in service mapping activity, but also for troubleshooting incidents. Labels that I have personally seen used consistently are name, created-by, and created-date. Other labels that are often used include cost-center, project-id, region, and last-modified-date.
When you label all resources, and when teams use products that have autodiscovery, service mapping becomes a high-value activity of mapping dependencies between services that are meaningful to your business units (rather than trying to find, tag and map each individual IT resource). The initial effort to capture all resources (especially in legacy environments) is still required, but sustaining the dynamic portion of service mapping is much more reasonable when you use modern service mapping and discovery products.
Conclusion
As IT infrastructure extends onto cloud platforms, maintenance can become a logistical nightmare without a proper service management strategy. This includes the ability to map services across multiple clouds, which requires the right set of tools. Ultimately, any coordination around change and release management without a proper tool for tracking IT resources will require an unbelievable amount of babysitting by senior technical people, who are now free to focus on much more valuable tasks that can help your business move forward.
The goal and dream of cloud platforms is to let IT service delivery teams provide value faster and with more agility as and when business needs change. Multi-cloud service mapping for your hybrid infrastructure is key to making the new and more agile IT paradigm viable.
Learn More:
- See how OpsRamp’s Unified Service Discovery helps you understand service interdependencies using visual workflows.
- Read our service-centric AIOps whitepaper.
- Schedule a custom demonstration with a solution consultant today.
