Not necessarily cloud, but a lot of these patterns have to do with asynchronous distributed systems design (for example leader election, all the queueing patterns, sharding, circuit-breaker). CQRS is part of that (eventual consistency, scalability, etc.). Distributed systems are not necessarily tied to the cloud, but it's a very good fit because of the flexibility the cloud offers.

There's a lot of people out there doing distributed systems that are hosted "indoors" (Or should I say "on earth"? What's the opposite of "cloud"?). A lot.

Don't you agree that putting "cloud" on the title may be misleading?

'What's the opposite of "cloud"'

"on-premise"

So what is an on-premise cloud?

Lol. Or "private clouds" as our CFO calls them...

Not really. Them being cloud design patterns says nothing about being able to to be used outside the cloud, just that the people who made them designed them for the cloud.

> designed them for the cloud

I guess I have a different understanding of designing for than you them.

Yes, you clearly do. If they were thinking about the cloud and what patterns might be appropriate for it, then it's being designed for the cloud. As I said before, just because it's designed for A doesn't mean it isn't also applicable to X, Y, Z, just that they weren't specifically thinking about those when they wrote the document.

Similar like they called new Core .net before, "cloud optimized" framework! It doesn't have absolutely nothing to do with cloud, but marketing department needs to push "cloud everything" because Satya said so. Useful and nice list though...

Actually, I don't see it as pure marketing fluff to call the new ASP and .NET Core "cloud optimized". Breaking the framework into smaller pay-for-play components to reduce deployment footprint and allowing for xcopy deployment of self-contained binaries without a globally installed .NET runtime really does help enable new scenarios for cloud containers and microservices.

Am I reading your comment wrongfully or are you saying that making things modular is great because, well, "the cloud"?

No, that's a fair interpretation of my comment - after all, the meaning of "cloud optimized" is kind of vague. However, if you compare the new version and previous version and the new version ticks more positive boxes for cloud usage scenarios, then it's not unreasonable to call the new version "cloud optimized".

Beyond the modularization efforts, one could look at the Linux port and dramatic performance improvements in the same light.

The Asp.Net core are on record several times saying the primary goal was to be able to cram more websites per host for Azure Websites to reduce costs and to remove the issues of servicing a machine wide framework. Sounds like 'cloud optimized' was a good fit in the early days! :)

I think he's right in terms of deployment scenarios.

In contrast, the "old style" was to setup a physical server manually: install the OS, install all the dependencies for your application, configure everything manually. If you need to scale out or replace a broken server, you repeat these steps. There are of course various levels of automation that can be done with this, but dealing with physical severs meant at least some manual effort was always required.

In this case, I read "cloud optimized" as you can easily deploy to the typical "cloud" server instance or container (which is basically an installed OS with enough config to get it on the network). Your application doesn't have any dependencies: for example, .NET Core (framework) is bundled.

That's not how I read it. Rather, it makes sense for a cloud-focused company/development team to focus on efforts aligned with that cloud-focused strategy. The work in .NET Core and ASP .NET Core clearly fits this description.

Having things modular have a myriad of benefits, fitting the cloud being just one of them. Making things modular is good design in my book way before the term "cloud" even existed.

Modular things also have drawbacks. They need to be versioned, deployment is a lot more complicated, etc.

I feel that in the case of .NET Core claiming that the changes were cloud-focused is valid. After all, .NET was already in place and Microsoft didn't really need to make it that modular. It did do it and it spent a lot of resources doing it, in order to follow its cloud strategy.