Skip to main content

What cache mechanism to use from Windows Azure

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 mechanism offed by Windows Azure can be accessed only from the deployments roles (NOTE: A deployment can have 1...n number of applications and roles). Because of this we cannot make this type of combination.
Windows Azure Appfabric Cache is a good solution when we need a cache mechanism that needs to be shared between different servers. It is not mandatory all servers to be hosted by Windows Azure. Using this cache mechanism we will be able to use our cache from any machine in the world that has internet connection. Don’t forget about an important think about this cache mechanism. Any machine that has the credentials of our cache can access it.
The other to cache mechanisms is very powerful mechanism that can be used by our application. When we need a cache mechanism for our application to be used only by our application I think that this caches are the best. What do decide to use? Co-location caching or cache worker role. The decision is not very simple. The good part is that the switching between them is very simple. Using the configuration file of our application we can very easy change the cache mechanism. Only when we make a switch between this and Windows AzureAppfabric Cache, in some case we will need to add some assemblies, but the API are very similar.
If we have a simple application, that doesn’t consume many resources; we can start with Co-located role caching. If the size of cache increase or/and resources that are used by our application increase also we could switch to Cache worker role. When we use the Cache worker role, we will have a dedicated role used only for cache. For a medium or big application this could be a better solution. Our resources of the roles will not be shared with the cache and also we will know that we will have a dedicated role only for cache.
But if we will have only a Cache worker role what will happen if the role crash. We will lose all data from cache. An option is to activate the automatic backup that will be made on our storage account. In this way the cache will be back-up automatically and restore when is needed. But until the role is restored we will have a period of time when the cache will be down. Also the cache data that is restored could not be with the last cache data (not all data from cache is backup in real time).
From what we saw, if we begin to use Cache worker role, a good decisions it would be to use two instances of Cache worker role if we want to be sure that we have a good uptime. But from my experiences, it is not very often that a role crash because of Microsoft. I n the case we have applications that dependents of crash and need to be up 100% of time use two instances of Cache worker roles of co-located cache.
If you have some data that need to be used only by one role from the application (for example some client information) than Co-located role cache could be a better solution. The time necessary to access this cache is the lowest one because the data are in the memory of the role (in general). Because you can define more caches (by name) in the same Co-located role you can group the data from that need to be stored in the cache.
It is not very simple to decide what cache mechanism to use from Windows Azure. If we need a cache mechanism that is used by different application, Windows Azure Cache can be a good decision, but is hard to decide to decide what to use between Co-located role cache and Cache worker role. For medium to big application I recommend Cache worker role. At start is okay to use Co-located role but after make a switch to Cache worker role. If you have application that doesn’t use all the resources of your role that Co-located role could help you to save some money. Don’t forget that the switch between these cache mechanisms is very easy. Almost all can be done from the configuration file.

Comments

  1. Thanks for the post, Radu. Nice work.

    ReplyDelete

Post a Comment

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…