How do we rationalize these notions? Cloud-native? Cloud-ready? IBM divides the world into cloud-centric (native/ready) and cloud-enabled.

Everyone is coming to the same conclusions, but I'm eager to nail down similar terminology we can all get around and drive in order to help the marketplace move faster.

Here's the original interview I did with @adrianco two years ago on Netflix and their approach to 'cloud-ready' on AWS:

cloudscaling.com

While technical, I thought many of the key points here underscored the changing face of applications, particularly those that run on clouds.

Cloud native seems to imply built in the cloud. Cloud ready implies that it's a datacenter app that could be run in the cloud. I think cloud apps need to be antifragile. If you can run a chaos monkey against your app without destroying it, it's cloud ready.

So, "cloud ready" implies a degree of testing against fault, while "native" and "ready" speak to where the app was originally architected to run?

Antifragile isn't about testing, it's that the presence of adversity makes the system stronger. There are fewer assumptions made, so less brittleness in the architecture.

Thanks for sparking this discussion Randy. While not perfect, we use these design principles to guide our cloud-native efforts at Message Bus:
• Workloads deployed and managed across multiple cloud infrastructure providers to be highly distributed
• Dynamic wiring/routing built on stateless configuration
• Designed to accommodate failure with dynamic policy driven optimization to ensure QoS
• Elastic/scale-out of nodes (computational and data grids)
• Versionable, incrementally deployed, testable, coordinated resources
• Overall system/service/tenant monitoring provided across providers
• Fully multi-tenant across clients, sub-clients and their users and system administrators
• Operational expense with automated metering / billing

Porting aside, I'd argue there are "Burl Ives" workloads that will not get cloudy [1] by virtue of purposeful inattention by ISVs, preclusive highly customized design choices, or otherwise premises / latency / isolation / legal / license / cultural / etc. oriented requirements.

It does not preclude placement within some variety of ultra generalized x86 basis cloud (today [2]). It's simply a question of how well it runs as measured against these concerns.

Shops running "Burl Ives" workloads will never stop asking if it is permissible to get more cloudy. If it means enduring the legacy for another few seasons of market innovations to get there [3] so be it.

[1] youtube.com
[2] intel.com
[3] dilbert.com

dilbert.com

Great conversation! Another influence (similar to Jay's point) is whether the application is Legacy or Greenfield. The easier to answer is Greenfield: Should be cloud-native from the start. Period. Legacy is a much more complex answer. Ideally, they would be made cloud-ready or re-written to be cloud-native. But frankly, that's not realistic for many legacy applications at the moment. And there are a number of reason for this ranging from: cost to politics to priorities.

At some point we will reach a tipping point where the number of cloud-native/ ready apps outnumber (is number the right metric?) the number of non-cloud apps. At that point, the value equation changes.

@Adrian - LOLz
@Tim - Great point on the 'from the start' and I'd expect as future app developers keep getting minted we'll see far more of that -- especially with increasingly mobile first generation workers entering the workforce

I'm going to close this thread out soon. In terms of "anti-fragile", the book Anti-Fragile comes to mind:

amazon.com

It was one of several in the list shared by Ben Black that I think clearly represents the 'new thinking' on cloud and cloud applications.

Ben's tweet:

twitter.com