People sometimes ask me what it felt like to complete a full multi-year migration journey from on-premise hosting into the cloud. My answer is always the same: for the parts we were able to transform, it felt like we were changing the world. However, the “lift and shift” components that were too hard or too expensive to deal with felt the same as it did to the move from physical to virtualized infrastructure five years prior to the cloud migration. The reality is that for better or for worse the transitional nature of technology means the work is never done.
Investments in hardware and software used to have life cycles between three and five years whilst assets depreciated. With cloud computing, however, companies can afford to experiment and change often due to its feature-rich toolsets. Plus with a pay-for-play finance model, the barrier for entry is lower than ever. As a result, cycle times are now more like six months or even less. The wheel still never ends, but now spins faster. So why do it at all?
If you speak to most C-level executives these days, you can be certain that their organizations will have at least one cloud initiative of some kind in progress, either tactical or strategic. They know moving to the cloud is imperative. They don’t want to be the next Blockbuster Video and go the way of the dinosaur for missing a chance to use IT as a competitive edge and be an industry disruptor.
These same C-levels however are less clear as to what they are going to do when they get there – they just hope life will be better when they do. The sobering realization is that organizations talking about cloud migrations are missing the point. The real benefits are only ever realized if you transform into the cloud and adopt new architectures. A startling parallel is organizations looking to adopt secure access service edge (SASE) and zero trust who describe the change solely as a network migration.
My brilliant colleague Tony Ferguson reminds me often that enhancing something that should no longer exist is a common mistake by engineers in all markets. His top example is the electric “engine. Sometimes you must completely reimagine something from the ground up for it to be truly transformative and impactful.
Much like how the electric vehicle is transforming the automotive industry, new architectures are the real power of the cloud. Microservice applications may look the same, but under the hood, they are not. Reimagining applications through new microservice architectures to bring simpler, cheaper, faster, and more scalable designs are how to truly achieve a competitive advantage. Something that rehosting alone does not do.
The few who’ve achieved cloud transformation or were “born there” have a distinct advantage over those who’ve simply migrated onto it. Deconstructing siloed applications into a series of distinct highly aligned but loosely coupled layers gives you something that those who migrate don’t have – a choice!
Having run development teams in the past I can tell you they like nothing more than exploring new services, forever tinkering and seeking perfection, or at least until the next big thing shows up. Today, we call this innovation – Apple calls this “thinking differently.” Challenging the norm and never accepting the status quo is the role of a good disrupter after all.
So what is the next disruption in the area of the cloud? In my view, it’s having a choice to pick and mix services across multiple cloud providers. When I started my cloud journey, I was vendor-agnostic in my cloud platform thinking and offered three for my organization to use. It wasn’t long, however, before a natural gravity well formed. A single cloud vendor started to dominate. But was this because the vendor was better than the others? Not particularly. The reason came down to two realities. The first is that it’s difficult to become an expert in more than one platform. Many organizations struggle to build and seek talent with experience for one cloud vendor let alone two or more. Like lemmings following each other, the choice came down to which platform they happened to experiment with first. The second reality is that having a private network acts as a drag on multicloud adoption. Not only is a private multicloud network expensive and complex to implement, but there is a constant obsession with bandwidth and latency. Network performance limits the potential of multicloud adoption and prevents true objective selection. Developers are forced to architect within a single cloud platform to avoid poor performance.
Many who are adopting multicloud are doing so to create a disaster recovery safety net. Very traditional lift and shift thinking, but justifiable as many of us had data centers designed solely for business continuity in the past. The interesting thing is, however, cloud disruptors do not think of delivering this way. They think about architectures that are highly resilient and are designed for resilience in the event of failure, not warm standby. Netflix chaos engineering is a great example of this in action. So, if we are not thinking of multicloud in terms of disaster recovery why would we have one? The answer is that it comes back to choice; specifically, gaining competitive advantage through having the choice to support ever-evolving business models.
Cloud platforms are differentiating themselves in new and exciting ways. Capabilities such as artificial intelligence, machine learning, and analytics are all emerging unique selling propositions (USPs) between providers. But if you do not have a multicloud strategy, how do you take advantage of each platform's competitive edge? In my experience, you need two crucial components.
The first is good Cloud Security Posture Management (CSPM). As mentioned earlier, finding engineers who are experts in even one cloud is hard, let alone more than one. This is unlikely to change. Being able to deploy a set of tools that can provide configuration assurance is a real win when you need a secure baseline over multiple cloud vendors. Gartner states that through 2025, 99% of security breaches on cloud platforms will simply be the result of misconfiguration and human error. Engineers and developers want to create great products. Reducing the chance of human error will allow them to focus more on building better feature-rich solutions across multiple clouds. Deploying these tools is essential for managing risk.
The second and most crucial component is a way to communicate between services across multiple cloud vendors securely without drag. Solving this problem is not easy. Most are forced down a route of creating independent transit network hubs which sit in between vendors to broker communication between cloud vendors. Unfortunately, this can yield unacceptable latency. The performance gains developers seek often evaporate and they become forever hostage to a platform. Even if the performance could be addressed, how do you secure that connectivity as developers do not want to be building complex virtual connections and building firewalls?
This is where SASE and zero trust come to the rescue. If you want to connect two objects (e.g, apps, users, data) together using the most secure and optimal path, then inline cloud-native zero trust solutions are the most logical way to do so. By adopting SASE and zero trust architectures, developers can adopt a multi-vendor, a cloud-agnostic application using best-of-breed platform features to create the most resilient, scalable, and innovative solutions. Zero trust architectures have had a powerful impact on both security and performance when connecting users to applications, but they’ll have an even greater impact by connecting applications to applications across multiple clouds as it evolves.
Many organizations have gained a key competitive advantage from using just a single cloud vendor platform. Imagine the power if they could harness the best of all of them. Cloud interconnectivity through SASE and zero trust is the key to unlocking this vast potential. So, if the cloud is an imperative, then zero trust architecture for multi-cloud strategy is how to level up to make the most of it.
What to read next