LocalData

customer want to know

node fails, service still online

Are there any software limits to the architecture.

I don't think it's a useful question. I would rather deal with technical features than buzzword compliance.

are there hard maximums which require major equipment upgrades? In simpler terms, no forklift upgrades.

When I can power on a new node and it auto joins a cluster

How they answer what the limit is

Ok Chris: @fdmts What technologies are driving the change to scale out

Is it a consistent namespace across all nodes or components in the architecture.

@andriven All systems have limits. When a vendor says "no limits" I hear "we didn't scale test it hard enough."

a 4 node cluster provides exactly 4X the performance of a single node

in defense of non-scaleout, if you can predict your growth and environment, a non-scaleout architecture might make the most sense financially. I'd argue that almost no companies can accurately predict that in a 3 year window though.

I think we handled the drivers to scale out in an earlier question. I mean ... containerization seems like a biggie.

we argued about this for years - just because something can scale, doesn't mean that it really is scale-out. Need to understand the limitations. Of course, not everything must be infinitely scalable to be useful.

@fdmts partly agree - sometimes I'll distinguish between theoretical limits (i.e. our filesystem can grow to 32 exabytes) and what they've tested/QA-ed especially.

I like where Chris @fdmts is going with this..what triggers the BS detector when vendors talk "scale out"

@fdmts agree about limits, but solid tech and qa rigor should lead to limits that 99% of customers can't reach

@dinisco #IBreakThings

It's also about minimum size and the linearity from there. I think if you have lots of upfront requirements to achieve scale, you are simply planning for capacity growth, not scaling out.

Non-scale out typically requires you to provision capacity ahead of when you actually need it which becomes very expensive.

good question, plenty of BS, anytime there's talk of a masters or slaves, any node more important than another means not true scale out

@dinisco More seriously, you never remove a bottleneck, you just move it around. Recall the happy days when the whole industry freaked out about how RAID rebuilds on 1TB disks would take longer than MTBF on another disk in the set.

workloads that are very latency sensitive simply don't need it, the cost of coordination between nodes isn't worth it

Adding the same hardware to a solution without being able to use it. Think DataDomain. You would buy a solution for the capacity you needed then when you needed more capacity you would have to buy a whole new DataDomain and use it as a new target

Most of EMCs current products.

Adding more disk shelves.

My network closet.

Oracle Databases... Most businesses simply throw TB's of RAM at them to make them run better and avoid licensing charges.

Legacy batch HPC approaches.

Anything where you say "I loved my first; I hated my ninth" - e.g., NetApp, Data Domain, etc.

Truly, most cloud services are not transparently scaleable. You still need to provision individual servers and services incrementally.

@dinisco going back to my EMC days, I do remember candid latency comparisons between Isilon, VNX, and VMAX with some solid technical explanation about the latency involved in any scale-out architecture.

the need for a large namespace warrants it, but there are cases where isolated islands of data make sense

Sounds like the argument about what is truely hyper-converged. :)

It's not scale out if your workload is has to be sharded and mapped to specific nodes so that each time a node fails or is added, you have to manually remap everything.

It's not true scale-out if adding nodes does not provide linear or near linear increase in performance.

When one of us uses Azure and the other uses GCS, and we have to interoperate.

it's the happy, buzzy, credibility-building successor to "hybrid cloud"

it's the reality that we live in now that there are legacy cloud environments.

Hybrid cloud is a compromise. Multi-cloud means you've removed the distinction between on-premises and public cloud.

Pricing arbitrage, feature arbitrage

@jhughes I know zero people who actually do pricing arbitrage between cloud vendors.

Go to LHC1809bu at VMworld to find out! I have been asking people this question for a while. Most say it is when they use multiple clouds. Not a fan of that response.

if I'm a bit less cynical, I see it was companies living in multiple IaaS or PaaS environments, doing so intentionally, and thinking about how to move workloads back and forth. SaaS sits outside of that.

@fdmts this is my pet peeve bc many just think multi-cloud is apps on one cloud and others on another. Not really multicloud in my mind. Latency is huge issue

@johna_white Well what's a better one? Wide area ESX?

AWS ☑️ Azure ☑️ GCP ☑️ - all the ☁️s

Cloud is not one destination. Most enterprises will rely upon a collection of Multi-Clouds.

why use one cloud provider when you can spend twice as much with 2

Smearing a single app across multiple cloud providers is almost always a mistake.

@fdmts It's a "nice to demo" feature but even if you do live costing the portability is too hard to be worth it often due to the weight moving data. It almost cries out for a cloud data management layer. ;)

Hybrid cloud will be the way of the future once you get common data and network planes working across multiple clouds. It will allow for much better decision making and curation of cloud.

There is a spectrum implied in multi-cloud - to some its JBOC (just a bunch of clouds) to others it's federated hybrid cloud with application logic spanning clouds

Data at rest in the cloud is cheap. Why lock yourself into a single cloud provider.

@patrickrogersca Lock yourself into a single cloud provider and get on with solving business use cases. Not worth the time to optimize between the major public providers.

@fdmts Actually, I don't know if the multi cloud application here is really arbitrage but rather using other clouds like Azure when you want to integrate with Active Directory or Google when you want to use some special capabilities (AI / ML) primitives.

Some users are treating multi-cloud like they did with multi-OS. Choosing different clouds for different apps based on bit or preference.

For example, most workloads in AWS run in Linux while most in Azure, it's Windows.

@fdmts Could be acceptable... NSX plus Linked vCenters will allow you to use multiple cloud locations as one.