Humanity has long recognized the significance and usefulness of maps to their lives. Indeed, the history of mapping stretches back more than 5000 years. In essence, maps are tools which depict, as precisely as possible, the spatial relationships between features. In other words, where a feature is located relative to other features.
CloudHarmony makes use of maps to denote and compare cloud providers service regions in an easy to digest side-by-side comparison. Not only does CloudHarmony provide information on service regions it also goes a step further by providing information on the number of Availability Zones available in these regions. At this point you may be thinking, what is the difference between a Service Region and an Availability Zone (AZ) and how exactly does knowing this information assist me in deploying my cloud-based application?
Great questions, allow me to explain.
Service Regions are separate geographical areas cloud providers use to house their infrastructure for a service. Typically, these are distributed around the globe allowing users to choose a region closest to them in order to host their cloud applications there. Reading some of the other Blogs on the CloudHarmony site you should be familiar on how latency (and the lack of) is beneficial to cloud based applications. So, armed with this knowledge and being able to see where a vendor has a service region presence can help a user pick a particular cloud provider over another.
What are Availability Zones (AZs) I hear you ask?
Think of AZs as logical building blocks that make up a region. These AZs are all within a same Service Region, however, they are not all within the same physical infrastructure. An example of this could be a provider that has a Service Region which includes three AZs. Each of these AZs could be a different datacenter some 10 – 15kms apart. One of the more common use cases for deploying a cloud-based application in a region with AZs is the ability to distribute your instance across multiple AZs. So, if an instance fails in one AZ your application can handle requests on an instance in another AZ. While not as robust as a fully implemented DR plan there is still a high element of resiliency with this use case. In CloudHarmony the number of AZs for a region is denoted in brackets next to the region identifier.
Let’s examine a comparison of IaaS compute service locations for three of the more popular cloud providers – AWS, Azure and Google.
If we focus in on Europe, we can see that all three providers have a significant footprint in this region with Azure looking to have a considerable edge in terms of service regions covered. However, for potential customers that wish to deploy a cloud workload and make use of redundant AZ coverage the keen eyed among you would have noticed that there is almost parity between the cloud providers (Azure and Google each with seven service regions with multiple AZs and AWS with six.)
Knowing this kind of information may assist users of CloudHarmony data to decide where they want to deploy their cloud-based application. Is resiliency more important than latency? Only you can tell, and with CloudHarmony we provide the information to allow you to make these important decisions.
This is but a single example of how knowledge of cloud service locations covered in CloudHarmony can help users of this information make strategic decisions on their cloud migration/deployment journey. I am interested in what other ways people may use this information, please feel free to comment below as to how CloudHarmony has assisted you on your cloud journey.