3 cloud architecture secrets your cloud provider won’t tell you

Do you have an optimized architecture? This means that your solution maximizes efficiency and minimizes costs. You’ve selected the right cloud resources to configure the best storage systems, databases, and compute platforms—at least that’s what you think.

What I’m seeing out there, over and over again, is the selection of the wrong cloud resources for the wrong reasons. Cloud providers are pushing something that maximizes their revenue rather than being right for you. 

So, here are three cloud architecture secrets that you’ll never hear from your cloud provider:

Secret #1: Non-native resources are often better than native ones

You’ve probably heard that it’s better to go with a native database, cloudops system, or security system that’s part of a single public cloud offering. Now that we’ve moved to a mostly multicloud world, that’s just not the case.   

It’s much better to pick general-purpose and heterogeneous solutions that span public clouds instead of a native solution that’s only good on a single public cloud. You’ll never see this in the architecture guide offered by your cloud provider. Non-native resources should be considered each and every time.   

Secret #2: Keep data in the cloud

Cloud solutions that depend on a lot of data ingress and egress are almost never a good idea. No brainer, considering that you’ll see data leaving and entering a public cloud provider on your monthly cloud bill, and it is not cheap. However, this is often overlooked when considering a core architecture.   

This is typically an issue for IT organizations that want to keep some data on-premises, usually due to outdated concerns about compliance and security. The providers won’t advise you otherwise, considering that they make bank on the exit and entrance charges. Keep your data in the cloud if you’re looking for the best performance and security and the lowest costs.

Secret #3: Security should be systemic 

I often see security systems bound to a single application’s workload. The application leverages its own encryption system, identity management systems, role-based security, etc. Typically, these are also native to a single cloud provider where the application is hosted. 

The issue here is that a cloud provider wants the workload in the cloud ASAP and will often advise for the speed of movement instead of a sound security architecture. This can’t scale, considering that you’ll be creating one-off security solutions for all applications, and it will create so much security complexity that you’ll have security issues just from the complexity.

Security should be systemic to all things in the core architecture. Applications should use very similar security patterns—and the same security systems, if at all possible. Again, these are typically non-native, and your cloud provider won’t benefit as much.

By the way, I’m not picking on cloud providers. They are only acting in their best interests. However, the savvier you are, the more you know when to accept and reject their advice.