Wednesday, June 3, 2009

Going to the Clouds with windows AZURE. (A platform for cloud computing)

Access to software, services and applications over the Internet, with/without you having an idea of the original location, such services is referred to be living in the cloud. Users need not bother about where the software is located.

With cloud computing, you do not have to worry about the technologies that supports your virtual environment. You don't have to wait too hard for your service providers who have to setup/install and configure components for your server environment before using cloud computing, all the components that you require for smooth running of your cloud business, are already in the cloud.

Cloud computing is mixture of other existing buzzes in the INTERNET jargon, these are :

1. Iaas : Infrastructure as a service
2. Paas : Platform as a service
3. Saas : Software as a service

These existing services are incorporated together to form what we refer to the cloud. They all are functionally Dependant on one and other to give a breath taking user experience.

Is cloud computing the new IT Jargon?
In today's IT complexity driven world, reliance or dependencies on technology resources are becoming cumbersome for large and small enterprises, while maintaining large infrastructures of computing resources are becoming an cost issues to organisations, there is a newly born term (Cloud computing) to wash away our worries. Doing business on the web is not as easy as it seem when you have to worry about all the infrastructures, security, maintenance and continuous up gradation of these infrastructures, it would be nice when several providers take charge of the technology backing and the rest is for you to leverage an existing API's/Frameworks to complement your business.

The cloud buzz is already attracting bigger IT providers like Google, IBM, Sun, Microsoft. What does all these mean to us all, the future is in the cloud (with the exception of propriety based technologies).

Microsoft answered with Windows AZURE
Windows Azure is Microsoft first step into the cloud computing foray. Azure is a Microsoft initiative in providing services on the cloud. This is an operating system that is used for deploying azure services on Microsoft owns data centers.

In our day to day deployment/development experience, we overcome several challenges in application configurations, server prerequisites, and configurations.

The windows Azure is an assurance that all these server components (MS-MQ, WCF Host, WWF host, SOAP, XML, REST, ASP.NET etc) will be available without you worrying.

The good thing is that Microsoft is providing SDK's for windows azure, and there is already a Visual Studio integration. Although, Microsoft technologies will be supported (As these are core to the heart of the software giant) , windows Azure will also host non-microsofts technologies. (infact there is already an effort on codeplex for PHP Azure .


The Azurance Provided by windows Azure
  1. Provisions for Binary large object (Blob) tables hosted in the cloud.
  2. Full .NET Framework support.
  3. Available security polices.
  4. Support for other platforms languages (PHP)
  5. Message queuing.
  6. SDk's available everywhere
To azure yourself on the next IT jargon using Microsoft platforms and technologies you will need to go here http://www.microsoft.com/azure/default.mspx. Do not panic, because your development will still be the same, and you can continue to use your existing applications. Infact, your applications can be made azure compliance.

Good thing for .NET developer
Microsoft is not forgetting us and we are already cloud compliant as Microsoft, already provides an SDK for integration into Visual Studio development environment. In fact, our existing developments can be converted to azure services (Its just a matter of configurations). Download the Visual Studio Tools for windows Azure, and reassure yourself of the future of computing.

If you wait on this channel, i would be providing a simple .NET application that is windows Azure compliant.

Hating Try Catch Block (Successful way of cleaning code)

The title of this post is a bit weird, it is weird in the sense that it promotes hatred for try catch blocks in our code. I am not a try and catch block hatter, but too much of it will lead to code rots and very, very buggy software.

Did i just say buggy, not only will it make it difficult to maintain but very inexperienced.

In our grained experience in developing object oriented components/systems, we have met with several challenges that tells us that OO (Object Orientation) is not complete and it is not a silver bullet and answer for all. Well for the OO enthusiastic, permit me to say OO has its own bad practices and so therefore it is not complete in its own rigth (No wonder we have several design patterns all over).

Anyway, the purpose of this post is not about OO not beign complete particularly, but about a practices that can lead to very hard to read code, a difficult and un-maintainable codebase. The following contains short list of code demons :
  • Too much IF ELSE statements : This is a killer code beast that if not properly used, you end up with a code that no one will understand.
  • Separation of concern : The statement 'Separation of Concern' does not apply to components/libraries/.dlls alone. It also applies to classes, methods, properties, interfaces. Any code elements is there for a purpose (Concern). If you write a class and you have several methods within the class (even utility methods like GetDate()) , your class does not have a concern. This allows your library, componets, dlls not to conform to concerns from class levels. I will rather create a class that does one thing and do it very well, instead of creating one class that does many things. A dog is a dog and not dogcat. If your class is a dog, let it be a dog, if its a cat let it be a cat.
  • The evil of all TRY CATCH BLOCKS : Yeap too much of this leads to code rot and it does not encourage readability of codebase. Since this is the subject of this article, i will start in a separate paragraph.
The Problem Statement
Consider the following code snippets.


public delegate void SafeMethodCall();

public void DoSomeBadThing()
{
try
{
//Do bad thing
Thrower();

try
{
//Really Do some wacky thing
Thrower();
}
catch (Exception ex)
{

}
}
catch (Exception ex)
{

}
}

public void Thrower()
{
throw new InvalidOperationException("Exception message");
}


Some people will not see any bad in the above code, let us assume we are doing the same in several places. This will lead to very messy code base, i rather allow the application to fail and log the error than catching different exceptions in several places. The only way out of this situation is maintaining at least one try catch block at the application entry points. That is if you have a class that kick starts your entire application, or its an abstraction of a framework, this is the most suitable place to hook the try and catch.

An efficient approach :


public delegate void SafeMethodCall();

public void Thrower()
{
throw new InvalidOperationException("Exception message");
}

public void SomethingNeat()
{
CallSafely(Thrower);
}

public void CallSafely(SafeMethodCall methodCall)
{
try
{
methodCall.Invoke();
}
catch (Exception x)
{

}
}


The delegate can be used by several other methods to do safe call. This means your try and catch is maintained in a single location. This approach is also efficient for logging, if you are logging errors to file or different repositories.

Now, how does this approach save cleanse our code base

Let us assume we have three different parameterless methods (because our delegate is parameterless) :

public void GetName(); //Can throw string format exception
public void GetAge(); // Can throw invalid cast exception
public void GetCountry(); //Can throw country not in world map exception

These methods have a potential of throwing these errors, how can we call these methods using the above approach, instead of defining try and catch everywhere in our code base. we will now do like so :

CallSafely(GetName);
CallSafely(GetAge);
CallSafely(GetName);

For me, the following is more cleaner, than having many try catch handlers to handle the exceptional situations.

Let me know what you think.