eWeekChat

A6: That if you’re not doing multi-cloud, you’re doing something wrong. Not to undermine any of the advantages we’ve been discussing, but if you’re happy with a single provider, that’s OK!

A6: Multi-cloud introduces complexity, and you want to go in with your eyes wide open. If a single provider is meeting your business needs, you should really take the time to weigh your motivations, the perceived benefits, against the complexity you are introducing.

A6: The biggest myth with multicloud is that it provides a straightforward approach for increased #reliability, cost efficiency and optimized ways of working.

A6: In reality, having the right design, architecture and operations of a workload in a multicloud environment is a must to unlock the true potential of multicloud.

A6: Going multicloud mitigates vendor lockin

@KPHariHitachi It's anything but straight forward, surely!

A6 IT execs may think that multicloud is easy-it is not. E.g., one can easily drift from RDS Postgres to Aurora for Postgres for a specific project, but that just put an end to the multicloud option. Data gravity is a problem too - apps tend to go where the data is

(edited)

@dangit_hub So true. Multicloud also includes vendor lock-in.

@dangit_hub My point too!

A6: Taking a deliberate, planned approach to abstraction can mitigate some lockin risk. Multicloud in and of itself is no panacea.

Until the vendor changes their pricing or licensing, and then you are stuck. You are back to where you were with conventional software vendors - locked in

Exactly. Multi-cloud is often being locked into multiple clouds.

Which brings us back to two very different multi-cloud strategies: 1. Trying to make everything portable across clouds for future migration, and 2. Assuming things built in any cloud will stay there, and determining which workloads/data should live in each cloud.

(edited)

A6: In a way here, the natural portability of open source in the architecture.

(edited)

Enterprises needs to make this choice and follow through with people / process / technology to achieve it

No doubt those words are often uttered!

@JamesMaguire A5: @HitachiVantara we believe that an effective #multicloud strategy or implementation is underpinned by a strong design and architecture.

(edited)

Infrastructure as Code (IaC). Always. Everywhere. For cloud infrastructure teams, your multicloud platform is your product, and development/operations/security (DevSecOps) teams are the consumers

A5: Here are three key considerations: 1) look at a workload in a holistic manner as compared to individual cloud resources – infrastructure, network, application, data and security etc.

A5: 2) design, build and operate with a right balance of reliability, efficiency and cost management. 3) manage multicloud environments with a consistent and automated set of configuration and policies for seamless integration.

A5: Lean on their vendors to help solve cloud challenges as unbiased experts. Partners and solutions will emerge.

(edited)

A5: Designate a group to own strategy and management. At a minimum, task them with instituting controls around performance and spending. Tools, capabilities, and standards are evolving, and this group should regularly evaluate those in conjunction with stakeholders and real data

A5 Use Postgres - it is available on every cloud PaaS and IaaS. Using Postgres provides complete cloud portability and vendor independence. Outside of Postgres: use standard open source software, not the cloud-specific forks. Avoid lock-in like the plague #eweekchat

A5: We have proven that even for mainly IaaS workloads distributed across multiple CSP's, using a common IaC approach is the single greatest lever to mitigate complexity

@dangit_hub I agree - manual deployment at scale, without Infrastructure as Code is a losing proposition

A5: If a companies objective with multi-cloud is avoiding lock-in, then they have to carefully govern the architecture and services decisions for each project. Easier said than done with the real-world pressures on project velocity.

A5: enterprises can help project teams by building out enterprise-wide best-practices of DevOps processes and tools, technologies, open-source components and multi-cloud software capabilities to leverage.

A5: Choose a partner and platform designed for secure multicloud that can scale and grow as your data needs change.

A4: Companies also struggle on the portability tradeoff. Taking advantage of cloud-specific services may accelerate project velocity but inhibit future workload movement.

A4 Multicloud management tools are lacking. For example, tools to make sure that patch levels are maintained, RBAC and security guidelines are aligned, that configurations don't drift, are still missing #eweekchat

#1. Complexity #2. Complexity ... #99. Complexity

A4: The biggest pain points our customers share are 1) ensuring interoperability between applications and services across multicloud 2) increased operational complexity 3) increased training requirements and a smaller pool of skilled resources.

That seems to sum it up well

A4: Hands down, management and governance. From monitoring spending and performance to data management and DevSecOps. It’s difficult and you need to be intentional.

A4: Complexity manifested across multiple domains, including governance, security, skills, operations, resiliency, etc.

A4: Centralizing multicloud management and functioning as a single cloud architecture.

A4: Managing the multi-cloud application lifecycle is a top challenge. Building on disparate services, testing interoperability of application landscapes (including with onpremise applications) and managing these consistently.

A4: Companies also struggle on the portability tradeoff. Taking advantage of cloud-specific services may accelerate project velocity but inhibit future workload movement.

A4 Integrating tools with security and governance.

Is that mostly rogue activity, shadow IT, or planned?

All of the above