Wednesday, March 19, 2008

The Social Enterprise Opportunity

I want to begin today with a quick shout-out to my fellow bloggers at Data Center Knowledge. In a recent post, they identified me as one of the bloggers they follow for cloud and utility computing, and I'm honored to me included among such a strong list of bloggers. (Rich Miller, who posted the list, is no slouch himself.) Update: I violated the cardinal rule of Internet social networking: assuming a given name applies to one person. Rich Miller from Data Center Knowledge is not the same Rich Miller that writes Telematique. My apologies to both.

One of those bloggers is Phil Wainwright, whose Software as Services blog is one of my regular reads. He is the most aggressive, forward thinker in the SaaS space, and he is very often sees opportunity that most of us miss. (Phil's blog is also a great way to stay on top of the companies and technologies that specifically support the SaaS market.)

Phil recently wrote an interesting post about SaaS and Web 2.0 concepts, titled "Enter the socialprise", in which he points out that the very nature of an "enterprise" is changing thanks to the Internet and cloud computing concepts. He notes that loyalty between individuals is replacing corporate loyalty, and that social networking on the Internet is creating a new work economy for individual knowledge workers.

He then goes on to challenge enterprise computing models:
But enterprise computing is still designed for the old, stovepipe model in which every transaction took place within the same firm. There’s no connection with the social automation that’s happening between individuals. Many enterprises even resist talking about social networking. And even when an application vendor adds some kind of social networking features, there’s always the suspicion that they’re just painting social lipstick on a stovepipe pig.

This yawning chasm is an opportunity for a new class of applications to emerge that can harness the social networks between individuals and make them relevant to the enterprise. Or perhaps reinvent a new kind of enterprise, better suited to the low-friction reality of the connected Web. Enter the socialprise.

The example he gives of a company leveraging this is InsideView, which is creating a very cool sales intelligence application that integrates with major SaaS CRM vendor products to aggregate information from a variety of online sources into a single prospect activity dashboard. This is an incredibly cool example of how rich data about individuals within and across firms can be used at an enterprise level.

Another product that is similar that struck me was JobScience, which is one of the companies whose blog is in the Data Center Knowledge list referenced above. JobScience is using force.com to create a rich social intelligence engine for Salesforce.com customers. Their product, aptly called Genius, is an excellent example of what they are able to do. Read the post for all the features, but my favorite is:
The Genius Tracker. Not only does the tracker pop up to tell me an email recipient has just opened my email, or is visiting my web site, but the more important intelligence this gives me is that this prospect is is online and engaged with our solution. If a sales rep can call 40 people in a day, and a blast to 5000 prospects shows me that 40 of those prospects are online and engaged, it doesn’t take a genius to figure out who to call. That rep’s going to have a much more productive day calling people who they know are in the office. Less voicemails, less brushoffs, less calls to people who don’t work there anymore.
Bordering on privacy issues, I know, but an amazing level of detail, and invaluable if used wisely. More importantly, it goes to show what is possible in a stable, shared application environment.

By the way, this direct integration with a given CRM platform by a "value added extender" is an interesting twist to the dependency issues that Bob Warfield writes about on the SmoothSpan blog. JobScience's products are services that become a feature of the destination both visually as well as functionally. Bob's point about being a component provider to the actual product is well taken, and I wonder if the only exit strategy for these guys is acquisition by Salesforce. What else can they hope for as a company dependent on force.com? Talk about cloud lock-in.

Monday, March 17, 2008

How to find me these days...

I must apologize for my continued absence (8 days now) in the blogosphere, but I have a "perfect storm" of time-demanding things in my life right now. Blogging is taking the hit, unfortunately. I should be back to regular posting in the next week or two.

In the meantime, you can follow what I am reading/doing at http://friendfeed.com/jamesurquhart. If you are on FriendFeed already, just subscribe to me and I'll return the favor.

Also, if you haven't watched Simon's pre- and post-conference talks from the Enterprise 2.0 Summit at CeBIT, they are a must-watch. Simon is really tightening up this talk, and I hope he gets a chance to present it soon in sunny CA.

Finally, I am using my del.icio.us page now to highlight key articles and posts from my Google Alerts emails (most importantly, alerts on "utility computing" and "cloud computing"). This will also show up on FriendFeed, however.

Lot's going on. I'm itching to comment on Ray Ozzie at MIX, James Governor on what makes cloud computing cloud computing, and what I hope to achieve at GreenDevCamp this year.

Sunday, March 09, 2008

Update on Dataportability.org activities from the source

Interesting interview of Chris Saad and Frank Arrigo (Chris is organizing dataportability.org, and Frank is a Microsoft employee that is somehow related) by Robert Scoble.



Interesting in here is the update on what dataportability.org is focusing on right now--standard "best practices" for open data, and a "logo" to indicate standards are followed--plus the discussion of Silverlight, etc.

Wednesday, March 05, 2008

Off Topic: Just added Snap to site...let me know if its annoying

I just added Snap Shots to my blog, which will bring up previews of the target site/page when you roll over a external link. Let me know if you think its annoying. I'm really just experimenting, as I have both loved and hated this feature on other sites. Feel free to email me or comment below.

I have a client install that will take the next couple of days, so blogging is way down. In the meantime, keep track of what I am reading, Twittering, scheduling, etc at http://friendfeed.com/jamesurquhart.

Tuesday, March 04, 2008

Service as a Service Market Explored

Real quick, David Linthicum has a cool post on the move in the market from human-oriented SaaS (Software as a Service) to systems oriented SaaS--perhaps better named "Service as a Service". The naming is a little nerdy, but David is right on about this being an ultimate goal of the SaaS market, as well as of cloud computing in general.

Again, be prepared for real challenges to your distributed software systems architecture, and for challenges to your mental model regarding IT and IT operations.

Sunday, March 02, 2008

Ah, Yes. How To Define Cloud Computing...

Geva Perry, Chief Marketing Officer at GigaSpaces, wrote an article that has the tiny cloud computing community I follow a-buzzing. In it, Geva essentially makes the argument that utility computing is a business model (which, at its heart, it is), and cloud computing is a technology; specifically, so-called grid computing technologies.

Now, as you may know, I'm the father of two small children (an infant and a 3 1/2 year old), so I wasn't able to take the time to respond promptly. Thank goodness Simon Wardley was. His post breaking down SaaS, utility computing, cloud computing and virtualization is an enlightening one. For the most part, I agree with how he characterized everything, so I won't simply restate his post here.

(Damn. That's two references to Simon's blog in a row. Am I becoming a groupie? :)

The one area that I'd like to explore, however, is the specific definition of cloud computing. When you see folks like Geva and Simon talk about a "computing grid" in relation to cloud computing, you must be careful not to confuse that definition of "grid" with the "high performance computing" definition that many in the IT industry maintain. (Like who? Check out gridcomputing.com.) I want to challenge everyone who sees cloud computing as either "grid computing gone wild", or "virtualization applied to everything" to step back a second and look at the bigger picture.

Eric Schmidt is widely credited for raising the term "cloud" into the mainstream IT lexicon. (He almost certainly didn't invent it, but there is clear evidence that he understood the effects of increasing bandwidth on computing years ago, and successfully challenged the world to imagine the "cloud".) So I think its only fair to examine Eric's vision of what cloud computing would be. Here is his full response to the simple question of what Google sees Web 3.0 being:



Now, I will grant that his answer is tilted a little bit to what the user experience of the cloud will be in the next generation, but I think his argument that the next phase of cloud computing is a fundamental shift in software development is an excellent one. Change it to a fundamental shift in software development and deployment, and it goes to the heart of my own definition of cloud computing.

(Lest you think equating Eric's Web 3.0 to cloud computing in general is a stretch, check out Nick Carr's analysis on Eric's comments.)

Cloud Computing: One Man's Definition

Cloud computing describes a systems architecture. Period. This particular architecture assumes nothing about the physical location, internal composition or ownership of its component parts. It represents the entire computing stack from software to hardware, though system boundaries (e.g. where does one system stop and another begin) may be difficult to define. Components are simply integrated or consumed as need requires and economics allow.

There are two key sub-architectures, in my opinion: the functional architecture, and the deployment architecture.
  • The functional architecture is traditional software stuff, and can (but is not required to) include elements like service orientation, recombination (e.g. "mashups") and loosely coupled integration (both within and across organizational boundaries).

  • The deployment architecture includes all of the supporting components that allow the functional architecture to operate. This obviously includes both physical and virtual infrastructure (including servers, networks and storage), but may also include such software elements as middleware, enterprise service buses or various service automation platforms.

Demand for this architecture is driven by technology organizations who seek increased access, quicker innovation and reduced cost within the software and infrastructure marketplace. Now, you may go back and look at both Geva's post and Simon's post, and say "um, what's different about your definition except semantics?" Well, I feel my definition is broader than either of theirs. To me, SaaS is an element of the cloud. So are PaaS and HaaS. So is software designed to run in optimized infrastructure, as well as software deployed in capacity provided by an external supplier/utility.

The key thing isn't "how does it work", but "how can I use it".

And, again, as the others have noted, cloud computing is not synonymous with software as a service, utility computing, virtualization or even grid computing. Rather, each of those are models that can be applied to this systems architecture (as well as several others, really), and utilized to deliver a user experience and economics that will--some day, many years from now--change the world.

By the way, as several others have noted, we aren't there yet.

Friday, February 29, 2008

Fun with Simon

Simon Wardley created a couple of posts this week that make for good smiles. The first is his maturity model for cloud computing:



This one I agree with. Very funny, but funny because it reflects truth.

The second is a post on open source computing. I completely disagree with the concept that open source can keep up with closed source in terms of innovation (Anne Zelenka makes a great argument here), and that closed source is bad for ducks (see Simon's post).

However, I do believe that standardization spreads faster with open source than with closed source. For what its worth, I would also like to see a major utility computing platform release its technology to open source. (Well, at least the components that are required for portability.) I just wonder why any of them would without pressure from the market.

My equations would reflect the "Schrodinger's Cat" aspects of closed source products prior to the introduction of accepted standards,

open source == kindness to ducks
closed source == ambivolence towards ducks; could go either way
:-)

FriendFeed

I just wanted to let everyone know that my entire time-wasting life--er, online research--can be found at http://friendfeed.com/jamesurquhart. I love this site, but wonder how the heck they are going to make any money. There are no ads or anything.

If you are on friendfeed, subscribe to my feed. Several other big name bloggers are also there, which makes it very cool for understanding what they are reading or commenting on.

Wednesday, February 27, 2008

Enterprise Architecture, Business Continuity and Integrating the Cloud

(Update: Throughout the original version of this post, I had misspelled Mr. Vambenepe's name. This is now corrected.)

William Vambenepe, a product architect at Oracle focusing on enterprise management of applications and middleware, pointed me to a blog by David Linthicum on IntelligentEnterprise that makes the case for why enterprise architects must plan for SaaS. In a very high level, but well reasoned post, Linthicum highlights why SaaS systems should be considered a part of enterprise architectures, not tangential to them.

As Vambenepe points out, perhaps the most interesting observation from Linthicum is the following:

Third, get in the mindset of SaaS-delivered systems being enterprise applications, knowing they have to be managed as such. In many instances, enterprise architects are in a state of denial when it comes to SaaS, despite the fact that these SaaS-delivered systems are becoming mission-critical. If you don't believe that, just see what happens if Salesforce.com has an outage.

I don't want to simply repeat Vambenepe's excellent analysis, and I absolutely agree with him. So let me just add something about SLAuto.

Take a look at Vambenepe's immediate response:
I very much agree with this view and the resulting requirements for us vendors of IT management tools.
Now add the comments from Microsoft's Gabriel Morgan that I discussed a couple of weeks ago.
Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well.
Gabriel's point boiled down to the following equation:
Service Offering = (Product Features) + (Operational Features)
which I find to be entirely in agreement with Linthicum and Vambenepe.

As I am wont to do, let me push "Operational Features" as far as I think they can go.

In the end, what customers want from any service--software, infrastructure or otherwise--is control over the balance of quality, cost and time-to-market. Quality is measured through specific metrics, typically called service level metrics. Service level agreements (SLAs) are commitments to maintain service level metrics within commonly agreed boundaries and rules. In the end, all of these "operational features" are about allowing the end user to either

  1. define the service level metrics and/or their boundaries (e.g. define the SLA), or
  2. define how the system should respond if a metric fails to meet the SLA.

Item "2" is SLAuto.

I would argue that what you don't want is a closed loop SLAuto offering from any of your vendors. In fact, I propose right here, right now, that a standard (and, I am sure Simon Wardley would argue, open source) protocol or set of protocols for the following:
  1. Defining service level metrics (probably already exists?)
  2. Defining SLA bounds and rules (may also exist?)
  3. Defining alerts or complex events that indicate that an SLA was violated

Vendors could then use these protocols to build Operational Features that support a distributed SLAuto fabric, where the ultimate control over what to do in severe SLA violations can be controlled and managed outside of any individual provider's infrastructure, preferably at a site of the customer's choosing. This "customer advocate" SLAuto system would then coordinate with all of the customer's other business systems' individual SLAuto to become the automated enforcer of business continuity. In the end, that is the most fundamental role of IT, whether it is distributed or centralized, in any modern, information driven business.

"Nice, James," you say. "Very pretty 'pie-in-the-sky' stuff, but none of it exists today. So what are we supposed to do now?"

Implement SLAuto internally in your own data centers with your existing systems, that's what. Integrate SLAuto for SaaS as you understand the Operational Feature APIs from your vendors, and those vendors, your SLAuto vendor and/or your systems talent can develop interfaces into your own SLAuto infrastructure.

Evolve towards nirvana, don't try to reach it by taking tabs of vendor acid.

If you want more advice on how to do all of this, drop me a line (james dot urquhart at cassatt dot com) or comment below.

Tuesday, February 26, 2008

Jonathon Schwartz hints a MySQL cloud

Robert Scoble interviewed Jonathan Schwartz today using his ultracool Nokia N95/Qik personal broadcasting package. During that interview, Jonathan made an interesting non-announcement. It seems, he notes, a natural fit that a data center expert like Sun could leverage their new highly scalable database environment, MySQL, to build a MySQL cloud service.

I think this is would be awesome; not only because it forces Oracle to consider getting into the same market (thus potentially creating a competitive commodity database service market), but also because it opens all kinds of possibilities for add-on capabilities that might not be economically feasible to develop in a traditional enterprise sales model.

Here's my only suggestion to my former boss, Mr. Schwartz. Buy Endeca. Not because they own the ecommerce search for most combination "bricks-and-mortar"/online retailers (they do), but because the technology has been developed in such a way that it can be used as tag-based search for just about any data source. (They don't present it that way, but I got an in depth demo, and that is what it is.) What I imagine would be a competitive advantage for Sun/MySQL would be a cost-per-byte data source with both SQL and tag-based or unstructured querying. Buy Endeca!

OK, soon we will have capacity, storage and databases in the cloud. Who wants to be first in the "System Management as a Service" game?

Monday, February 25, 2008

Comments on Paul Wallis: Cloud Computing

Paul WillisWallis has an excellent post tying the history of prior utility/cloud/grid computing attempts to the current hype. I've been trying to comment for a while, but haven't been able to get comment submission to work until today. This is a reworking of that response, in case it doesn't get through moderation for some reason.

Let me just say that, contrary to Paul's description of my position may sound to others, I am not blindly "pro-cloud". In fact, I firmly recommend that existing enterprise data centers and applications think hard before going "outside" to a commercial capacity-on-demand provider. In most cases, it would actually be better for such enterprises to convert their own infrastructure to a utility computing model first, while the necessary technologies and businesses mature.

I also define the cloud broadly, to include SaaS, PaaS (e.g. force.com) and HaaS (e.g. Amazon, Mosso, etc.). SaaS is in clearly in play today, HaaS is being experimented with, but PaaS may be the most interesting facet of the cloud in the long term.

That being said, Paul provides very valuable information in this post, and I for one very much appreciate the work put onto it. It is very true that bandwidth is something to be nervous about (especially when Amazon charges as much as it does for bandwidth), and I have had some interesting discussions (such as the one Paul references) about how data integration will happen over the cloud. Finally, cloud-lockin is indeed something to be concerned about; as in, what happens if my first choice provider sucks? Can I move my applications, data, etc. to someone else cheaply enough that it doesn't put me out of business? Simon Wardley has a good post on that today.

Update: Er, two seconds and I could have confirmed the spelling of Paul's last name. Sorry, Paul!

HPC in the Cloud

Check out Blue Collar Computing. High Performance Computing is one area that should really benefit from utility computing models. Imagine gaining access to the worlds most powerful computers (with reasonable assistance from experts on programming and deploying on those systems) at a price made reasonable by paying only your "share" of resource usage costs.

Cool to see someone try this business model out for real.

Wednesday, February 20, 2008

Data Goes SLAuto at Oracle

Thanks to Steve Jones, check out this presentation from David Chappell, Oracle VP and CTO of SOA, titled "Next-Generation Grid Enabled SOA". (A shorter written article can be found in at SOA Magazine's site.) Chappell outlines the work that Oracle is doing at turning the traditional model of application scalability on its head; instead of a fixed amount of database resources and scaling the applications/services horizontally, scale the database (using a cool complex adaptive systems approach) and alleviate much of the need to scale apps and services (except for CPU bound services). For someone like me, that's mind blowing.

Add to that the fact that the data management functions are relatively homogenous (though the infrastructure may not be), and aware of its resource utilization, and you can see why they are claiming a certain amount of hardware-metric based SLAuto.

(Hardware metric based SLAuto is based in measurements of hardware components, such as CPU utilization, memory utilization and so on. Software-based SLAuto usually uses business metrics such as transaction rates, active accounts, etc. to make scaling decisions.)

The catch? Well, everything must be written to use the "Data Grid" if its to take advantage of these capabilities. Legacy applications need not apply. (Could be the deal killer for David's "Not your MOM's Bus" concept.)

It seems to me that if Oracle wants this approach to catch on, it should open source a reference implementation as soon as possible. I'm not an expert at the most recent data processing approaches, but it would seem to me that Map-Reduce approaches would be complimentary to the Data Grid. However, Hadoop implementations would generally only be integrated with a data grid if there was an open source alternative. Otherwise, MySQL will continue to be the first choice. Open Source would also speed up integration between the data grid and infrastructure automation such as Cassatt and its competitors.

Dave hints at a URL for more info on the Oracle site, but I can't find it. If anyone tracks it down, I would appreciate any help I can get.

Government Data and the Greater Cloud

These days, so much is being made of cloud computing from the "capacity-on-demand" perspective, that I thought I'd take the time to review an interesting "service" that I consider an element of the "cloud system" in the larger sense. It's not a Web Service as such, but a site that performs a valuable service that can be utilized in business or government applications.

John Udell introduce me to EveryBlock with his discussion of how EveryBlock is exposing the value of free access to government data. This public information site is heavily processing data readily available from public agencies, allowing any user (or other system) to query the data in ways not originally intended by the agency. John has an excellent example of these types of queries, but I played around with the site a little, and I can see that this is an excellent resource. Imagine what this service can do for the legal, construction and journalism industries.

Of course, John notes that the government data isn't nearly as *digitally* available as it needs to be. I hate to "me too" his post, but I have to concurr. These agencies aren't *good* cloud citizens until they expose their public data via a (hopefully simple) API.

(Caveat: I am still trying to determine if EveryBlock has an API, but their site HTML looks parsable enough.)

Many of the "cloud computing" definitions I've seen lately have had to do with how easy it is to move resources around between "capacity-on-demand" vendors. I want to submit that the "cloud system" is everything that is available to support computing via the Internet, including the key services that are ready to be integrated into other applications. Google Maps for instance. Or Flickr. Just as long as they remain decoupled from the clients that use them, any electronically accessible Internet property has a potential to contribute to the cloud system.

Friday, February 15, 2008

A Day of Storage and the Cloud

My reading began this morning with Nick's covereage of the Amazon S3/EC2/AWS outage. Perhaps most interesting to me, though, were the comments. A variety of people responded to note that we perhaps are holding the cloud to impossibly high standards, while others noted that this was supposed to be a distributed service, and an extended downtime like this indicates a certain lack of redundancy. I find this facinating, in light of the recent discussion of cloud lock-in. Not surprising, just facinating.

Let me explain.

While I remain extremely concerned about the proprietary operational approaches taken by most "capacity-on-demand" providers--many based on open source platforms, ironically--I think it is important to acknowledge that:
  1. 100% uptime is unreasonable for any platform in its infancy, including S3
  2. Not everyone will be negatively impacted as much by a three hour outage as some
  3. SLAs should be set if service is extremely critical to a business. Ironically, Amazon has limits on who and what they will provide SLAs for.
  4. Even with a three hour outage, Amazon S3 is probably the best service of its kind...for now.

That last point is critical, as Nick put up another post later in the day highlighting EMC's plans to enter the cloud storage market---in a big way. The competitors to Amazon are coming, and that fact may change the equation for how much leeway Amazon has in the future.

Assuming it is not super onerous to copy data from one provider to another--Storage may in fact be the earliest of the commodity cloud components if this is true--an alternative approach will make it that much simpler for an unsatisfied customer to make a move. This, in turn, will make some who will tolerate an outage now, well, less tolerant.

I anxiously await Amazon's explaination for the glitch.

By the way, Robert Scoble certainly believes Amazon has won the cloud market in its entirety already. He is way off, of course. Do you know how much datacenter capacity there is in corporate America alone? There is no way one company that is spending a fraction of the budget on building new data centers that Microsoft, Google and Yahoo are will create a barrier of entry that high. Amazon is a typical first enterant, ala Netscape. Hopefully the market is different enough, though, that they can build a survivor.

Thursday, February 14, 2008

Latency: Obstacle to cloud computing, or opportunity?

I was challenged in the comments to my Cloud Computing Heats Up post regarding my criticism of pupwhines' post that in turn criticized cloud computing. The anonymous author of the comment thought I was too hard on pupwhines, and wanted to know what my response specifically was to the challenge latency presents to distributed computing. I responded there, but I want to expand a little bit on the topic, as it is indeed important to understand, and backs my contention that there will need to be some software architectural changes made to leverage the cloud system.

(Quick note: I've alluded to this before, but I strongly believe there is no one cloud, but a bunch of siloed clouds today with *some* limited integration between them. More of a frontal system, really.)

Latency is an issue in most IT application environments today. There is no question that "traditional" tiered application design scales well at the processing layer, but has real issues at the data layer. There is simply no easy way to manage a traditional relational database architecture over a widely distributed environment. Pupwhines' contention that joining a table between two SaaS vendor implementations would be disaster is right on. In modern technology terms, it would be insane.

However, this is the disruptive aspect of cloud computing: the architectures you know and love are no longer necessarily best practices in a world where your functionality and capacity is:
  1. not necessarily your own,
  2. not necessarily integrated, and
  3. splayed out across this 5.1×108 km2 rock we live on
There are new technical advances being made today in the companies that already rely on cloud principles (think Google, Amazon, Microsoft, etc.). These advances will change the way you design and deploy software, but they will enable a world where proximity of data means less and less.

In fact, you probably already leverage one of these technical changes: increased bandwidth. Indulge me in some autobiographical narrative to illustrate.

Back in the late '90s, while I was a Senior Principal Consultant with Forte Software, Inc, the legendary(?) distributed application development platform vendor, one of my key roles was advising clients on how to best architect for high performance, high scalability and high availability. Forte was an early service oriented architecture, but it ran on the 10Mb/100Mb networks of the time. Thus, the rule for message passing between components (UI<->service or service<->service) was (in order of priority):
  1. Send as few messages over the network as possible
  2. Send the smallest messages possible

Thus, it was better to send large messages once than many small messages, but you wanted to optimize each message as much as possible.

To this end, best practices was to create data services and to actually deploy these services directly on the database server hardware. It was more important to process the relational mapping of data into the object mapping according to need in a timely fashion--thus avoiding unecessary network traffic--than to divide processing responsibility so that there was no custom application components running on the RDBMS hardware.

Fast forward to the 1G/10G networks of today. From what I am seeing, it is actually considered bad practice to do what I described above. While at Sun, I actually got admonished by a (very competent) manager for suggesting the way around Sun Access Managers horrible performance was to deploy the identity server and database on the same box (with our custom login and registration UIs deployed on separate, horizontally scalable servers). Pure architectural heresy. He was right in many ways: doing so would have put the business logic tier into horizontally locked architecture, but that wasn't his point. "We don't deploy our software on our database servers" was the gist of his argument.

So, faster networks have already changed the so-called "laws of physics" that software architects must design around. Given this, it seems easy to postulate that additional advances in network bandwidth will open additional opportunities for architectural change. In fact, it already has; check out Gigaspaces for a cool (though controversial) alternative to horizontally replicated service architectures.

Will bandwidth really grow at a rate that will make a difference to the current IT generation(s)? Many postulate it has to, even if the core network operators resist. As I noted in my response, Cisco's new Nexus 7000 series is a sign of times to come. Does anyone deny that 40G and 100G networks have the opportunity to change the laws of physics? (Disclaimer: I know just enough about networking to be dangerous, so I may be overstating the case...but change is still clearly on the horizon.)

Even if network bandwidth doesn't change at all, or any additional bandwidth is chewed up by demand at existing rates, there are other software architectural advances that will revolutionize certain kinds of computing. I spoke in my response about MapReduce and its open source implementation, Hadoop. For processing large, distributed data loads, this architecture is eliminating boundaries created by traditional scaleout RDBMS-based approaches. Google has used this approach to tie data from every one of its properties (including acquired properties, such as Blogger) into a single user identity and profile. Talk about a distributed join problem...

(Another quick note: hats off to Google and Yahoo respectively for their work in this space. I know from my past life at Sun what a pain in the whatever this is, and I love the seamlessness I experience on these sites.)

One other major advancement is the increasing sophistication of business integration technologies, from traditional application integration (force.com, boomi.com, BizTalk, Lombardi, etc.) to data integration options (Informatica, Business Objects, etc.) to subscription data propogation techniques. These integration options can allow one to go back to some of the basics I spoke of before: do as much processing as possible on Saas vendor A's infrastructure before sharing the relevant data with vendor B. Not as perfect as a join in many cases, but in a service oriented world, a common, required approach for most.

Perhaps the most important point I want to make today, however, is that today--in the modern IT era--many of these technologies are either future tech or not what was used to build existing applications. Given that, what does an existing datacenter do? Stick to my recommendation; convert your own datacenter into a utility/cloud today, and begin to leverage the maturing compute grid/cloud computing ecosystem as it and your applications mature.

Tuesday, February 12, 2008

Green Aware Programming

monkchips writes about "green aware programming", as coined by Christopher O’Connor, vice-president strategy and market management, Tivoli. I responded and pointed out that "green = cheap" in the utility computing world.

Sunday, February 10, 2008

Analyzing the Green opportunity

I just want to quickly bring Ken Oestreich's analysis of the Green Grid meeting in San Francisco (Day 1 and Day 2), and its aftermath to your attention. Pay special attention to the aftermath post, as it is one of the most well thought out statements of the status and opportunity for the Green Grid organization I have seen.

Ken really knows his stuff with respect to the Green Data Center movement, so if you have any interest in the subject at all, subscribe to his blog. His earlier analysis of DC energy efficiency metrics is an all time classic on the subject.

Friday, February 08, 2008

Off Topic: Blog domain change

With increased interest in Service Level Automation in the Datacenter, I decided to take the advice of many a more successful blogger than me, and register my own domain name for the blog. I debated quite a bit about which name to select, but in the end I wanted a domain that would travel with me regardless of where my career might take me in the future. (No plans to leave Cassatt, but you never know where the future might take you...)

To that end, this blog will now officially reside at http://blog.jamesurquhart.com. The original URL, http://servicelevelautomation.blogspot.com will continue to operate, but will redirect you to the new site. All feeds should also continue to work unchanged.

Please let me know if you have problems by emailing me at james dot urquhart at cassatt dot com.

Thursday, February 07, 2008

The importance of operations to online services customers

I hadn't caught up on Gabriel Morgan's blog in a while, so I'm a week or so late in seeing his interesting post on the importance of operations features in a SaaS product offering. Gabriel works at Microsoft on the team that is looking at the Software plus Services offerings introduced by Ray Ozzie a few months ago. According to Gabriel, being a software product company, Microsoft has occasionally been slow to learn a key lesson in the online services game:

In the traditional packaged software business, product features define what a product is but Customer 2.0 expects to have direct access to operational features within the Service Offering itself.

Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well. In traditional packaged software products, these features were either supported manually, didn't exist or were change requests to a supporting IT department.

In other words "Service Offering = (Product Features) + (Operational Features)".

Wow. What a simple way to state something I've been concerned about for some time now: as you move your enterprise into the cloud, will your service providers (be it SaaS, HaaS, PaaS or others) provide you with the tools and data you need to successfully operate your business? How will you be able to interact with both the service provider's software and personel to make sure those operations run a) according to your wishes, and b) with no negative impact on your business?

Gabriel goes on:
Guess who builds and supports these Operational Features? Your friendly neighborhood IT department in conjunction with the Operations and Service Offering product group. This raises the quality bar for your traditional IT shop.
Heck, yeah. And guess what? Should a business do something crazy--oh, say, select SaaS products from more than one vendor to integrate into their varied business processes--they will need not only to build solid operational ties with each vendor, but integrate those operational features across vendors. Think about that.

How best to do that? You shouldn't be surprised when I tell you that a key element of the solution is SLAuto under the control of the business. Managing SaaS systems to business-defined service levels will be a critical role of IT in the cloud-scape of tomorrow.

Wednesday, February 06, 2008

Cloud computing heats up

Today's reading has been especially interesting, as it has become clear that a) "cloud computing" is a concept that more and more IT people are beginning to understand and dissect, and b) there is the corresponding denial that comes with any disruptive change. Let me walk you through my reading to demonstrate.

I always start with Nick Carr, and today he did not disappoint. It seems that IBM has posited that a single (distributed) computer could be built that could run the entire Internet, and expand as needed to meet demand. Of course, this would require the use of Blue Gene, an IBM technology, but man does it feed right into Nick's vision of the World Wide Computer. To Nick's credit, he seems skeptical--I know I am. However, it is a worthy thought experiment to think how one would design distributed computing to be more efficient if one had control over the entire architecture from chip to system software. (Er, come to think of it, I could imagine Apple designing a compute cloud...)

I then came across an interesting breakdown of cloud computing by John M Willis, who appears to contribute to redmonk. He breaks down the cloud according to "capacity-on-demand" options, and is one of the few to include a "turn your own capacity into a utility" component. Unfortunately, he needs a little education of these particular options, but I did my best to set him straight. (I appreciate his kind response to my comment.) If you are trying to understand how to break down the "capacity-on-demand" market, this post (along with the comments) is an excellent starting place.

Next on the list was a GigaOm post by Nitin Borwankar stating his concept of "Data Property Rights" and expressing some skepticism about the "data portability" movement. At first I was concerned that he was going to make an argument reinforced certain cloud lock-in principles, but he actually makes a lot of sense. I still want to see Data Portability as an element of his basic rights list, but he is correct when he says if the other elements are handled correctly, data portability will be a largely moot issue (though I would argue it remains a "last resort" property right).

Dana Blankenhorn at ZDNet/open-source covers a concept being put forth by Etelos, a company I find difficult to describe, but that seems to be an "application-on-demand" company (interesting concept). "Opportunity computing", as described by Etelos CEO Danny Kolke describes the complete set of software and infrastructure required to meet a market opportunity on a moments notice. “Opportunity computing is really a superset of utility computing,” Kolke notes. Blankenhorn adds,

"It’s when you look at the tools Kolke is talking about that you begin to get the picture. He’s combining advertising, applications, the cash register, and all the relationships which go into those elements in his model. "

In other words, it seems like prebuilt ecommerce, CRM and other applications that can quickly be customized and deployed as needed, to the hosting solution of your choice. My experience with this kind of thing is that it is impossible to satisfy all of the people, all of the time, but I'm fascinated by the concept. Sort of Platform as a Service with a twist.

Finally, the denial. The blog "pupwhines" remains true to its name as its author whimpers about how Nick "has figured out that companies can write their own code and then run it in an outsourced data center." Those of you that have been following utility/cloud computing know that this misses the point entirely. Its not outsourcing capacity that is new, but its the way it is outsourced--no contracts for labor, no work-order charges for capacity changes, etc. In other words, just pay for the compute time.

With SLAuto, it gets even more interesting as you would just tell the cloud "run this software at these service levels", and the who, what, where and how would be completely hidden from you. To equate that with the old IBM/Accenture/{Insert Indian company here} mode of outsourcing is like comparing your electric utility to renting generators from your neighbors. (OK, not a great analogy, but you get the picture.)

Another interesting data point for measuring the booming interest in utility and cloud computing is the fact that my Google Alerts emails for both terms have grown from one or two links a day, to five or more links each and every day. People are talking about this stuff because the economics are so compelling its impossible not to. Just remember to think before you jump on in.

Sunday, February 03, 2008

Off topic: Hey, my wife is an entrepreneur!!!

This is just too much fun.

Mia has been amazing throughout Emery's pregnancy, birth and early weeks. Her focus and determination has really made the addition of a new "startup" much easier than I anticipated (though its early yet :). She has seen to it that Owen knows he is still her favorite little boy, and I love the time we have been able to spend together between my family leave and the late nights.

She faces the difficult choice of returning to school in the next few weeks, and I just wanted to say publicly that I am so proud of all she is doing. She is the true entrepreneur in our family.

Tuesday, January 29, 2008

One Step To Prepare For Cloud Computing

Some of you may be wondering why I am making such a big stink about software architecture on a blog about service level automation (SLAuto). Well, as Todd Biske points out, "the relationships (and potentially collisions) between the worlds of enterprise system management, business process management, web service management, business activity monitoring, and business intelligence" are easier to resolve if the appropriate access to metrics is provided for a software service. For SLAuto, this means the more feedback you can provide from the service, process, data and infrastructure levels of your software architecture, the easier it is to automate service level compliance.

Let's look at a few examples for each level:
  • Service/Application: From the end user's perspective, this is what service levels are all about. Key metrics such as transaction rates (how many orders/hour, etc.), response times, error rates, and availability are what the end users of a service (e.g. consumers, business stakeholders, etc.) really care about.
  • Business Process: Business process metrics can warn the SLAuto environment about cross-service issues, business rule violations or other extraordinary conditions in the process cycle that would warrant capacity changes at the BPM or service levels.
  • Data Storage/Management: Primarily, this layer can inform the SLAuto system about storage needs and storage provisioning, which in turn is critical to automated deployment of applications into a dynamic environment.
  • Infrastructure: This is the most common form of metric used to make SLAuto decisions today. Such metrics as CPU utilization, memory utilization and I/O rates are commonly used in both virtualized and non-virtualized automated environments.

As noted, digital measurement of these data points can feed an SLAuto policy engine to trigger capacity adjustment, failure recover or other applicable actions as necessary to remain within defined service thresholds. While most of the technology required to support SLAuto is available, the truth is that the monitoring/metrics side of things is the most uncharted territory. As an action item, I ask all of you to take Todd's words of wisdom into account, and design not only for functionality, but also manageability. This will aid you greatly in the quest to build fluid systems that can best take advantage of utility infrastructure today.

Monday, January 28, 2008

It's the labor, baby...

I'm getting ready to go back to work on Wednesday, so I decided today (while Owen is at school and Mia has Emery) to get caught up on some of the blog chatter out there. First, read Nick Carr's interview with GRIDToday. Damn it, I wish this was the sentiment he communicated in "The Big Switch", not the "its all going to hell" tone the book actually conveyed.

Second, Google Alerts, as always, is an excellent source, and I found an interesting contrarian viewpoint about cloud computing from Robin Harris (apparently a storage marketing consultant). Robin argues there are two myths that are propelling "cloud computing" as a buzz phrase, but that private data centers will never go away in any real quantity.

Daniel Lemire responds with a short-but-sweet post that points out the main problem with Robin's thinking: he assumes that hardware is the issue, and ignores the cost of labor required to support that hardware. (Daniel also makes a point about latency being the real issue in making cloud computing work, not bandwidth, but I won't address that argument here, especially with Cisco's announcement today.)

The cost of labor, combined with real economies of scale is the real core of the economics of cloud computing. Take this quote from Nick Carr's GRIDToday interview:
If you look at the big trends in big-company IT right now, you see this move toward a much more consolidated, networked, virtualized infrastructure; a fairly rapid shift of compressing the number of datacenters you run, the number of computers you run. Ultimately … if you can virtualize your own IT infrastructure and make it much more efficient by consolidating it, at some point it becomes natural to start to think about how you can gain even more advantages and more cost savings by beginning to consolidate across companies rather than just within companies.
Where does labor come into play in that quote? Well, consider "compessing of the number of datacenters you run", and add to that to the announcement that the Google datacenter in Lenoir, North Carolina will hire a mere 200 workers (up to 4 times as many as announced Microsoft and Yahoo data centers). This is a datacenter that will handle traffic for millions of people and organizations worldwide. If, as Robin implies, corporations will take advantage of the same clustering, storage and network technologies that the Googles and Microsofts of the world leverage, then certainly the labor required to support those data centers will go down.

The rub here is that, once corporations experience these new economies of scale, they will begin to look for ways to push the savings as far as possible. Now the "consolidat[ion] across companies rather than just within companies" takes hold, and companies begin to shut down their own datacenters and rely on the compute utility grid. Its already happening with small business, as Nick, I and many others have pointed out. Check out Don McAskill's SmugMug blog if you don't believe me. Or GigaOM's coverage of Standout Jobs. It may take decades, as Nick notes, but big business will eventually catch on. (Certainly those startups that turn into big businesses using the cloud will drive some of these economics.)

One more objection to Robin's post. To argue that "Networks are cheap" is a falicy, he notes that networks still lag is speed behind processors, memory, bus speeds, etc. Unfortunately, that misses the point entirely. All that is needed are network speeds that get to the point where functions complete in a time that is acceptible for human users and economically viable for system communications. That function is independent of the network's speed relative to other components. For example, my choice of Google Analytics to monitor blog traffic is solely dependent on my satisfaction with the speed of the conversation. I don't care how fast Google's hardware is, and all evidence seems to point to the fact that their individual systems and storage aren't exceptionally fast at all.

Thursday, January 24, 2008

Data propagation and software fluidity

Jon Udell has an interesting post commenting on Jeff Jonas' explaination of Out-bound Record-level Accountability in Information Sharing Systems. The central thesis of Jeff's post is that tracking who specifically received a given datum is very expensive yet highly necessary in many applications. The example given is that of a user who wishes to no longer receive email from a site they have an account with, or any of the other sites that the original site shared that preference with. How does the original site know who to contact? The high cost is a result of the difficulty in tracking who data has been forwarded to.

John replies very simply that a "publish" model, much like blogging, might be the answer. "Data blogging", coined by fellow blogger Galvin Carr, refers essentially to the problem of syndication, but Udell projects that to a much wider arena of data types. As he notes, there is much evidence out there that "push" models are generally only applicable to edge systems calling "inward". "Publish and Subscribe"-type pull models are far easier to implement when running "outward" from the cloud to edge systems (as well as, generally, within the cloud--aka event-driven architectures).

There are two valuable results of this approach:
  1. The originating system can require users of data to subscribe with a unique identity, and each "pull" of published data could be tracked (if necessary) to identify who is up to date and who isn't.
  2. For software fluidity purposes, it further decouples the originating system from its subscribers, meaning both the subscribers and the originating system can be "moved" from physical environment to physical environment with no loss of communication. The most negative action that could take place here is if the originating publisher's DNS name changed in the course of the move, but redirects and other techniques could even mitigate that issue.

I am commenting on this, of course, largely for the second item. Access to data, services and even edge devices must be very loosely coupled to work in a cloud computing world. This is one great example of how you could architect for that eventuality, in my opinion.

Wednesday, January 23, 2008

Children of the Net: Why Our Decendents Will Love The Cloud

Our children--or perhaps our grandchildren--won't remember a time when there was a PC on every desk, or when you had to go to Fry's Electronics to buy a shrink-wrapped copy of your favorite game. This, as Nick notes frequently in The Big Switch, is one of the real parallels between what our ancestors went through with electrification and what we have yet to go through with compute utilities. Heck, I already find it hard to remember when I didn't have access to the World Wide Web, and in what year all of that changed. Also, I'm frankly already taking the availability of services from the cloud for granted.

My Dad used to tell me stories of when he lived in a house in Scotland with only a few lights and no other electrical appliances, no indoor plumbing and no telephone. I can't imagine living like that, but it was just about 50-60 years ago. Those born in the latter half of the twentieth century (in an industrialized country) are perhaps the first to live a lifetime without seeing or experiencing life without multiple sockets in every room. It is unimaginable what life was like for our ancestors pre-electrification.

There will likely be both positive and negative consequences that come from any innovation, but to the innovator's descendants, they won't remember things any other way. In the end, once basic needs are taken care of, all human kind cares about is lifestyle anyway, so the view of how "good" an "era" is, is largely driven by how well those needs are taken care of. One of those basic needs is the need to create/learn/adapt, but another one is the need for predictability of outcome. This constant battle between the yearn for freedom and the yearn for control is what makes human culture evolve in brilliantly intricate ways.

I for one hold out hope that our descendants will be increasingly satisfied with their lifestyles, which--in the end--is probably what we all want to see happen. Will those lifestyles be better or worse from our perspective as ancestors? Who knows...but it won't really matter, now, will it?

Of course, one of the biggest challenges to humanity is meeting even the basic needs of its entire population. To date, the species has failed to achieve this--the study of economics is largely targeted at understanding why this is. Cloud computing could, as Nick suggests, actually make it more difficult for some groups of people to meet their basic needs, but I would argue that this would be counter productive to the rest of society.

At the core of my argument is the fact that so much of online business is predicated on massive numbers of people being able to afford a given product. Nick argues that life in the newspaper world shows us the future of most creative enterprises; the ease of the masses to create and find content makes it difficult to sell advertising to support newspapers, thus the papers struggle. But if huge numbers of people are out of work, with no one valuing their talents and experience, that will lead to less consumer spending. Less consumer spending will lead to less advertising, which will in turn lead to less income for "the cloud" (i.e. those companies making money from advertising in the cloud). Its a horribly negative feedback cycle for online properties/services, and one I think will fail to come to pass.

The alternative is that the best of the talent out there continue to find ways to get paid, while the masses are still encouraged to participate. Newspaper journalists are already finding opportunities online, though perhaps at a slower pace then some would like. I believe that ventures such as funnyordie.com and even YouTube will create economic opportunities for videographers and film makers to rise above the noise. Musicians are already experimenting with alternative online promotion and sales tools that will change the way we find, buy and consume music. Yes, the long tail will flourish, but the head of the tail will continue to make bank.

The result of this is simply a shifting of the economic landscape, not a wholesale collapse into a black hole. Yeah, the wealth gap thing is a big deal (see Nick's book), but I believe that the rich are going to start investing some of that money back into the system when the new distribution mechanisms of the online world mature--and that should create jobs, fund creative talent and create a new world in which those that adapt thrive, and those that don't struggle.

Did I mention I think the utility computing market is a complex adaptive system?

Sunday, January 20, 2008

Evidence of pending doom and imminent salvation...

Two news articles that occurred as soon as I went offline for the birth of my daughter provide increasing evidence of the importance of service level automation and image portability between vendors:

  • Joyent, one of the most ambitious new "capacity on demand" managed hosting services, has experienced a multi-day outage that has affected two of their prime storage services. No failover path was available to users of the services, and there is no mention of functionality or services to assist customers with moving--temporarily or permanently--to another vendor's service. Odds are high that some of these customers have lost access to key data, or are flying without substantial backups to key systems. Any decision to move to a different servers (like Twitter will according to the post) is on the customer's own dime.

    A prime example of the dangers of vendor lock-in that Simon and I have been warning you about...


  • Oracle has announced its intention to build and sell "Grid 2.0" technology that will target--yes, you heard right--service level automation. Welcome to the SLAuto game boys. I hope you're ready to talk standards for image and policy portability; as well as policy platform interoperability. Otherwise, you're just creating a new DB grid "silo", and not helping anyone in the long run. Please, feel free to educate me if you think otherwise...

These events show the caution that users of cloud services must employ. Be ready to take on increased integration responsibilities as you deploy more and more elements of your datacenter to the cloud, automate more of the management of those elements, and find the product landscape one in which there (still) is no silver bullet. You may not be writing apps, but you sure as heck will be writing the orchestration that will tie the apps you employ into a cohesive business process ecosystem. You may also find yourself writing backup integration again, just in case you experience "Joyent 2.0"...

Thursday, January 17, 2008

Off Topic: Introducing Emery Anne Urquhart


Emery Anne Urquhart
Born 1/16/2008
7lb, 12 oz
19 3/4"
Mom and baby are fine. Dad is scared silly, however...

Tuesday, January 15, 2008

Off Topic:The next two weeks...

Just a quick note about what I will be doing for the next two weeks starting tomorrow morning. At 5:30AM sharp tomorrow, my wife and I will arrive at the hospital for the birth of my daughter, my second child. I will post pictures and/or video when it is available. (Also off topic, I know, but I'm just too proud...)

Once "Baby Girl" has arrived, I will be splitting my time between caring for my son, caring for my wife and baby girl, and caring for all three. In other words, the blogging will suffer a bit. Once we get settled in a bit, I'll start posting again. That may be a few days or a few weeks. Please be patient.

On a vaguely related note, I finally got Feedburner set up for my site, and I was happy to find so many of you were regular subscribers. I hope many of these are mutual subscriptions where I also follow your work, but if you'd like to let me know where and what you post, please post a comment here and I'll check it out.

In the meantime, for utility computing related topics, stay in touch with Nicholas Carr, Simon Wardley and Anne Zelenka. (Anne's post on GigaOM is especially good, and one that I seriously wish I wrote myself. She captured much of what I would want to say about the effect of utility computing on the middle class, and placed Nick's book in exactly the right context.)

Friday, January 11, 2008

The Compute Grid is Like Nothing Before It

In a continuation of the discussion regarding Nick Carr's "The Big Switch: Rewiring the World from Edison to Google" and Yochai Benkler's "The Wealth of Networks: How Social Production Transforms Markets and Freedom", I want to focus today on the shortcomings of the electric utility analogy--or any other analogy I have heard of for that matter--in describing the compute capacity utility story. It is important to note that, while the electricity-as-utility story has dominated the utility computing discussion to date, other interesting analogies have been put forth lately that enlighten some aspects of the compute story while clouding (no pun intended) others.

Let's start with the electric utility analogy that Carr focuses on in his work. Nick does an excellent job of laying out both the history of electric production and distribution in the United States, as well as mapping those to similar aspects of compute utilities. As Nick puts it:
"The commercial and social ramifications of the democratization of electricity would be hard to overstate...Cheap and plentiful electricity shaped the world we live in today. Its a world that didn't exist a mere hundred years ago, and yet the transformation that has played out over just a few generations has been so great, so complete, that it has become almost impossible for us to imagine what life was before electricity began to flow through the sockets in our walls.

Today we're in the midst of another epochal transformation, and its following a similar course. What happened to the generation of power a century ago is now happening to the processing of information. Private computer systems, built and operated by individual companies are being supplanted by services provided over a common grid--the Internet--by centralized data-processing plants. Computing is turning into a utility, and once again the economic equations that determine the way we work and live are being rewritten."
OK, so its hard to argue with the basic premise that we are undergoing a change that is similar to the introduction of cheap, readily available electricity in the early twentieth century. Nick is a master for pointing how the evolution of electric technology fed changes in societal norms, and vice versa. "It's a messy process--when you combine technology, economics and human nature, you get a lot of variables", he writes, "but it has an inexorable logic, even if we can trace it only in retrospect."

Unfortunately, the same can be said about a variety of other technical advances that didn't end up looking like the electric marketplace; take manufacturing, food production, and music and film production, for example. All of these have elements that can be seen as paralleling utility computing, social production or both. Yet none of them really map completely, and the flaws in the analogy have a "chaos"-like ability to magnify as history bears out.

Now, to Nick's credit, he does start Part 2 of the book--his in depth comparison of the social implications of utility computing--with the following comments:
"Before we can understand the implications for users...we first need to understand how computing is not like electricity, for the differences between the two technologies are as revealing as their similarities."
He goes on to highlight the following differences, using them to make key points about how the effects of compute utilities on society may not be nearly as beneficial as the effect of electric utilities:
  1. With electricity, the applications of the commodity lie outside of the utility--i.e. the appliances, electronics, lighting, etc. that consume the power. With computing, the applications themselves are deliverable over the network, and can be shared by anyone that wants to (and is allowed to) use them.


  2. Computing is much more modular than the electric grid, meaning that the components that make up the commodity service (storage, processing, networking) can be split up and offered by a variety of different parties.


  3. The compute utility is programmable; it can be made to perform a variety of custom tasks are required by its customers. Electricity from your basic power outlet is a fixed state commodity--there are exacting standards to what it is and how it is delivered, as well as laws of physics that limit how it can be used.


  4. Choosing an electric utility was generally an all-or-nothing choice; you either got power from the grid, or you had your own power generation. The modularity of computing, however allows for a slow transitional change from private to public consumption. (I think there is a serious flaw in this analogy, for what its worth. Look at the increasing installation of solar power systems in residential applications--all while remaining a part of the grid. This seems to indicate a gradual transition to a hybrid public/private power grid in the electricity space.)


  5. The compute utility allows others to participate directly in creating value for the utility, and do so cheaply and simply. Providing power to the electric grid has always been expensive and very technical (as, I have to admit, is true in my objection in point 4).
These are excellent examples, and are all important to note (even point 4). However, I think Nick fails to note the most important difference between electricity and data processing; namely

data != electricity

There are huge implications to what is being moved over the network versus what is being moved over the power grid, beyond just the programmable elements. These differences are critical when analyzing the compute as utility story, and its a shame he doesn't address them.

For example, checking his index for the terms "security", "data security" or "software security" shows exactly zero entries. When talking about the transition of data vs electricity, it seems critical that one consider the sensitivities that people and organizations have about how it is transmitted. "Privacy" is the subject of a 7 page essay highlighting what we have been willing to give up so easily, but he basically uses the subject to highlight a specific trait of the network without investigating how related issues will cause compute capacity to differ from electricity. My own opinion is that these two subjects--security and privacy--are exactly what will slow down the "total conversion" to centralized computing utilities for customers like banks, classified federal bureaucracies and health care. I spoke of this in detail before.

As noted earlier, others have commented on some of these issues, and have used other analogies like manufacturing to counter the electricity analogy. One excellent example of this is an an article by Michael Feldman of HPCwire in which he argues that a better analogy is food production. As he puts it:

"When food became a commodity, agribusiness conglomerates took over and replaced lots of family farms with much larger, more efficient "factory farms." Today, crops like wheat and soybeans are typically grown on multi-hundred acre land parcels. But not all food products are easily commoditized. Specialty fruits, vegetables, and organic products don't usually lend themselves very well to large-scale production. According to the U.S. Department of Agriculture about a quarter of farm revenue is still generated on family farms. Many of these farms are focusing on these specialty items and have formed cooperative arrangements in order to remain economically viable."

This analogy works from the standpoint that it describes a system in which people care about the varying qualities of the service output by the "utility". For example, we all know the amount of effort spent by the FDA and others to make sure our meats aren't tainted with deadly bacteria. In fact, some specialty food producers have built their marketing message around food safety and health, and many of those are small, boutique producers. Other small players have provided specialty food items to very specific markets with great success. I have believed all along that the compute market will evolve into a few major players and hundreds (thousands?) of small boutique specialty players, especially in the SaaS space. ("Special SaaS with that?" Please forgive me...)

Unfortunately, the food analogy also breaks down in one critical way:

data != food

In this case, its the real, physical nature of food, and the accompanying issues with logistics, cost of production (including fixed real estate costs), and brick-and-mortar sales that don't compare well to the zero marginal production cost nature of data. Replicating food and shipping it to a new customer destination are expensive acts; doing the same with data costs nearly zero. Furthermore, geographic location means nearly nothing for computing. Food, on the other hand is subject to cultural, climatological and logistical limitations to where it can be produced and sold.

For this reason, computing will tend to a much higher level of centralization than food production has seen. Intuitively, one must believe that this will lead to larger displacement of private data centers than would have happened if it was more expensive to share infrastructure.

I'm still trying to digest all of this, but I have a growing feeling that Carr's dependency on the "Edison analogy" (to coin a phrase for no good reason) actually limits the likelihood of some of his arguments. He also seems to assume that the economics of the web won't evolve much from where it is today--largely advertising based, with millions of people willing to do stuff for free and few existing cultural industries willing to produce for online audiences. I want to bring Benkler back into the conversation when I cover this in a later post.

(One side bar on the commercial production of online content: did anyone see the news from NBC today?)

Monday, January 07, 2008

7 Businesses to Start in 2008

Rather than offer a list of predictions for 2008, I thought I'd have some fun suggesting some businesses that could make you money in 2008 or the few years following.

  1. SaaS<-->Enterprise data conversion practice: All those existing enterprise apps will need to have their data migrated to that trendy new SaaS tool; and should anyone actually decide they hate their first vendor, they'll be spending that money again to convert to the next choice. Perhaps they'll even get fed up and return to traditional enterprise software. Easy money.
  2. Enterprise Integration as a Service: No matter how much functionality one SaaS vendor will provide, it will never be enough. Integration will always be necessary, but where/how will it be delivered? Go for the gold with a browser based integration option. Just figure out how to do it better/cheaper/faster than force.com, Microsoft, Google, Amazon, etc...
  3. SaaS meter consolidation service: Given the problem stated in 2 above, who wants 5 or 6 bills where its impossible to trace the cost of a transaction across vendors? Provide a single billing service that consolidates the charges of the vendor stable and provides additional analytic capabilities to break down where costs and revenues come from. Then get ready to defend yourself against the data ownership walls put up by those same vendors (see 4 below).
  4. SaaS/HaaS Customer litigation practice: Given the example of Scoble's experience with Facebook, there are clearly a lot of sticky legal issues to be worked out about "who owns what". Ride that gravy train with litigation expertise in data ownership, vendor contractual obligations and the role of code as law.
  5. SaaS industry (or SaaS customer) data ownership rights lobbyist: Given 4 above, each industry player is going to want their voice in congress to protect/promote their interest. Drive the next set of legislation that screws up online equality and individual rights.
  6. Sys Admin retraining specialist: All those sys admins who will be out of work thanks to cloud computing are going to need to be retrained to monitor SLAs across external vendor properties, and to get good at waiting on hold for customer service representatives.
  7. Handset recycling services: The rate at which "specialized" hardware will evolve will raise the rate of obsolescence to a new high. Somebody is going to make a killing from all those barely used precious metals, silicon and LCD screens going to waste. Why not you?

Friday, January 04, 2008

"Social Production" vs. "Greed" Online

I want to start my comparison of Yochai Benkler's tome, "The Wealth of Networks: How Social Production Transforms Markets and Freedom", and Nick Carr's "The Big Switch: Rewiring the World from Edison to Google" with coverage of the direct critique of the former in the latter.

Benkler proposes that we are entering a new phase of economic history, which he calls the "networked information economy". Counter to the prior industrial economy, this phase is highlighted by the rising effect of "non-market" production on the creation of intellectual capital, made possible by the near zero cost of creating and sharing content on the Internet.

According to Benkler, in a network based economy:

  1. "Individuals can do more for themselves independently of the permission or cooperation of others."


  2. "Individuals can do more in loose affiliation with others, rather than requiring stable, long-term relations, like coworker relations or participation in formal organizations, to underwrite effective cooperation."
As a result of this, says Benkler, "we can make the twenty-first century one that offers individuals greater autonomy, political communities greater democracy, and societies greater opportunities for cultural self-reflection and human connection."

In chapter 7 of Carr's book, titled "From the Many to the Few", Carr makes an argument for the inequitable effects of social networking and unpaid content creation. With specific reference to Benkler and others writing about the rising importance of the so-called "gift economy", he notes that

"[t]here's truth in such claims, as anyone looking at the Web today can see...[b]ut there is a naivete, or at least a short-sightedness, to these arguments as well. The Utopian rhetoric ignores the fact that the market economy is rapidly subsuming the gift economy."
As evidence, Carr notes that two of the most important Web 2.0 acquisitions of the last couple of years--that of Flickr by Yahoo, and YouTube by Google--were driven in large part by the incredible economics of these companies. When Flickr was acquired for $35 million, there were less than 10 people on staff. YouTube had less than 70 employees when they were bought for 1.65 billion.

However, perhaps the most astounding comparison between the two is that both had millions of people producing, organizing and promoting content, but effectively none of them got a single dime of equity. When YouTube was sold, each of the 3 founders got about a third of a billion dollars for 10 months of work. Its hard to argue that Google bought the web site software for that price. Google bought content and traffic, both of which were largely attributable to those unpaid millions.

I think Carr is right, unfortunately, that we overestimate the influence that "open" technologies will have on the incumbent industrial system. Carr notes important evidence like the growing income gap between the richest Americans and the rest of us, as well as the struggle that newspapers and other media companies are having to generate sufficient income to sustain their businesses--and, in turn, their employee's standard of living. I will add that even the distinct line between "open source" and "proprietary" projects is blurring, as Anne Zelenka notes on GigaOM today. The result of this trend will, of course, be mixed. At times the content created out of love, frustration or even narcissism will loosen the grip of corporate systems on our society, but these may always be offset by new controls and entrepreneurial successes by these same systems.

On the other hand, I think Nick is too skeptical about the amount of change that will beset business in the coming decades. It is easy to think of ways to provide equity to those that produce content, and I believe someone will come up with a business that does so in the next year or two. Furthermore, the process of democracy itself may be changed significantly in the next two decades, as both the government and entities seeking influence over the government (or seeking to loosen the control of government) find new ways to tweak the system. John Udell at Microsoft has covered an interesting corollary, public access to government data, and noted some of the progress made in that space.

Those of you that have read me for a while know that I am extremely interested in complexity theory and its applications to technological development. In the end, I believe what we are going to see in the next data is an "edge of chaos" process, where the forces of liberalization continually struggle against the forces of social and economic inertia. In the long term, however, I believe that this process will continually better the lives of those swept up in it; with (significant) luck, the lives of everyone on Earth. What is left to chance, however, is the amount of pain and suffering that may be felt as change takes place.

Wednesday, January 02, 2008

First look at Nick Carr's "The Big Switch" and Yochai Benkler's "The Wealth of Networks"

Welcome back one and all. I hope everyone enjoyed the holidays as much as I did this time. While I enjoyed several visits with family and friends throughout the week, most of my time was spent either playing with my son, or preparing the house for the arrival of my daughter in two weeks. As you might imagine, the latter is taking up most of my mental cycles these days.

I did, however, spend some time reading two books over the break, both covering the broad topic of the effects of Web 2.0 and the compute cloud system on society and culture. One is a very positive economic analysis of what the possibilities may be, while the other is a skeptical comparison of the history of the electric grid with the evolving history of the compute grid.

"The Wealth of Networks: How Social Production Transforms Markets and Freedom", by Yochai Benkler--which can be read for free online--surprised me as being a much more fascinating read than I expected it to be. I knew that Benkler was going for a more formal economic analysis of the effects of "non-market" production online (e.g. videos submitted to YouTube, photos on Flickr, etc.), but his analysis of both the trends and possibilities was actually very easy for anyone in technology to understand, and didn't require a lot of economics knowledge. I'm still working on this one, but I will provide some more in depth discussion in later posts.

Nicholas Carr's latest, "The Big Switch: Rewiring the World from Edison to Google", is everything you would hope from Nick, though perhaps with a little bit darker outlook than expected. However, I believe this is a must read for anyone contemplating the utility computing revolution, as it lays out an honest assessment of the evils that utility computing will bring along with the good. Using the history of the electric utility grid as a model, Nick points out that particular technical revolution brought with it promises of the democratization of humankind, but actually unfolded with much more mixed results. Utility computing will be no exception, Carr argues, and I heartily agree with him--though I am not sure I agree with all of his detailed examples and predictions.

I actually recommend reading these two books in parallel, as I have been. Here's what I did, and I think it allowed me to read both texts with a more critical eye:
  • Read Chapters 1-3 of Benkler to get a sense of the economic arguments about how social production will change the way we interact, generate information and entertainment, and possibly change our political and cultural landscape to create a more egalitarian society.
  • Now read Carr's work in its entirety, mostly to get sucked back to earth about how Benkler's grandiose vision is just that, a vision; much of the positive developments Benkler looks for can easily be countered by opposing forces looking to maintain or enhance the status quo.
  • Now finish Benkler's work to gain a detailed perspective of the economics at work in the online world, but with a more critical eye towards his desired social and political outcomes.

I am still working on Benkler's book, but I can say now that my eyes have been opened to how much change is before us, and how the great value we get from social production is tempered by the effects on certain careers, economic segments and perhaps even the quality of work we produce itself.

I will dig into a few specific subjects soon, comparing Benkler's vision with Carr's, and adding my own "special sauce". I would really welcome comments from my contemporaries who have read one or both of these works, including critiques of my critiques. My intuition tells me that those that understand what is at stake, and what could happen--both good and bad--will have a distinct advantage as the next two decades play themselves out.

Update: Below are links to the follow on posts for this joint review of the two works: