Tag: multi-cloud

Multi-cloud: Strategic Choice or Confusion? | Blog

The multi-cloud environment is not going away, with most large enterprises favoring this approach. Multi-cloud allows enterprises to select different cloud services from multiple providers because some are better for certain tasks than others, along with other factors. While there are valid points to be made both for and against multi-cloud in this ongoing debate, the question remains: Are enterprises making this choice based on strategy or confusion? Let’s look at this issue closer.

The technology industry has never solved the question of best-of-breed versus bundled/all-in consumption. Many enterprises prefer to use technologies consumed from different vendors, while others prefer to have primary providers with additional supplier support. Our research suggests 90% of large enterprises have adopted a multi-cloud strategy.

The definition of multi-cloud has changed over the years. In the SaaS landscape, enterprise IT has always been multi-cloud as it needed Salesforce.com to run customer experience, Workday to run Human Resources, SAP to run finance, Oracle to run supply chain, and ServiceNow to run service delivery. The advent of infrastructure platform players such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) has reinvigorated this best of breed versus all-in cloud debate that results in multi-cloud or single-cloud adoption.

In a true multi-cloud world, parts of workloads were expected to run on different clouds seamlessly. But increasingly, interoperability is becoming the core discussion in multi-cloud. Therefore, it is not about splitting workloads and working across the cloud, but ensuring one cloud workload can be ported to another cloud. While debating a pedantic definition of multi-cloud is moot, it is important to acknowledge it as the way forward.

Most cloud vendors now realize multi-cloud is here to stay. However, behind closed doors, the push to go all-in is very apparent across the three large vendors. Let’s examine the following pro and anti-multi-cloud arguments:

Picture1 3

Both the pro and anti-multi-cloud proponents have strong arguments, and in addition to the above points, there are many others on each side. But the truth is increasing numbers of enterprises are adopting multi-cloud. So, when an enterprise proactively adopts a multi-cloud strategy, does that mean it’s a strategic choice or strategic confusion about cloud and its role as well as the other factors outlined above?

This is a hard question to answer, and each enterprise will have to carve its cloud strategy. However, enterprises should realize this strategy will change in the future. No enterprise will be “forever single cloud,” but most will be “forever multi-cloud.” Therefore, once they embark on a multi-cloud strategy, it will be extremely rare for enterprises to go back, but they can change their single cloud strategy more easily.

In enterprises with significant regional or business autonomy, multi-cloud adoption will grow. Enterprises may adopt various cloud vendors for different regions due to their requirements for workloads, regulations, vendor relationships, etc. Instances will continue to exist where some senior leaders support certain cloud vendors, and, as a result, this preference may also lead to multi-cloud adoption.

On many occasions, enterprises may adopt multi-cloud for specific workloads rather than as part of their strategy. They may want data-centric workloads to run on a cloud but may not want to leverage the cloud for other capabilities. Many cloud vendors may play “loss leaders” to get strategic enterprise workloads (e.g., SAP, mainframe) onto their platform to create sticky relationships with clients.

Many software vendors are launching newer offerings proclaiming they work best with client’s multi-cloud environments. As an ecosystem is built around multi-cloud, it will be hard to change. In addition to AWS, GCP, and MS Azure, other cloud vendors are upping their offerings, as we covered earlier in Cloud Wars Chapter 5: Alibaba, IBM, and Oracle Versus Amazon, Google, and Microsoft. Is There Even a Fight?.

Given multi-cloud drives “commoditization” of underlying cloud platforms, large cloud vendors are skeptical of it. Integration layers that provide value accretion on abstract platforms rather than core cloud services is an additional vendor concern. However, eventually, a layer on top of these cloud vendor platforms will enable different cloud offerings to work together seamlessly. It will be interesting to see whether cloud platform providers or other vendors end up building such a layer.

We believe system integrators have a good opportunity of owning this “meta integration” of multi-cloud to create seamless platforms. However, most of these system integrators are afraid of upsetting the large cloud vendors by even proactively bringing this up with them, let alone creating such a service. This reluctance may harm the cloud industry in the long run.

What are your thoughts about multi-cloud as a strategy or a confusion? Please write to me at [email protected].

AWS Outpost, Azure Stack, Google Anthos, and IBM Satellite: The Race to Edge-to-Cloud Architecture Utopia | Blog

In earlier blog posts, I have discussed chapter 1 and chapter 2  of the cloud wars. Now, let’s look at chapter 3 of this saga, where cloud vendors want to be present across the edge to cloud.

Since the days of mainframes and Java virtual machines, enterprise technology leaders have been yearning for one layer of architecture to build once, deploy anywhere, and bind everything. However, Everest Group research indicates that 85 percent of enterprises believe their technology environment has become more complex and challenging to maintain and modernize.

As the cloud ecosystem becomes increasingly central to enterprise technology, providers like Amazon Web Services, Google Cloud, IBM, and Microsoft Azure are building what they call “Edge-to-Cloud” architectural platforms. The aspiration of these providers’ offerings is to have a consistent architectural layer underpinning different workloads. And the aim is to run these workloads anywhere enterprises desire, without meaningful changes.

Will this approach satisfy enterprises’ needs? The hopes are definitely high as there are some key enablers that weren’t there in earlier attempts.

The architecture is sentient

This is a topic we discussed a few years back in an application services research report. Although evolutionary architecture has been around for some time, architectural practices continue to be rigid. However, the rapid shortening of application delivery cycles does not provide architects with the traditional luxury of months to arrive at the right architecture. Rather, as incremental delivery happens, they are building intelligent and flexible architectures that can sense changing business requirements and respond accordingly.

Open source is the default

As containers and Kubernetes orchestration become default ways to modernize and build applications, the portability challenge is taken care of, at least to some extent. Applications can be built and ported, as long as the host supports the OS kernel version.

Multi-cloud is important

We discussed this in earlier research. Regardless of what individual cloud providers believe or push their clients toward, enterprises require multi-cloud solutions for their critical workloads. This strategy requires them to build workloads that are portable across architectures.

The workload is abstracted

The stack components for workloads are being decoupled. This decoupling is not only about containerizing the workload, but building services components that can run on their own stack. This capability helps to change parts of workloads when needed, and different components can be deployed across scale-distributed systems.

With all this, the probability of achieving architectural portability may indeed be different this time. However, enterprise technology leaders need to be aware of and plan for several things:

  • Evaluate the need for one architecture: In the pursuit of operational consistency, organizations should not push their developers and enterprise architects toward a single common underlying architecture. Different workloads need different architectures. The focus should be on seamless orchestration of different architectural choices.
  • Focus on true architectural consistency versus “provider stack” consistency: This consistency issue has been the bane of enterprise technology. Workloads work well as long as the underlying platforms belong to one provider. That is the reason most of the large technology providers are building their own hybrid offerings for Edge-to-Cloud. Although many are truly built on open source technologies, experienced architects know very well that workloads porting across platforms always require some changes.
  • Manage overwhelming choices: Enterprise architects are struggling with the number of choices they now have across different clouds, terminologies, designs, and infrastructures, which makes their job of building a unified architecture extremely difficult. They need automated solutions that can suggest architectural patterns and choices to drive consistency and reliability.

So, what should enterprise architects now do?

Enterprise architects have always been envied as the guardians of systems, as they set the broad-based strategic underpinning for technology systems. Going forward, they will be bombarded with more choices and provider-influenced material to choose their underlying platforms to build workloads. All of the platforms will be built on a strong open source foundation and will claim interoperability and portability. The architects will need to be discerning enough to understand the nuances and the trade-offs they have to make. At the same time, they should also be open and unsuspicious of technology choices. They must have transparent discussions with technology providers, evaluate the offerings against their business needs, and assess the drivers for a unified architecture.

What is your take on unified architecture from Edge-to-Cloud? Please share your thoughts with me at [email protected].

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

  • Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.