Cloud as a Story - Vunvulea Radu

There were a set of updates related to Azure Redis Cache last days. If you didn't had the opportunity to use Redis Cache until now, you should know that it is a in-memory data structure stores that is used very often not only as a database or a cache, but also as a message broker. It is fully with features that can make  your life easier. Microsoft is offering this feature as a out of the box service, that you can use it from the 1st moment, no configuration or installations needed. Some new features are now appearing in Public Preview, that will make Azure Redis Cache more appealing to anybody. Azure Redis Cache Clustering Until now we didn't had to many options on Azure Redis Cache if we wanted more power from it or if we would reach the size limit of an instance. Now, in the moment when we create a new instance of Azure Redis Cache we have the ability to activate this feature and specify the number of instances that we need. Don't forget that each instance (shar...

List of all posts from this series:  http://vunvulearadu.blogspot.ro/2014/11/azure-blog-post-marathon-is-ready-to.html Short Description If you already used Redis Cache you should know that Microsoft Azure Redis Cache is based on this open source cache solution. This cache solution is offered as a service, with an SLA that reaches 99.9% uptime. Everything is managed by Azure infrastructure, the only thing that we need to do is to use it. There are two editions of Azure Redis Cache in this moment. The basic edition is formed from only one node and can be used with success when we are in the development phase or we are working on a PoC. You don’t have any SLA on the base edition. The standard edition is formed from 2 nodes (Master/Slave) and comes with a SLA of 99.9% uptime. On top of this, because we are having a multi-node configuration this edition is ready for high performance. The maximum size of an instance is 53GB for each unit and we will talk more about this in the n...

On the market there are a lot of caching solution. The same thing is happening on Microsoft Azure. In this moment we have 4 different solution for caching (Azure Redis Cache, Managed Cache Service, In-Role Cache and Shared Cache). A normal question that I heard from different people was: What kind of cache solution should I use? This is a normal question, because having so many option you don’t know what to choose. I will try to describe what are the benefits of each cache solution that are available on Azure and see what we should use. Azure Shared Cache Azure Shared Cache is the oldest cache solution that was offered on Azure and is still available (for old clients) It was retired this year and can be accessed from Silverlight portal.  This solution used to offer cache support as a service and I can say that I was able to use it with success on 3 or 4 project. The thing that I really enjoyed was the API, which was very simple to use and understand. In-Role Cache This cac...

These day I started to migrate a Windows Azure application to a new version of SDK. With this occasion we decided to migrate also the cache service to the new service that is now in preview. After we configured the cache service we was shocked to see in the trace tables a lot of logs from the cache service. Almost all the actions that are done over Windows Azure Cache Service are logged. It seems that this an issues known by Azure team, but they decided to not fix it yet. The problem with this is that this is creating a lot of noise in the logs tables and even if we tried to set the log level to minimal from cscfg files, it was without success. <Setting name="Microsoft.WindowsAzure.Plugins.Caching.ClientDiagnosticLevel" value="0" /> When this thing don’t work from configuration, the best thing to do is to go to the code and change it. DataCacheClientManager allow us to change the log level pretty easily using the following two methods: DataCacheClientLogM...

I heard more and more often think like this: “If your website is to slow, you should use a CDN.” Great, CDN is THE solution for any kind of problems… or not. Depends what is our problem. First of all let’s see what does CDN means. Content Delivery Network gives us the possibility to improve our web application performance by distributing our content in different geographical location that is closed to our client. This is a great solution when we have static content like images, videos or any kind of static content. In this moment there are a lot of great solutions, from Azure CDN that are very easy to config and scalable to EdgeCast or Akamai. But maybe our problem is not from there. What happens if users are in the same geographical region? Using a CDN may or not may improve our speed performance. The entire request will hit our servers. A bunny will tell us: “It’s not a problem dude, we live in the cloud nowadays, scale up your application on more instances”. HTTP Caching Reverse...

Yesterday, I had a talk with one college about cache mechanism. The true is that Microsoft has a lot of cache mechanism and when we talk about Windows Azure we have so different mechanism that there are times when we don’t know what the best cache mechanism for us is. We will talk about 3 times of cache mechanism that are supported by Windows Azure: Windows Azure Appfabric Cache (specials service defined by Windows Azure) Co-located Role Caching (in-memory cache – resources are shared between cache and hosted applications) Cache Worker role (dedicate role used only for cache) From my perspective we have a lot of options. What we should know from the begging about Windows Azure Appfabric Cache is that be used in combination with Windows Azure of course, but from what I saw until now we cannot have a combination between co-located role caching and Windows Appfabric Azure Cache or Cache Worker role and Windows AzureAppfabric Cache. Why we cannot combine them? Because the last two cache me...

In the last post we talked about the new in-memory cache from Windows Azure. In this post I would like to talk about what are regions and tags. For what we know until now, we can define one or more named cache in the same cache “server”. Based on the cache name, we can point to that cache and used it. At this point you should know that we have a limit of 128 named cached for a given server. But I think that this number of named cache per deployment is enough for almost all scenarios. Each named cache can contains an “unlimited” number of regions. You can image a region as a container in a named cache. A named cache doesn’t need to contain a region. We need explicit create a region in a given named cache. Very important, because a region group cache items, a region is limited to a single cache host. Because of this regions are not supported in Windows Azure Shared Caching. Each item added to a region can contain a tag. Normally, an object that is added to a cache (without being added ...

Until the last version of Windows Azure to be released, for caching we could use Windows Azure Cache. This was and is a very powerful caching mechanism that can be used without any problem. Almost all the problems related to synchronization were resolved by the framework. In this blog post a talk about Windows Azure Cache. But today I don’t want to talk about the old Windows Azure Cache. The new version of Windows Azure Cache has a new functionality: in- memory cache. Why is so important? First of all is free and the synchronization between roles is automatic done by Windows Azure. First of all what should we know about in-memory cache. Even if is free, in-memory cache have some cost indirectly. It will consume memory space from the role and also computation power. The most important resource is the memory. Because of this, based on the role size you need to be aware of the size of the cache of each role. The good part is that we don’t have any limitation. Because of this you can def...

Nu de mult a fost lansat CTP pentru Azure AppFabric Caching. In ultima perioada am început sa studiez API-ul acestuia mai în detaliu. O sa încerc în urmatoarele rânduri sa trec în revista API-ul acestuia si sa fac highlight la cea ce ii mai important. In primul rand este bine de stiut ca Azure AppFabric nu este totuna cu Windows Server AppFabric. Chiar daca cele doua se aseamana, acestea au assembly-uri diferite pe partea de client. Totodata nu avem posibilitatea sa facem switch intre Windows Server AppFabric si Azure AppFabric. API-ul care îl ofera Azure în acest moment nu este atât de larg, partea de notificari si regiuni înca nu este suportata în întregime. Am scris într-un post trecut modul în care trebuie sa se configureze Azure AppFabric. In momentul în care am configurat cache-ul în cloud, acesta ne pune la dispozitie sectiunea care trebuie sa adaugam în fisierul de configurare (aceasta v-a contine inclusiv token-ul de autentificare). http://vunvulearadu.blogspot.com/2011/03/out...

In post-ul anterior am vorbit despre cum putem sa ne definim propriul nostru mecanism de cache-ing. Dar daca ne aflam in cloud. Iata urmatorul scenariu: avem o aplicatie MVC 2 pe Windows Azure si vrem sa putem folosii un mecanism de cache-ing. In cazul in care avem mai multe web roluri dorim sa facem un sistem de cache-ing oarecum centralizat. Nu dorim sa încărcam de doua ori anumite date daca acestea sunt deja incarcate. O varianta pentru a rezolva aceasta problema este sa ne definim propriul mecanism pentru cache-ing. Nu ar fi foarte complicat, dar ne-ar costa ceva timp. Cea mai simpla varianta este sa folosim mecanismul intern de pe Windows Azure. AppFabric ne ofera si posibilitatea sa facem cache-ing la date. Acest provider de cache-ing se numeste DistributedCache , iar pentru al putea folosi este nevoie sa accesam sectiunea de AppFabric din contul de Windows Azure si sa adaugăm un serviciu. In web.config-ul aplicatiei trebuie sa adauga o noua sectiune prin care sa pute...

.NET 4.0 ne-a adus si posibilitatea de a controla output caching. Pana in momentul acesta puteam sa controlam obiectele la care sa se faca cache. Daca de exemplu avem o actiune la care doream sa facem cache, puteam sa folosim atributul OutputCacheAttribute , prin care puteam defini durata la care sa se faca cache si prin ce parametri acest cache sa difere. [OutputCache(Duration=20, VaryByParam="none")] public ActionResult GetItems() { // Executa ceva. } In momentul in care se face un call spre actiunea GetItems , se verifica daca aceasta exista in cache si daca cache-ul este valid( nu a expirat iar parametri trasmisi prin VaryByParam sunt identici). Daca conditiile sunt indeplinite atunci rezultatul se incarca automat din cache si se trimite mai departe, altfel se executa actiunea GetItems , iar rezultatul se salveaza in cache. In cazul in care dorim sa definim un provider propiu pentru output cache este nevoie sa scriem o clasa ce sa mosteneasca din OutputCacheProvider ....