

Enterprises confront many challenges as they incorporate multicloud computing into their digital transformation initiatives.
On Tuesday, Wikibon gathered analysts and cloud experts online in a #CLEUR Community CrowdChat, a targeted discussion forum, to discuss steps for enterprises to succeed in a multicloud world. Here are some of the takeaway comments to key questions we asked:
As moderator of this CrowdChat, I decided to start it off with a scoping question, just to make sure everybody was roughly aligned around the same frame of reference. Here were the principal definitions put forth by participants:
Of course, I added my own definition to the mix: “Multicloud refers to any cloud computing implementation where there are two or more public and/or private clouds across which workloads and data support specific apps and need to be managed through a single pane of glass.”
The case for multicloud comes down to business technological architectural imperatives, rather than the advantages of this approach for any specific application. This was the thrust of many comments:
However, the architectural pushback against multicloud was also mentioned by some participants:
One of the chief market drivers behind cloud-native is the need to future-proof applications against platform churn.
According to Max Mortillaro, “perhaps an important factor is workload portability / mobility / compatibility. Build apps in one format, execute anywhere, move wherever needed / wherever the pricing is best. No need to re-architect apps every time the platform changes.”
Jennifer Shin stated that “kubernetes and containers save a lot of time and effort in being able to launch an app or microservice. [They also enable] standardization and minimizes the amount of time needed to get an app up and running.”
I added that “lift and shift to the next cloud platform requires refactoring legacy apps in containers. Portability, scalability, efficiency, migration.”
Kubernetes contributes to frictionless portability and migration of older apps, said rquelle: “As an application developer, the ability to control my application runtime environment (containerization) and hand that off to a well-thought out orchestrator for deployment (Kubernetes) helps me concentrate on the business problem I’m solving, rather than infra…. What I see a lot is new application development taking advantage of new patterns (‘cloud native’), yet our customers wanting to apply some of the advances in deployment to their older apps as well.”
Different participants approached the discussion of multicloud journey from different angles. Chief among those was:
Kubernetes may not be a one-size-fits-all environment for application migrations, and even if it were, there are so much complexity in available distributions that migration is anything but straightforward. According to rquelle: “Challenges are in two forms; suitability to the Kubernetes way of doing things (not all applications are a great fit) and the variation in Kubernetes itself (auth, networking, storage all pluggable interfaces, and hence potentially different).
Migration of all existing IT assets to Kubernetes may not be feasible or even desirable, said Max Mortillaro. “Have enterprises adopted K8S yet? Many orgs still lag behind. 1st challenge is whether existing ‘legacy’ apps, can be refactored at all for the cloud. Only after we can talk about multicloud challenges.”
Conversion of existing apps to make them ready for migration to Kubernetes may be more trouble than it’s worth, even if it were technically feasible. David Floyer said that “one challenge is interfacing with existing applications. Converting existing applications is NOT an option for most enterprises. Finding ways of using interfacing and enhancing existing applications is one important challenge.”
The learning curve for Kubernetes migrations may be steep, said Jennifer Shin. “Companies that are unfamiliar with #multicloud will need education to understand how Kubernetes works and understand the overall architecture as well as the usual cloud technical necessities, i.e. reducing latency, disaster recovery.”
Migrations may be quite limited, in terms of the scope of resources moved to Kubernetes, or they may be more enterprisewide. According to Keith Townsend, “For those looking to adopt K8s, they should be looking to how they expect to use the platform. Will it be a general purpose cluster/resource similar to VM farms? Or will it be the foundation of your PaaS?….Will K8s be a resource hidden from consumers? Will it be the primary interface for developers? Or will it power a serverless framework?”
Build the right multicloud management skills and partnerships, said Max Mortillaro. “Besides working with seasoned professionals with extensive understanding of each cloud vendors capabilities? It becomes an almost inextricable endeavor and because of it choices have to be made on the scope of cloud vendor an org has to work with.”
Multiclouds should be built and managed in a building-block fashion. According to rquelle, “It’s important to “[ensure] that whatever you are choosing is flexible and modular. You want solutions that can be used together *or* independently, and across your private *and* public datacenters….. As an example, one wouldn’t want to rely on your deployment tool alone to ensure that applications are configured properly (though it should help with that). Invariably, a new team with particular needs will use a different tool. So, you also want to observe actual traffic…..’The Unix Way’ — collections of interoperating, flexible tools, continues to serve us well in running large-scale, multicloud systems.”
Architecting the multicloud according to the distribution patterns of data is a key principle, according to David Floyer. “One element is to understand the sources of data, and put in place a distributed data architecture. All the tools need to reflect the distributed nature of the IT world, from files systems to backup, to security…. Moving applications or parts of applications to the data, and the APIs to enable this, are a key parts of a distributed multicloud environment.”
My core observation on this was that “automation is a best practice. AIOps is an emerging best practice for automating using machine learning inline to multicloud management. Security — the bottom-line protection use case — is the core AIOps use in multicloud management.”
Transparency and observability are key to multicloud management and optimization. Several participants contributes thoughts in this regard:
My two cents on this matter is that “for security across the multicloud, observability needs to be pervasive. So do identity, permissioning, trust webs, etc. Much of the ongoing policy enforcement needs to be automated and containerized and managed in federated deployments.”
Simplification is in the eye of the multicloud beholder. According to Keith Townsend, “This problem is too big to take an infrastructure based approach. You have to understand the [multicloud] app at a services abstraction vs. an infrastructure abstraction.”
Bobby Allen took a different tack. Rather than focus on high-level abstractions, he tweeted that simplifying the multicloud management requires “low-level analytics on container utilization (allocated vs. used resources) but you also need app level analytics to understand how things you changed ‘under the hood’ impacted end-user experience.”
Rquelle stressed the experience simplification that comes from standardizing on high-performance multicloud tooling. It comes down to “picking tools that are designed from the start to support multiple clouds. The way a tool like [Cisco] StealthWatch gathers data for its threat analysis on-premises differs from the cloud, but the capability remains the same.”
Multiclouds are complex IT infrastructures. Nevertheless, rquelle stated that “measuring the cost in cloud is actually pretty straightforward, as cloud providers are great at billing on consumption models. What’s a heck of a lot harder is planning and optimizing!” However, he added that “ironically, it’s measuring the cost of local assets (private datacenters) that is harder. We know what overall IT spend is, but less what is allocatable to service/product A vs. B.”
David Floyer prefers to focus on “the value of the [multicloud] application to the enterprise, rather than the resources it takes. The key measures are its usage, its contribution to business processes and its contribution to business agility.”
Speaking from personal experience, Jennifer Shin says that she “learned the hard way that an important part of managing the cost of running cloud-native apps is making sure there’s a notification system in place when costs starts to increase exponentially. Automation is great… until it starts costing you a lot of money!”
Bobby Allen observed that multiclouds can be complicated assets to track, in terms of impact on the enterprise bottom line. “We first need to agree on the factors that make up the cost. Each team does this differently today. (network, labor, software, monitoring, backup). Most only look at the cost of the resources not the other stuff on top of or around the cloud-native workloads.”
To see the full CrowdChat transcript, visit this page. You can carry on the multicloud conversation at Cisco Live, which will take place Jan. 28-Feb. 1 in Barcelona. Even if you’re not going to the event, please tune into theCUBE for live interviews with Cisco executives, developers, partners and customers during Cisco Live.
THANK YOU