eWeekChat

A5: (1/2) Choose tools that work across multiple clouds. If you are using a single native cloud, the provider tools may suffice but the reality is most enterprise customers (1) don’t want to be tied to a single cloud (2) may need capabilities that require multiple cloud platforms

A5: lots and lots of internal discovery and assessment, you need to know where all of your data is, what applications are business critical, do this first, then document and deploy your MC platforms

A5: Cross cloud portability needs to be a design consideration for any greenfield application & part of the test plan. Make opensource or cloud-native technology choices that are standards based & not proprietary ones wherever possible. Use a common DevOps toolchain across clouds

A5. Unfortunately there isn't a thing called "right blueprint" for multi-cloud. Too many nuances and considerations (tech stack, latency, operational tools, skill-set) ... and each ends up creating their own version.

A5: Be consistent where you can. application delivery pipelines, languages, deployment mechanisms. Consistency that still allows for taking advantage of that cloud choice benefits and not abstracting away it's value.

A5: understand what your workload needs are, prioritize your pain points, know the strengths/offerings of clouds under consideration

A5: (2/2) Also the reality is that most #enterprises are hybrid and will have some assets and systems in their data centers and others in #cloud or #SaaS. Tooling from discovery to observability to optimization should ideally support that hybrid scenario.

That said - start small with a few workloads that need to operate across clouds, decide if they are independent parallel clouds or you need interaction. If latter, ensure the experience is good before scaling out. Cloud elasticity is great and all but if you don't start correctly

A5: dont add security post deployment, include this in your overall deployment strategy, integrate security into your multicloud strategy with stakeholder buy in

it becomes unmanageable fairly quickly

@arnlopez - well said. Need to understand all the assets and identify what needs to be multicloud and why so?

@arnlopez True that. I wished multiple elements of infrastructure (security, networking etc) were shifted left in the decision making process

agree with the comments about consistency, making it as seamless as possible by avoiding unnecessary differences between offerings

@arnlopez Agreed. Both security and observability need to be built-in upfront.

multi-Cloud may not be for all, as it may be complex for you to manage, so start with One Cloud, identify why you need it , see the gains, then move to multi-cloud only if you do need.

@ramsba great point on starting out small and building from there. don't boil the ocean

@GaneshJKRam Agreed as well. And discover those assets and dependencies as well as map them to business services.

if you do not have Dev Teams and Cloud Practitioners in house, get trained before you start . You can start with Edge Cloud for CDN, Load Balancer, WAF , BOT etc. So, you can start by leveraging these acceleration and security and data and compute from centralized clouds.

A6 Examine the complete app architecture prior to beginning building to ensure dependencies on a single cloud are identified and portability requirements to other clouds are defined and designed. Post-implementation redesign is expensive and error-prone.

@bernardgolden The challenge with this is convincing decision makers to adopt an approach that triages apps to find candidates where some degree of modernization is warranted versus lift-n-shift only. Hard to optimize spend or do cost takeout w/out touching the app architecture.

A4. (1) Be clear on the architectural choices driving workload placement in single vs multiple clouds. (2) Invest in skillset, tooling, operations - DevNetOps, DevSecOps etc.

A4:
Observability tools can help with managing usage and cost, also need a cloud agnostic security solution to keep your users and data protected

(edited)

A4: Optimize your spend vs. your actual need so that you can proactively avoid unnecessary costs by understanding organic growth trends and future planned events. Like insurance or cell phone plan, it’s important to pick a #cloud provider that is right for your needs & plan ahead

A4: We have leveraged Kubernetes operators that could run in any k8s environment – using cloud agnostic open source or other enterprise software will be critical to success in multi-cloud. There are cross cloud cost or configuration management solutions in the market today.

A4: Ask yourself: "what is my business trying to achieve?" "what are my risks to that result?" if you can answer those it can push towards a decision. Is the main risk time? money? complexity? politics? Work the risks backward

Interesting quote I heard from a recent Enterprise on multi-cloud networking. "I don't want to gold plate my infrastructure and later find that my apps don't deliver". "I'd rather start with the most problematic apps, and then build infra underneath"

A4: Ultimately it comes down to making sure you can deliver service levels customers expect without going over budgeted spend.  Proactive scenario planning to understand how business driver growth can impact your IT resources and spend is important

@GaneshJKRam agreed on the Kubernetes talent, very useful, especially if they know security too

@ramsba agree, workload considerations should be top of mind. this isn't an all or nothing approach

A4 Understand the use case you are trying to address. In our work, we've identified 11 different use cases that all use the term 'multi-cloud.' Each providers different benefits and imposes different requirements and constraints. Use case drives everything else.

@ramsba agree on DevOps, DEvSecOps tooling and making it simple to build, deploy , debug/monitor the apps.

@ramsba - Interesting thought. Goldplating is definitely bad - in the cloud can be cost prohibitive and unnecessary architectural complexities.

@bernardgolden Nice one. In that same order. Use-case > architectural choice

@bernardgolden - good one. Go multicloud only if you need to.

@bernardgolden @ramsba So that means we have to PLAN our deployment ahead of time???

Q4: Make it easy to deploy applications, use standard practices like Terraform providers, automation frameworks , and Multi-Cloud Monitoring and Observability tools.

@bernardgolden +1 for "Start with the outcomes". However, these need to be actually business-centric outcomes and not just technology goals dressed up to pretend like they are biz goals.

@mdcarlson Heh

Q4: Offer specific use cases with some Code samples , API snippets, that work best for those use cases and a way to deploy those templates/code and APIs integration.

Open source and open standards, ideally end-user driven communities. Portability. Requiring app teams to have an data extraction strategy from day one. Don't be afraid to bring cloud concept to on-prem where it makes sense.

A3: Cost is the biggest challenge on any single cloud and gets exponential dealing across multiple clouds. Leveraging technologies proprietary to a cloud makes it very difficult to go multi-cloud. Though the capability gap has minimized not all clouds are still equal.

I'd say Cost is the effect - the challenges are mostly around either speed of operations, the NxM matrix of capabilities that someone needs to dig into, skill-set gap especially in Enterprise.

A3 Cost is something to be managed, whether on one cloud or multiple clouds. Most organizations confront higher-than-expected bills when their traditionally-designed apps confront a hosting environment designed for cloud-native architectures.

A3: Increased architectural complexity, disaster recovery planning, and security policies are just a few #multicloud challenges. #CostOptimization is absolutely a key challenge especially when cloud resources are over-provisioned, leading to wasted operational spend.

(edited)

Early to cloud customers are trying to get those apps running - so they don't feel the pain of cost as much. Minute you go past 20-30 VPCs etc - the cost suddenly shoots to the forefront.

A3: "is it worth it" This is a hard question. There is value no doubt, and often a lot of it. But is it right for you? Cost is part of it, but the opportunity cost is another. Yes it might be cheaper in my bill, but is it cheaper in my time?

A3: cost is a big one, especially with cloud application sprawl inside the organization but security is also a big one

That said - we've seen enough enterprises focus on their careabouts well. If they care about speed of operations, and getting apps to deliver on their digital experience, then cost is the price you pay for that... given current macro climate, it certainly is a big factor

@bmcsoftware agree on the complexity of the architecture, requires lots of due diligence and planning

@arnlopez - completely agree. Cost management cannot be an afterthought. Need to cost mgmt as part of design.

Q3: Cost and parity of features for products and services. e.g (1) Take Serverless, or Cloud Functions. the Dev Frameworks and tooling are all not at parity, (2) the CI/CD integrations are not consistent, (3) e.g Marketplace options have different integration models / providers

@bernardgolden Seems like there is a spectrum of responses to this that vary over the timeline of a cloud migration. Early on, the response might be "this too shall pass" but after multiple quarters of unexpectedly higher costs the patience begins to wear thin.

@bernardgolden Good point - if you're not Cloud Native, cost is likely to be an issue, regardless of multi-cloud or not

@bmcsoftware agree, we hear a lot about how Medium and small size enterprises do not want multi-cloud because of the complexity, For multi-CDN/Edge complexity outweighs the gains from reliability if one provider can offer performance and reliability the customer needs.

A4 Also understand that running an app across multiple clouds requires work beyond the app itself -- cloud infrastructure, use/rejection of cloud-specific services that require mapping/encapsulation (e.g., SQS from AWS), and storage.

@bernardgolden Plan to address all of these areas as part of an app-centric multi-cloud initiative.

@bernardgolden If the business goal is resilience, is running the app on multiple clouds really the "best" way to accomplish that outcome? Are you managing the risk of a major cloud provider losing a region or something less dire? Can you really afford to mitigate against that?

The biggest issue we see is data gravity locking into particular cloud providers. This gravity is often created before an application scales and leads to unwanted spread across clouds.

@mdcarlson Not always. this is a question of size of the enterprise as well. An S small to medium size company can get most benefits with one providers , at least in Edge Cloud Space.

Another major challenge is security. Clouds bring appealing modern identity and role-based security concepts but they break down outside of the context of a single cloud, leaving SecOps teams to solve security challenges with rudimentary security tools at cloud scale.