The Pervasive Data Center

"Real world" examples of some trend or business model are great. Theory is fine up to a point but eventually it's awfully nice to connect up with a concrete example that gives the theory some real cred.

At the same time, examples can mislead us. Often they turn out to be anomalies. Maybe a company is some sort of historical quirk, a product of a very specific time and place. Or maybe some technology approach is valid enough--but only for a very narrow set of needs. One warning sign is seeing the same tired examples trotted out for every discussion, every news article, and every conference.

I see some of that in all the following cases. I certainly won't go so far as to say that the underlying trends or business models are illusory. But I do think they're more limited or further away than their most overenthusiastic proponents suggest.

The Long Tail, as popularized by Wired's Chris Anderson is a hot meme of the blogging and Web 2.0 crowd. Simply put, the Long Tail states that bestsellers aren't in the majority when you tally up the sales at Amazon or Netflix. Rather it's the total of the far more numerous other 80 or 90 percent of content. From a business perspective, the significance is that there's money to be made selling what's in the long tail.

However, the number of true long tail businesses gets thin outside of aggregators of digital media--the companies who have minimal costs to acquire, inventory, and sell incremental low-volume products. Amazon, in particular, is a highly atypical, if not unique, retailer in terms of scale. In fact, we're starting to see a body of evidence that suggests that the long tail is, if not necessarily wrongheaded exactly, more limited in applicability and degree than some of its proponents have suggested.

We've also seen pure Open Source much touted as a viable business model. By "pure," I mean a model that doesn't hold any software back for paying customers only. The hope is that enough users will elect to pay for support and other services to cover a company's cost and profit. Red Hat, a profitable and growing company, is the poster child here.

But Red Hat is exceptional really. It's emerged as the unquestioned leader among enterprise Linux distributions, one of the most visible and core elements of the entire Open Source world. And its financial success is helped, in no small part, because it's selling a value, ISV application certification against Red Hat Enterprise Linux, that doesn't have the equivalent in layered software products. Other pure Open Source plays have also been modestly successful, but we're certainly not talking Oracle or Microsoft levels of success--nor, indeed, Sybase or SAS levels. Even Red Hat pulls in well under $1 billion in annual revenues, and may also be starting to hit the limits of low-cost customer acquisition enabled by free downloads.

Other cases involve long-term trends that almost certainly will have an increasing impact over time. More software is moving out into the network "cloud," and--in an at least peripherally-connected shift--thin clients of various stripes are beginning to move beyond their historical ghettos in call centers and other narrow use cases.  However, the oft-cited Salesforce.com and many Citrix case studies aside, these shifts will be far more gradual and incremental than the enthusiasts would have us believe. Enterprises will be slow to adopt Software as a Service for anything they consider even vaguely core and the traditional fat client PC model may be flawed in a lot of ways, but it is familiar, well-understood, and has huge inertia.

I love examples. They help give me confidence that something has at least a patina of reality. But, in the singular, they constitute anecdotes and not data. And anecdotes don't really prove anything. In fact, they can mislead by giving the atypical more weight than it deserves.

Lots of large system and software vendors, even (or perhaps especially) those who have traditionally focused largely on enterprise sales, talk loudly and often about the midmarket these days.

Or they use terms like "SMB" (small and medium business) or "SME" (small and medium enterprise)--categories that aren't really the same thing but nonetheless often get used more or less interchangeably to denote companies with about 100 to 1,000 employees.

The reason for the interest is pretty simple. There are far more smaller businesses than there are larger ones--especially in developing economies. Midmarket IT spending is also growing quickly in many categories. As a result, it's not especially surprising that even those vendors most accustomed to selling to enterprises are itching to boost their midmarket share as well.

The challenge they face is that IT at midmarket companies bears, at best, a passing resemblance to that of enterprises. Development and operations staffs are small and are far more likely to be made up of generalists than specialists. Furthermore, most selling to midmarket companies takes place through regional or vertical market partners of some sort. Thus, the vendor seeking to increase midmarket footprint typically has to put together different types of product packaging, if not entirely different products, and craft go-to-market (GTM) approaches that differ in substantial ways from those supporting large enterprise sales.

Given these complexities, it's natural that historically enterprise-y vendors have taken awhile to craft successful midmarket plans. Even IBM, which has long had a strong midmarket presence with System i (and the AS/400 that preceded it), has gone through numerous GTM and organizational iterations to improve its ability to tap the midmarket with other product lines. However, most large vendors have made progress. The best are doing quite well (as we've noted in the case of Hewlett-Packard for example). Others, such as Sun Microsystems, have at least made improvements to their partner programs even if their overall grade remains middling.

Expanding market reach in this way is all well and good. Certainly, many small and midsized businesses continue to run their IT departments in much the same way as in the past on in-house systems running a combination of packaged and custom applications.

However, we're also struck by how tenuous the connections are between many vendors' midmarket planning and any sort of software-as-a-service (SaaS) or broader cloud computing initiatives.

Computing isn't going to jump from the data center to the network overnight; if nothing else, the rate and specifics of such a shift are matters for spirited debate. But as a general direction for computing, it's hard to make much of an argument.

It's also hard to argue with a contention that, again as a general rule, SaaS should have more near-term appeal in the midmarket than in the larger enterprise. The list of reasons why is substantial: midmarket companies have smaller IT staffs; they tend to use more pre-packaged and less complex applications; their IT infrastructures tend to have fewer "moving parts" (and therefore better lend themselves to carving out pieces to run over the network); and existing relationships with midmarket ISVs and VARs could make the transition to SaaS applications from those partners fairly natural.

Or, to put it more bluntly, enterprises may find running their own IT infrastructures costly, but for many midmarket companies, it's genuinely hard and even harder to bring new applications and the like online.

Therefore, the disconnect at many vendors between forward-looking SaaS and cloud computing strategies and their more tactical midmarket plays is, at the very least, a strategic oversight.

What does running software in the network mean exactly?

This is one of the questions that users are exploring as they start to increasingly poke at what "cloud computing" means for them.

On the one hand, cloud computing can refer specifically to running some sort of fixed software service--frequently through a browser's user interface--over the network. This is cloud computing in the Web 2.0 sense. We don't necessarily even think of Flickr, Facebook, or Google as "applications" as such. At the other end of the scale, services such as Amazon's EC2 and S3 just rent bare CPU cycles and storage capacity for whatever software a user wants to load up.

However, between these extremes lies a continuum of customization and malleability. Application programming interfaces that allow third-party customization and extension are rapidly becoming a de rigueur companion to software as a service. At the same time, virtual appliances and other predefined software loads offer at least a degree of preassembly when renting raw computing by the hour.

Tuesday's announcement by Mosso, a start-up funded by hosting provider Rackspace, offers up yet another variant. The core concept behind Mosso's Hosting Cloud is that many Web-based applications or sites are built up using largely common stacks of technologies such as PHP and MySQL databases. Mosso takes advantage of this fact by providing the means to provision applications running on one of these common stacks. Mosso is effectively offering cloud computing at a level of abstraction more akin to that of a Web hosting provider. For example, Mosso takes care of patching and updating the operating system and other software stack components. This is unsurprising given Rackspace's historical business, but it's a bit different than what's generally discussed in the context of cloud computing.

A user sets up a site by logging into Mosso's management application, entering a domain name, the technology stack to be used (Mosso supports Windows/.Net as well as Linux), and additional services required--such as databases. Mosso will then provision the site on a cluster of servers at which time the user can upload custom code.

The big difference from a typical hosted Web site is that Mosso monitors the site's resource use and will scale up available hardware resources as needed automatically. The pricing model is as follows:

Base pricing is $100/month, which includes:

• 24x7 live technical support (phone and chat)
• 50GB disk space
• 500GB bandwidth
• 3 million Web requests/month  (A Web request is the retrieval of any item from a Web server, i.e. a Web page with two photos counts as three requests)

Additional disk space is 50 cents per gigabyte, bandwidth is 25 cents per gigabyte, and requests are 3 cents per 1,000 requests.

Mosso does not currently provide any means to throttle or otherwise limit the traffic or resource use by a site. This seems reasonable enough in the context of businesses that would typically be more concerned with their site going down than in having an unexpectedly large hosting bill at the end of the month. In addition, by partially pegging charges to Web requests, Mosso is aligning its fees to a measurement that has direct relevance to many companies operating Web sites--especially if they are advertising-supported in some way.

Writing Defining Cloud Computing last month really crystallized for me that it would be a mistake to narrowly define this trend as only about Web 2.0 or software as a service. Announcements such as Mosso further emphasize this point. More and more computing may go out into the network. But the way that it moves into the network will take a multiplicity or forms--especially as users experiment in these early days.

Sun's not the only vendor busily acquiring this morning.

Dell has signed a definitive agreement to acquire MessageOne, Inc., an industry leader in Software-as-a-Service (SaaS) enabled enterprise-class e-mail business continuity, compliance, archiving and disaster recovery services. The acquisition, for approximately $155 million in cash, has been approved by the board of directors of each company and is subject to regulatory approvals and customary closing conditions.

One angle here is that Dell is a very changed company. They're no longer just about selling the cheapest boxes. They've expanded their processor portfolio, they've dipped a toe into retail, they've unveiled a more-than-decent new blade lineup, and they acquired iSCSI storage vendor EqualLogic. Now they're apparently expanding into the email continuity and archiving business. The Dell of today is a much changed company from the one of a couple of years back.

However, the acquisition also offers a window into what could potentially be a much bigger story for system vendors.

If we posit that "Cloud Computing" is the next big thing. That software services will be delivered over the network rather than from an on-site datacenter. That software vendors and service providers, rather than end-users, will increasingly consume server hardware. Such a state has huge implications for IT vendors. In the extreme, perhaps the largest providers of such services (can you say Google?) will even effectively become the systems companies in this new landscape.

However, even if we don't posit anything so extreme--at least for any reasonable planning horizon--it's still reasonable to ask a question: "Shouldn't system vendors be looking at ways to themselves deliver the software and services that users need over the network?" The alternative, it seems, is to cede considerable control to service providers who are as likely to build their own white boxes as to pay a premium for any Tier One vendor's gear.

Perhaps Dell is starting to think along those lines. Which would be a smart move on their part.

When my posting frequency drops a bit, the usual reason is that I'm flying here and yon and otherwise occupied with goings-on at some conference, meeting, or client engagement. The situation in January was a bit different. For the first time in a while, I had some decent blocks of uncommitted time. And I put those to use fleshing out and writing some longer research notes that had been sitting on the to-do list for way too long.

Two of these deal with so-called "cloud computing"--the idea that software will increasingly run in the network. These were originally planned as a single paper, but for structural and length reasons, I decided to break out the definitional piece, "Defining Cloud Computing." To tell the truth, I don't typically find formal taxonomies and categorizations especially interesting, but I thought it useful in this case to be clear about the topic under discussion.

The main research note, "The Cloud vs. Open Source," focuses on the relevancy of open source in a cloud computing world--and, especially, whether other types of protections and rights may not be more important than the right to view, modify, and redistribute source code. Tim O'Reilly has written and spoken on this topic.

At the just-concluded Sun Analyst Summit, I also had the opportunity to broach this topic with Simon Phipps, Sun's Open Source Officer. An interesting perspective that he added is that we're really talking about two different kinds of rights. One is essentially individual--the right for me to decide who can access what "data" that I "own" (whatever those terms mean exactly) and to transfer my data from one place to another. However, there's also the idea of what I'll call community or collective rights--the idea of reciprocal obligations associated with providing application programming interfaces and access.

One follow-up piece that I want to write when I have time will be something along the lines of "Why Not the Cloud?" in which I'll look at some of the inhibitors to moving computing into the network.

Finally, "The Future of the Operating System" looks at how changes in the way that we operate computers and deploy applications is starting to change how we view the operating system, a technology construct that, in important ways, hasn't really changed for decades. Server virtualization is the big driving force behind change here. However, virtualization is hardly unrelated to cloud computing--both through services like Amazon EC2 and, more conceptually, in the fact that virtualization is all about masking lower-level details from users.

These three Illuminata research notes are all available as free samples.

The broad strokes of Red Hat's announcement yesterday left a lot of canvas unpainted. Its JBoss middleware, an acquisition that hasn't met Red Hat's expectations, was MIA. And a great deal of management, provisioning, identity, etc. capabilities--essentially the services that span the entire infrastructure--were casually lumped under the Red Hat Network (RHN) umbrella, or handed off to Open APIs, without much in the way of detail. RHN is a capable update and monitoring tool that has become increasingly capable over time. But RHN, even augmented by Red Hat's other infrastructure products, hardly comprises a complete enterprise automation strategy, contrary to what the company seemed to suggest. Overall, it seemed more like a conceptual vision for a strategy than an actual strategy.

For me, more interesting for the near- to medium-term were a pair of other announcements that are more closely related than they might initially appear. One was the Red Hat Appliance Operating System (AOS) that the company plans to make available in the first half of 2008. (The acronym takes me back to my previous life...but that's another story.)

A couple of weeks ago, I was in Las Vegas for the Citrix iForum show. Citrix is best known for its Presentation Server product, nee MetaFrame. Presentation Server delivers specific business applications to remote desktops using Windows Terminal Server on the back-end. It's usually thought of in terms of thin client computing; in fact, the vast majority of Presentation Server installations deliver applications to ordinary PCs. (I describe the technology in more depth in this Illuminata research note.) However, these days, Citrix has many other products as well, variously tailored to delivering applications and full desktop images to a variety of clients.

I've been seeing more interest among IT folks in alternatives to traditional desktops over the past year since, well, ever. Traditional SMS-style provisioning and management systems never truly performed up to hopeful expectations; increasing concerns about security have only exacerbated an already sub-par situation. Nor are users thrilled with the current state of affairs. Their PCs tend to accumulate "cruft" (that's the technical term) over time and software loads "blow up" (another technical term) periodically. Furthermore, IT policies intended to keep things under some vague semblance of control tend to consist, in no small part, of long lists of "Thou shall nots" that limit what users can do with corporate PCs.

And, before the various fanboys chirp in, switching to Linux or a Mac doesn't make all these issues magically go away.

A couple of weeks back, Amazon.com announced an expansion of its Elastic Compute Cloud (EC2) service. The still-in-beta EC2 is a twist on the much-discussed, if rarely seen in the wild, compute utility whereby customers rent computing by virtual machine (VM)-hour; Amazon's EC2 infrastructure is based on a Xen hypervisor structure rather than running directly on physical hardware.

One implication of Amazon using VMs is that they can easily offer a variety of different VM sizes up to the size of the physical hardware. That was the most recent change announced. In addition to the default "Small Instance," users can now get "Large Instances" or "Extra Large Instances." These might be useful if, for example, you need to pair a heavyweight database instance with some lightweight Web services.

Another implication is that VM images, called Amazon Machine Images (AMI) in this case, can be archived and transported. This is analogous to VMware's virtual appliances. Amazon itself hasn't done much to jump-start an image marketplace at this point as VMware has. However, it does provide a mechanism for customers to post and publicly share AMIs and sees the opportunity for people to offer paid AMIs over time.

I bring this up because Emre Sokullo over at Read/Write Web has a post and table that does a great job of crystallizing why getting into Web services is such a big deal for Amazon. In short, Amazon's revenue is comparable to Google's. The difference is that, while Google is operating at a 29 percent profit margin, Amazon is under 2 percent. Which is probably about the best one can hope for with a big "mail order" retail operation.