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.