CLEUR

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!

The key measurement is the value of the 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.

With data residing in multiple clouds and possible using multiple solutions/vendors, this will be a challenge for many companies running their apps both on-prem or in the cloud. #CLEUR #multicloud #challenges #costefficiency #onprem

(edited)

Ironically, its measuring the cost of local assets (private datacenters) that is harder. We know what overall IT spend is, but less what is allocatable to serivice/product A vs. B.

I 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!

(edited)

- 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.

@rquelle - I disagree a bit. Public cloud costs are documented but have too many options to get right without automation. Private cloud costs are still very subjective
. I see lots of bias in rate cards and service catalogs as folks try to defend their turf.

(edited)

@dfloyer makes a good point. One of my favorite customer conversations was with a financial services company about their need for agility above all. The reason? Getting a new fraud detection/prevention capability out in response to bad actors was key.

SaaS applications are also an integral part. Salesforce and ServiceNOW are cloud platforms in their own right. Many enterprises are asking who owns the data, and wanting their own data on-premises to allow greater integration of these business processes.

- Don't commit to a venue or paradigm unless you have at least a draft "exit" strategy to get your data to another venue. We know that things will change. Even if you don't move to another venue, you may adopt a different service or deployment model.

Avoid 'boiling the ocean'. It'll never happen. Tackle local, individual problems while keeping in mind the big picture.

a major sin of IT in data centers was the heterogeneous mess, need to be careful we don't recreate silos in the clouds.

In my opinion, there are different multicloud for different purposes. If you want real-time improvement of systems of record, you are likely to need a tightly integrated hybrid cloud...

operating multicloud seamlessly looks like an utopia today. As long as there will not be a standardization effort adressing certain processes and interfaces. Marginal cost efficiencies are offset by large amount of efforts to make things hold together.

As @ballen_clt says, change is inevitable. If you try to build the perfect master plan, you'll find yourself implementing that plan in a world that has changed.

Simplifying the programmability of multiclouds requires infrastructure-as-code tooling to stand up compute, storage, and other resources in automated fashion across clouds and clusters. It also requires AI-driven auto-development of images, containerized apps, serverless function

If you want to drive robotics and IoT at the Edge, you are likely to want a loosely connected cloud with ability to push the operational AI out to the Edge and process data in real-time, with an overall control plane.

from a #technology standpoint, its easier to stick to use a minimal number of #cloud service providers when building a #multicloud.

I don't need a "seamless" experience. Indeed, to steal a phrase from a Yelp blog from 2015, seams are *desireable*. That's where I can take something apart and put another part in.

- I had a CIO ask me last week to give him a 3 year plan for cloud strategy. My advice was to only do that if he's willing to revisit it every 6 months. Some enterprises are working on stuff now they decided years ago.

Its the way we've always built our networks; its the way we are building applications today.

Progressively harder question and capability. Where we get to the concept of observability. This problem is too big to take an infrastructure based approach. You have to understand the app at a services abstraction vs. an infrastructure abstraction.

- You need 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.

a good way to optimize containerized apps in #multicloud is to utilize logs and reporting to assess any weaknesses in the existing architecture or to identify any needs for managing the system in order to scale

The first requirement is picking tools that are designed from the start to support multiple clouds. The way a tool like StealthWatch gathers data for its threat analysis on premises differs from the cloud, but the capability remains the same.

Goes back to the multi-cloud question. What set of capabilities are so unique to multi-cloud that you want to take on this advanced observability question? The answer to this latest question is in the drivers for multi-cloud for your organization.

It all depends! First comes ensuring the value created by the applications, and the enhancement to other applications.

- For the record - I still think it's too early for a single app to be deployed across multiple clouds well. App A will likely be one place and App B in another location. We need clear requirements between them to make sure users aren't impacted.

But as @ballen_clt and @jennjshin note, "observability" is paramount, whether for security or performance.

@CTOAdvisor Yes. 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.

optimizing apps in the #multicloud can depend on the organization. organizations interested in optimizing networking needs to consider speed and reliability factors, i.e. latency whereas optimizing security requires logging vulnerabilities (i.e. IP, hacking, etc)

still emerging - just as managing and securing multi-vendor environments has plagued IT for decades, it has not been solved for cloud yet.

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 (1/2)

The first thing to come to mind is ensuring that whatever you are chosing is flexible and modular. You want solutions that can be used together *or* independently, and across your private *and* public datacenters.

@darkkavenger the other point is whether we need yet another abstraction layer (a kind of "NSX") for security, or rather have cloud vendors set up a kind of consortium to build industry standards. The current complexity is not sustainable. (2/2)

Such a wide question. 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.

from a #datascience perspective, always make sure that compliance requirements are met and sensitive materials is kept secure. from a #technology perspective, regular reporting and monitoring is essential

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.

Moving applications or parts of applications to the data, and the APIs to enable this, are a key parts of a distributed multi-cloud environment.

My VMware employee answer? NSX... My industry analyst answer? It's not that simple.

"The Unix Way" - collections of interoperating, flexible tools, continues to serve us well in running large-scale, multi-cloud systems.

Automation is a best 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.

NSX does as good if not the best job for the technical part of connectivity. This is way more about governance and people vs. the technology.

- multi-cloud strategy is only as good as the weakest link. Any enterprise should ask how the vendors that support them enable multi-cloud. If a key vendor only runs in "x" venue and doesn't play well with others, the strategy isn't worth much.

One way to accelerate the deployment on #multicloud while minimizing risk is to consider integrating cloud services for operational functions, such as monitoring.

@darkkavenger I'm not sure that multicloud security can be addressed adequately with an NSX-type "layer." Security is an architectural and operational imperative that needs to be addressed pervasively throughout multicloud.

to be clear I meant that perhaps we need to build an abstraction layer for security; abstracting each cloud's own security features into an universal set that works regardless of the underlying cloud security capabilities or how they're named.

Skills, change to process are two right off the top

Here's my recent #SiliconANGLE article on harnessing Kubernetes to monitor and control the multicloud fabric: https://siliconangle.com/2019/01/18/using-kubernet...

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).

Great point by @darkkavenger - cloud is not a utility - skills, management, security all differ greatly. Kubernetes is not a "magic layer", just a base to help standardize How Kubernetes fits into the multi-cloud discussion

Organizations should be looking to migrate or Kubernetes. That's a mistake. They should be looking at how to integrate K8s as part of their long-term strategy for supporting cloud-native apps. K8s isn't a consolidation/replacement platform.

Shouldn't

The biggest challenge imho is the end to end lifecycle issue on apps. Lots of management challenges once the apps are deployed and can that be addressed b4 apps deploy?

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.

On the positive side, Kubernetes significantly normalizes the way not only is an application packaged and deployed, but also how it is managed and configured (ConfigMaps and secrets patterns, "operators", etc). That is significant!

Organizations should be looking to migrate to Multi-cloud. If they are really that advanced, I'd argue very few if any of us on this thread are qualified for that conversation. And I respect everyone on this thread.

scale, security, and compliance might be a challenge but that might be addressed in "state" ...feels like this is something not talked about much

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.

dang shouldn't be looking...

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

I have yet to find an enterprise who isn't using Kubernetes. None as "the one true way, all in", but every one of them has *some* Kubernetes running. Perhaps in dev, or in build pipelines.

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?

- More mature CMP's are required for serious multi-cloud adoption. CMP's in theory also help orchestrate different flavors of K8s across venues. Not sure that any of them do that well (yet).

Will K8s be a resource hidden from consumers? Will it be the primary interface for developers? Or will it power a serverless framework?

Again Kubernetes isn't the destination. Neither is multi-cloud. It's about a set of capabilities. Are these services required for the desired capabilities. Or are they just the new thing.