Cloud Design Patterns(msdn.microsoft.com) |
Cloud Design Patterns(msdn.microsoft.com) |
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.
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.
Don't get me wrong, I think is a lovely page (bookmarked), but I fail to see how those techniques are necessarily tied to the cloud.
One thing is to put our services in the cloud, another is to put our concepts in it.
Don't you agree that putting "cloud" on the title may be misleading?
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.
@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.
(Actually, there's several hundred million in unclaimed returns from 2012 that are about to expire.)
objectify looks interesting! but I'm a nodejs user, not java.
Beyond the modularization efforts, one could look at the Linux port and dramatic performance improvements in the same light.
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.
"on-premise"
I guess I have a different understanding of designing for than you them.
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.