Americas

  • United States

Why the cloud will never eat the data center

Opinion
Jun 08, 20217 mins
Data CenterSDNSecurity

Even if traditional data-center tasks are all moved to the cloud, there will still be a need for on-site infrastructure that will ultimately require what looks like a traditional data center.

Sometimes it’s hard to see gradual changes in technology paradigms because they’re gradual.  Sometimes it helps to play “Just suppose…” and see where it leads. So, just suppose that the cloud did what some radical thinkers say, and “absorbed the network”. That’s sure an exciting tag line, but is this even possible, and how might it come about?

Companies are already committed to a virtual form of networking for their WAN services, based on VPNs or SD-WAN, rather than building their own WANs from pipes and routers.  That was a big step, so what could be happening to make WANs even more virtual, to the point where the cloud could subsume them?  It would have to be a data-center change.

The largest component of enterprise network spending is the data center, and in fact enterprises have been telling me for 30 years that data-center networking sets their overall network requirements.  The view that the cloud will absorb the network arises from the presumption that the cloud will absorb the data center.

In this cloud-centric vision of the future, every site would be connected to the cloud and each other using the internet, just as homes, small businesses, and smaller SD-WAN sites are already.  There wouldn’t need to be any other service like MPLS VPNs because you can get to the cloud from the internet. You’d access the internet at each site using what’s now described as a secure access service edge or SASE.  You could have little SASEs for small locations, giant SASEs where there were a lot of people gathered to use their now-in-the-cloud applications. The SASE’s goal would be to create what looked like a “company network”, just as SD-WAN already does, and to make all the complexity of networking as we know it invisible.

While a lot of CFOs and line executives might love the idea of eliminating data centers, I’ve yet to find an enterprise with a serious strategy to move everything to the cloud.  In fact, there are more enterprises trying to figure out how to modernize legacy core applications that stay in the data center than are trying to cloudify everything.  Security and compliance concerns, reliability/availability, and cost management are all issues enterprise planners tell me are likely to keep their data centers rolling, maybe forever.

Even if you believe the cloud will eat all of IT application hosting, that doesn’t eliminate everything but those SASEs. An office is a bit like a home network. Where there are only a few employees, maybe up to a hundred, you can build the local connectivity using nothing more than an internet gateway with Wi-Fi and Ethernet, maybe some repeaters, and maybe a few dumb LAN switches.  As your employee count rises, those simple dumb LAN switches spread like weeds, and the cascading of traffic that daisy-chaining them to create connectivity start to load down the switches closest to the internet gateway.  We need a hierarchy of switches, backbone and edge, to form a true local network.

Daisy chains are pretty easy to diagnose, but backbones are more complicated.  We need to have some switch management, so our switches aren’t dumb any longer.  We also need a management system to manage them, which has to run on something. The cloud? Hardly, given that if our site backbone breaks, we don’t have internet and so we don’t have access to the cloud or, in fact, to any of our company’s applications. We might not even be able to share information locally because the cloud is holding all our local storage, too. Even phoning between our on-site extensions might not work, if we use VoIP.

This probably doesn’t sit well with senior management, and so let’s say our company decides to put in some servers to host local storage, share print access, and do other routine things if the internet or the cloud is down.  We add in an IP PBX to provide for on-site calling. If our site is big enough, we now have dozens of these servers scattered everywhere, with people kicking them over, spilling stuff on them, unplugging them…you get the picture. So our company gets a room somewhere and sticks all the servers in the room. The concentration quickly blows all the breakers and overwhelms the air conditioning, so we put in special facilities to power and cool everything. Servers and server networks now live in a controlled facility. Next thing you know, we’ve invented (or reinvented) the data center and we’re back to where we started.

OK, but might the cloud eat our wide-area network devices?  We can do switching and routing on servers, so even if the cloud couldn’t absorb all of networking, couldn’t we do all our in-the-data center and wide-area switching and routing using cloud servers? Not so fast.

Servers aren’t designed to push terabits of data through them. The telcos and cable companies who move a lot of data know that, and while they’ve been very interested in replacing proprietary switches and routers with something more open, their focus has been on white-box devices that are built around custom networking chips, not on commercial off-the-shelf servers–COTS, as they’re known.  Chances are that those data centers we just reinvented, and our employees, will be connected with either proprietary network equipment or white boxes, not servers.

Before we dismiss the cloud-eats-the-network theme as an urban myth, though, we have to consider another fact. While we’re not moving our data-center apps to the cloud, we’re moving the front-end traffic handling to the cloud. In fact, more application-modernization tasks are related to building cloud-resident GUIs these days than on actually changing legacy applications. These cloud front-ends gather user, customer, and partner traffic from the internet, and deliver a couple of pipes to the data center to pass the resulting transactions. All the aggregating of traffic and the structuring of information is connected within the cloud.

Every cloud provider has a private network that connects all its data centers and to its customers. These networks are getting bigger all the time. Google’s network also has to carry all its web crawling, search activity, video, music, and advertising.  Amazon’s network carries a lot of video and music traffic. That front-end traffic is focused within this cloud network, down to some pipes that carry things to the data center.

The WAN for an enterprise like this is now ten thousand internet connections and perhaps a couple of pipes between data center and cloud. The cloud isn’t eating the network; LANs are here to stay. Instead, “the network”, every wide-area network, is becoming “the internet”. Any business site, anywhere, has internet access if they have any data service at all, and that universality is what will eventually win.  SD-WAN, SASE, and the cloud are simply new technologies that accelerate the shift to the internet.

Cloud-eats-data-center isn’t an urban myth, it’s an oversimplification. We’re redefining services to include both application services (the cloud) and network services (the internet), and we’re building information technology from this new model. It’s going to have a major impact on every buyer, cloud provider, network operator, and vendor, and the changes it generates will keep us hopping for years. That should be enough excitement for everyone.

tom_nolle

Tom Nolle is founder and principal analyst at Andover Intel, a unique consulting and analysis firm that looks at evolving technologies and applications first from the perspective of the buyer and the buyers’ needs. Tom is a programmer, software architect, and manager of large software and network products by background, and he has been providing consulting services and technology analysis for decades. He’s a regular author of articles on networking, software development, and cloud computing, as well as emerging technologies like IoT, AI, and the metaverse.

More from this author