"When I'm introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native... because it just wasn't there. And it's not that HTML5 is bad. I'm actually, on long-term, really excited about it."

So before we go down this path, let's just set a little context around what "native" actually means, because it means a lot of different things depending on how & where you use it, and I want to be clear about how I'm using it in this post (and how I believe Mr. Zuckerberg used it in the discussion at Disrupt). 

"Native app" is a term that's historically been used to refer to apps programmed directly to the native capabilities of the machine, so think of machine code, for instance, executed directly by the CPU. As of late, we've seen folks play a little fast & loose with the term "native", essentially using it as a catch-all term for "non-web". A definition that fits this use case might be that a native app is one that is device/platform/runtime specific or exposed to the full capabilities of the underlying application platform, regardless of how close to the metal it is. So for purposes of this discussion, I am going to take that same liberty here ...  

Now, back to the Disrupt interview. So Mark says this, and a lot of people start scratching their heads, wondering if HTML5 is somehow getting knocked here, but this is actually pretty simple ... this is a statement about web apps vs. native apps (fast & loose definition applies), and his position was clear ... the best experiences on mobile devices remain native experiences. Then, on Sept 12^th (the last day of Disrupt), Mashable ran this opposing-point-of-view headline: "Why Web Apps Will Crush Native Apps". See here.  Not surprisingly, others then jumped into the fray, deriding the web vs. native debate as silly, probably best articulated by Jean-Louis Gassée (see here). For the record, I agree ... it is silly, and just another one of these "tyranny of the 'or'" discussions, which is why it's déjà vu all over again. As this debate has ebbed & flowed over the years, there seems to be this underlying quest for singularity ... the proverbial "write once, run anywhere" answer to the multi-device, multi-platform conundrum. I think the pros & cons of both native and web development have been well-chronicled, so I won't bore everyone with a retrospective of something that's been beaten to death on the internet for the last decade. But if you want more depth, there's always Bing. But I do want to come back to the HTML5 piece in particular ... what does this mean for HTML5? More importantly, what does this mean for the web developers who've bet on HTML5, who periodically hear an industry opinion leader like the founder of Facebook assert that native is the way to go if you want a first-class experience on mobile devices?  

Well, one thing we all know by now is that people who use mobile devices use more than one, which means developers have a compound issue ... having your app on the multiple platforms that matter in the market for a device category, and having that app run across the multiple device categories being used by the customer you're trying to win. The reality is that many (if not most) user experiences will eventually be some combo of native and web, depending on the device, the context, the task at hand, the time available to complete the task, the reliability of the connection that's available, etc.  Of all the reasons people are excited about HTML5, this is probably the frontrunner: people use a collection of different devices throughout the day, and you need to deliver an experience across all of them.  So back to our question:  if you've bet on HTML5, have you simply just bet on the "web" side of the "web vs. native" debate?  No, you have not ... you can also go native, and that's where Windows 8 comes in ...

<pitch>

In Windows 8, HTML5 *is* a full-fledged application platform for building client apps (along with C++, C#/XAML, and VB). This means that if you know HTML5, you can come to Windows 8 and use those same skills to build native apps, in the sense I described earlier. And to be clear, HTML5 is indeed the path forward for web apps, and energy around HTML5 (see Mark's quote above ) continues to grow. The meta point here is that on Windows 8 you have the choice:  if you're building in HTML5, you can build for the web and take advantage of HTML5 in IE10, along with hardware acceleration, site pinning, and full-screen experiences, or go native and take advantage of WinRT, which includes HTML5 as a first-class application platform, or build for the multi-screen scenarios that are increasingly becoming the norm. Either way, you can do great things with HTML5 when HTML5 is done right ... both in the browser and on the device itself.

</pitch>

The closing thought on all of this is that we shouldn't get suckered in by click-baiting headlines that depict the app dev equivalent of red states vs. blue states. It's great fodder for debate I suppose, but app experiences are all about the "and". When people (and by that, I mean regular people) talk about apps, they talk about PCs and phones and tablets and game consoles and cars and (increasingly) home appliances, and the list goes on and on. There's a bigger 'internet of things' discussion to be had later, but this is the reality of how people do stuff, both in and out of work, and these old, ongoing debates about this vs. that always seems to end in an impasse. The only difference now (as opposed to, say, 5-10 years ago) is that we get to impasse much faster, and in 140 characters.

• Google deprecating its SOAP Search API in favor of the more restrictive AJAX API ... see here
• Google deprecating its Translation API ... see here
• Google deprecating Tables and Records feeds for the Spreadsheets API ... see here
• Google, well, just deprecating lots of APIs in general ... see here ... and then trying to pacify developers with  pitiful 1-year support commitments
• Google jamming the websockets protocol onto developers before it was actually done, in a fiasco that was well-chronicled ... here was our take on it
• Google head-faking web devs with Gears ... in 2008, Chrome + Gears was supposed to be the new desktop, but in 2011 Gears was pulled out of Chrome ... see here
• Google marshaling the developer community around Open Social, only to put it out to pasture later ... see here
• Google marshaling the developer community with an API for Google Buzz, only to pull the plug later
• Google marshaling the developer community with an API for Google Wave, only to pull the plug later
• Google doing next to nothing to solve the Android fragmentation conundrum for developers ... see here and here
• Google making late payments to Android developers in Europe, exposing a number of other developer support pain points ... see here
• Google welching on its promise to Mozilla to remove H.264 support from Chrome in support of their WebM science project, effectively forcing Mozilla to reverse course on H.264 ... see here

The list goes on and on.

Now, to be fair, Google is no different than any other platform provider, in the sense that we've all (including Microsoft), at one time or another, changed/reversed/adjusted course on a number of things over the years, either because of developer community feedback, technical strategy course-corrections, competitive pressures, "the world has changed" scenarios, etc., but a little humility goes a long way, and Vic's post, which All Things D describes as having a "sense of delight", contains none of it.   Ten-year support commitments are always helpful, too, but I'm not sure Google's big on those, either.  Maximizing the amount of developer investment in things like skills and code that come forward into new technologies is another piece that we continue to work hard at, but Google seems more inclined toward making a clean break with these sorts of things (and I'm being polite here).   Enough with the compare & contrast ... the point is this: opportunistically taking advantage of an anti-Facebook meme to grandstand about how Google+ is somehow the shining beacon of platform goodness just feels oily.  But more importantly, it deserves some proper context ... the reason Google is or isn't holding back on a write API for G+ is irrelevant ... this is about taking a humble tone in the wake of a dubious track record.

BUILD 2012 will be on the Microsoft campus, and I know what you're thinking ... if it's not in some cavernous convention hall, then it must be a dialed-down version of last year's event, etc. ... but don't be confused: this will be unlike anything we've held on our corporate campus in a long time. More details to come . And, as we talked about in the January post, if you've gone to a Microsoft developer event, you know that most of the speakers and participants are from our engineering teams, so a campus event puts you in the thick of things along with the engineers directly responsible for our products and the platform opportunities they represent. This one's not to be missed.  

So what happens next? Well, at 8AM Pacific time on 8.8 (see what we just did there?), we will open registration for BUILD 2012 at www.buildwindows.com.  At that point, we'll start sharing details over time about keynoters, sessions, content, and more, but for the time being, set a reminder for August 8^th.

That's it for now. Because my thesaurus was unable to suggest a decent synonym for "super excited", let's just say we're stoked about BUILD 2012, and we hope to see you there.

The notion that non-tech-industry people should care about cloud computing continues to weasel its way into mainstream media and popular culture, most recently with a slew of stories about how last week's East Coast storms were to blame for the unscheduled downtime that affected a bunch of popular services on the web like Instagram, Pinterest, and Netflix.   Who knew there was actually such a thing as a derecho or a shelf cloud (sinister photo above)?  I digress.  Anyways, as people continue to come to terms with their reliance on availability and uptime for the unseen back ends of their favorite web destinations, the discussion rages on about we can learn from this and what we'd do differently next time.  A few have posed the question, but it's kind of the same old same old ... a discussion of computing architecture, availability zones, replication, failover, and other IT-specific stuff.  It's useful, for sure, but it begs the most fundamental question of all: how do complex systems fail?  If you ask the question in the context of cloud computing, you'll get to comb through lots of tech papers by tech people talking all sorts of tech jargon about stuff that only other tech people would understand.  I guess that's fine, but it puts a tech lens on something that should be more basic and fundamental than that.

So I went poking around and found a proverbial diamond in the rough ... a paper written over 12 years ago by a doctor, and not a guy with a doctoral degree in computer science, but a medical doctor.  Richard Cook is a director at the Cognitive Technologies Laboratory at the University of Chicago who has done a bunch of work examining impact of health IT on patient safety, and in 2000 published a paper he described as a "short treatise" on the nature of failure entitled, How Complex Systems Fail.  In reading this paper, you'd think he'd had the web on his mind, even back then, but no ... this short 4-pager rises above the level of vertical-industry-specific context and gets to the heart of how stuff breaks.  It's very, very good.  And reading this last week while news of the storm's impact on the web was making headlines here in the U.S. made it an obvious connection back to how we need to think about these new architectures and design points.  I thought I knew a thing or two about this stuff, but this paper was pretty eye-opening. 

- Tim

I may actually be underselling the amount of attention being put on this problem, but that attention has only shown up recently, and now it seems to be everywhere.  The talent situation as it relates to data is getting a lot of punditry now, with lots of smart people trying to figure out the point in time at which the talent supply will catch up with demand and reach equilibrium, as the future career opportunity becomes more apparent to aspiring data quants in their formative years, and as universities load up on courses offered to prepare them for those careers.  We've seen this movie before ... COBOL programmers were in big demand long before universities even had a thing called "the computer science department", and during the dot-com boom in the late 90's, even a flimsy grasp of basic HTML was enough to get you contract work churning out websites.

But we should probably talk about the role of software, too .   The answer to people shortages in the face of economic growth opportunity has always been automation, which was probably the single most impactful thing that fueled the industrial revolution.   So how do you automate the statistician's proverbial "ah-ha" moment while wallowing in a large dataset?  This is where the McKinsey study hits the nail on the head in its May 2011 big data report, which calls out one of the key ways big data delivers value as the ability to "use automated algorithms to replace and support human decision making."   This is, of course, easier said than done, but there are examples if this all around us.     Bing Travel is one of the best examples I know of ... originally launched as Farecast, the service does massive scale analytics on some 200+ billion pieces of historical airfare data to build predictive algorithms for future airfare price movements.  No one is suggesting you hire a Harvard mathematician to help you decide whether or not to buy a plane ticket, but the leap from a consumer scenario like travel to business scenarios like drug discovery or natural resource exploration is an easy one to make ... it's all about data-driven decision-making on a course of action with an expected outcome, and given the state of the analytical talent pool now and in the future, it will be increasingly software-driven.

As for the people who *are* in the talent pool, there are some math geeks out there who are going to get rich.  Both my friend & self-described data geek Peter O'Kelly, and my colleague Dave Campbell have been telling me for nearly 10 years now, "Mark my words ... the data guys are going to win in the end."  They may have been onto something.    Meanwhile, my kids are teenagers, and they're getting all this heat from school counselors to make all sorts of monumental career choices at an age where you can barely think beyond next week.   I just tell them there's this thing called 'supply & demand', and if they know math and statistics, they'll never have to worry about a job, ever.

When web development reached critical mass in the early-mid 2000's, there was a lot of discussion about what it all meant for native development and apps that are optimized for devices, but developers' penchant for exploiting what devices can do has persisted through all of that, and it keeps getting more interesting with every passing year: devices are smarter, faster, and more packed with features than ever before. Gone are the days when developers had to wait patiently for hardware to catch up to software. Now it's the other way around, and it's great for developers, who just can't seem to get enough of cameras, accelerometers, location sensors, touch screens, gesture inputs, voice inputs, and a bevy of other previously-unheard-of coolness.   Even Steve Jobs got an education in this undercurrent as Apple brought the iPhone to market ... if you've read Walter Issacson's book, you know the story: Jobs was of course maniacal about user experience, and was adamantly opposed to the idea of third-party developers messing things up with native apps. Subsequently, the iPhone comes to market with a lot of fanfare about Safari and web mobility, but once developers understood what the device could do, it began a mini-standoff that resulted in a November 2007 capitulation blog post, promising developers an SDK for iPhone and iPod Touch. The rest, of course, is history.

Since then, we've seen the term "device" take on all sorts of different meanings ... most people think of it as a smartphone, or a PC, or a tablet, or a game console to name a few form factors, not to mention the embedded world of ATMs, traffic lights, and sensor networks.  But anything with a microprocessor can run software, and as things get smaller and more modular, the sky's the limit in terms of developer creativity and imagination, which brings us to today's post. Jeff Sandquist and the Channel 9 team have been busy with a project that we've talked about since September, and for lots of folks, it will reshape how you think about what a device is, where it goes, how it gets integrated into things you use today, and (in this case) how amazing it can be when it's done right .

Thanks – Tim 

Those of you who attended or watched BUILD last September may recall a project that Dan, Clint and I have been working on with the guys at West Coast Customs. Against the odds, and perhaps against our better judgment in terms of sleeping hours, we set out to see what was possible when you combine some of the world's most innovative technology, the latest in cloud connectivity and raw American auto muscle. What would it look like if you could take Windows, Windows Phone, Windows Azure, Xbox, Kinect, Bing - you name it - and put it all together into one iconic car?  Well, we're excited to announce that the experiment is complete and "Project Detroit" will be unveiled to the world this Sunday, March 25 at 9:00 p.m. PT/ET on Discovery's Velocity Network.

To say that this has been a labor of love is an understatement. To do this right we knew that we needed to work with the best and the only option was West Coast Customs. Along with Ryan Friedlinghaus and his crew, we started with a 2012 Mustang, retrofitted it with Dynacorn's 1967 Mustang fastback replica body. From there, we piled on Microsoft's latest technologies, many of which have never been used in automotive applications. We created heads-up displays with augmented reality in the windshield. We put a Kinect on the front and a Kinect in the rear for skeletal tracking and live streaming video feeds. We added swipe-able touchscreen dashboard displays and then we tied it all together with Windows Azure in the cloud and Windows Phone applications to control it all. And that's just the beginning.

(want a really big version of this picture? It makes a great desktop background )

To really understand how it all came together, you have to watch the episode, but to give you just a taste, here are some of the things you can expect to see: 

• Windows Phone Integration: Although the Mustang's design makes the car easy to spot, you can keep tabs on the car's location even when it is out of sight. Locate, unlock, and start the car all from the Viper SmartStart app for Windows Phone.
  
• Built-in WIFI: To help ensure the Mustang is always online and connected to the cloud, the vehicle has a built-in 4G wireless network that supports multiple devices.
• Digital Instrument Cluster: Swipe the touch-screen instrument cluster and toggle between different dashboard skins including a 1967 Mustang, a 2012 Mustang and a Windows 8 Metro design style version.
  
• Heads Up Display: Similar to what's found in fighter jets, the windshield contains a driver side and passenger side heads-up display (HUD) highlighting telemetry and Bing Maps information directly on the windshield. View nearby restaurants, shopping centers and gas stations all without taking an eye off the road.  A passenger can play Xbox on his/her side of the windshield without distracting the driver.
• Ford SYNC: Up-to-the-minute traffic information, hands-free communication and even voice control applications are part of the standard Ford SYNC system that is available in Project Detroit.
• Entertainment System: The entertainment system comes with an Xbox 360 and a Kinect. When parked, the rear windshield can actuate up to serve as a projector screen for playing movies or video games from behind the car.
• External Audio System: The audio system acts as a public address system so you can speak into your phone and have the audio played through the car's external speakers. Using this system, the car also has customizable car horn "ringtones" that enable you to change what sound plays when the horn is honked.
• Kinect Integration: Front and rear Kinect cameras provide a live video feed of surrounding pedestrians and objects. You can even watch and listen to the live audio and video stream from the Kinects remotely using a Windows Phone and send a message (see below) to the external audio system like "Hey skateboarders: stay away from my car."

  

• Cloud Powered: Using the built-in wireless network, the Mustang is able to communicate with cloud services including Bing Maps, Viper's Smart Start system as well as store real-time telemetry data such as speed, location, RPM and fuel level in Windows Azure.
• Customizable Rear Windshield: While driving, the rear windshield can serve as a customizable display system that can play video, show images and display custom messages, like "Stop tailgating me please" or something more, umm, colorful.

As a community of developers you might be saying, "that's great, but what does this mean for me?" We started this project because we knew it would be a challenging and fun way to show what all of these technologies can do in an environment like a car. So now we not only have an incredible Mustang "device" to showcase what we have done, we will be making source code for the major components of the project available on CodePlex in the coming weeks.

We want you to think BIG about the types of scenarios you can create. Think bigger – beyond the devices we hold in our hands, those that sit on our desks and the things that mount to our walls. We are so incredibly proud of this car, but we're even more proud of what it represents – ingenuity, creativity and some great demonstrations of Microsoft technologies in cool applied scenarios. Make sure you tune in Sunday, but in the meantime check out some photos and let us know what you think.  As you know, Channel 9 is all about community and Project Detroit is only as successful as you make it.  Get excited, download the code and create your own device powered by hardware and software.

– Jeff

I remember speaking at a number of industry conferences when this whole thing was getting started circa 2007-2008-ish, and just about everyone – private sector companies, industry experts, luminaries, vendors (myself included) – would kick off our talks with some slide that says, "what is cloud computing?", followed by 20 minutes of mind-numbingly complex techno-goo on SaaS and PaaS and IaaS and just-about-everything-you-can-think-of-as-a-service. To make matters worse, the big thinker analysts, pundits, and researchers jumped into the fray to try to put their unique perspective on things, presumably in the interest of selling even more research and analysis to explain the double-click down on said perspective for those who were confused by it, which was pretty much everyone. No wonder people are still scratching their heads on this thing.

But the best part is that from this cacophony of editorial opinions about what the cloud is, the voice of reason emerged from the most unlikely of places … that's right, you guessed it: the US government. Maybe you have (or haven't) heard of the National Institute of Standards and Technology (NIST, for short), who a couple of years ago came up with a working definition for cloud computing that's impressive for its conciseness in nailing a set of essential attributes of cloud computing (on-demand self-service, network accessible, pooled resources, elastic, and metered/measured). Even the definition paper itself is only 3 pages, and it's a government document . See here. Lots of people (yes, us vendors included) have a tendency to sometimes tweak this definition in weird self-interested ways, but at the end of the day, it's a pretty bulletproof list of attributes that gets to the heart of what the cloud actually is.

Why should we even care about this? Because part of the shift going on in the industry at the moment has a major impact on the developers who build these apps, and the approach to design and architecture that ultimately decides whether or not the apps are really optimized for cloud computing. At the risk of oversimplification, n-tier apps are really yesterday's design point. The new design point is cloud. So how do you get there? How do you optimize design & architecture around this new design point? Here's an admittedly incomplete list, but it represents a set of big-ticket best practices that should help to get folks down this path …

Design for scale

Whenever people talk about cloud computing, they talk about scale. The platform you build on has a lot to do with that, but an app design that doesn't allow for scale renders the platform capabilities irrelevant. To deal with this, there are some design patterns that are well-understood and broadly used today. Statelessness is something that web developers have used for years to get scale, and it still holds true for cloud apps as well. Cloud apps run on commodity servers, any one of which could fail and get recycled, and you don't want your app affected when (not if) that happens. Writing asynchronous apps is another approach to getting scale – the idea here is that instead of relying on server availability to respond to multiple front-end requests, you can use things like message queues that can be scaled independently to process requests so users aren't waiting on synchronous responses from a slammed server. Another example of designing for scale involves using role concepts (web roles, worker roles, for example) to create "scale units", which are effectively units of work that you can consistently scale. In the world of "testing in production", this is important … it's simply not practical to test a service for hundreds of millions of users, but you can and should build and test a scalable unit of work that you know you can grow horizontally.

Design for failure

Resiliency is an attribute that's talked about quite a bit in the context of cloud computing, and it's grounded in the reality that stuff happens, hardware fails, human error comes into play, the list goes on and on. Designing for failure means cloud apps should absorb these failures, re-route workloads to running instances, and drive recovery time down to zero. You're going to fail. Embrace it and focus your energy on mean time to recovery (MTTR) vs. focusing on and over engineering for mean time to failure (MTTF). Included in the approach of designing for failure is geo-redundancy. When problems come up, they can often take down an entire datacenter. Even if you've replicated instances across multiple isolation zones or availability zones within a single datacenter, the unit of work is still the physical datacenter. If you lose that, your service goes with it, so multiple instances across multiple geos not only provides the benefit of high availability, but also a solution to the really hard problem of business continuity, which is now table stakes for a cloud app. What once was a serious piece of planning and orchestration becomes much simpler. The funny thing here is that if you talk to someone in enterprise IT about multi-instance and geo-redundancy, the response is often something along the lines of, "Yeah … no kidding." It's been a best practice in big IT for decades … and a lot of developers and cloud startups are learning why that is.

Decompose by workloads

A lot of applications are made up of workloads – seemingly individual pieces, each of which has a specific job to do. An online store, for example, is comprised of searching functionality and checking out, among other things. Each of these specific workloads may have unique availability requirements, costs, security requirements, capacity constraints, scalability, etc. For apps in the cloud, decomposing by workload means assuming more granular control over each workload, and optimizing each of them around what matters for that specific workload ... for some it might be scale, for others it might be resiliency or graceful degradation, for others it might be security. Even failure and recovery is dealt with at the workload level. You can make specific technology decisions at the workload level ... you might want to use a relational store for one workload, and a key value store for another. You're basically optimizing the app on a workload-by-workload basis, which is a much more adaptable approach than tightly coupled systems. By the way, if any of this sounds like SOA circa early 2000's, it's not a coincidence. This was one of the basic principles.

Design for interoperability

The idea of multiple components connecting across services running on the Web is not a new idea, as composite apps have been around for decades. What's different now is that app composition/mash-up is no longer done in the confines of a walled garden or a proprietary, single-vendor stack. It's now done in the cloud, and interoperability and standards-based approaches matter more than ever before. Cloud development requires people to "think more like the web", and build apps with a mix of platform services, languages, runtimes, frameworks, and protocols that work together. This means that identity federation becomes pretty important, as having a composite app in which each piece has its own unique identity/auth system is unwieldy to say the least. A common set of REST APIs also makes life easier from a composition standpoint, as well as OData for data access. The underlying assumption here is that religion about one stack to rule them all is a thing of past, and we hear this from customers all the time … heterogeneous environments, either on-prem or in the cloud, are the norm. The apps that run in these environments are simply nodes in a network of services, and those nodes need to interoperate without a lot of architectural gymnastics.

Design for operations

There's a fair amount of energy today around the idea of "dev/ops" as a new org model for a services business – a much tighter integration between the building and running of apps that's more aligned with the services world of continuous development and deployment. But the organizational construct doesn't matter if that app itself doesn't facilitate it and unlock its potential. The attributes that support this are things like measurability, and the ability to isolate, detect, and rollback. Apps need to provide health information, and the implementation of versioned interfaces for doing diagnostics, drilling into issues, and applying fixes & remediation is a design-time decision. Taking it a step further, there is the issue of automation, and the use of these interfaces to automate creating, provisioning, de-provisioning, and restoring services. The more of this that's manual, the less reliable the app will be, so automation is another important thing to optimize around. Testing also plays a huge role here … you don't know how reliable your app is unless you're stressing it with failures as part of your regular operation. Netflix's use of Chaos Monkey is probably the best example I've seen of how to go all-in on tuning your infrastructure to absorb and withstand failures.

As I mentioned earlier, this is not by any means an all-inclusive drill-down into prescriptive architectural guidance on cloud apps … it's intended to be more of an introduction to the principle: there are lot of developers these days putting single-instance, n-tier apps onto hosted VMs, proudly hanging the "cloud" shingle on their door, and then wondering why their apps are impacted by component failures, and why their apps don't scale, and why they have to manually look after their VMs, and why the services dream isn't being realized. I guess that's to be expected, given where we are in the process of moving to what is effectively a generational shift in computing, but we're moving toward something very different than the apps we know today. It's a new design point, a new set of app patterns, a whole new approach to designing, building, and running apps.

Today, we're introducing Vector. It's a blog about developers, platform, and big ideas/trends in tech, but with a little bit different bent on what folks are used to from Channel 9...

It's been eight years since Channel 9 first introduced many of our key engineering folks to the developer community to deliver a transparent view into how we think about the technologies we're working on, the teams doing the work, and the huge community of people in and around Microsoft that are connected to all of it. None of that changes ... the team continues to produce the great content that has personified Channel 9 since 2004. But we're also going to spend some time on a more 'elevated' view of what we're thinking when it comes to our own strategy, our competitors, broad-based industry stuff, and of course the intersection of all of this with business. Sometimes it'll be topical, other times it will just offer commentary on something that people are talking about. We will also have guest posters talking about what they're doing that fits in this vein.

So that brings us to an actual post on something meaningful ... the disruptive impact of the services model on businesses.

- The Channel 9 Team

In 2007, Nick Carr published "The Big Switch," which chronicles the evolution of electricity from being locally-generated by businesses on their factory floors to something we all now consume as a pay-for-what-you-use utility. The book draws parallels between electricity and packaged software as a means to offer up a potential end-state for cloud computing, hence the title ... there will be, the book asserts, a switchover from in-house datacenters to software delivered as a utility, and it's just a matter of time. It's a good book, not steeped in technical jargon but rather a set of thoughtful mappings between these two eerily similar eras of technology disruption.

Nearly five years have gone by since it was first published, and a lot has happened (and not happened) relative to the pace of cloud adoption ... we know a lot more about what motivates companies to push some apps out the door and into public clouds in a hurry, while other apps will take their time, or maybe even continue to run on-premises in so-called private cloud environments. So it begs a bunch of questions: What is the end state for the services disruption? Is it public cloud platforms and SaaS, or a hybrid of public and private cloud deployments, combined with traditional IT? In other words, is the big switch actually more of a dimmer switch, in the sense that it's not just a simple matter of on/off? Are there any other historical lessons or examples of disruption we can draw insight from?

Disruption is a great word ... if you talk to enough developers, IT folks, and industry pundits about services, "disruption" shows up as by far the most-used and (IMO) best descriptor for what's happening in computing today. Scenarios that used to be impractical, uneconomical, and just plain impossible are now fair game for developers to build and deliver, all because of increasingly cheap and abundant resources like compute, storage, and bandwidth, available at scale and on a pay-as-you-go basis. So when people talk about disruption, the shape of its impact on the market is generally assumed by most folks to be one of outright replacement, such as the advent of electricity as a utility, the combustion engine's replacement of the horse-drawn carriage, and digital media's disruption of physical media, to name a few - basically, the end state in which the disruptive technology means buggy-whip obsolescence for the existing technology. But not all disruptions play out this way, and there are more than a few historical examples, my personal favorite being the captivating story of the microwave business. Seriously, it's actually pretty interesting ...

So here's the story (courtesy of Wikipedia):

As we all know, atomic research started in the 1940's for military purposes, but one of the offshoots of it was the discovery that you could actually use microwave radiation to heat food. Like most technology disruptions (including cloud computing), the discovery & development pre-dated mass adoption by many years. In the case of the microwave, the earliest patents were filed by Raytheon just after World War II, and were licensed to Tappan for the first home-use microwave. It was introduced in 1955 and cost over $1,000, but not surprisingly it didn't do well in the market. Raytheon got back into the game by acquiring Amana and introducing the Radarange in 1967 for about $500, and that's really where market adoption began to take shape. In 1971, 1% of US households owned a microwave, and by 1986 it was 25%, and today it's over 90%.

What's interesting here is how the adoption curve was shaped based on the market's education on what you could and couldn't do with this thing. Keep in mind that the value prop of the microwave was time-savings for the subset of cooking tasks for which the new technology could be used. Can you bake a cake with a microwave? They're not ideal for that. Can you thaw out frozen stuff? Yeah, it's great for that. What about broiling a salmon? Well, no. How about reheating leftovers? Yeah, it's perfect for that. Why do sparks fly everywhere when I put metal in it? You should really read the owner's manual. This was all part of what could best be described as a partitioning process ... partitioning what you do in a kitchen between the existing thing and the new thing. How was this process accelerated? It was just outright education, in many cases through print and TV advertising, which were rife with "ideas" about what you could actually cook, but also by shipping microwave cookbooks with the actual units. Some of the recipe ideas were a stretch (Thanksgiving turkey in a microwave?), but over time, people figured it out and knew what they should and shouldn't be cooking with it, and that essentially determined the end state for the disruptive technology: every modern kitchen will generally have both a conventional oven and a microwave.

So what can we learn from this? Allowing for the fact that the oven business and computing are two entirely different animals, the biggest and most obvious parallel is the ongoing education of the market that we're seeing now about which apps are and are not necessarily well-suited to public cloud deployment. In other words, within any business' app portfolio, there are no-brainers for cloud deployment (web workloads, email, collab, CRM, test, HPC, etc.), while other apps and workloads are subjected to more scrutiny, at least for the time being (ERP, mission-critical apps, apps with HBI data, etc.). Every business, no matter how small, has a portfolio of apps, and this process of portfolio portioning is pretty similar to the task-partitioning process that shaped microwave adoption. In the software industry, we see this in business scenarios, in which there's a lot of focus these days on things like PII at massive scale, infrastructure security, data sovereignty, the regulatory environment, and a host of other factors that business folks consider as part of the go/no-go decision on cloud computing.

At any rate, the end state is becoming increasingly clear: businesses end up with a mixed bag of delivery and deployment approaches to deal with the variable needs & complexities of each & every app in their respective portfolios, at least for the foreseeable future. If you pay attention to cloud computing rhetoric in the industry, hybrid cloud is the new black, but for our part, but the answer was there all along. There's an obvious tension between the possibilities afforded by what is arguably the biggest shift in our industry since the advent of client/server, and the practical realities of technology change for businesses that are grappling with this new era of computing. But from a technical strategy standpoint, there is no confusion on our part ... the design point that defines cloud computing is the path forward for app dev: the next set of apps that matter will be designed for scale and elasticity. They'll be resilient, multi-instance, and highly available. Everything we're doing in the platform across Windows Azure and Windows Server is geared toward enabling developers to meet this design point with the new apps they're building.

This means that today's great debate is twofold: a.) where will these new apps run? And b.) where will those existing apps end up? Off-prem in the cloud, or on-prem in the data center? The answer is "yes." And that's really the point ... the discussion about *where* the apps run (and what most people fixate on when they talk about the services disruption) is orthogonal to the discussion about whether it's an app that meets the bar for the cloud design point vs. an n-tier app running in a VM that's really yesterday's design point. Most businesses' portfolio of apps will have both kinds, old school and new school, and they'll be partitioned across off-prem and on-prem. Cloud adoption in big companies still has a ways to go, but even in these early days, the emerging trend line is becoming increasingly clear. Nick Carr even called this one in the "Big Switch", in the form of this excerpt from pg. 118...

"...larger companies...can be expected to pursue a hybrid approach for many years, supplying some hardware and software requirements themselves and purchasing others over the grid. One of the key challenges for corporate IT departments, in fact, lies in making the right decisions about what to hold on to and what to let go."

The idea that app portfolios will be partitioned in this way seems pretty intuitive to the folks that are grappling with the change, at least based on the customer discussions we're having these days. To be clear ... the cloud design point is, without a doubt, what we're headed toward with a new generation of apps that are going live in increasing numbers every day (and the subject of a future post), but their place in the broader business app portfolio makes it's trajectory more akin to a dimmer that's turned up over time than a simple on/off.

Thanks for listening – comments & feedback welcome.

-Tim