Monthly Archives: January 2009

Head in the Cloud with Windows Azure

Microsoft hosted a developer conference in Boston today.  I think for the most part, you get when you pay for, and the $99 price of this event told me it would probably be more marketing than technology.  But it’s always good to get out and hear what’s going on and talk with other developers.

There were several topics of interest to me at the conference, ranging from F#, Silverlight, Visual Studio Team System 2010, and ASP.NET 4.0 , but one of the things I was most interested in learning about is Azure, Microsoft’s foray into cloud computing.  I thought that this conference would give me a good 50,000 foot view into Microsoft’s plans for a cloud computing paltform.

In the keynote, Amanda Silver referenced the Battle of the Currents, where in the early days of electrical distribution Thomas Edison’s system of direct current (DC) was pitted against Nikola Tesla and George Westinghouse’s system of alternating current (AC).  One of the disadvantages of direct current was that the power generation had to be close by due to power loss associated with transmission.  This meant that a manufacturing plant might need to have its own electrical plant, with all the associated capital costs and maintenance. This is much the same as technology companies today incurring the capital cost and IT support of maintaining their own data centers.  The ability to buy electric power from a utility company would allow the consumer to focus on their business and treat the incoming power as a service.

Microsoft’s intention in this market seems to be to offer a similar utility model that would have the benefits of scalability, redundancy, and IT support and allow a company that subscribes to the Microsoft data center services to focus on it’s own business domain.  As any of us who have had internal data centers know, power outages, scaling, and IT support (security patches, etc.) can be a real headache for a developer and data center IT support keeps us from doing our real jobs: design and writing code.

Now before you think I drank too much Microsoft Kool-Aid, I am just saying that is the idea behind cloud computing in general.  Why absorb the capital outlay and support costs of setting up and maintaining a data center when you can lease those capabilities?  Theoretically, this could lead to better support, scalability, and fault tolerance.  Microsoft seems to be positioning itself for proving data center services and support in the future.  How far off in the future is a question that remains to be answered.

The presentations on Windows Azure presented a fairly realistic picture of where the technology is today, and I give the presenters credit for that.  Michael Stiefel’s presentation was good and gave the 50,000 foot view that I was looking for.  He also drilled down a little bit into the services provided in Azure, including  high level.  Ben Day’s presentation was particularly good I thought, pointing out the potential of the technology while balancing that against some of the limitations of the current implementation, particularly related to Azure data storage.  I would assume their blogs will have the presentations at some point in the future, so you may want to check in.

The presentations and keynote showed how you can get started with Azure today using Visual Studio 2008.  You will need to install the Azure SDK and Azure Tools for Visual Studio that you can find here. Azure applications can execute locally on a Development Fabric, which is a simulated cloud environment on your desktop. You can also deploy a service to run in the Azure cloud, but you need to set up an account for that, and for the purposes of learning about the technology it would seem that the Development Fabric is adequate.  The developer “experience” (another big buzzword at the conference) is the same as developing other Windows apps in Visual Studio.  You can debug applications normally if they are running in the Development Fabric, however once they are deployed the only debug mechanism is logging statements.

This is definitely a “down the road” technology, and there are several kinks to work out, but if you want to be ahead of the curve it might not be a bad idea to try some of it out.  One of the things that came up in the presentations is that Microsoft is on the fence on some aspects of the implementation and will be looking to the developer community for feedback.  We’ll have to wait and see how all this plays out, but I am certainly willing to give it a spin.

Just Because You Can, Doesn’t Mean You Should

I got a new car recently.  For the last 10 years, I have been driving a Jeep Cherokee with roll-down windows, manual door locks, and no modern conveniences other than air-bags.  Now I am getting used to all kinds of conveniences like lights that shut off on their own when I turn off the car, ABS, stability control, and even power windows and locks.  Basically all the good things that the rest of you have enjoyed for a while.

It took a bit for me to come to grips with the fact that a car with ABS can stop the car better on snow than I can by gently pumping the brakes.   And I am pretty sure that I’ll never get a dead battery because I left my lights on.  So what does all this have to do with software you ask.  Well I’ll tell you.

I love all these new features.  But there are a few things that my car does that I think may have been “cool” to the guy that designed it, but maybe not such a great idea in the long run.  My favorite example is the stability control system.  The stability control feature will do wonderful things like help keep me pointed in the right direction if I start to lose traction in snow.  What’s wrong with that….nothing, I love it.

What drives me crazy is that when the stability control automatically activates, an alarm sounds telling me that it has kicked in.  Now I have one job in all this and that is to drive the car, but when I hear an alarm my first reaction is to look at the dashboard and find out what is wrong.  Whoever designed this “feature” probably thought it was a cool thing to do, and we might as well use the buzzer in the dash for something, but is an unintended consequence of getting a driver to take his eyes off the road while losing traction a good thing?   I don’t think so.

We’ve all been in situations when we have wanted to do something because it would be fun to implement or maybe would use a technology that we’ve always wanted to try.  That isn’t a good enough reason to do put something into a product.  It needs to add value to your product and be the right approach.  If you want to try out a new technology, put it in a spike solution where you are free to experiment and where it stands alone and is easier to be reviewed. Prove that it works and show it to your peers.  Determine how it can make your product better and convince the product owners.

Being agile means responsing to changing requirements and technology, but product decisions need to be made in the light of day.

By the way, this has not been a problem on the teams I have worked on.  It’s just that we’ve been getting a lot of snow lately and that stability control alarm keeps going off.