Windows Azure

I've noticed a subtle change in the tech marketplace over the past few years. I believe the Operating System market has been / is fragmenting, statistics about the number of college students that are using Macs is pretty shocking to me. No one was using Macs when I was in college, I don't recall seeing even one. These students are the next generation of computer users, and they are all computer users. Even though I don't personally agree from a technical / use perspective, it appears Microsoft has made a major misstep with Vista. (I have been using it since some of the pretty early available MSDN betas.)  This has opened a door that I believe Microsoft would have rather had stayed closed. Along these lines, there is some pretty good movement with the open source OS platforms. Dell and others are selling machines with Ubuntu pre-installed as a general option. These things weren't going on just a few years ago, or at least to any real degree. It was always mainly Microsoft. In addition, Microsoft's other major franchise, the Office suite, has been challenged by other, often much cheaper or free, competition like Open Office, and Google Docs. What's more, the Microsoft Zune, which I own and think is an awesome device,  hasn't even really dented the mp3 player marketshare of Apple's Ipod (last number I remember hearing was Zune = 3-5%, I might be wrong). The XBOX, although also very awesome, has been a real money looser (until lately?). Don't get me wrong, they're still making money hand over fist.

So I've been wondering what the future looks like for Microsoft. With the apparent fragmentation in the OS game, (which many will dispute I'm sure) it seems the ubiquity of the 'Windows Desktop' (call it whatever you want XP, Vista,  7), may have a limited future (perhaps 5-10 years still I think). Other players will probably come into this game in a non-trivial way. This concerns me because I've invested a ton of time over the years learning the Microsoft stack, the last few on .NET particularly. If .NET == 'Windows Desktop' then that investment looses value. (In this vane, I'm really glad to see things like Mono coming up which take .NET onto other platforms like Linux, etc. Also, glad that Silverlight is bringing the .NET skillset out to so many new places.) Recently, a major new future direction for Microsoft was announced at the PDC. They announced a new platform called 'Windows Azure'.

While, from a cursory glance, this looks similiar to other platforms that have recently come out of Redmond (think WPF, WCF, WF....and on and on), I think there is something more to it. They are looking for their next franchise, Microsoft sees that its core franchises are, or will soon be, under major attack for the reasons mentioned above. The marketplace is simply evolving. We know how Microsoft made zillions with those francises, they sold licenses to run on-premise software. 'Windows Desktop' runs on your desktop machine, Office likewise. Individuals and businesses shelled out major money for the software that they would run.  Windows Azure is presented as an 'Operating System for the Cloud' - it doesn't run on your machine (in deployment / real world). People (users) don't generally pay for the software they run in the cloud. They pay for the utility they get. Think music you buy from Amazon, think photos you store online to share with your family, even think about paying your bills online. There's software under there - you don't pay for it as such but someone does. Further, there's hardware under there. Amazon pays a ton, in hardware, management & power costs to make its marketplace available. Your bank pays a boatload for operating its datacenter. These costs are actually prohibitive in some cases for businesses of certain sizes. Its hard to scale and do so quickly when you need to (you get Digged or something).

Ok, back on point. So what is Windows Azure. Well, its a platform for doing these things. With Azure, it looks like Microsoft is starting in a new direction, one with many of the same facets of its massively successful 'Windows Desktop' franchise. 'Windows Desktop' has been successful not because it, itself, is that great, but largely due to the fact that it has been the choice platform for people who MAKE applicaitons. It is the ease of application development and therefore the diversity of said application base that has propelled 'Windows Desktop' for so long. Windows Azure looks to be largely the same thing in the new world of online apps and services. It is a platform that will seem familiar to the army of Microsoft developers that want / need to enter the 'connected game' in a big way. It may not even be the 'best' (some people are religious about Macs), Amazon has been doing similiar things, other people might have a 'better' platform, but what Microsoft brings is the developers. So how are they going to make their zillions off this platform like they did off the 'Windows Desktop'? They have not announced exact details yet on the price structure, but it seems like they are going to be monetizing the hardware, the software and the management (which is also, in part, software.) These are all things you have to pay for anyway to get in the game - so why pay Microsoft? Well, some of these are hard - as I mentioned, its hard to scale quickly. Its hard to have reliable storage. You have to know things / hire people. This is expensive if you have to do it yourself - especially up front. You can pay as you go. Also advantageous for Microsoft here, as with 'Windows Desktop' is that there is lock-in. They offer the platform you build on. The platform isn't just software anymore, its the whole scale of a datacenter. I was wondering how Microsoft was going to challenge the Googles of the world. Now we know.

Scaling Software Development

Software is a strange beast, a survey of the industry's history seems to show that, despite our best efforts, large scale development projects seem to leave something to be desired in terms of schedule and budget. Microsoft’s latest OS, Windows Vista, was, maybe, years late & I don't think anyone wants to know how much it actually cost. What should an organization do when schedule falls behind? In a brake plant (I used to do automation & robotics in one), if schedule is slipping then the answer usually is - add more resources - more shifts, more hands. The thought being - more hands = more production, ten times the labor should make about ten times as many rotors. Yet, again with the survey of software development history, we see that this doesn't seem to work well with software development. Why? Well, Fred Brooks - in his seminal book on software development - the Mythical Man Month, tells us that adding developers to a late software project only makes it later. Ten times the developers = ten times the (human) communication interfaces = greater than ten times the overhead = mucho cost.  So then the question is - how do you scale software development? If a project would take a single developer ten years - how do you get that project done so that it is still relevant to the need (the market) which demands it at project outset? How do you squeeze that 10 man-years into 1 or 2 so that you can get to market in time? Well, what advantage does a single developer have that you don't get with a team? The answer has something to do with this - if YOU wrote the code then YOU know the software better than anyone else. This means that you can forge ahead without having to review heaps and heaps of code every time you need to add new a new feature or change something. It’s pretty easy to see how this could help you get more done. Such a discovery!? Why not have a single developer work on each individual project - that would solve our software problems, eh? Right? Well wait a minute, there's obviously a couple things wrong with this idea...one being that 'the customer' probably can't wait 10 years to get the software. So, what is it about 'each individual project' that make this so? Is it that each project has a different customer, allowing the requirements to be tailored to the specific project? Maybe, but it could be that, if one person were to suffice for the timeframe of the project deadline then they could do EVERYTHING for the development themselves. Let’s look at this a little more... In that 10-man-year project we were talking about earlier - what if we could break that up so that 10 people could have 'their own project' and not need to work with the others much, if at all, to accomplish the goals of their 'project'? Maybe we can 'scale software development' that way. What would we need to allow such 'division of labor'? The answer is a long-known software architecture design premise - encapsulation. Encapsulation is what makes a single developer get done in 10 years (1 x 10 = 10 man-years) what it might take 10 developers 4 years to accomplish (10 x 4 = 40 man-years = blown budget) to accomplish. Being 'encapsulated' is what allows a single developer to avoid 'reviewing heaps & heaps of code' before touching anything.

So, think about a medium-to-large company that has any kind of ambitous product plan, they generally have tons of development to do. They might need to create frameworks, utilities, libraries of common functionality, design-time tools, testing tools, deployment tools, analysis tools, validation tools, and on and on. They probably want it all to come together in the end so that it 'feels integrated.' For all but the most trivial of such systems, which a company with such goals would never need anyway, an estimate of the effort required for a single developer to accomplish the development tasks (only the development tasks) might need to account for the brain cells that are lost as that developer teleports to work (if we still actually GO to work at an actual place by then). Further, would the end result still be relevant at that time? So again, we arrive at the problem of how to scale software development.

Large scale software needs encapsulation – no single developer can build all this ‘stuff’ in the required time frame. Customer & stakeholder feedback is also needed – large systems are generally too complex to get right the very first time. Planning & design are key – poor design will cause rework that reverberates through the whole codebase as feedback rolls in. What is needed is architecture, an architecture that supports reuse by allowing encapsulation – letting single developers or small teams build the pieces of THEIR part of the great puzzle while harnessing services created by others.

How do you get something that, when everything comes together, 'feels integrated'? How can you allow the single developer or small team to work – encapsulated – while harnessing services provided by others? One suggestion that is out there is the Enterprise Library from the Patterns & Practices group at Microsoft. This library of 'commonly used application building blocks' promises to provide solutions to many of the issues people encounter when developing enterprise solutions. One of the building blocks in this library, the Composite Application Building Block (CAB), promotes reuse by creating an extensible framework which provides basic functionality and services and allows, potentially different, developers to enhance this framework by creating 'snap-in' modules (reusing base services, etc...). I will be commenting on the Enterprise Library and specifically CAB in the future, hoping to shed some light on how it is useful in 'scaling software development.'