Avoiding Vendor-Lock-in: Is code written for Windows Azure completely portable to self-hosted IIS/ASP.NET?

Question

Background
I'm just getting started on a new web-development product that I intend to host in the cloud and am weighing my options for cloud-providers.

I really like the idea of going with a Platform-as-a-Service solution like Azure because my server administration skills aren't nearly as robust as my development skills. So the ability to focus only on the app and outsource concerns like backups/load balancing/etc. is attractive to me.

HOWEVER, I am also concerned about vendor lock-in. I expect the margins on my application to be fairly slim and need to keep a careful eye on cost controls. If I pick a PaaS solution like Azure and MS decides to jack up their prices substantially I'd like to be able to take my business to a cheaper provider.

I've been doing ASP.NET development for years, but am just getting up to speed with Azure. I know that Azure apps are written using the same tools/language as normal ASP.NET apps, but don't know whether they differ enough that the same app wouldn't run on a regular IIS/ASP.NET installation without substantial modifications.

The Question
Are Azure apps generally portable to non-cloud versions of IIS/ASP.NET enabling you to move them easily to one of the numerous IaaS/HaaS providers without major surgery?

I understand that obviously I'd lose the PaaS advantages like built-in load balancing and the other extras. I am mainly concerned about whether Azure forces you to write you web app in a very Azure specific way that will need to be re-factored to work outside of Microsoft's Cloud.

Answer 1

No, for "websites" Microsoft does not currently force you to write code in a very Azure specific way - a web role is essentially just a website.

So if you are sticking to just web roles and you are just using SQL Azure for storage, then currently your Azure code would be very portable.

However, if you start to include: - worker roles - table, blob or queue storage - advanced Azure configuration - Azure diagnostics - Azure management (e.g. for scaling or for deployment)

then you will start to include Azure specific functionality.

Also, as a personal opinion, I don't think Microsoft "jacking up" the price is likely to be the problem - but competitors coming along with cheaper or more functional solutions might be an issue.

Answer 2

It's somehow.

As Stuar has pointed out, if you start to include specific Azure technologies, you will be a little dependant on it.

But also the approach. For example, when you architect your app for Azure, you start also to use some approaches that doesn't make sense in "on premises", for example blobs with shared signatures.

If you try to design application very portable, you will miss the advanced features, so what I do is separate everything in modules, in a way that modules can be easily rearranged, replaced or deleted, as I think BrentDaCodeMonkey is also pointing out.

Answer 3

Lock-in will be found in every system you will decide to use, specifically if you talk about the PaaS you will adopt for your online services. It is a matter of level in comparison to other vendors. In a deep research I performed on the Cloud market including IaaS and PaaS (in two different posts I found that Azure holds the highest level of PaaS vendor lock-in that are not really aligned with its benefits. You are welcome to read my founding in - The Cloud Lock-In (Part 2): The Great Lock-In of PaaS - http://www.iamondemand.com/post/10120499126/the-cloud-lock-in-part-2-the-great-lock-in-of-paas

I Will be happy to get to know if that helped you. Ofir.