UnifiedCloud

#1 myth - is that customers need to go all-in with on-prem private cloud or all-in with public cloud. The world is multi-cloud.

“That it just exists everywhere and quickly accessible.” Understanding zone/region design is critical for on-premises to public cloud success. Latency is your planning metric for cloud success on apps/services.

The greatest myth is that everything can be can processed in one cloud, without regard for latency, cost of moving data, and government/corporate compliance. Hybrid cloud bringing together distributed nodes is an essential evolution of enterprise computing.

#2 myth - Containers or VMs. It's both. Containers are cloud native and easier to move between clouds. VMs provide backwards compatibility - until enterprise apps are released as containers. MS SQL Server - now in a container. This will move some deployments out of VMs.

IMHO the strategy of moving "all your applications" to the Cloud (CTO/CIO mandate :) ) has gotten a reality check in the recent years. Capabilities available in the Cloud vs. on-prem are very different, which translates to on-prem, Cloud and hybrid apps that we see today

The requirement for true hybrid cloud architectures is growing stronger as an IoT data tsunami descends.

#3 myth - There is no such things as a steady state for IT. The faster you adopt cloud-native formats, the more fluidity your IT department will have an infrastructure and applications technologies advance.

That cloud is always the cheaper option. It can be hard to tally all the costs of moving to and running in the cloud. There are cases where it is the most cost effective and others where it is not

"people go to the cloud to save money"

Myth - "Public cloud services aren't for enterprise workloads." Of course Enterprises are using the public cloud. @PureStorage (and many others) are strengthening / complimenting public cloud capability for greater Enterprise adoption.

Myth - Cloud is cheaper...#It_Depends

@vStewed how about containers ON vms. I'm seeing that regularly as well.

@jcefidel great point. Lots of value in hypervisor ability to preserve the running state of a VM with a persistent application (ala SQL server in a container)

@dfloyer the experience of the early pub-cloud adopters showed a change in terms of moving data to compute to moving compute to where the data is. Data gravity seems to have some pull ;)

availability is #1

database-as-a-service; storage-as-a-service, transcription and translation, real-time streaming

resiliency is the new availability.

Portability of data to Run Anywhere at Anytime.

Availability and Resiliency for the win!!!

expanding on resiliency. Public clouds infrastructures are very different than on-prem, thus designing resiliency in the app is how availability is accomplished.

Interesting to see "availability" called out as as data service.I find that many people take it for granted.

Companies value agility, but at what cost or compromise?

@WorldC3 they take it for granted until the thing they want isn't available. Then it's all gnashing of teeth and rending of clothes.

@vStewed I see people underestimate this difference all the time. Cloud applications are resilient by running across many less reliable pieces

@DeepStorageNet just because the evolution has begun, doesn't mean we're all on the same page.

@vStewed ain't that the truth. "The future is here, it's just not evenly distributed"

First that the term hybrid is widely used in different ways. Hybrid is often used to describe what many would call multi-cloud.

simple - a hybrid application is code that runs across the collective services - public and on-prem - that best deliver the intended business outcome.

Portability. Ideally apps can quickly and easily exploit the best of both onprem and pub cloud innovations along w/ cost optimization

May options!! on-prem Datacenter, co-locations, SaaS and multi-cloud available as platforms it is important to leverage the best of each of these platforms for your application needs. Building an application that can leverage the best of all worlds will be critical!!

Hybrid application is an app that pulls data and microservices both from on-prem and from a public cloud.

One useful characteristic of hybrid is in helping move code to data - i.e., latency aware distributed storage, enabling orchestration of hybrid cloud applications.

One could take the explanation one step deeper by stating a hybrid application is a collection of disaggregated services - function, API, AI, compute, network, storage, etc - that is dynamic, extensible and spans multiple clouds.

I look at hybrid from less of an “application top down view” and more of an API focus. Design your application/service with independence in mind then you can deliver, hybrid, multi, etc. solutions. The focus on design the framework allows for ultimate flexibility.

@dfloyer Yes, the terminology can be confusing. In my mind, hybrid is used for data or apps that span clouds (private and/or public). Multi simply means you are using many clouds.

It is done by native and web app. A hybrid app is made for easier maintenance and lower app maintenance costs, whereas multiple native apps can be costly to update, repair and expand.

@451research paper "Businesses are Shifting to a
Unified Hybrid Cloud" talks about this. https://www.purestorage.com/content/dam/pdf/en/sol...

Hopefully it will lead to more collaboration between those teams

@DeepStorageNet the siloed team is definitely still a thing in most large orgs, and it really bottlenecks progress unless there's excellent open communication btwn teams.

@DeepStorageNet But what will be the basis for that collaboration? The goal is to benefit from separation. Orchestration technologies will be important, of course. But will data emerge as a glue that ties services together?

This design principle is straightforward for new application (or service) development. Cloud born, developed and scaled. Taking existing apps/services is a bigger challenge and converting to a micro or serverless model. Could mix on-premises APIs with Cloud APIs.

true - the micro services approach reduces the data required in terms of OS and app binaries - but that amount of capacity is minuscule compared to the capacity required to store the data being serviced, collected, etc by the app.

Because every team become customers for the services the other teams' services.

Everything must be fast..ideally silicon speed, non-stop, secure, shared, and deeply integrated w/ common orchestration frameworks like K8s, docker, rkt.. Intent based deployments for developers/devops to declare what attributes they want for their apps, builds + pipel

Essentially, this is what I call a "cellular" approach to building microservices with microdata. That requires a federation architecture at both the services and data levels, with the zones being federated going out to the edges.

the stateless nature of micro services requires the provisioning or access to data storage to be automated. This is trivial with a single cloud, more complicated when connecting to multiple clouds.

@jcefidel Are you seeing walls being broken down between teams in larger orgs? I am not yet.

@vStewed In many ways, this architecture requires automation of data storage/access through a pub-sub topic-oriented architecture in which microservices request and are provided with the most relevant data for which they've been permissioned.

@WorldC3 Hence my hopefully. Siloization is the enemy of efficiency

@vStewed but what if we have the same control plane across multiple clouds?

@jcefidel currently universal control planes - typically provided by 3rd parties - is the only way to unify cloud services.