3 must-haves for your multicloud architecture

Most cloud architects are finding that their world is suddenly heterogenous. Where once we could focus on a single public cloud provider, today we have as many as four in the mix. The patterns of architecture have moved from intra-cloud to inter-cloud, and that is where complexity and risk come in.

As a result, architects, including myself, have put together processes to make sure that most bases are covered—much like a pilot uses a preflight checklist. These include items such as cross-cloud governance, security, operations, etc. However, a few things that are vital for success are often forgotten. Here are my top three:

Cross-cloud, centralized user account management. If you’re looking for true success with multicloud, you need to treat the group of public cloud providers as a single cloud as much as possible. There should be a common user management layer to add, remove, or change user accounts using a single point of control that’s capable of talking to each cloud natively.

Besides making user management much less onerous, centralized account management improves security by making the identities represented to each cloud provider consistent. Identity access management systems will be more consistent as well, and thus cloud security will be, well, more secure.

Cross-cloud resource management. This category can be AIops tools, cloud management platform tools, or anything that monitors the use of resources, such as storage and compute (including provisioning), and most important, automated deprovisioning to return the resource back to the pool. This stops the cloud provider from billing for that resource.

I get a call a month from somebody in a panic because they allocated a huge amount of cloud resources and never shut them down. The bills are enormous, and it’s tough to get the cloud providers to forgive them, mistake or no. Multicloud means more to keep track of and a greater chance of costly mistakes. 

Normalization of assets. Let’s say that you’re using the same database brand in each cloud within your multicloud. This is clearly not cost- or operationally efficient, considering that you’re likely paying more than you should for license costs, and one cloud running the same resources is going to be much less than the others.

IT departments often think that using the same database in more than one cloud is redundancy—not keeping all of your data eggs in the same public cloud basket. If one cloud provider “breaks bad” on you, you can move to the same database on another cloud.

Although I’m certainly down with risk reduction, it may not be the best approach to run production databases using the same technology and brand in more than a single cloud provider. Other methods are just as risk-averse, not as complex, and less costly to run. Again, just a checklist item to define better ways to solve the same set of business problems.

Building multicloud is not easy. I suspect we’ll get much better during the next few years by learning from the mistakes of others. For now, let’s avoid being the ones who make the mistakes.