During a ‘hybrid cloud’ workshop for a major cloud operator, I was asked an interesting question:
“How is a cloud service provider’s data centre different from a typical enterprise data centre?”
As I began to answer, I realized that this wasn’t as simple as you might think.
Before we get into the details, though, we’d better clarify what we mean by a ‘cloud service provider data centre’.
What is a cloud service provider data centre?
Data centres are already well established as a concept — once upon a time it may have just been a fancy term for a server room, but as they’ve grown over time, standards have been developed for them and they became a specialized field of IT. Professionals can now get certification relating to them, which covers a range of issues from design, layout, dimension, power, cabling, temperature, environment (humidity/ventilation), safety (fire/smoke), security (authorization/locks) and several other aspects.
Cloud service providers are also well known. They offer cloud platforms to the public (or private in some special cases) where organizations/users can deploy and manage resources using various methods including APIs, portals, command line tools and shells. Resources may include compute, networking, storage, infrastructure, security virtual appliances, apps, containers, identity solutions, databases and so on.
Cloud service providers allow their customers to purchase access to the benefits of physical infrastructure without needing to build or buy that infrastructure themselves.
So, what are we referring to when we talk about cloud service provider data centres?
Cloud service providers have many customers they need to provide service to, and therefore need their own data centres (commonly referred to as zones) with their own distinct needs. In these physical facilities, customers of the cloud service provider can deploy and manage their virtualized or non-virtualized resources without having physical access to the actual facility.
Before we can start examining what makes them special, we do also need to consider the kind of scale we’re looking at.
Hyperscale vs enterprise scale
A major difference between a cloud service provider’s data centre (zone) and an enterprise data centre is scalability. As enterprise data centres are made to serve a specific organization, they don’t need to be as large.
Unlike an enterprise data centre, a cloud service provider data centre is providing cloud services to organizations all over the world. This means they’re probably going to be enormous.
These ‘hyperscale’ data centres theoretically offer infinite resources to customers, and can be as large as 10 to 20 soccer grounds. They are modern in terms of design and provide several segregating layers inside, with separate racks, power sources and infrastructure. This way, if any one of the layers fail inside the cloud data centre, it doesn’t affect the other layers due to the segregated design. As a customer, you may never get the chance to see it from the inside even when you hold resources inside it. Access is usually restricted to the cloud service provider’s staff only.
The most common way to achieve scalability or extend capacity of an enterprise data centre is to connect it with a public cloud data centre. This is how most organizations add scalability to their on-premises data centres.
SDN or traditional?
All cloud data centres use Software Defined Networking (SDN), which means they use software/programmatic control of hardware and infrastructure resources. That may not be true when it comes to enterprise data centres, though most enterprise data centres these days are SDN-based.
Unlike enterprise data centres, which only use a single networking controller, cloud data centres use several types of controllers in their infrastructure. Along with the network controller, which is the heart of SDN architecture, there are other controllers too including compute, storage and app controllers, to name a few. There can be more than one controller for every resource category (in the case of multiple vendors offering the same resources) over that public cloud. For example, in the compute resource category, two compute controllers are used if the compute resources offered by the cloud service provider use two different vendors.
Don’t be surprised if you find several controllers in the design of a cloud data centre, which serve various resource categories and vendors.
Data centre connectivity
It’s common to find three data centres in a certain region that are all connected with each other.
There can be several regions covering various geographical locations. All these regions are connected by a high-speed, route-optimized, and secure backbone. This is very helpful for customers of cloud service providers as they can move resource(s) between data centres or choose the data centre for deployment of their resources without having to worry about physical distances.
Of course, this isn’t achievable for an enterprise data centre, which is usually made to serve a specific organization in a particular location. Though modern enterprise data centres are connected too via VPNs or MPLS backbones with their sister sites, their resource movement is limited to their own few sites. Data centre connectivity also provides the additional benefit of disaster recovery by allocating a secondary site in case of primary site failure.
Access to resources
As mentioned earlier, organizations/customers can deploy, manage and/or configure their resources in cloud data centres via several ways including APIs, portals, command line tools, developer tools, shells and so on. The key to this is automation, which reduces the staff costs for cloud service providers. It’s rare to find this level of automation while managing or configuring resources at enterprise data centres.
A hyperscale data centre consumes much more power on account of its sheer size, with an average of 20 to 50 MW and 10 to 25 KW per rack. Some consume hundreds of megawatts. That said, they offer an economy of scale when it comes to power consumption; they’re bigger so they consume more, but they’re also more efficient. If enterprises were to build their own data centres to match the kind of services that hyperscale centres provide, far more electricity would be required overall.
Maintenance and troubleshooting
All the maintenance inside a cloud data centre is the responsibility of its staff. This includes patches, updates, service pack installations, hardware/firmware updates, infrastructure related matters including underlying physical servers, cabling and switches. As a customer, you are only concerned with the assets you have deployed.
For example, you may want to troubleshoot a connectivity issue, like finding out why your virtual machine in the cloud is unable to access the Internet. In that case, you can use simple cloud-based troubleshooting tools to figure out the issue, however, these cloud-based tools are very limited in scope and functionality, which means they can’t provide as much detail as you normally get from traditional tools used in your enterprise data centre.
Similarly, the routing and access rules are much simpler than they are in an enterprise data centre, due to the fact that users get access to their resources in a cloud data centre at an abstraction level.
Ownership of resources
Almost all the physical resources inside an enterprise data centre are generally owned by the organization that maintains it. This isn’t the case for a cloud data centre. The organizations taking advantage of this infrastructure don’t have ownership of the infrastructure itself, merely the software deployed on it. They’re renting the resource(s). Purchasing is simply not an option for customers of the public cloud.
In short, cloud data centres are hyperscale, offer a variety of resources from various vendors, support automation, and are ideal for organizations looking to extend their enterprise data centre capacity.
I hope you enjoyed reading this blog post. Please keep learning and broaden your knowledge using APNIC resources.
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.