Skip to main content

In-Role Cache and Azure Managed Cache Services will be retired next year

A few days ago Azure team announced that they will retire Azure Managed Cache and In-Role Cache will not be supported anymore. In this post we will take a look on why this is happening and what could this decision affect us.
The official announced can be found on the following link: https://azure.microsoft.com/en-us/blog/azure-managed-cache-and-in-role-cache-services-to-be-retired-on-11-30-2016/

Azure Managed Cache Services is a service that allow us to use a cache solution as a service. From our application, we would only need a 'connection string' to the cache services. Using this information we could store or retrieve any kind of content from cache.
In-Role Cache allows us to cache content in the memory of our role (web/worker role). A part of the memory can be configured to be used for cache. The data that is cached in In-Role Cache is synchronized automatically between multiple instances of our role.
This two cache solutions offered by Microsoft Azure are used very often by small to medium size application that needs a simple solution to cache content.
I'm using Azure Managed Cache in 6 application that are hosted on Azure and works great. The cache is not super fast, but it is enough for the use cases that we need to cover. For cases when we need to be super fast and we have a more complex use case we use Redis Cache. Personally I never used In-Role Cache in production. I played with it on different occasion, but nothing more than that.

From November 30, 2016 Microsoft Azure will retire Azure Managed Cache Service completely. This means that if you are using this service that you should start to plan and prepare a migration to another cache service like Azure Redis Cache. On the same date, the support for In-Role Cache will end.
It is important to know that on all public Azure Regions, China and US Government Datacenters , Azure Redis Cache is available and ready to use.

A normal question is: 'Why this is happening?". This is happening because both services of cache are using Windows Server AppFabric 1.1, for which the support will end next year. It is normal that all services that are constructed over AppFabric 1.1 features to be affected.

The migration from Azure Managed Cache Service or In-Role cache to Azure Redis Cache can be made easily. Not only this, but all features that were available in this two cache solution can be found in Azure Redis Cache. There are some small things that cannot be ported directly 1 to 1, but are isolated and simple to migrate. A post about this topic will come next week.

Even if this change may affect some clients, overall this is a good change. From a cache perspective, there were a lot of options on Azure, with similar performance and features. For clients is pretty hard to decide when you have 2 or 3 services with the same functionality, features and costs.    

Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Can User Technical Profile Influence AI Architecture Decisions?

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

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.51 EF 6.0.2 VS2013 It see...