Microsoft Azure Reviews

What is most valuable?

How has it helped my organization?

What needs improvement?

Which solution did I use previously and why did I switch?

Buyer's Guide

Microsoft Azure

August 2025

Free Report: Microsoft Azure Reviews and More

Learn what your peers think about Microsoft Azure. Get advice and tips from experienced pros sharing their opinions. Updated: August 2025.

DOWNLOAD NOW

867,497 professionals have used our research since 2012.

How was the initial setup?

What about the implementation team?

What's my experience with pricing, setup cost, and licensing?

Which other solutions did I evaluate?

The Announcement

Microsoft recently announced a partnership with Oracle which brings a number of Oracle technologies to the Windows Azure cloud.

In short, they announced:

• Hyper-V (i.e. the virtualisation technology underpinning Azure) is now certified to run Oracle software.
• Virtual Machine images will be available with the Oracle Database, and Weblogic preconfigured.
• Properly licensed and supported Java on Azure.

Items 1 & 2 I’m not that excited about, but it’s item 3 which is interesting.

The current state of Java on Azure

Microsoft have supported Java on Windows Azure since the start. There’s an SDK and tooling built into Eclipse.

However, Microsoft haven’t been able to install Java, you’ve had to do that yourself. This has meant that the package you deploy to Azure has had to contain the Java installer, any frameworks and web servers you need, as well as your application code. This makes the package too large to work with, in some cases too large to even upload. It certainly slows down application updates.

Utilities such as AzureRunMe have helped bridge this gap, by splitting your package into separate zip files in blob storage which are only downloaded when required. However, ultimately you have to do more work to get Java running, and it takes longer to spin machines up.

Having said that, Java applications work surprisingly well in Azure. Applications are coded against the JVM, rather than the operating system and make relatively few assumptions about the environment. They also tend to use ORMs (like Hibernate) giving you a simple database schema which is easy to port to Windows Azure SQL Database.

I often find that Java applications are quicker to get running in Azure than similar .NET apps.

The JVM

When we talk about Java here, we’re really talking about the Java Virtual Machine (JVM), the runtime which hosts Java applications.

Java is just one of the languages supported by the JVM, there has recently been a small explosion in language options on the JVM, including:

• Clojure
• Scala
• Groovy
• Jython
• JRuby
• Kotlin

…to name just a few.

What does this mean for the future?

I haven’t got any special knowledge here, but there are few things Microsoft could do now:

1. Provide a ‘Java’ role in Cloud Services. This would have Java and (optionally) Tomcat pre-installed, making deployment of Java applications faster and easier.
2. Enable the JVM as a hosting option on Windows Azure Websites (alongside Python, .NET, PHP and Node.js).
3. JVM support gives you Ruby (using JRuby). There’s already a Ruby SDK for Azure, and JRuby seems to be the fastest Ruby runtime (AFAIK). This is potentially true for this long list of languages too.
4. This is probably good news for Hadoop on Azure.
5. Enterprise Java developers should certainly take note. The capabilities of the Azure Service Bus, coupled with competent PaaS and IaaS offerings and the low-cost SQL Database, make Azure an attractive option.

Hold On, Load balancing…

Java web applications (in my experience) often hold large object graphs in memory, as state stored against each user session. This means that sticky sessions are required, and the Azure load balancer in Cloud Services is round-robin (sort of). Sticky sessions aren’t very cloud friendly, but it’s difficult to make legacy application stateless.

Whilst there are ways to work around this, they all rely on ‘un-balancing’ the load balancer, and will frequently add network hops and overhead to the processing of each request. We need to be able to select a load balancing strategy on endpoints configured in Azure (i.e. round robin/sticky/performance based decision).

As a side note, the load balancing strategy for Windows Azure Websites is sticky.

Conclusion

Better support for Java on the Microsoft cloud goes well beyond one language, and unlocks a number of possibilities, such as better support for Ruby and Hadoop for example.

Load balancing is one pain point, but something we know they can fix in the platform.

Azure remains an exciting place for everyone from the smallest startup, to the largest enterprise.

I was recently asked whether I do have some cheat-sheet for migrating applications to Windows Azure. The truth is that everything is in my head and I usually go with “it should work” – quickly build, pack and deploy. Then troubleshoot the issues. However there are certain rules that must be obeyed before making any attempt to port to Windows Azure. Here I will try to outline some.

Disclaimer

What I describe here is absolutely my sole opinion, based on my experience. You are free to follow these instructions at your own risk. I describe key points in migrating an application to the Windows Azure Platform-as-a-Service offering – the regular Cloud Services with Web and/or Worker Roles. This article is not intended for migrations to Infrastructure Services (or Windows Azure Virtual Machines).

Database

If you work with Microsoft SQL Server it shall be relatively easy to go. Just download, install and run against your local database the SQL Azure Migration Wizard. It is The tool that will migrate your database or will point you to features you are using that are not compatible with SQL Azure. The tool is regularly updated (latest version is from a week before I write this blog entry!).

Migrating schema and data is one side of the things. The other side of Database migration is in your code – how you use the Database. For instance SQL Azure does not accept “USE [DATABASE_NAME]” statement. This means you cannot change database context on the fly. You can only establish connection to a specific database. And once the connection is established, you can work only in the context of that database. Another limitation, which comes as consequence of the first one is that 4-part names are not supported. Meaning that all your statements must refer to database objects omitting database name:

[schema_name].[table_name].[column_name],

instead of

[database_name].[schema_name].[table_name].[column_name].

Another issue you might face is the lack of support for SQLCLR. I once worked with a customer who has developed a .NET Assembly and installed it in their SQL Server to have some useful helpful functions. Well, this will not work on SQL Azure.

Last, but not least is that you (1) shall never expect SQL Azure to perform better, or even equal to your local Database installation and (2) you have to be prepared for so called transient errors in SQL Azure and handle them properly. You better get to know the Performance Guidelines and Limitations for Windows Azure SQL Database.

Codebase

Logging

When we target own server (that includes co-locate/virtual/shared/etc.) we usually use local file system (or local database?) to write logs. Owning a server makes diagnostics and tracing super easy. This is not really the case when you move to Windows Azure. There is a feature of Windows Azure Diagnostics Agent to transfer your logs to a blob storage, which will let you just move the code without changes. However I do challenge you to rethink your logging techniques. First of all I would encourage you to log almost everything, of course using different logging levels which you can adjust runtime. Pay special attention to the Windows Azure Diagnostics and don’t forget – you can still write your own logs, but why not throwing some useful log information to System.Diagnostics.Trace.

Local file system

This is though one and almost always requires code changes and even architecting some parts of the application. When going into the cloud, especially the Platform-as-a-Service one, do not use local file system for anything else, but a temporary storage and static content that is part of your deployment package. Everything else should go to a blob storage. And there are many great articles on how to use blob storage here.

Now you will probably say “Well, yeah, but when I put everything into a blob storage isn’t it vendor-lock-in?” And I will reply – depending on how you implement this! Yes, I already mentioned it will certainly require code change and, if you want to make it the best way and avoid vendor-lock-it, it will probably also require architecture change for how your code works with files. And by the way, file system is also “vendor-lock-in”, isn’t it?

Authentication / Authorization

It will not be me if I don’t plug-in here. Your application will typically use Forms Authentication. When you redesign your app anyway I highly encourage you rethink your auth/autz system and take a look into Claims! I have number of posts on Claims based authentication and Azure ACS(Introduction to Claims, Securing ASMX web services with SWT and claims,  Identity Federation and Sign-out, Federated authentication – mobile login page for Microsoft Account (live ID), Online Identity Management via Azure ACS, Creating Custom Login page for federated authentication with Azure ACS,  Unified identity for web apps – the easy way). And couple of blogs I would recommend you to follow in this direction:

• Dominic Baier: http://leastprivilege.com/
• Vittorio Bertocci: http://www.cloudidentity.com/blog/

Other considerations

To the moment I cant dive deeper in the Azure ocean of knowledge I have to pull out something really important that fits all types of applications. If it happens, I will update the content. Things like COM/COM+/GDI+/Server Components/Local Reports – everything should work in a regular WebRole/WorkerRole environment. Where you also have full control for manipulating the operating system! Windows Azure Web Sites is far more restrictive (to date) in terms of what you can execute there and to what part of the operating system you have access.

Here is something for you think on: I worked out with a customer who was building SPA Application to run in Windows Azure. They have designed a bottleneck for scaling in their core. The system manipulates some files. It is designed to keep object graphs of those files in-memory. It is also designed in a way that end-user may upload as many files as day want during the course of their interaction with the system. And the back-end keeps a single object graph for all the files user submitted in-memory. This object graph cannot be serialized. Here is the situation:

In Windows Azure we (usually, and to comply with SLA) have at least 2 instances of our server. These instances are load balanced using round-robin algorithm. The end user comes to our application, logs-in and uploads a file. Works, works, works – every request is routed to a different server. Now user uploads new file, and again, and again … each request still goes to a different server.

And here is the question:

What happens when the server side code wants to keep a single object graph of all files uploaded by the end user?

The solution: I leave it to your brains!

Conclusion

Having in mind the above mentioned key points in moving application to Windows Azure, I highly encourage you to play around and test. I might update that blog post if something rather important comes out from the deep ocean of Azure knowledge I have. But for the moment, these are the most important check-points for your app.

If you have questions – you are more than welcome to comment!

Everybody speaks about recently announced partnership between Microsoft and Oracle on the Enterprise Cloud. Java has been a first-class citizen for Windows Azure for a while and was available via tool like AzureRunMe even before that. Most of the customers I've worked with are using Apache Tomcat as a container for Java Web Applications. The biggest problem they face is that Apache Tomcat relies on Session Affinity.

What is Session Affinity and why it is so important in Windows Azure? Let's rewind a little back to this post I've written. Take a look at the abstracted network diagram:

So we have 2 (or more) servers that are responsible for handling Web Requests (Web Roles) and a Load Balancer (LB) in front of them. Developers has no control over the LB. And it uses one and only one load balancing algorithm – Round Robin. This means that requests are evenly distributed across all the servers behind the LB. Let's go through the following scenario:

• I am web user X who opens the web application deployed in Azure.
• The Load Balancer (LB) redirects my web request to Web Role Instance 0.
• I submit a login form with user name and password. This is second request. It goes to Web Role Instance 1. This server now creates a session for me and knows who I am.
• Next I click "my profile" link. The requests goes back to Web Role Instance 0. This server knows nothing about me and redirects me to the login page again! Or even worse – shows some error page.

This is what will happen if there is no Session Affinity. Session Affinity means that if I hit Web Role Instance 0 first time, I will hit it every time after that. There is no Session Affinity provided by Azure! And in my personal opinion, Session Affinity does not fit well (does not fit at all) in the Cloud World. But sometimes we need it. And most of the time (if not all cases), it is when we run a non-.NET-code on Azure. For .NET there are things like Session State Providers, which make developer's life easier! So the issue remains mainly for non .net (Apache, Apache Tomcat, etc).

So what to do when we want Session Affinity with .NET web servers? Use the SessionAffinity or SessionAffinity4 plugin. This basically is the same "product", but the first one is for use with Windows Server 2008 R2 (OS Family = 2) while the second one is for Windows Server 2012 (OS Family = 3).

I will explain in a next post what is the architecture of these plugins and how exactly they work.

I’m been using Azure IaaS in a lot of enterprise deployments lately and I’ve noticed that there is some confusion regarding the different storage types available and provisioned for the virtual machines.  In many ways the capabilities associated with Azure storage is its greatest strength, but unless you configure it properly, you might be in for a surprise regarding your results.    The key message to understand is the difference between the operating system disk, the temporary disk, and data disks as they have different performance characteristics and will impact your systems in different ways when used correctly or incorrectly.

The operating system disk:

This disk is used for the operating system install and it will exhibit great read performance.   It is not however scalable for write performance, so you shouldn’t use it for any write-centric or data-centric use.   It would NOT be the place where you would put your Microsoft SQL data, or your file server.

The cache / temporary disk

The cache disk is used for temporary data that you don’t want to keep.  It might seem like it is retained, but eventually you will find this disk refreshed when the system is booted back up, or undergoes a “repair”.  The cache disk is really only appropriate for storage of data you don’t want to keep.

The data disk

The data disk is where you should put any of your important information, especially databases and file stores.  The data here can be effectively scaled out through striping several data disks together.  A rule of thumb to use is that each data disk is worth approximately 500 IOPS.  If you stripe several together you’ll see that number increase.  At this point you might find it helpful to run some tests against the disks you’ve allocated to ensure you’ve added the appropriate IOPS for your capacity requirement.  I’ll note that the disk IOPS will increase as it is used, which is a component of the caching engine of the data disk type.  The cool thing about the data disk is that they are easy to provision and you can create stripes of a lot of disks (16) which will provide excellent scalability to your application.

The key point?  Use the right disks for the right things.  If you don’t, then you’ll get a different performance experience than you’re expecting.  Now move some workloads to Azure and take advantage of the scalability!

Want to learn more?  Check out the Azure internals session from TechEd!

Azure Internals

Also, check out Azure Storage Testing, which checked a standard Azure hard disk against a local SSD and a small server.  This performance can be improved by striping multiple Azure disks together.

Disclosure: The company I work for is a Microsoft Partner

UPDATE – 06-DECEMBER-2012

I originally wrote this post in September 2012. Recently at their re:Invent event, Amazon announced reduction in their storage prices by 24-28% (http://aws.typepad.com/aws/2012/11/amazon-s3-price-reduction-december-1-2012.html). Yesterday Microsoft announced similar price reduction (http://blogs.msdn.com/b/windowsazure/archive/2012/12/05/announcing-reduced-pricing-for-windows-azure-storage.aspx). I have updated this blog post taking these price reductions into consideration and including them in my calculator below. Please note that both Amazon and Windows Azure have reduced only the storage charges. They have not changed the transaction charges or the bandwidth (Egress) charges. The new prices for Amazon became effective as of 01-December-2012 while that for Windows Azure will become effective on 12-December-2012.

Few months back, I wrote a few blog posts comparing Windows Azure Blob Storage and Amazon S3 services. You can read those blog posts here:

http://gauravmantri.com/2012/05/09/comparing-windows-azure-blob-storage-and-amazon-simple-storage-service-s3part-i/

http://gauravmantri.com/2012/05/11/comparing-windows-azure-blob-storage-and-amazon-simple-storage-service-s3part-ii/

http://gauravmantri.com/2012/05/13/comparing-windows-azure-blob-storage-and-amazon-simple-storage-service-s3summary/

Since pricing for both of these services are changing quite frequently and depended upon a number of factors, it was not possible for me to pinpoint exactly which service is cheaper. I created a simple calculator where you can input appropriate values and compare the cost of both of these services to you.

As mentioned in my other blog posts, the pricing depends on 3 factors in both services:

1. Transaction costs i.e. cost incurred based on number of transactions performed against each service. These include various REST based operations performed against the two services.
2. Storage costs i.e. cost incurred based on the amount of data stored in each service. These are usually calculated based on Giga bytes of data stored per month.
3. Bandwidth costs i.e. cost incurred based on the data sent out of the data center in each service. Please note that at the time of writing of this blog, all incoming traffic is free in both service as well as the data transferred between an application and storage service in same data center is also free.

In this simple calculator, I took only first two factors into consideration. Again when it comes to storage costs, both services offered a tiered pricing scheme, which I have not considered.

A few comments:

• At the time of writing this blog post, the pricing is taken from respective services pages (https://www.windowsazure.com/en-us/pricing/details/ and http://aws.amazon.com/s3/pricing/). I will try an keep this post updated with the default pricing however I would strongly recommend that you check the pricing page for respective services to get most current pricing.
• While pricing is an important criteria, it should not be the sole criteria for deciding which service to choose. One must also consider the features offered by each service. You can check http://gauravmantri.com/2012/05/13/comparing-windows-azure-blob-storage-and-amazon-simple-storage-service-s3summary/ for a feature by feature comparison as of 11th of May 2012. Since then both services have offered some new features (e.g. Asynchronous copy blob support in Windows Azure and CORS support in Amazon S3 etc.) which should also be taken into consideration.
• For storage costs, I have taken very simple scenario though both services offer tiered pricing as well. One should take that into consideration as well.
• Lastly, I must emphasize that it is a very simple calculator with no in-built error checking or data validation. If you find any issues with this calculator (especially around incorrect calculations), please let me know ASAP and I will fix them.
http://gauravmantri.com/2012/09/03/simple-calculator-for-comparing-windows-azure-blob-storage-and-amazon-s3-pricing/

In this blog post, I will talk about some of the best practices for building cloud applications. I started working on it as a presentation for a conference however that didn’t work out thus this blog post. Please note that these are some of the best practices I think one can follow while building cloud applications running in Windows Azure. There’re many-many more available out there. This blog post will be focused on building Stateless PaaS Cloud Services (you know that Web/Worker role thingie :) utilizing Windows Azure Storage (Blobs/Queues/Tables) and Windows Azure SQL Databases (SQL Azure).

So let’s start!

Things To Consider

Before jumping into building cloud applications, there’re certain things one must take into consideration:

• Cloud infrastructure is shared.
• Cloud infrastructure is built on commodity hardware to achieve best bang-for-buck and it is generally assumed that eventually it will fail.
• A typical cloud application consist of many sub-systemswhere:
  • Each sub-system is a shared system on its own e.g. Windows Azure Storage.
  • Each sub-system has its limits and thresholds.
• Sometimes individual nodes fail in a datacenter and though very rarely, but sometimes entire datacenter fails.
• You don’t get physical access to the datacenter.
• Understanding latency is very important.

With these things in mind, let’s talk about some of the best practices.

Best Practices – Protection Against Hardware Issues

These are some of the best practices to protect your application against hardware issues:

• Deploy multiple instances of your application.
• Scale out instead of scale up or in other words favor horizontal scaling over vertical scaling. It is generally recommended that you go with more smaller sized Virtual Machines (VM) instead of few larger sized VMs unless you have a specific need for larger sized VMs.
• Don’t rely on VM’s local storage as it is transient and not fail-safe. Use persistent storage like Windows Azure Blob Storage instead.
• Build decoupled applications to safeguard your application against hardware failures.

Best Practices – Cloud Services Development

Now let’s talk about some of the best practices for building cloud services:

• It is important to understand what web role and worker role are and what benefit they offer. Choose wisely to distribute functionality between a web role and worker role.
• Decouple your application logic between web role and worker role.
• Build stateless applications. For state management, it is recommended that you make use of distributed cache.
• Identify static assets in your application (e.g. images, CSS, and JavaScript files) and use blob storage for that instead of including them with your application package file.
• Make proper use of service configuration / app.config / web.config files. While you can dynamically change the values in a service configuration file without redeploying, the same is not true with app.config or web.config file.
• To achieve best value for money, ensure that your application is making proper use of all VM instances in which it is deployed.

Best Practices – Windows Azure Storage/SQL Database

Now let’s talk about some of the best practices for using Windows Azure Storage (Blobs, Tables and Queues) and SQL Database.

Some General Recommendations

Here’re some recommendations I could think of:

• Blob/Table/SQL Database – Understand what they can do for you. For example, one might be tempted to save images in a SQL database whereas blob storage is the most ideal place for it. Likewise one could consider Table storage over SQL database if transaction/relational features are not required.
• It is important to understand that these are shared resources with limits and thresholds which are not in your control i.e. you don’t get to set these limits and thresholds.
• It is important to understand the scalability targets of each of the storage component and design your application to stay within those scalability targets.
• Be prepared that you’ll encounter “transient errors” and have your application handle (and recover from) these transient errors.
  • It is recommended that your application uses retry logic to recover from these transient errors.
  • You can use TOPAZ or Storage Client Library’s built-in retry mechanism to handle transient errors. If you don’t know, TOPAZ is Microsoft’s Transient Fault Handling Application Block which is part of Enterprise Library 5.0 for Windows Azure. You can read more about TOPAZ here: http://entlib.codeplex.com/wikipage?title=EntLib5Azure.
• For best performance, co-locate your application and storage. With storage accounts, the cloud service should be in the same affinity group while with WASD, the cloud service should be in the same datacenter for best performance.
• From disaster recovery point of view, please enable geo-replication on your storage accounts.

Best Practices – Windows Azure SQL Database (WASD)

Here’re some recommendations I could think of as far as working with WASD:

• It is important to understand (and mentioned above and will be mentioned many more times in this post :)) that it’s a shared resource. So expect your requests to get throttled or timed out.
• It is important to understand that WASD != On Premise SQL Server. You may have to make some changes in your data access layer.
• It is important to understand that you don’t get access to data/log files. You will have to rely on alternate mechanisms like “Copy Database” or “BACPAC” functionality for backup purposes.
• Prepare your application to handle transient errors with WASD. Use TOPAZ for implementing retry logic in your application.
• Co-locate your application and SQL Database in same data center for best performance.

Best Practices – Windows Azure Storage (Blobs, Tables & Queues)

Here’re some recommendations I could think of as far as working with Windows Azure Storage:

• (Again :)) It is important to understand that it’s a shared resource. So expect your requests to get throttled or timed out.
• Understand the scalability targets of Storage components and design your applications accordingly.
• Prepare your application to handle transient errors with WASD. Use TOPAZ or Storage Client library’s Retry Policies for implementing retry logic in your application.
• Co-locate your application and storage account in same affinity group (best option) or same data center (next best option) for best performance.
• Table Storage does not support relationships so you may need to de-normalize the data.
• Table Storage does not support secondary indexes so pay special attention to querying data as it may result in full table scan. Always ensure that you’re using PartitionKey or PartitionKey/RowKey in your query for best performance.
• Table Storage has limited transaction support. For full transaction support, consider using Windows Azure SQL Database.
• With Table Storage, pay very special attention to “PartitionKey” as this is how data in a table is organized and managed.

Best Practices – Managing Latency

Here’re some recommendations I could think of as far as managing latency is concerned:

• Co-locate your application and data stores. For best performance, co-locate your cloud services and storage accounts in the same affinity group and co-locate your cloud services and SQL database in the same data center.
• Make appropriate use of Windows Azure CDN.
• Load balance your application using Windows Azure Traffic Manager when deploying a single application in different data centers.

Some Recommended Reading

Though you’ll find a lot of material online, a few books/blogs/sites I can recommend are:

Cloud Architecture Patterns – Bill Wilder: http://shop.oreilly.com/product/0636920023777.do

CALM (Cloud ALM) – Simon Munro: https://github.com/projectcalm/Azure-EN

Windows Azure Storage Team Blog: http://blogs.msdn.com/b/windowsazurestorage/

Patterns & Practices Windows Azure Guidance: http://wag.codeplex.com/

Summary

What I presented above are only a few of the best practices one could follow while building cloud services. On purpose I kept this blog post rather short. In fact one could write a blog post for each item. I hope you’ve found this information useful. I’m pretty sure that there’re more. Please do share them by providing comments. If I have made some mistakes in this post, please let me know and I will fix them ASAP. If you have any questions, feel free to ask them by providing comments.