Meta or micro cloud architecture? You need both

As the person heading “the cloud project,” you spent the past few years, during the pandemic and before, working to migrate most of the traditional on-premises applications to the public cloud. To date, you’ve moved 15% of the applications and data.

This is an impressive feat by any measure. However, the board of directors’ focus is no longer on what’s been accomplished. Now they’ve called you to a meeting to review some of the decisions you made along the way. Because a single cloud provider ended up being the “preferred cloud,” the board wants to know why that provider’s solution was “always the right answer.”

Here’s a simple fact: One provider rarely has the best or optimal solution because you can’t leverage best-of-breed features from the other cloud providers’ native systems. Perhaps one has a better artificial intelligence platform, another is better at devops, and a third supports a compliance system that could have saved the company more than $500K last year in fines from failing an audit.

What happened was also simple. You focused on cloud architecture in the narrow versus cloud architecture in the wide. In other words, you hired only those trained in a single cloud provider. Now you have skill sets for that cloud provider covered, but you missed opportunities to acquire skills for services native to the other cloud providers. Your staff probably doesn’t understand meta cloud architecture. Nor do they have a firm grasp on cloud architecture in the wide or multicloud, but they understand the narrow, single-cloud approach just fine.

It’s not entirely your fault; it has a lot to do with how we’ve subconsciously trained ourselves to approach architecture.

The issue first came on my radar when some of the better cloud architects I know complained that they were having trouble finding gigs. They found that most enterprises focus on a single cloud platform and look for new hires who are certified in architecture, development, security, etc., on those specific platforms.

I’ve advised people for years to get those pieces of paper if they want more money and/or a career change. Considering the market right now, people with AWS, Azure, or GCP certifications will have their pick of jobs.

The trouble is not with those who have knowledge of a single cloud provider. It’s the thinking a few years ago from those who sent cloud migration and development down this path in the first place. How can we expect a cloud architect with a specific skill set in a specific public cloud to take a wider look at possible solutions in other clouds that might offer the ability to create much better and more cost-effective solutions? In other words, we created “group think” around a single cloud platform that might have the most optimized solution 30% or 40% of the time. The other 60% to 70% of the time, you’re wasting money and adding risk.

Today, too many IT shops focus on micro cloud architecture or solutions around a single cloud provider. We need to shift our focus to meta cloud architecture and take a more holistic view of potential solutions, and even consider traditional platforms and approaches. This includes all public and private clouds, on-premises solutions, and even the option to leave some applications and data where they are.

Our lack of a wider view means we lose the opportunity to create truly optimized solutions using best-of-breed technology. The result is usually more cost, more risk, and less agility down the line. Most in the C-suite will notice that impact. Eventually, the board of directors will too. Good luck in that meeting.