Foreword: Apologies for the title, I’m still not sure (after completing the entry) what it should be called.
Why would I use the Windows Azure Platform? Its a good question, one that I’ve had a lot of internal discussions on lately (fellow consultants from Readify). For most its quite a paradigm shift and therefore difficult to grok. Many believe that you can only build Azure apps from scratch and that it would be a lot of work to convert an existing product to use the Azure platform. I don’t want to say this is a false statement, but Azure is pretty big, bigger than most people realise.
I Can’t Use Azure Because…
Most of us are only familiar with the Windows Azure component which allows you to host either services or web pages. Most custom applications require a data store and for Microsoft developers, this tends to be SQL Server. Unfortunately there is no one-for-one mapping to easily port your database over to the data stores in the cloud (Windows Azure Storage, SQL Azure, etc). This means people feel resistance when they do consider the Azure services and write-off the whole platform.
When SQL Azure is presented as an option, people tend to pick on the little features that are missing, expecting a direct cloud equivalent for their data. But some things just don’t make sense for SQL Azure. People lose context: SQL Azure is a service. It should be treated like any other service within your architecture. You don’t need to be implementing the next service related buzzword (SOA, SaaS, S+S, etc) to get the benefits of the abstractions provided by services. If you build your services in an autonomous fashion, SQL Azure will fit right in with your story.
What about off vs on-premise data storage? I hear this one a lot as well. I want to control my data, I have no need for Azure. This is an easy answer for me, and I defer back to my last statement. Its a service driven world, your data should be the same. Where that service is located should be irrelevant. This is where the .Net Services ‘Service Bus’ steps up. It can route your data to your other services/applications extremely easily, with top level security all the way, so not even Microsoft can see what is being transmitted. What about my firewall, it will stop people from seeing my service right? No problem – the service bindings use outbound connections to connect to the Service Bus, meaning that you can host your own services on-premise, behind your firewall, and still get flawless connection to/from the cloud.
The Next Step In Developer Evolution
Modularity, loose-coupling, single-responsibility.. any of these terms ring familiar for you? As a developer I enjoy building applications that realise these design qualities. I use Inversion of Control and Dependency Injection wherever possible, and have realised that my code classes have somewhat turned into services. Not like ASMX or WCF services; just classes that have very defined purposes, are abstracted by a contract (interface), and provide a service to the rest of the application.
I won’t lie, since being introduced to IoC my programming style has changed, and I think that this happens for most developers who use it as well (regardless of implementation technology or language). You start viewing everything as services, even your Views (since we all love MVP, MVC, and MVVM). Quite often when I’m with a client discussing aspects of an application I might say “.. so we’ll just create a service for blah…” not realising that it might have a different meaning to them (however its not long before they agree with me and start referring to things the same way!).
So I honestly believe that services are the next level of developer evolution (“devolution” anyone?), whether we mean actual web services or just classes that service our application. For me this even brings about new meaning for Service Oriented Architecture – design your systems to be service based whether those services are across the wire or not.
<Disclaimer> I am an advocate of smart clients and believe everything should be services and that web pages are evil and should only exist to help find smart clients</Disclaimer>
So I Have To Redesign My App As Services?
Yes. Well no, but you should certainly think about it for all new applications, regardless of whether you are considering Azure or not. I honest believe it is just good design. As for existing apps, consider the key dependencies. These might be file storage, relational database, data mining, 3rd party components, etc. Write a list and detail each one individually. Is their a mechanism you can use to abstract the calls to that dependency? Perhaps IoC will work for you, or perhaps the ASP.Net Provider model will help you. Or perhaps you just need to wrap the calls up in a new class in a separate assembly.
The next step is how those dependencies will work in the cloud. Do you need to replace any? Can they also be moved to the cloud? Do they need to be rewritten as services? Do you need to expose their functionality from within your organisational boundaries? This is where a lot or a little work may need to happen. Those applications that already have looser coupling will find this part easy. For example, you may already have a class that handles your database calls. A customer class might have a create, update, and delete methods, which wraps calls to LINQ to SQL (L2S). Well its very easy to indentify your customer class as the service boundary, and move the L2S code to a new service. All you need now is to think about the security and you’re done!
Once you have a firm plan for dealing with those dependencies, the rest should be a piece of cake. Obviously what happens next will differ for web and smart client apps, but the dependencies are really the most difficult thing. When you have hard wired dependencies to 3rd party solutions (eg. K2) you might find that it is very difficult making the transition to Azure.
What About Products?
Well the same rules apply, only that you might get an added benefit from creating products that can easily by run on Azure. For example, check out SplendidCRM – a CRM product recently refactored to run on Azure. Why? Well what if you want a CRM product but don’t want to host it yourself? Kinda seems smart to me… allow the purchaser of your software to run it anywhere they choose, on or off premise. And then of course there is the multi-tenant applications designed to only run in the cloud, like Saasu and Salesforce. If you want to go viral, you need to be prepared to scale quickly!
Summary
Its hard to say exactly when you should consider Azure, but I guess the point of this post is not so much to answer that question, but rather to provide you with some insight into good design techniques, that when followed properly, will provide you with an application that can easily be deployed into Azure, or any other cloud platform for that matter. If we’re doing things right at the bottom level, then we can be flexible with the higher level architectural choices.
So please check out the links for any of the concepts I’ve mentioned above (or listed below) to ensure you and your team are familiar with them. And if you have any questions, please feel free to email me.
Some more links:
Previous: 
Next: 
Comment Meta:
XHTML:
More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Last 50 Posts 
Back
Void 
Life 
Earth 
Wind 
Water 
Fire