This posting may very well be banter. You have been forewarned.
Everywhere I look I see services. I can get pizza delivered, my clothes dry-cleaned, and my shopping delivered to my home without ever leaving my computer. These are all services provided by someone, somewhere. A little closer to home I have my TV which delivers a digital service, radio which delivers an analog service, phone line which delivers a communication service, an XBOX which delivers an entertainment service, and even my kitchen counter, which props up the toaster and bowl of fruit, is performing a useful service.
Here’s a site I often use that provides a service that explains the meaning of words. The word I am interested in, surprisingly, is “service”:
an act of helpful activity; help; aid
Ok I ignored the other definitions but they all pretty much relate back to the concept of something, someone or some corporation doing something useful for others. Sometimes we pay for services, sometimes they are free. But really, services are there to help and form the cornerstone of our very society.
Now that you love services as much as I do, you’ll completely appreciate what this means in software engineering: A service is any code component that helps your application achieve completeness. It is not necessarily something that communicates over the wire, via named pipe or some message queuing application. It isn’t always found in the form of XML, JSON, or binary formats. Its just like your kitchen counter, a piece of code that provides a useful function to your application.
I think we often get too wrapped up in someone’s interpretation of various buzz words and lose site of the meaning of the words themselves. I have no problems using the term ‘service’ in a way that relates in no way to objects going over the wire, WCF, ASMX, etc. Instead, our repositories, factories, presenters, controllers, managers, builders, all those code classes that have a single responsibility, they are all services. For example, in an app I am working on now for a client (ASP.Net, WCF, MS SQL) I am using the MVP pattern and am using IOC (Ninject). I wanted my presenters to be responsible for navigation, but didn’t want them to know anything about page urls. So I created a ‘NavigationService’ (with matching interface) with a simple ‘Navigate’ method on it. It takes a view ‘name’ and looks up the sitemap to work out where to navigate to. This works great because now my presenters are controlling page flow without knowing anything about how navigation works. Its highly testable since my NavigationService can be mocked out easily (thus the interface). You obviously don’t have to put the word ‘service’ in the name, its just sometimes helpful if your class can’t easily be classified as a repository, factory, etc. If you had ‘Helper’ somewhere, generally you could probably replace that with ‘Service’ since it means the same thing.
Yes SOA means Service Oriented Architecture, not Service Oriented Application, and certainly not Service Only Architecture, which is what some people seem to think it means even when they say the word ‘oriented’. The term ‘oriented’ means ‘aligned’ or ‘related’ and in my mind, the literal translation of the phrase means “an architecture where the majority of modularisation is achieved through services”.
OASIS is a standards group and has a reference model for SOA which states:
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
When we hear the word ‘distributed’ in computing we automatically assume disparity and remoteness. But again if we look to our word salad service (dictionary) we get:
“to divide into classes”
Oh this is almost too easy! Of course it doesn’t mean software classes (example, plant species as classes of plant distribution) but it fits too well to ignore. And those capabilities are of course our helpers, repositories, etc. The last part of that statement says “that may be under the control of different ownership domains”. I guess the point here is that it doesn’t have to.
Lets say I have a smart client application, WPF since that’s my drug of choice. I’ve broken it down into a main EXE and a separate DLL where I store all my repositories, builders, factories, presenters, etc. I go to great lengths to ensure everything acts like a service (as per my explanations above). All my capabilities are distributed into separate classes.
In this scenario, am I implementing a Service Oriented Architecture?
Well I’m overly focused on services, some services call others, each is defined by a contract (since I use IOC to locate and resolve them), the implementation is hidden behind the interface, and the only implementation not in a service is the UI. So as far as I’m concerned, the answer is yes!
The great thing about IOC and services in general in .Net is that you can easily turn one of those interfaces into a WCF service contract with very little effort. You want to ‘distribute’ over the wire? You can! The important thing is that you have control over how the services are surfaced.
So the final takeaway is this: consider SOA for every application you ever design. This doesn’t mean WCF, ASMX, named pipes, etc. It just means designing your application with individual services that take care of all your application needs. If you can do that, you will realise clean abstractions, encourage testability, improve maintainability, and create reusability. And I can assure you, once you adopt this style (and a good IOC container to help), you’ll never go back.
Some of that service stuff above is not overly relevant to what I’m going to talk about next. But SOA in general certainly is. Windows Azure supports division of labour very well: If your services are all located within one application assembly, then just provision one web project. If you feel you need to scale out certain services due to work load, slap some service contracts on them and push them into a new instance of their own. Want to keep some of those services on premise? No problems, use the Service Bus to route requests to your on-premise services, easily skipping through those firewalls. Want your data in the cloud too? No problem, stick it in SQL Azure or just plain old Windows Azure Storage if necessary. Hell you could even put it in Amazon S3 if you wanted, Azure doesn’t care: it supports these service abstractions easily and doesn’t know if the service you are calling is hosted in Azure, on-premise, through the service bus, or some external service (eg. S3, Flickr, etc).
The point I am trying to make is that if you follow the SOA principles above, your application design will “just work” when you want to move to Azure. The applications that are hardest to move to Azure are those with tightly coupled components and leaky abstractions. Its certainly difficult to adopt this style of development at first and is certainly something that your architect should be involved in continuously (code reviews, etc). But even if you don’t plan on moving to the cloud, its a great way to build your applications and helps you benefit in the long term. Once you get used to the style, it certainly improves your development speed, and removes dependencies on the components being built in other teams. And it certainly works well for large and small projects alike.
Firstly this is pure speculation. Either that or it is known fact and I am behind the game (I’ve been out of action for a couple months, you may have noticed my absence in blogging). If I am the first person you have heard this from, then there is every chance that it is false, so once again, this is just speculation.
Recently there have been a spate of questionnaires going out to Azure consumers/clients. Being a good CTP user and evangelist of the platform, I filled out every single one that came my way. Some took hours, some took minutes. But while it would seem that Microsoft were collecting information from me, it also alluded/hinted at some features that might be released by Microsoft sometime in the future. This post is simply identifying those features that have already been discussed in those surveys.
The feature name currently is ‘Managed VM Role’ and would essentially be an instance that you could remote to like any other server. This would fall into direct competition with GoGrid/EC2 type hosting where you provision server instances and get full terminal services access to the instance. In this case it would be custom Server 2008 instances that could still be managed by the Fabric Controller. Microsoft summarises the concept like so:
‘A mechanism to snapshot an entire application environment and create a Windows VM to be deployed and managed by Windows Azure together with the relevant data, registry settings, and the ability to choose and control OS versioning. In this case, the customer is responsible for installing security patches, OS updates, and upgrades by creating a new image snapshot updating the running VM roles using the Windows Azure upgrade facility’.
This would work in harmony with a ‘Managed Application Role’ which basically sounds like what they are already doing with Windows Azure, however it also hints at using a packaging facility like MSI for the deployment process. Also some elevated privileges might be possible in the final release (currently you can run in full trust but under a restricted user account).
There’s a few other smaller bits and pieces hinted at, summarised below:
Remember as I said before, its all speculation at this point.
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.
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.
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>
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.
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!
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:
More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Void 
Life 
Earth 
Wind « Default
Water 
Fire Light Bad Behavior has blocked 310 access attempts in the last 7 days.
Last 50 Posts 
Back