Advertisement

Cloud Architecture Mistakes: Losing Visibility and Control Over Data Processing

By on
Read more about author Shahzad Ali.

This is a five-part series of articles examining five critical mistakes organizations face when building a cloud architecture, and how those mistakes can lead to soaring costs and inefficient – even risky – data management. 

In making their digital transformations, organizations too often lose visibility and control of their data right from the beginning. They can make the mistake of trying to build a cloud network on their own, resulting in an unwieldy hodgepodge of solutions. The lack of a proper cost-sharing model can inflate costs while leaving an organization with underutilized resources and error-prone financial planning that disrupts business. Rather than integrating security, many organizations treat it separately, leading to bolted-on solutions that increase vulnerability and negatively affect compliance. And failure to implement a data recovery plan – relying too much on what a cloud service provider (CSP) offers natively – can result in a longer mean time to recovery (MTTR).

All these mistakes contribute to the costs of cloud. But they can be avoided. In this series, I’ll explain how, starting with the initial step of ensuring that going to the cloud doesn’t mean losing control of your data.

Someone recently shared an article about a business that existed out of the cloud, citing that the cloud is very expensive. I decided to write this article because stories like these may encourage others to needlessly forgo incredible cloud benefits by glossing over the truth about cloud cost and how to control it. I want to share the wealth of experience I gained while working with CIOs, CTOs, and lead architects in the enterprise community to explain why “cloud” and “expensive” don’t necessarily go hand in hand. 

Cloud is still new to many enterprises and very different from on-premise. A new cloud architecture and discipline are needed to run and operate the cloud with the cost guards in place. There is no going back to the on-premise operating model. Any organization thinking about returning to the on-premise model or delaying cloud adoption will soon be irrelevant and forgotten. 

Cloud Cost Reality

It’s true that public cloud can be costly if not done right. Another reality is that going back to on-premise is like going back to an era when the smartphone didn’t exist. Our world is about apps, services, and anything-as-a-service (aka XaaS). The public cloud has given us many benefits at an enterprise’s fingertips that have improved agility, innovation, competitive advantage, and quick time-to-market, allowing our businesses to deliver on the XaaS economy.

Five Major Cloud Architecture Mistakes by Organizations

While cloud cost can be broken down into various buckets, the cost of cloud infrastructure itself can be controlled, optimized, and reduced when networking and security are done right. 

When I analyzed the data, I concluded that there are five major reasons or mistakes organizations make that are attributed to the soaring cost of cloud infrastructure. There could be more than what I list here, but I guarantee that if you control these five areas, you will alleviate many cloud-cost concerns raised by the board, CEO, CIO, or CFO.   

  1. Lack of visibility and control into the data processing
  2. DIY (I will do it myself) mindset
  3. Inadequate showback and chargeback options
  4. Poor security architecture
  5. Higher mean time to recovery (MTTR)

Let’s tackle the first mistake: losing visibility and control over data processing.

One of the biggest sticker shocks for enterprises comes from charges related to data processing, data storage, and egress data transfer. Enterprises using only cloud-native services must be ready to digest this additional cost. Enterprises would not observe this cost in on-prem deployments because they own the hardware, software, and architecture for data centers, branches, etc. They get complete visibility and control related to data being processed and transferred. Also, other charges, such as the cost of MPLS circuits, internet, etc., are manageable and predictable in on-premises deployments. 

Unfortunately, in the cloud, you must pay for the cost of data transfer, data storage, data processing, and sometimes even the cost of running a simple ping-type connectivity test. In the cloud, the data is charged at every stage, so much so that you must pay for the cost of log processing, for example. NAT Gateways and internet egress charges also fall into the highest pricing tier and could cost the organization a lot. 

Compounding this issue, I’ve also seen that some small and medium organizations and/or DevOps-centric cloud teams choose sub-optimal architecture. They send their sensitive and critical network traffic or data to a foreign NaaS (Network-as-a-Service) or SaaS (Software-as-a-Service), or CASB (Cloud Access Security Broker) type of product. 

These foreign NaaS/SaaS/CASB-type products add another layer of complexity. They do not provide the visibility and control mandated by most businesses. Moreover, it is flawed architecture to send sensitive and production traffic outside the organization’s control for networking and security needs. This practice will increase data transfer and processing costs, and it will cost extra to implement necessary audit, compliance, and governance guardrails. 

Cloud Architecture Recommendations

For enterprises struggling with visibility and control issues, consider this: You own the hardware in on-prem deployments, control the traffic with visibility, and build your own architecture – shouldn’t you do the same for your cloud networking and security needs? 

Adopt a solution that allows you to build your cloud architecture under your cloud accounts, subscriptions, and projects in your VPC, VNet, and VCN – an enterprise’s owned NaaS, not a foreign NaaS. This cloud networking solution must be consistent across single or multiple clouds. It must let you control your network and provide embedded telemetry and security services. 

This solution must not charge for processing and transferring the data through its data plane, which is where costs can accumulate quickly. It should be built on top of your favorite clouds, such as AWS, OCI, Azure, GCP, or Alibaba, and allow you to use native services such as EKS, Anthos, Serverless, etc., but without modifying your applications and DNS policies.

For details, refer to this Gartner study discussing various vendors in the multi-cloud networking software (MCNS) space.

Conclusion

On-premise operations may be going the way of the rotary phone, but not every aspect of the on-prem model should be abandoned. The visibility and control that teams have had over their data centers should carry over to how organizations manage their cloud architectures. Choosing a solution that allows you to build an architecture across multiple clouds while retaining control over your network will reduce extra costs for data processing, transfer, and storage. It also will help you avoid the mistake of sending sensitive and/or critical data outside the organization.

In part two of this series, I’ll explore the pitfalls of a DIY approach to cloud, which can quickly grow unwieldy and costly.