The convenience of not coping
There’s a lot to be said for the ability to get a server for less than the price of a stick of chewing gum.
But convenience has a price, and it’s sufficient that shared hosters, blog hosters, and other folks who make their daily pittance from infrastructure-plus-a-little-extra aren’t especially threatened by cloud infrastructure services.
For instance, I pay for WordPress to host a blog because, while I am readily capable of managing a cloud server and everything necessary to run WordPress, I don’t want to deal with it. I have better things to do with my time.
Small businesses will continue to use traditional shared hosting or even some control-panel-based VPS offerings, despite the much-inferior price-to-resource ratios compared to raw cloud servers, because of the convenience of not having to cope with administration.
The reason why cloud servers are not a significant cost savings for most enterprises (when running continuously, not burst or one-time capacity), is because administration is still a tremendous burden. It’s why PaaS offerings will gain more and more traction over time, as the platforms mature, but also why those companies that crack the code to really automating systems administration will win over time.
I was pondering this equation while contemplating the downtime of a host that I use for some personal stuff; they’ve got a multi-hour maintenance downtime this weekend. My solution to this was simple: write a script that would, shortly before shutdown time, automatically shut down my application, provision a 1.5-cent-an-hour cloud server over on Rackspace, copy the data over, and fire up the application on its new home. (Note: This was just a couple of lines of code, taking moments to type.) The only thing I couldn’t automate was the DNS changeover, since I use GoDaddy for primary DNS and they don’t have an API available for ordinary customers. But conveniently: failover, without having to disrupt my Saturday.
But I realized that I was paying, on a resource-unit equivalent, tremendously more for my regular hosting than I would for a cloud server. Mostly, I’m paying for the convenience of not thinking — for not having to deal with making sure the OS is hardened, pay attention to security advisories, patch, upgrade, watch my logs, etc. I can probably afford the crude way of not thinking for a couple of hours — blindly shutting down all ports, pretty much — but I’m not comfortable with that approach for more than an afternoon.
This is, by the way, also a key difference between the small-business folks who have one or two servers, and the larger IT organizations with dozens, hundreds, or thousands of servers. The fewer you’ve got, the less efficient your labor leverage is. The guy with the largest scale doesn’t necessarily win on cost-efficiency, but there’s definitely an advantage to getting to enough scale.
Getting real on colocation
Of late, I’ve had a lot of people ask me why my near-term forecast for the colocation market in the United States is so much lower (in many cases, half the growth rate) when compared with those produced by competing analyst firms, Wall Street, and so forth.
Without giving too much information (as you’ll recall, Gartner likes its bloggers to preserve client value by not delving too far into details for things like this), the answer to that comes down to:
- Gartner’s integrated forecasting approach
- Direct insight into end-user buying behavior
- Tracking the entire market, not just the traditional “hot” colo markets
I’ve got the advantage of the fact that Gartner producing forecasts for essentially the full range of IT-related “stuff”. If I’ve got a data center, I’ve got to fill it with stuff. It needs servers, network equipment, and storage, and those things need semiconductors as their components. It’s got to have network connectivity (and that means carrier network equipment for service providers, as well as equipment on the terminating end). It’s got to have software running on those servers. Stuff is a decent proxy for overall data center growth. If people aren’t buying a lot of stuff, their data center footprint isn’t growing. And when they’re buying stuff, it’s important to know if it’s replacing other stuff (freeing up power and space), or if it’s new stuff that’s going to drive footprint or power growth.
Collectively, analysts at Gartner take over a quarter-million client inquiries a year, an awful of lot of them related to purchasing decisions of one sort or another. We also do direct primary research in the form of surveys. So when we forecast, we’re not just listening to vendors tell us what they think their demand is; we’re also judging demand from the end-user (buyer) side. My colleagues and I, who collectively cover data center construction, renovation, leasing, and colocation (as well as things like hosting and data center outsourcing), have a pretty good picture of what our clientele are thinking about when it comes to procuring data center space, in addition to the degree to which end-user thinking informs our forecast for the stuff that goes into data centers.
Because of our client base, which not only include IT buyers dispersed throughout the world, but a lot of vendors and investors, we watch not just the key colocation markets where folks like Equinix have set up shop, but everywhere anyone does colo, which is getting to be an awful lot of places. If you’re judging the data center market by what’s happening in Equinix Cities or even Savvis Cities, you’re missing a lot.
If I’m going to believe in gigantic growth rates in colocation, I have to believe that one or more of the following things is true:
- IT stuff is growing very quickly, driving space and/or power needs
- Substantially more companies are choosing colo over building or leasing
- Prices are escalating rapidly
- Renewals will be at substantially higher prices than the original contracts
I don’t think, in the general case, that these things are true. (There are places where they can be true, such as with dot-com growth, specific markets where space is tight, and so on.) They’re sufficiently true to drive a colo growth rate that is substantially higher than the general “stuff that goes into data centers” growth rate, but not enough to drive the stratospheric growth rates that other analysts have been talking about.
Note, though, that this is market growth rate. Individual companies may have growth rates far in excess or far below that of the market.
I could be wrong, but pessimism plus the comprehensive approach to forecasting has served me well in the past. I came through the dot-com boom-and-bust with forecasts that turned out to be pretty much on the money, despite the fact that every other analyst firm on the planet was predicting rates of growth enormously higher than mine.
(Also, to my retroactive amusement: Back then, I estimated revenue figures for WorldCom that were a fraction of what they reported, due to my simple inability to make sense of their reported numbers. If you push network traffic, you need carrier equipment, as do the traffic recipients. And traffic goes to desktops and servers, which can be counted, and you can arrive at reasonable estimates of how much bandwidth each uses. And so on. Everything has to add up to a coherent picture, and it simply didn’t. It didn’t help that the folks at WorldCom couldn’t explain the logical discrepancies, either. It just took a lot of years to find out why.)
Credit cards and EA/Mythic’s epic billing mistake
Most of us have long since overcome our fear of handing over our credit cards to Internet merchants. It’s become routine for most of us to simply do so. We buy stuff, we sign up for subscriptions, it’s just like handing over plastic anytime else. For that matter, most of us have never really thought about all that credit card data laying around in the hands of brick-and-mortar merchants with whom we do business, until the unfortunate times when that data gets mass-compromised.
Bad billing problems plague lots of organizations, but Electronic Arts (in the form of its Mythic Entertainment studio, which does the massively multiplayer online RPGs Dark Ages of Camelot and Warhammer Online) just had a major screw-up: a severe billing system error that, several days ago, repeatedly charged customers their subscription fees. Not just one extra charge, but, some users say, more than sixty. Worse still, the error reportedly affected not just current customers, but past customers. A month’s subscription is $15, but users can pre-pay for as much as a year. And these days, with credit cards so often actually being checking-account debit cards, that is often an immediate hit to the wallet. So you can imagine the impact on even users with decent bank balances, being hit by multiple charges. (Plenty of people with good-sized savings cushions only keep enough money in the checking account to cover expected bills, so you don’t have to be on the actual fiscal edge to get smacked with overdraft fees.) EA is scrambling to get this straightened out, of course, but this is every company’s worst billing nightmare, and it comes at a time when EA and its competitors are all scrambling to shift their business models online.
How many merchants that you don’t do business with any longer, but used to have recurring billing permission on your credit card, still have your credit card on file? As online commerce and micropayments proliferate, how many more merchants will store that data? (Or will PayPal, Apple’s storefronts, and other payment services rule the world?)
Cogent’s Utility Computing
A client evaluating cloud computing solutions asked me about Cogent’s Utility Computing offering (and showed me a nice little product sheet for it). Never having heard of it before, and not having a clue from the marketing collateral what this was actually supposed to be (and finding zero public information about it), I got in touch with Cogent and asked them to brief me. I plan to include a blurb about it in my upcoming Who’s Who note, but it’s sufficiently unusual and interesting that I think it’s worth a call-out on my blog.
Simply put, Cogent is allowing customers to rent dedicated Linux servers at Cogent’s POPs. The servers are managed through the OS level; customers have sudo access. This by itself wouldn’t be hugely interesting (and many CDNs now allow their customers to colocate at their POPs, and might offer self-managed or simple managed dedicated hosting as well in those POPs). What’s interesting is the pricing model.
Cogent charges for this service based on bandwidth (on a Mbps basis). You pay normal Cogent prices for the bandwidth, plus an additional per-Mbps surcharge of about $1. In other words, you don’t pay any kind of compute price at all. (You do have to push a certain minimum amount of bandwidth in order for Cogent to sell you the service at all, though.)
This means that if you want to construct your own fly-by-night CDN (or even just a high-volume origin for static content), this is one way to do it. Figure you could easily be looking at $5/Mbps pricing and below, all-in. If you’re looking for cheap and crude and high-volume, then these servers in a couple of POPs, and a global load-balancing service of some sort will do it. For anything that’s not performance-sensitive, like large file downloads in the background (like game content updates), this might turn out to be a pretty interesting alternative.
I’ve always thought that Level 3’s CDN service, with its “it costs what our bandwidth costs” pricing tactic, was a competitive assault not so much on Limelight (or even AT&T, who has certainly gotten into mudpit pricing fights with Level 3), but on Cogent and other providers of low-cost high-volume bandwidth — i.e., convincing people that rather than buying servers and getting colocation space and cheap high-volume bandwidth, that they should just take CDN services. So it makes sense for Cogent to strike back with a product that circumvents having to make the investments in technology that would be required to get into the CDN mudpit directly.
I’ll be interested to see how this evolves — and will be curious to see if anyone else launches a similar service.
Who’s Who in CDN
I’m currently working on writing a research note called “Who’s Who in Content Delivery Networks“. The CDN space isn’t quite large enough yet to justify one of Gartner’s formal rating methodologies (the Magic Quadrant or MarketScope), but with the proliferation of vendors who can credibly serve enterprise customers, the market deserves a vendor note.
The format of a Who’s Who looks a lot like our Cool Vendors format — company name, headquarters location, website, a brief blurb about who they are and what they do, and a recommendation for what to use them for. I like to keep my vendor write-up formats pretty consistent, so each CDN has a comment about its size (and length of time in the business and funding source, if relevant), its footprint, services offered, whether there’s an application acceleration solution and if so what the technology approach to that is, pricing tier (premium-priced, competitive, etc.), and general strategy.
Right now, I’m writing up the ten vendors that are most commonly considered by enterprise buyers of CDN, and then planning to add some quick bullet-points of other vendors in the ecosystem but who aren’t CDNs themselves (equipment vendors, enterprise internal CDN alternatives, etc.), probably more in a ‘here are some vendor names’ with no blurbs, fashon.
For those of you who follow my research, I’m also about to publish my yearly update of the CDN market that’s targeted at our IT buyer clients (i.e., how to choose a vendor and what the pricing is like), along with another note on the emergence of cloud CDNs (to answer a very common inquiry, which is, “Can I replace my Akamai services with Amazon?”).
Q1 2010 inquiry in review
My professional life has gotten even busier — something that I thought was impossible, until I saw how far out my inquiry calendar was being booked. As usual, my blogging has suffered for it, as has my writing output in general. Nearly all of my writing now seems to be done in airports, while waiting for flights.
The things that clients are asking me about has changed in a big way since my Q4 2009 commentary, although this is partially due to an effort to shift some of my workload to other analysts on my team, so I can focus on the stuff that’s cutting edge rather than routine. I’ve been trying to shed as much of the routine colocation and data center leasing inquiry onto other analysts as possible, for instance; reviewing space-and-power contracts isn’t exactly rocket science, and I can get the trends information I need without needing to look at a zillion individual contracts.
Probably the biggest surprise of the quarter is how intensively my CDN inquiry has ramped up. It’s Akamai and more Akamai, for the most part — renewals, new contracts, and almost always, competitive bids. With aggressive new pricing across the board, a willingness to negotiate (and an often-confusing contract structure), and serious prospecting for new business, Akamai is generating a volume of CDN inquiry for me that I’ve never seen before, and I talk to a lot of customers in general. Limelight is in nearly all of these bids, too, by the way, and the competition in general has been very interesting — particularly AT&T. Given Gartner’s client base, my CDN inquiry is highly diversified; I see a tremendous amount of e-commerce, enterprise application acceleration, electronic software delivery and whatnot, in addition to video deals. (I’ve seen as many as 15 CDN deals in a week, lately.)
The application acceleration market in general is seeing some new innovations, especially on the software end (check out vendors like Aptimize), and there will be more ADN offers will be launched by the major CDN vendors this year. The question of, “Do you really need an ADN, or can you get enough speed with hardware and/or software?” is certainly a key one right now, due to the big delta in price between pure content offload and dynamic acceleration.
By the way, if you have not seen Akamai CEO Paul Sagan’s “Leading through Adversity” talk given at MIT Sloan, you might find it interesting — it’s his personal perspective on the company’s history. (His speech starts around the 5:30 mark, and is followed by open Q&A, although unfortunately the audio cuts out in one of the most interesting bits.)
Most of the rest of my inquiry time is focused around cloud computing inquiries, primarily of a general strategic sort, but also with plenty of near-term adoption of IaaS. Traditional pure-dedicated hosting inquiry, as I mentioned in my last round-up, is pretty much dead — just about every deal has some virtualized utility component, and when it doesn’t, the vendor has to offer some kind of flexible pricing arrangement. Unusually, I’m beginning to take more and more inquiry from traditional data center outsourcing clients who are now looking at shifting their sourcing model. And we’re seeing some sharp regional trends in the evolution of the cloud market that are the subject of an upcoming research note.
And so it begins
We’re about to start the process for the next Magic Quadrant for Cloud Infrastructure Services and Web Hosting, along with the Critical Capabilities for Cloud Infrastructure Services (titles tentative and very much subject to change). Our hope is to publish in late July. These documents are typically a multi-month ordeal of vendor cat-herding; the evaluations themselves tend to be pretty quick, but getting all the briefings scheduled, references called, and paperwork done tends to eat up an inordinate amount of time. (This time, I’ve begged one of our admin assistants for help.)
What’s the difference? The MQ positions vendors in an overall broad market. CC, on the other hand, rates individual vendor products on how well they meet the requirements for a set of defined use cases. You get use-case by use-case ratings, which means that this year we’ll be doing things like “how well do these specific self-managed cloud offerings support a particular type of test-and-development environment need”. The MQ tends to favor vendors who do a broad set of things well; a CC rating, on the other hand, is essentially a narrow, specific evaluation based on specific requirements, and a product’s current ability to meet those needs (and therefore tends to favor vendors that have great product features).
Also, we’ve decided the CC note is going to be strictly focused on self-managed cloud — Amazon EC2 and its competitors, Terremark Enterprise Cloud and its competitors, and so on. This is a fairly pure features-and-functionality thing, in other words.
Anyone thinking about participation should check out my past posts on Magic Quadrants.
Equipment vendors get into the CDN act
Carriers are very interested in CDNs, whether it’s getting into the CDN market themselves, or “defensively” deploying content delivery solutions as part of an effort to reduce the cost of broadband service or find a way to monetize the gobs of video traffic now flowing to their end-users.
So far, most carriers have chosen partnerships with companies like Limelight and Edgecast, rather than entering the market with their own technology and services, but this shouldn’t be regarded as the permanent state of things. The equipment vendors clearly recognized the interest some time ago, and the solutions are finally starting to flow down the pipeline.
Last year, Alcatel-Lucent bought Velocix, a CDN provider, in order to get its carrier-focused technology, Velocix Metro (which I’ve written about before). Velocix Metro is a turnkey CDN solution, with the added interesting bit of adding aggregation capability across multiple Velocix customers.
Last month, Juniper partnered with Ankeena in order to bring a solution called Juniper MediaFlow to market. It’s a turnkey CDN solution incorporating both content routing and caches.
This month, with the introduction of the CRS-3 core router, Cisco announced its Network Positioning System (NPS). NPS is not a CDN solution of any sort. Rather, it’s essentially a system that gathers intelligence about the network, and uses that to compute the proximity between two endpoints. NPS is essentially used to provide a programmatic way to advise clients and servers about the best place to find networked resources. Today, we get a crude form of this in the technical functionality of BGP Anycast; NPS, by contrast, is supposed to use information from layers 3 through 7, and incorporate policy-based capabilities.
And in news of little companies, Blackwave has been chugging along, releasing a new version of its platform earlier this month. Blackwave is one of those companies that I expect to be eyed as an acquisition target by equipment vendors looking to add turnkey CDN solutions to their portfolios; Blackwave has a highly efficient ILM-ish media storage platform, coupled with some content routing capabilities. (Its flagship CDN customer is CDNetworks, but its other customers are primarily service providers.)
The (temporary?) transformation of hosters
Classically, hosting companies have been integrators of technology, not developers of technology. Yet the cloud world is increasingly pushing hosting companies into being software developers — companies who create competitive advantage in significant part by creating software which is used to deliver capabilities to customers.
I’ve heard the cloud IaaS business compared to the colocation market of the 1990s — the idea that you build big warehouses full of computers and you rent that compute capacity to people, comparable conceptually to renting data center space. People who hold this view tend to say things like, “Why doesn’t company X build a giant data center, buy a lot of computers, and rent them? Won’t the guy who can spend the most money building data centers win?” This view is, bluntly, completely and utterly wrong.
IaaS is functionally becoming a software business right now, one that is driven by the ability to develop software in order to introduce new features and capabilities, and to drive quality and efficiency. IaaS might not always be a software business; it might eventually be a service-and-support business that is enabled by third-party software. (This would be a reasonable view if you think that VMware’s vCloud is going to own the world, for instance.) And you can get some interesting dissonances when you’ve got some competitors in a market who are high-value software businesses vs. other folks who are mostly commodity infrastructure providers enabled by software (the CDN market is a great example of this). But for the next couple of years at least, it’s going to be increasingly a software business in its core dynamics; you can kind of think of it as a SaaS business in which the service delivered happens to be infrastructure.
To illustrate, let’s talk about Rackspace. Specifically, let’s talk about Rackspace vs. Amazon.
Amazon is an e-commerce company, with formidable retail operations skills embedded in its DNA, but it is also a software company, with more than a decade of experience under its belt in rolling out a continuous stream of software enhancements and using software to drive competitive advantage.
Amazon, in the cloud IaaS part of its Web Services division, is in the business of delivering highly automated IT infrastructure to customers. Custom-written software drives their entire infrastructure, all the way down to their network devices. Software provides the value-added enhancements that they deliver on top of the raw compute and storage, from the spot pricing marketplace to auto-scaling to the partially-automated MySQL management provided by the RDS service. Amazon’s success and market leadership depends on consistently rolling out new and enhanced features, functions, capabilities. It can develop and release software on such aggressive schedules that it can afford to be almost entirely tactical in its approach to the market, prioritizing whatever customers and prospects are demanding right now.
Rackspace, on the other hand, is a managed hosting company, built around a deep culture of customer service. Like all managed hosters, they’re imperfect, but on the whole, they are the gold standard of service, and customer service is one of the key differentiators in managed hosting, driving Rackspace’s very rapid growth over the last five years. Rackspace has not traditionally been a technology leader; historically, it’s been a reasonably fast follower implementing mainstream technologies in use by its target customers, but people, not engineering, has been its competitive advantage.
And now, Rackspace is going head to head with Amazon on cloud IaaS. It has made a series of acquisitions aimed at acquiring developers and software technology, including Slicehost, JungleDisk, and Webmail.us. (JungleDisk is almost purely a software company, in fact; it makes money by selling software licenses.) Even if they emphasize other competitive differentiation, like customer support, they’re still in direct competition with Amazon on pure functionality. Can Rackspace obtain the competencies it will need to be a software leader?
And in related questions: Can the other hosters who eschew the VMware vCloud route manage to drive the featureset and innovation they’ll need competitively? Will vCloud be inexpensive enough and useful enough to be widely adopted by hosters, and if it is, how much will it commoditize this market? What does this new emphasis upon true development, not just integration, do to hosters and to the market as a whole? (I’ve been thinking about this a lot, lately, although I suspect it’ll go into a real research note rather than a blog post.)
Google’s DNS protocol extension and CDNs
There have been a number of interesting new developments in the content routing space recently — specifically, the issue of how to get content to end-users from the most optimal point on the network. I’ll be talking about Cisco and Juniper in a forthcoming blog post, but for now, let’s start with Google:
A couple of weeks ago, Google and UltraDNS (part of Neustar) proposed an extension to the DNS protocol that would allow DNS servers to obtain the IP address of the end-user who originally made the request. DNS is normally recursive — the end-user queries his local DNS resolver server, which then makes queries up the chain on his behalf. The problem with this is that the resolver is not necessarily actually local — it might be far, far away from the user. And the DNS servers of things like CDNs use the location of the DNS query to figure out where the user is, which means that they actually return an optimal server for the resolver’s location, not the user’s.
I wrote about this problem in some detail about a year and a half ago, in a blog post: The nameserver as CDN vantage point. You can go back and look at that for a more cohesive explanation and a look at some numbers that illustrate how much of a problem resolver locations create. The Google proposal is certainly a boon to CDNs as well as anyone else that relies upon DNS for global load-balancing solutions. In the ecosystem where it’s supported, the enhancement will also give a slight performance boost to CDNs with more local footprint, by helping to ensure that the local cache is actually more local to the user. The resolver issue can, as I’ve noted before, erase the advantages of having more footprint closer to the edge, since that edge footprint won’t be used unless there are local resolvers that map to it. Provide the user’s IP, though, and you can figure out exactly what the best server for him is.
There’s no shortage of technical issues to debate (starting with the age-old objection to using DNS for content routing to begin with), and privacy issues have been raised as well, but my expectation is that even if it doesn’t actually get adopted as a standard (and I’m guessing it won’t, by the way), enough large entities will implement it to make it a boon for many users.
CloudPundit: Massive-Scale Computing 