By Trevor Patch, Principal Architect for Cloud Adoption

The term multi-cloud has become extremely common and holds a different meaning depending on one’s perspective or exposure. For Presidio Federal, the multi-cloud definition is rooted in the fundamentals of cloud combined with potential strategy, economic benefit, and risk mitigation. As a multi-decade value-added partner for OEMs, enterprises, and government agencies, we can reference back 15-20 years where most applications were constructed in a monolithic fashion with many of the front end, middleware, and backend functionality of workloads operating all on the same piece of dedicated physical or bare-metal hardware. Environments with many applications often co-mingled with each other on top of the same hardware. This era often was limited by the complexities of compounding advances in technology, and very large teams of humans attempting to keep up with the learning curve. Design processes, and belt-tightening measures often became a limiting factor with massive existential risks to the organization in the event of human error in compiling runbooks and playbooks used for technical specification requirements of workloads and associated infrastructure.

Often coined “technical debt,” many of those same legacy applications and infrastructure design flow processes still exist today. Therefore, organizations that do not specialize in technology nor have the budget to invest in processes and teams, often incur additional technical debt. Many popular and successful virtualization solutions from ”compute” OEMs that have hypervisor software worked because of the lack of friction with legacy workload deployment models. Over the course of the virtualization revolution, the technical debt often increased as the physical restrictions lessen given the capacity for virtualization on a per server basis increased.

So, where does the value of “cloud” providers come into the picture? Many of those public cloud providers are not providing a “new” value proposition in the market of managed services. They instead have revolutionized how those managed services are consumed through a swipe of a credit card and a click of a button. As a result, development teams have been emboldened to resolve the technical debt, such as decoupling applications into microservices, without the organization’s infrastructure team delivering network, compute, and/or storage on time . Many public hyper-scaler cloud service providers (CSP) like AWS, Azure, Google, and Oracle have very comparable services. However, those services can vary in a multitude of ways based on the philosophy and investment by the cloud service provider. The same is true of private cloud-scale solutions from many commonly used OEMs. Multi-cloud is still rooted in the fundamental agility of consuming a single cloud. Moving to multi-cloud decreases the need for an organization to operate a very large infrastructure team, provides more strategic choices for resolving technical debt, and eliminates the need to operate a workload that competes with more agile competitors.

Read the other sections of this article:

Part 2: Networking: A Brief History

Part 3: The Move to Zero Trust

Part 4: Public Cloud Network Topologies

Part 5: Third-Party Network Design Configurations

Part 6: Secure Cloud Network Architecture Road Maps

Part 7: The Way Forward