CDNetworks buys Panther Express
For many months now, CDN industry insiders have gossiped that Panther Express was in financial trouble. Panther was caught with the bad luck of mistiming the funding cycle, leaving them to try to raise capital at a point when the capital markets were essentially frozen. Moreover, a large percentage of their revenues were tied to no-commit or limited-commit contracts, and with CDN prices in free-fall for much of 2008, Panther was doubly screwed from the perspective of the money guys. As time wore on, the likelihood of an acquisition by either a rival CDN or a carrier wanting to get into the space became more and more likely — but the longer the potential acquirers could wait to pull the trigger, the more cheaply they could buy the accompany, especially since rumors of Panther’s financial difficulties were starting to scare off potential customers.
Enter CDNetworks, a global CDN based in South Korea, who in the last year has been aggressively trying to penetrate the North American market. CDNetworks acquired Panther Express yesterday, in a deal structured so that it merged its US and European-based operations with Panther. Panther’s CEO Steve Liddell (who has experience working with Asian-based companies through his past experience as president of Level 3’s Asia business) will lead the new entity.
Dan Rayburn has offered some numbers and claims the acquisition values Panther at about $5 million — which would be about one-quarter of its 2008 trailing revenues, and would leave me wondering how that compares to the book value of Panther’s deployed eqiupment.
I’ll simply say that, although I agree with Dan that this acquisition basically has zero impact on other players or on pricing in the market, I have a very different perspective on the acquisition itself, and carrier opinion of this space, and of the general market opportunity (especially in the context that CDN is much more than video), than Dan does. Gartner clients who want to talk about it, you’re welcome to schedule an inquiry with me.
(Sorry. I started to write a long and detailed analysis, and then realized that I was crossing the line on what Gartner views as acceptable analyst blogging, and what is full-fledged analysis that ought to be reserved for paying clients.)
Interesting tidbits for the week
A bit of a link round-up…
My colleague Daryl Plummer has posted his rebuttal in our ongoing debate over cloud infrastructure commoditization. I agree with his assertion that over the long term, the bigger growth stories will be the value-added providers and not the pure-play cloud infrastructure guys, but I also stick to my guns in believing that customer service is a differentiator and we’ll have a lot of pure-plays, not a half-dozen monolithic mega-infrastructure-providers.
Michael Topalovich, of Delivered Innovation, has blogged a post-mortem on Coghead. It’s a well-written and detailed dissection of what went wrong, from the perspective of a former Coghead partner. Anyone who runs or uses a platform as a service would be well served to read it, as there are plenty of excellent lessons to be learned.
Richard Jones, of Last.fm, has put up an annotated short-list of distributed key-value stores (mostly in the form of distributed hash tables). He’s looking for a premise-based rather than cloud-based solution, but his commentary is thoughtful and the comments thread is interesting as well.
Also, I have a new research note out (Gartner clients only), in collaboration with my colleague Ted Chamberlin: evaluation criteria for Web hosting (including cloud infrastructure services in that context), which is the decision framework that supports the the Magic Quadrant that we’re anticipating publishing in April. (Also coming soon, a “how to choose a cloud infrastructure provider” note and accompanying toolkit.)
Single-function clouds are unlikely
GigaOm has an interesting post on HP’s cloud vision, which asserts that HP’s view of the future is that service providers will reducing complexity by delivering only one application (scaling up their own infrastructure in a monolithic way), and that generalized infrastructure-as-a-service (IaaS) providers will not be able to scale up in a profitable manner.
Setting the specifics of what HP does or does not believe aside, I think that it’s highly-unlikely that we’ll see super-specialization in the cloud. There are, of course, software vendors today who make highly specialized components, that in turn are incorporated into the software of vendors further up the stack — today, those are ISVs that sell libraries, Web 2.0 companies with mashable components, and so forth. But as software companies get more ambitious, the scope of their software tends to broaden, too. In the future, they may want to become the masher rather than the mashed, so to speak. And then they start wanting to become diversified.
For an example, look at Oracle. Originally a database company, they now have a hugely diversified base of enterprise software. Why should we believe that a cloud-based software company would be any less ambitious?
Certainly, it is more difficult and more expensive to manage general-purpose compute than it is to manage specific-purpose compute. But there’s a great deal more to driving profitability than keeping costs down. Broader integration has a business value, and the increase in value (and the price the customer is willing to pay) can readily outpace the increased infrastructure cost.
To take another example, Google runs incredibly efficient single-purpose compute in the form of their search farms. Yet, they are trying to broaden their business to other services, both for the potential synergies, and because it is incredibly dangerous for a business to be too narrow, since that limits its growth and vastly increases its vulnerability to any shifts in the market.
I don’t think successful software companies will confine themselves to delivering single applications as a service. And I think that IaaS providers will find cost-effective ways to deliver appropriate infrastructure to those SaaS companies.
Digsby
I have found at a partial solution to my communication proliferation problem. The tool I’m employing, at least for the moment, is Digsby, a free client that combines cross-platform instant messaging with access to social networking sites like Facebook, LinkedIn, and Twitter. This has replaced my usual IM client (Trillian, which I like a lot), but since I exchange very few IMs, that’s not an issue. However, the aggregated volume of communication still feels like it’s too much. I need robust filtering capabilities, and I have the feeling that I may need to write my own client (or hack an open-source client) in order to get that.
Credibility
I’ve recently read Pete Blackshaw’s Satisfied Customers Tell Three Friends, Angry Customers Tell 3000, which is a well-written, methodical introduction to consumer-generated media (CGM, also known as UGC, user-generated content). I’d recommend the book to anyone who hasn’t read a book on the topic; if you’re social-media savvy, chances are you won’t learn much (if anything) new, but the anecdotes are entertaining and useful, and the structured approach provides good framework language.
Thus, trust, credibility, and authenticity in corporate engagement are very much on my mind, at a time when there’s a new (resurfaced) controversy regarding local-review site Yelp, which is being accused of manipulating user reviews to gain advertising revenues. Naturally, Yelp denies any extortion of local businesses.
As an analyst, I belong to an industry which is constantly being questioned about the credibility and authenticity of its commentary — the age-old question of whether it’s a “pay to play” business where vendor clients receive ratings and recommendations that are more favorable than those that non-clients get. I still find myself having to stress to clients and non-clients alike that Gartner opinion cannot be bought. It’s one of the genuinely great aspects of working here — the organizational commitment to integrity. This is not to say that there aren’t conflicts — a vendor client has more avenues with which to express their unhappiness with an analyst’s opinion, and attempt to influence it in a more positive direction. But in the end, we pride ourselves on serving our IT buyer clients with honest advice — which means that vendor dollars can’t be allowed to influence analyst opinion.
I imagine that for any organization which provides reviews and recommendations as part of its business, and which accepts money from the entities being rated, has problems with rogue salespeople who attempt to imply, or even outright state, that paying for services means more favorable positioning. So the question is, what’s the organization’s attitude, from the CEO down, towards these things? Is it a wink-wink nudge-nudge thing where the organization only pays lip service to neutrality, is it a don’t-ask don’t-tell thing where the organization is willing to turn a blind eye as long as it doesn’t cause obvious problems, or is the organization really dedicated to ensuring that dollars don’t alter anything?
Which of these categories does Yelp fall into? I’m a pretty engaged consumer — I read reviews on Yelp, and I write them from time to time. I’ve got a keen interest in knowing.
Application delivery network adoption
A long-standing puzzle for myself and my various colleagues who cover application-fluent networking: Why don’t more SaaS providers adopt application delivery networks (ADNs), either via a service, or via application delivery controller (ADC) hardware?
Even if a SaaS vendor perceives their performance as being just fine for the typical US-based user, performance is often an issue in Europe, and frequently deteriorates sharply in Asia, especially China, and is erratic everywhere else depending on the quality of the country’s connectivity. (Change the names of the regions if the data center isn’t in North America.) Deploying an ADN helps to bolster performance for these users. And if it’s not cost-effective to do that for all users, why not charge extra for an accelerated service? (Yes, we understand that there are issues like “if we offer an accelerated service, are we implying our regular service is slow?” but really, that’s just a marketing issue. Performance can be a competitive differentiator and it’s also a revenue opportunity.)
Two interesting recent examples:
- Fog Creek’s CoPilot gets Akamai IP Application Accelerator service
- F5 does a China solution for its DevCentral portal
Yes, times are tough right now, so a SaaS company does have to evaluate the ROI carefully, but any SaaS provider with performance issues owes it to themselves to give this stuff a look. (And SaaS customers who have performance issues ought to be poking at their providers.)
Discipline and agility are not opposites
Too many service providers (and companies in general) use “discipline” as an excuse for “lack of agility”. Discipline does not mean appointing a committee to study the problem for the next year. Exercising caution and prudence does not mean failing to act. Laying a solid foundation does not mean standing around doing the equivalent of watching the concrete set. This misguided notion of discipline is made even worse if the committee sits around drawing personal conjectures based on fear, and concluding that moving with paralyzing slowness (because, I guess, sudden motion draws predators) is the only safe possibility.
There are highly agile companies out there who study and solve problems in a rigorous way — they go out and gather data, they analyze the data, they come to a conclusion, they come up with a solution, they decide what they want to measure to determine the success or failure of the solution, and go out and act. There’s enormous value in swift, decisive, fact-based action. Bonus points if the decision-making is focused on what delivers value to the customer, and that value (whether qualitative or quantitative) can be clearly articulated and measured.
Does cloud infrastructure become commoditized?
My colleague Daryl Plummer has mused upon the future of cloud in a blog post titled “Cloud Infrastructure: The Next Fat Dumb and Happy Pipe?” In it, he posits that cloud infrastructure will commoditize, that in 5-7 years the market will only support a handful of huge players, and that value-adds are necessary in order to stay in the game.
I both agree and disagree with him. I believe that cloud infrastructure will not be purely a commodity market, specifically because everyone in this market will offer value-added differentiation, and that even a decade out, we’ll still have lots of vendors, many of them small, in this game. Here’s a quick take on a couple of reasons why:
There are diminishing returns on the cost-efficiency of scale. There is a limit to how cheap a compute cycle can get. The bigger you are, the less you’ll pay for hardware, but in the end, even semiconductor companies have to make a little margin. And the bigger you are, the more you can leverage your engineers, especially your software tools guys — but it’s also possible that a tools vendor will deliver similar cost efficiencies to the smaller players (think about the role of Virtuozzo and cPanel in shared hosting). Broadly, smaller players pay more for things and may not leverage their resources as thoroughly, but they also have less overhead. It’s important to reach sufficient scale, but it’s not necessarily beneficial to be as large as possible.
This is a service. People matter. It’s hard to really commoditize a service, because people are a big wildcard. Buyers will care about customer service. Computing infrastructure is too mission-critical not to. The nuances of account management and customer support will differentiate companies, and smaller, more agile, more service-focused companies will compete successfully with giants.
The infrastructure itself is not the whole of the service. While there will be people out there who just buy server instances with a credit card, they are generally, either implicitly or explicitly, buying a constellation of stuff around that. At the most basic level, that’s customer support, and the management portal and tools, service level agreements, and actual operational quality — all things which can be meaningfully differentiated. And you can obviously go well beyond that point. (Daryl mentions OpSource competing with Amazon/IBM/Microsoft for the same cloud infrastructure dollar — but it doesn’t, really, because those monoliths are not going to learn the specifics of your SaaS app, right down to providing end-user help-desk support, like OpSource does. Cloud infrastructure is a means to an end, not an end unto itself.)
It takes time for technology to mature. Five years from now, we’ll still have stark differences in the way that cloud infrastructure services are implemented, and those differences will manifest themselves in customer-visible ways. And the application platforms will take even longer to mature (and by their nature, promote differentiation and vendor lock-in).
By the way, my latest research note, “Save Money Now With Hosted and ‘Cloud’ Infrastructure” (Gartner clients only) is a tutorial for IT managers, focused on how to choose the right type of cloud service for the application that you want to deploy. All clouds are not created equal, especially now.
Developer-driven cloud adoption?
James Governor’s thoughtful blog post on finding the REST of cloud prompted me to think about developer-driven versus sysadmin-driven adoption of cloud. This is a fulcrum that’s separate from GUI vs. CLI vs. API tug-of-war, which in many ways is a sysadmin-driven debate.
The immediacy of cloud provisioning has instinctive appeal to developers who just want to get something up and running. Amazon’s choice to initially do API-based provisioning was a clear choice to favor developer thinking, and developers at vast numbers of start-ups rewarded them by adopting the platform. At Web 2.0 start-ups, the founders, who usually come out of some sort of dev background, get to hire the ops people and call the shots. And thus, direct appeal to developers has been very important to cloud success, up until this point.
But my observation from client interactions is that cloud adoption in established, larger organizations (my typical client is $100m+ in revenue) is, and will be, driven by Operations, and not by Development. The developers may be the business stakeholders, and they might be the engineers who first experiment with the cloud (in a “rogue” or ad-hoc way), but Operations has the budget and Operations is going to be managing the actual cloud deployment, and therefore Operations makes the decision about what cloud to go with in the end.
That assumes, of course, that the developers haven’t tied their code to a non-portable API. If the developers have, unbeknownst to the Ops folks, gone and tightly integrated their application with, say, Amazon S3 in a way that doesn’t readily allow portability between different cloud storage APIs, or built on top of Google App Engine, then Ops isn’t going to have much in the way of options.
Another way to think about this: Developer-driven adoption is bottom-up adoption, rather than top-down adoption. The early stages of cloud adoption have been bottom-up. But because of the economic climate, larger organizations are experiencing a radical acceleration of interest in cloud computing, and thus, the next stage of cloud infrastructure adoption is more likely to be driven top-down.
Gallup Strengths
A client recently asked me what my Clifton Strengths are. I couldn’t remember at the time, but I’ve dug out old 1.0 results from back in 2006…
- Ideation. People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.
- Strategic. People strong in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.
- Input. People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.
- Learner. People strong in the Learner theme have a great desire to learn and want to continuously improve. In particular, the process of learning, rather than the outcome, excites them.
- Intellection. People strong in the Intellection theme are characterized by their intellectual activity. They are introspective and appreciate intellectual discussions.
CloudPundit: Massive-Scale Computing 