Monthly Archives: August 2010
I saw an interesting article about cloud provider liability limits, including some quotes from my esteemed colleague Drue Reeves (via Gartner’s acquisition of Burton). A quote in an article about Eli Lilly and Amazon also caught my eye: Tanya Forsheit, founding partner at the Information Law Group, “advised companies to walk away from the business if the cloud provider is not willing to negotiate on liability.”
I frankly think that this advice is both foolish and unrealistic.
Let’s get something straight: Every single IT company out there takes measures to strongly limit its liability in the case something goes wrong. For service providers — data center outsourcers, Web hosting companies, and cloud providers among them — their contracts usually specify that the maximum that they’re liable for, regardless of what happens, is related in some way to the fees paid for service.
Liability is different from an SLA payout. The terms of service-level agreements and their financial penalties vary significantly from provider to provider. SLA payouts are usually limited to 100% of one month of service fees, and may be limited to less. Liability, on the other hand, in most service provider contracts, specifically refers to a limitation of liability clause, which basically states the maximum amount of damages that can be claimed in a lawsuit.
It’s important to note that liability is not a new issue in the cloud. It’s an issue for all outsourced services. Prior to the cloud, any service provider who had their contracts written by a lawyer would always have a limitation of liability clause in there. Nobody should be surprised that cloud providers are doing the same thing. Service providers have generally limited their liability to some multiple of service fees, and not to the actual damage to the customer’s business. This is usually semi-negotiable, i.e., it might be six months of service fees, twelve months of fees, some flat cap, etc., but it’s never unlimited.
For years, Gartner’s e-commerce clients have wanted service providers to be liable for things like revenues lost if the site is down. (American Eagle Outfitters no doubt wishes it could hold IBM’s feet to the fire with that, right now.) Service providers have steadfastly refused, though back a decade or so, the insurance industry had considered whether it was reasonable to offer insurance for this kind of thing.
Yes, you’re taking a risk by outsourcing. But you’re also taking risks when you insource. Contract clauses are not a substitute for trust in the provider, or any kind of proxy indicating quality. (Indeed, a few years back, small SaaS providers often gave away so much money in SLA refunds for outages that we advised clients not to use SLAs as a discounting mechanism!) You are trying to ensure that the provider has financial incentive to be responsible, but just as importantly, a culture and operational track record of responsibility, and that you are taking a reasonable risk. Unlimited liability does not change your personal accountability for the sourcing decision and the results thereof.
In practice, the likelihood that you’re going to sue your hosting provider is vanishingly tiny. The likelihood that it will actually go to trial, rather than being settled in arbitration, is just about nil. The liability limitation just doesn’t matter that much, especially when you take into account what you and the provider are going to be paying your lawyers.
Bottom line: There are better places to focus your contract-negotiating and due-diligence efforts with a cloud provider, than worrying about the limitation-of-liability clause. (I’ve got a detailed research note on cloud SLAs coming out in the future that will go into all of these issues; stay tuned.)
I’m going to be at VMworld next week. If you’re a Gartner client, and you’d like to meet up with me while I’m there, please contact your account executive to arrange it. If you’re not a Gartner client, please email me and I’ll see what I can arrange. (My days are mostly spoken for, but breakfast and post-5 pm are largely free.)
I’ve been spending about a quarter of my time in the Bay Area for the better part of this year, a lot of my vendor-facing time has been with start-ups, and I spent much of my HostingCon time with start-ups whose executives have never interacted with analysts in the past, so a couple of FAQs are top of mind at the moment.
Emerging technology companies often ask me, “How do I get on your radar screen?” and sometimes, “How do I get you to write about our company?” (Venture capitalists often ask the same questions on behalf of their portfolio companies, too.)
I wrote a post about making a briefing request before; if you haven’t read it, I’d encourage you to do so, before continuing on with this post. So let’s assume that you’ve gone and asked for a briefing, and now you’re wondering what you should be doing to use that time to make a convincing case for why an analyst should continue to follow you.
Gartner analysts, as a matter of policy, do not take client relationships into account when deciding whether or not to follow a company. We choose which briefing requests we do or don’t take, and which companies we write about, solely based on whether or not we and our clients find a company to be of interest. If you’re a vendor client, you are always entitled to make an inquiry, tell us about your business, and ask specific questions — i.e., whether or not we find you worthy of covering in general, we are required to fulfill such requests — but it doesn’t get you any other special privileges with regard to coverage.
So, what makes a vendor interesting?
Client interest. If our end-user (IT buyer) clients are calling and asking about you, we want to know as much about you as possible, so that we can intelligently answer questions. If competitors and investors are calling and asking about you, ditto.
Unique vision or technology. If you’re doing something cool and different, either in implementation or the way you’re thinking about the market, that’s always of interest to us. We’re always interested in market mavericks, as well as people along the bleeding edge who might be tomorrow’s market leaders. We’re also hugely interested in blue-ocean companies, doing something that nobody else is.
Meaningful differentiation. Even if you’re not doing something that’s really unique, you should be able to articulate the things that meaningfully differentiate you from the competition, both in terms of where you see your company going, and the actual features and roadmap of your product or service.
Rapid growth. Evidence of market traction in terms of customer wins, especially enterprise customer wins, and fast revenue growth, is an indicator that we need to pay attention to you, because you’re clearly growing in importance. We like metrics, by the way. Knowing how many customers you have, how much you’ve grown recently, and the ballpark of your revenues, lets us know where you are adoption-wise.
Management team track record. If we know your management team from previous successes, we are much more likely to believe that your new venture will succeed, and will exhibit interest accordingly. (Also, if we have a prior relationship with you, our interest in interacting is likely to carry across between the companies you work for.) First-rate investors help, too; they’re usually a sign that some very smart people think you have a clue.
In short, your goal, if you’d like me to cover you, is to try to convince me that I need to know about you, because you’re going to be successful, my clients are going to want to know about you, and you’re going to be doing something interesting that’s worth my time to learn about. In other words, convince me that spending time researching you is not a waste — that I won’t be filling my brain with information that won’t translate to eventual client value.
My HostingCon keynote slides are now available. Sorry for the delay in posting these slides — I completely spaced on remembering to do so.
When I was told during HostingCon that private-equity firm GI Partners was acquiring a controlling interest in SoftLayer, my first question was, “Will it be merged with The Planet?” I got a coy answer about what would be logical, and now, it seems, the answer is indeed yes.
The two companies have an interesting mutual history that both might like to forget now — the founders of SoftLayer left The Planet a little over five years ago, leaving some amount of acrimony in their wake (expressed by a still-ongoing lawsuit that will presumably be put to rest now). Industry rumor back then said that the SoftLayer founders were essentially the movers and shakers at The Planet, and that their departure gutted significant talent from the company. By leaving, they missed the results of the GI Partners acquisition of The Planet, subsequent merger with EV1 Servers, and so forth. Management has changed almost entirely at The Planet in the intervening years, making the reconciliation of a merger completely reasonable, but it’s an interesting irony that SoftLayer’s CEO is going to get to come back to run the merged company. It’s also worth noting that the degree of common genesis ought to make this an easier merger than might otherwise be the case.
SoftLayer has been growing at an incredible pace, taking advantage of the same trend towards highly-automated, on-demand, self-managed infrastructure that Amazon has been riding high on. The Planet brings the rest of a hosting product portfolio to the game, so it’s an entirely sensible match. Also, for SoftLayer, the change in capitalization structure should be strongly beneficial, letting them get away from the equipment-leasing trap they’ve been in.
GI Partners has had a solid record of success in the data center space thus far — their other previous investments were Digital Realty Trust (wholesale data center leasing) and Telx (carrier hoteling and carrier-neutral colocation) — and the integration of The Planet and EV1 Servers clearly built a stronger company. I think merging fast-moving companies in the midst of a radically changing market is a dangerous, difficult proposition, since it risks loss of momentum, management confusion and distraction, and so forth, so this will be one to watch — it could build a much stronger merged company, or it could be disruptive to existing success.
There’s been a lot of M&A buzz around the hosting industry of late. Consolidation makes sense in the scale business of cloud, and there are also lots of companies seeking to move up-market with managed hosting offerings. Arguably, the thing that is preventing more M&A activity right now is that there simply aren’t great acquisition targets in the places where people are looking.
Many businesses fail to save significant amounts of money when they migrate to cloud IaaS, because of the cost of their software stacks. This can happen in a myriad of ways, such as:
- Getting on-demand hardware by the hour, but having to pay for permanent, peak-load software licenses
- Paying an “enterprise” uplift on software licenses or running into other licensing-under-virtualization issues
- Spending money on commercial middleware when free open source will do
While there obviously a host of complex issues surrounding software licensing both with in-house virtualization and in the external cloud, I want to focus this blog post on this last point: Using a big complex heavyweight package when a lighterweight simpler one will do.
In the enterprise, especially pre-virtualization, it previously made a reasonable amount of sense to standardize on relatively heavyweight architectures — say, WebLogic or WebSphere on top of an Oracle database. Sure, there were some applications that actually used the full power of Java EE and needed fancy Oracle features (like RAC), but for the most part, the zillions of apps within enterprises are basically business process, workflow, paperwork apps — fill out a form, take some kind of minor action, run a report. They work fine and probably unchanged, on a sliver of a compute core, JBoss, and MySQL, for instance. (And, while we’re at it, run fine under Linux rather than a proprietary Unix flavor.)
I used to convince Web hosting customers that they ought to switch from Solaris to Linux in order to save money. (I still occasionally do, though Solaris is a vanishingly tiny percentage of the market these days, going from near complete market dominance to being essentially negligible in less than a decade and a half.) These days, I pitch clients on why they should consider converting to open source middleware if they’re going to the cloud and want to maximize their cost savings.
The fact of the matter is, it’s expensive to shoot sparrows with a cannon. Standardizing on a single platform has cost advantages right up until the time that the single platform is vastly more expensive than having two platforms. Most of the compute infrastructure in most enterprises is used for commodity applications, and it makes sense to bring down the operational cost of those applications as much as possible. Open source does not necessarily mean free, of course, and commercial open source can be plagued by the same sorts of licensing issues, but there are good things to explore here (and even if open source doesn’t cut it for you, exploring commercial alternatives that are more cloud/virtualization-friendly is still a boon).
Gartner clients: I’ve written about this topic before, in “Open Source in Web Hosting, 2008“. My colleague Stewart Buchanan has authored a magnificent series of notes on this topic, and I recommend you read, at the very least, “Splitting End-User and Service Provider Licensing Will Increase the Costs and Risks of Virtualization and Cloud Strategies“, as well as “Q&A: How to License Software Under Virtualization“.