Cache-Aside is an Antipattern. It forces you to define your caching logic at the application layer, and suddenly the app must care about--and actually implement--your caching strategy. This is very difficult to scale correctly and is a common source of stale data and race conditions.
Better to treat caching as part of your overall database infrastructure. If caching "hot" data is really important for your app, make sure your data layer supports read-through and write-through caching. Or use the "CQRS" Pattern and read from a different source than your writes (allowing your writes to transparently apply whatever underlying caching strategy you need to support the reads).
The MSDN article on CQRS actually has some good advice on combining it with Materialized Views and handling consistency issues. Worth reading if you're interested in solving your caching problems.
i just finished implementing a similar pattern: atomic-cache (cache+eventually consistent modifications) and while it's debatable whether the pattern belongs in your "database" layer or "app" layer, you certainly do need this pattern somewhere.
For me, my orm layer is in my app, and my database is just google datastore. I have ideas for eventually writing a db caching layer as you suggest but it's rather a lot more complexity beyond the "get it working and move on" principle.
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?
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.
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.
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.
What's going on over at microsoft? They've had a flurry of OSS announcements, a linux-for-switches fork, are posting relevant tech articles etc. This isn't the same microsoft I know. Is there some sort of change in the direction of leadership? I haven't seen any articles about changes in strategy in these directions but am seeing a lot of activity.
This article is actually pretty old, I read it months ago. It's not new for Microsoft either, they have/had the Microsoft Patterns & Practices team which develops sample applications, books, websites and libraries to demonstrate various design patterns. This is just one of them.
They are heavily focused on the cloud. They recognized (correctly) that their time of living off revenues of Windows and Office were limited and thus they need to do other things as well. But yes, I am rather surprised at how well they are handling the change :).
I have the "cloud to my butt" plugin installed. It changes all occurrences of "the cloud" to "my butt".
So you opening sentence made me laugh, thanks!
The announcement of SQL Server for Linux is very interesting; the other year when they released an ODBC driver for Linux I thought it was a significant change but it would be interesting to know how many people actually used it.
Oddly the focus on The Cloud seems to be also matched by the focus on telemetry gathering etc. I will wait to see how it pans out.
To be fair Microsoft has always posted relevant tech articles. Even 10 years ago when they were hard core only in their own development bubble they had excellent articles about architecture and scaling, etc. The MSDN has more than just simple documentation and it's always been quite an amazing resource.
Most of these changes would have had to have gotten started under Balmer. Nadella has only been at the helm for two years. If anything, Nadella has been doubling down on a plan Balmer put into motion.
Not quite true, Satya led cloud and enterprise org. before stepping into CEO. Many of the initiatives at Azure started with direct involvement from Satya. He also pushed for open Microsoft long before becoming a CEO, its just that now he is the CEO, he can make it happen.
Yes, Microsoft Patterns & Practices were there from 2002/3 onwards i remember patterns on app move from Unix to windows instead of linux and MS has Services for Unix posix 1.x compliant at that time so all basic linux tools (ls/sh/awk/sed etc) and api worked on WIndows 2003 with NFS and NIS compatibility
Interesting read. Although, I wasn't a fan of the banner asking for feedback at the bottom. I immediately clicked no without reading what it was (It was something to the extent of 'Is this page helpful?') Although, after dismissing it I wanted to say Yes but after submit I can't change my opinion.
Same here, I did the same. Also: for me all MSDN pages became reeeeaaaally slow ever since I installed Ghostery. I just see a blank page for like 5 seconds before I can see the content. More people with this problem?
[Full disclosure, I work at Microsoft]
@an4rchy, I think if you open the page in private mode it will most likely ask you again. If that does not work, feel free to contact me and I can pass on your comments (my email is my HN alias + microsoft.com).
@Avalaxy, it would be great when you click Yes or No, that you also try to add a comment about your issue or why you liked the page. I can not speak for every group, but most groups I know of review the voting and comments for all of their pages really carefully. For example, my team has a weekly discussion on this and what we plan to do to improve the pages. If a page gets a negative vote along with a comment why it poor, it is much easier to improve the page, however, if it simply has a negative vote we have to make guesses as to why it was poor.
I get that, but the point is that I accidentally clicked No because instinctively I thought that was the way to dismiss the bar (in my mind it was something like: do you want to provide feedback yes/no, to which I clicked no). Only after clicking I realized my error.
For me that's an annoying experience. It's there at the bottom of each Azure page, pops in immediately, without a chance to digest the information first. Pretty bad UI.
Better to treat caching as part of your overall database infrastructure. If caching "hot" data is really important for your app, make sure your data layer supports read-through and write-through caching. Or use the "CQRS" Pattern and read from a different source than your writes (allowing your writes to transparently apply whatever underlying caching strategy you need to support the reads).
The MSDN article on CQRS actually has some good advice on combining it with Materialized Views and handling consistency issues. Worth reading if you're interested in solving your caching problems.