This is a five-part series about the costly mistakes organizations commonly make while building a cloud architecture. Part one explained how organizations moving to the cloud can quickly lose visibility and control over their data processing and detailed how to avoid that mistake. Part two looks at the ways doing it yourself can go wrong. 

What would you do if your business demanded that you build a cloud network with a future-proof architecture and consistent design across multiple clouds? (Did I mention that your network will need to provide embedded security with operational visibility and control and, on top of that, optimize cost?)

Would you start a complex web of automation scripts to build your own network? 

OR 

Would you prefer to buy a single, consistent, and repeatable cloud architecture with enterprise support? 

According to a recent EMA report, multi-cloud networking teams report difficulty in building a consistent network across their multi-cloud estate, with 97% of organizations facing significant challenges – notably monitoring and capacity management, as well as visibility and bandwidth – when implementing and managing connections between their networks and the cloud. Many enterprises running mission-critical workloads would prefer to buy vs. build this type of solution.

Surprisingly, I have noticed that many ill-informed organizations still commit the DIY (do-it-yourself) mistake. They think they can hire developers, utilize CSPs’ native networking and security constructs, and build a cloud network using automation scripts. That’s a flawed, time-consuming, and costly approach. While there are several challenges with this approach, let us examine some of the critical ones. 

CSP-specific automation scripts such as CloudFormation are only relevant to a particular CSP. They will fail in a multi-cloud scenario. And according to a Microsoft survey, 95% of business decision-makers said that multi-cloud was critical to their business success. 

Supporting the automation script would engage critical resources to perform mundane tasks rather than being part of business growth and strategic initiatives. These scripts don’t have any centralized control plane. There is no “brain or intelligence.” It is mainly run it and forget it. If the network conditions change (for example, a new BGP route is learned), the static automation script cannot take any action based on the new state change. There is no feedback loop available.

The behavior of the network could change anytime. You could have a spike requiring that you auto-scale the infrastructure. You could have an attacker trying to inject ransomware into the network. The brainless automation script cannot adapt to these changes. 

If the automation engineer becomes sick or leaves the organization, the knowledge is all gone, and it will be nearly impossible for a new person to understand and enhance that automation script.

Not to mention, the cost of hiring or replacing that person is rising steeply due to a multi-cloud networking skills shortage.

Recommendations

While a DIY solution may seem easiest and most cost-effective in the short term, investing in a born-in-the-cloud cloud networking platform dedicated to keeping your business on the cutting edge will set you up for long-term success and scalability. Organizations should focus their teams on innovation and time-to-market instead of constantly writing and tweaking scripts. Benefits to look for in a cloud networking platform vendor should at a minimum include: 

• A centralized controller with distributed data-plane
• Intent-based and embedded network and security control 
• Self-healing capabilities with anomaly detection 
• ML-based network behavior analytics
• Robust Terraform support that would allow you to write the Terraform independent of the CSP
• Support for all major CSPs to run your business-critical apps

Vendor pitfalls to avoid include:

• The legacy hardware vendors with immature and hardware-centric options that are unsuitable for modern and business-critical workloads
• Security-specific vendors for your cloud networking needs 
• Vendors trying to “cloud wash” their legacy hardware technology by lifting and shifting the hardware code as VM and calling it a cloud networking solution

Conclusion

Doing it yourself in the cloud – using a CSP’s native networking and security framework, and lots of automated scripts – might seem like an affordable shortcut at first, but it can quickly lead to a haphazard arrangement that creates inefficiencies and increases costs. CSP-only scripts won’t work in a multi-cloud environment, and automated scripts defy centralized control. An intelligent cloud networking platform, on the other hand, provides centralized control, self-healing capabilities, the ability to better employ machine learning, and support for all major CSPs. 

Next: Part three will examine the perils of inadequate showback and chargeback options, and the advantage of having a billing solution built on a CSP-agnostic platform.