When architecting cloud, geography still matters

When migrating to the cloud, it’s easy to assume that all your data and applications are just ‘out there,’ borderless. The geographical locations of your users and network infrastructure no longer matter, right?

Not exactly. Geography and regionalization still play an important role for global enterprises in architecting hybrid and multi-cloud environments. Even in the most cloud-first environments, chances are something will still need to be routed back to the data center or regionalized for different locales.

For the second episode of the third season of the Network Disrupted podcast, Sandi Jones, the AVP of Global Network Services at Manulife until September 2021, recently sat down with host and BlueCat Chief Strategy Officer Andrew Wertkin.

They discussed what Jones learned through many iterations of Manulife’s cloud adoption journey, her approach to the federation of cloud resources, and what large global enterprises as geographically spread out as Manulife should consider to maintain reliable service delivery.

Manulife’s journey to the cloud

Like most large enterprises, Manulife’s journey to the cloud began in the data center. Jones, who started at Manulife in 2014, recalled that the company, which has 34,000 employees worldwide, was largely data center-centric. A lot of software was developed and deployed in it for years.

They began to move to software-as-a-service, adopting platforms like Office 365. Then came the ‘lift and shift’ era of taking applications running on servers or virtual machines in the data center and plugging them into virtual machines hosted by cloud service providers.

The first iteration of ‘lift and shift,’ Jones notes, was simply about moving the data without changing much. It was only in follow-on efforts that the company began to take advantage of the cloud to make business process improvements.

For example, Manulife, which is Canada’s largest insurance company, previously had dozens of systems running in different parts of the company for its underwriting activities. Today, they feed all the data in those systems into the cloud for centralized synthesis and reporting, allowing underwriters to make risk decisions from a much bigger pool of data.

Jones characterized Manulife as “really aggressive” in its cloud adoption. The company first focused on Microsoft Azure as its provider but later went multi-cloud, an approach that cybersecurity expert Richard Clarke also recommends. The company has a complex network, with eight Azure regions—four pairs backing one another up—and different application stacks in each of them.

“There was a strong motivation for the IT teams if they were introducing something new or refreshing, transforming an application,” she says. “There was a strong push in all the regions to really put that into the cloud and really do it differently if they could. And we found ourselves often ahead of the curve.”

The geographical learning curve when architecting cloud

Along the way, Jones learned a few things about the importance of geographical considerations when architecting a hybrid network.

The most important takeaway? Even with the cloud, geography matters.

Don’t make purchase decisions by global committee

First, she says, global enterprises should not make big technology purchase decisions by a global committee. Just because the U.S. is pursuing something doesn’t mean that Japan should have a say in it. They might have a very different situation.

She calls adopting this mindset “really, really important,” and notes that Manulife and other companies are getting better at recognizing it.

For big technical decisions or anything else with enterprise-wide impacts, Manulife’s decision-making group includes all business lines’ chief architects and representatives from network infrastructure.

No, it’s not all in one big cloud

Second, she notes, many mistakenly think that if it’s in the cloud, geography or platform no longer matters to the network. It’s all just there in one big cloud, right?

In a word, no.

Jones recalled when someone stopped her in the hallway at Manulife to ask why his cloud instance in the U.S. comes back over the corporate data center when it tries to connect with the cloud instance in Hong Kong. They were both in Azure, he said, so why don’t they just talk?

Wertkin chimed in that, with the cloud removing so many barriers to entry, it’s easy to forget that it’s part of a broader network infrastructure. At some point that new application you’ve deployed on the cloud will have to refer to something that’s still in the data center. Or you’re going to need local access in different geographies and have to optimize the traffic between them.

The learning curve on this point can be steep for infrastructure teams.

“There’s still, I think, a long way to go with architects really understanding the implications of those things,” Jones says.

Look for the real differentiators

Jones also emphasized the importance of looking beyond current feature sets when choosing a cloud service provider. Feature offerings might change in a year and equal out. Instead, she says, consider what truly sets them apart.

“Look for, what’s the real differentiator? What are they able to do that somebody else can’t do?” she says.

The value of centers of excellence and microservices

Jones notes that establishing centers of excellence for cloud implementation can often lead to connections across organizations as they all use the same set of core tools.

“You get a lot more cross-pollination between the finance IT team and the HR IT team who might not have been talking before, but now they’re collaborating,” she says.

Furthermore, tools or microservices that teams develop can end up in a repository for others to use and contribute to.

Traditionally, IT has been responsible for soup to nuts: Requirements, building or buying solutions, service-level agreements, and delivery. Instead, with cloud, IT can deliver platform infrastructure and capabilities with a common set of guardrails. Others can then create their own applications and services on top of it.

This can lead to more regional customization within the same global architecture framework, something Jones saw happen at Manulife.

“We got to the point where, really, a lot of our decisions, were, ‘You know what? Asia, you go ahead and do that. And North America, you go ahead and do that. Those don’t conflict. They don’t have to be the same, but here’s the three places that they have to meet.’”

Jones pointed to the example of a new firewall and intrusion prevention standard that Manulife implemented, giving regions choices within a defined framework. If Asia uses a different firewall in some of its edge cases because it wants diversity, and North America would rather have the same one everywhere, or vice versa, that’s all OK.

Architecture needs to be flexible and sort of Lego-block-like… If each team achieves that in a slightly different way, but within a framework that can all fit, great. Then you don’t have to spend a lot of your time arguing about the one true way to architect something.

Really get to know your regions

Jones was based in Hong Kong and traveled throughout Asia for her first five years at Manulife. Based on her experience, she offers some advice for earning the trust of global IT teams.

It can be easy for those at corporate headquarters, she notes, to lose their understanding of and empathy for what’s happening technically—or even culturally—at far-flung locations.

“Head office is a four-letter word. And I had to really prove, once I got over there, that I wasn’t a spy from headquarters and I wasn’t there to inflict what headquarters thought on them,” Jones says.

She recommends taking the time to invest in your visits to global offices. Opt for less frequent, longer trips. Learn what’s happening on the ground and take the information back with you to share with headquarters.

Often it’s not that regional offices don’t want to share what’s going on, but more so that what we might perceive as different is just normal for them. Why would they think to bring it up?

“It makes a difference,” Jones says. “Because at the end of the day, tech is all run by humans and it’s all run for humans. So there’s only so much we can do without being there.”

To hear all of her thoughts, listen to Sandi Jones’ full episode on the Network Disrupted podcast below.