Blog Archives
Rackspace AppMatcher and SaaS marketplaces
Rackspace has teased a preview page for a SaaS marketplace called AppMatcher. (It looks to be more of a front-page mock-up than anything actual; note that the “1,000 apps”, “100,000 businesses” bits look like placeholders.) The concept is pretty straightforward: app providers provide info about their target customer, and potential customers provide info about their company, and the marketplace tries to hook them up.
Hosting companies have increasingly been talking about doing marketplaces for their customers and their partner ecosystems, particularly in the SaaS space, and Rackspace’s foray is one of several that I know of that are still under wraps. Parallels has gotten into the act on the small business end, too, with the SaaS marketplace it’s integrated into its software. And a ton of other companies in the technology services space are also wanting to jump into the SaaS marketplace / exchange / brokerage business. (And you have folks like Etelos who build software to enable SaaS marketplaces.)
We’re seeing other software marketplaces in the cloud context, of course. For instance, there’s the increasing trend towards cloud IaaS providers offering an app store for rent-by-the-hour or otherwise cloud-license-friendly software — an excellent and important convenience, even necessity, for really driving cost savings for customers. And there are plenty of opportunities, including in the marketplace context, to add value as a broker.
However, I suspect that, by default, these days, if you have a need for software that does X, you go and attempt to enter X into Google, and pray that you’ve picked the right search term (or that the vendors have done reasonable SEO), in order to find software that does X. Anyone who wants to do a meaningful matching marketplace needs to be able to do better than this — which means that the listings in a marketplace need to be pretty comprehensive before it offers better results than Google. What a marketplace offers to the buyer, hopefully, is more nicely-encapsulated information than raw search results easily deliver.
However, many SaaS apps are narrow, “long tail” applications — almost more a handful of features that properly belong in a larger software suite, than they are properly full products unto themselves. That means that it’s harder to make sure that you really have wide and deep listings, and it means that useful community review gets more difficult because the app that’s got a handful of customers quite possibly doesn’t get any thoughtful reviews. And for many of the companies that are considering SaaS marketplace, the length of the long tail makes it difficult to have a meaningful partner model.
So what does Rackspace have that other, previous, attempts to launch general SaaS marketplaces have not? Money to do marketing. And at least thus far, the apparent willingness to not charge for the matching service. That might very well drive the kind of SaaS vendor sign-ups necessary to really make the marketplace meaningful to potential customers.
Amazon introduces “micro instances” on EC2
Amazon has introduced a new type of EC2 instance, called a Micro Instance. These start at $0.02/hour for Linux and $0.03/hour for Windows, come with 613 MB of allocated RAM, a low allocation of CPU, and a limited ability to burst CPU. They have no local storage by default, requiring you to boot from EBS.
613 MB is not a lot of RAM, since operating systems can be RAM pigs if you don’t pay attention to what you’re running in your baseline OS image. My guess is that people who are using micro instances are likely to want to use a JeOS stack if possible. I’d be suggesting FastScale as the tool for producing slimmed-down stacks, except they got bought out some months ago, and wrapped in with EMC Ionix into VMware’s vCenter Configuration Manager; I don’t know if they’ve got anything that builds EC2 stacks any longer.
Amazon has suggested that micro instances can be used for small tasks — monitoring, cron jobs, DNS, and other such things. To me, though, smaller instances are perfect for a lot of enterprise applications. Tons of enterprise apps are “paperwork apps” — fill in a form, kick off some process, be able to report on it later. They get very little traffic, and consolidating the myriad tertiary low-volume applications is one of the things that often drives the most attractive virtualization consolidation ratios. (People are reluctant to run multiple apps on a single OS instance, especially on Windows, due to stability issues, so being able to give each app its own VM is a popular solution.) I read micro instances as being part of Amazon’s play towards being more attractive to the enterprise, since tiny tertiary apps are a major use case for initial migration to the cloud. Smaller instances are also potentially attractive to the test/dev use case, though somewhat less so, since more speed can mean more efficient developers (fewer compiling excuses).
This is very price-competitive with the low end of Rackspace’s Cloud Servers ($0.015/hour for 256 MB and $0.03/hour for 512 MB RAM, Linux only). Rackspace wins on pure ease of use, if you’re just someone who needs a single virtual server, but Amazon’s much broader feature set is likely to win over those who are looking for more than a VPS on steroids. GoGrid has no competitive offering in this range. Terremark can be competitive in this space due to their ability to oversubscribe and do bursting, making its cloud very suitable for smaller-scale enterprise apps. And VirtuStream can also offer smaller allocations tailored to small-scale enterprise apps. So Amazon’s by no means alone in this segment — but it’s a positive move that rounds out their cloud offerings.
Liability and the cloud
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.)
HostingCon keynote slides
My HostingCon keynote slides are now available. Sorry for the delay in posting these slides — I completely spaced on remembering to do so.
SoftLayer and ThePlanet merge
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.
Rackspace and OpenStack
Rackspace is open-sourcing its cloud software — Cloud Files and Cloud Servers — and merging its codebase and roadmap with NASA’s Nebula project (not to be confused with OpenNebula), in order to form a broader community project called OpenStack. This will be hypervisor-neutral, and initially supports Xen (which Rackspace uses) and KVM (which NASA uses), and there’s a fairly broad set of vendors who have committed to contributing to the stack or integrating with it.
While my colleagues and I intend to write a full-fledged research note on this, I feel like shooting from the hip on my blog, since the research note will take a while to get done.
I’ve said before that hosters have traditionally been integrators, not developers of technology, yet the cloud, with its strong emphasis on automation, and its status as an emerging technology without true turnkey solutions at this stage, has forced hosters into becoming developers.
I think the decision to open-source its cloud stack reinforces Rackspace’s market positioning as a services company, and not a software company — whereas many of its cloud competitors have defined themselves as software companies (Amazon, GoGrid, and Joyent, notably).
At the same time, open sourcing is not necessarily a way to software success. Rackspace has a whole host of new challenges that it will have to meet. First, it must ensure that the roadmap of the new project aligns sufficiently with its own needs, since it has decided that it will use the project’s public codebase for its own service. Second, it now has to manage and just as importantly, lead, an open-source community, getting useful commits from outside contributors and managing the commit process. (Rackspace and NASA have formed a board for governance of the project, on which they have multiple seats but are in the minority.) Third, as with all such things, there are potential code-quality issues, the impact of which become significantly magnified when running operations at massive scale.
In general, though, this move is indicative of the struggle that the hosting industry is going through right now. VMware’s price point is too high, it’ll become even higher for those who want to adopt “Redwood” (vCloud), and the initial vCloud release is not a true turnkey service provider solution. This is forcing everyone into looking at alternatives, which will potentially threaten VMware’s ability to dominate the future of cloud IaaS. The compelling value proposition of single pane of glass management for hybrid clouds is the key argument for having VMware both in the enterprise and in outsourced clouds; if the service providers don’t enthusiastically embrace this technology (something which is increasingly threatening), the single pane of glass management will go to a vendor other than VMware, probably someone hypervisor-neutral. Citrix, with its recent moves to be much more service provider friendly, is in a good position to benefit from this. So are hypervisor-neutral cloud management software vendors, like Cloud.com.
HostingCon (and Booth Babes)
I’m on my way home from HostingCon. I wish I had decided to stay an extra day. I originally expected I’d give my Monday keynote and be free to roam and have various conversations with random people, have plenty of time to wander the show floor, and so on. Instead, my schedule filled up rapidly with clients and friends-of-clients (for instance, folks with relationships with our investment banking clients who tugged some strings), plus other folks who grabbed me on email beforehand.
Great things have happened with the show since iNet Interactive took over running it — the audience has become much more diverse in terms of the types of attendees, and in general, it’s a smoothly-run, very professional show, quite a change from the past. I enjoyed having the chance to deliver the opening keynote, as well as my formal and informal conversations with people.
I wish I’d had more time than the 30 minutes I had to spend on the show floor. But there’s been a very interesting backchannel discussion happening on Twitter #HostingCon) that I want to highlight, and that’s the subject of booth babes.
Much to my surprise, there were several exhibitors who brought booth babes — you know the classic sort, in super-skimpy outfits, arrayed in front of their booths. A number of female attendees have called this out on Twitter, but just as interesting are the retweets and supporting objections that come from male attendees. This was particularly stark because of the near total absence of women from the conference; the attendance is overwhelmingly male, and so there was little female representation in either attendees or exhibitors. This was true to even a far greater extent than I’m accustomed to seeing at IT conferences.
So, vendors, here’s a set of reasons why you should not bring booth babes. (And especially not to something like HostingCon, where much of the audience is C-level executives, and it’s all about the business and networking.)
1. You imply your audience is immature and/or unprofessional. Booth babes imply that you think that your audience’s primary interest is in staring at boobs, as opposed to getting serious business done. Moreover, there’s no way to look professional while ogling, and even those people who would like to ogle don’t want to do so in front of people that they’re doing business with. Unless you’re E3 and your audience is adolescents and overgrown adolescents, this is a bad tactic. (And you can argue that booth babes ended up significantly contributing to the death of E3 as a serious trade show.)
2. You imply that your company’s offerings are less interesting than the flesh on display. Yes, everyone needs to do something to draw in traffic, but booth babes smack of desperation. But you do this by having a compelling display that makes people want to come have conversations, not by having booth babes shoving trinkets at people. People grab the trinkets and then don’t have the conversations.
3. You actually make it harder for people to get to the booth itself. This is especially true on crowded show floors, where the booth babes basically form a wall in front of your booth. This makes it hard to see your display, your collateral, and the nametags of the people you have staffing your booth (important for any attendee who is trying to do some networking). Chances are that a lot of people simply don’t make it through the obstacle, especially if they’re casually perusing the floor, rather than looking for you specifically.
I chose not to talk to any exhibitor with booth babes. It wasn’t really a principle thing; I’m not actually offended, just bemused. It was simply a practical matter.
I don’t think conference organizations necessarily need to have rules against booth babes, per se. I simply think that companies should exercise good sense when thinking about where they’re exhibiting and who they’re exhibiting to.
Abstracting IaaS… or not
Customer inquiry around cloud IaaS these days is mostly of a practical sort — less “what is my broad long-term strategy going to be” or “help me with my initial pilot” like it was last year, and more “I’m going to do something big and serious, help me figure out how to source it”.
My inquiry volume is nothing short of staggering (shoved into 30-minute back-to-back calls the entirety of my work day, so if you talk to me and I sound a bit anxious to keep to schedule, that’s why). I’m currently clinging to the desperate hope that if I spend more time writing, people will consult the written work first, which will free me of having to go over basics in calls and hopefully result in better answers for clients as well as greater sanity for myself.
Thus, I have been trying to cram in a lot of writing in my evenings. At the moment, I’m working on a series of notes covering IaaS soup to nuts, going over everything from the different ways that compute resources are implemented and offered, to the minutiae of what capabilities are available in customer portals.
It strikes me that in more than ten years of covering the hosting industry as an analyst, this is the first time that I’ve written deep-dive architectural notes. No one has really cared in the past whether or not, say, a vendor uses NPIV in their storage fabric, or whether the chips in the servers support EPT/RVI. That’s all changing with cloud IaaS, once people get down into the weeds and look into adopting it for production systems.
It’s vastly ironic that now, in this age of the fluffy wonderful abstraction of infrastructure as a service, IT buyers are obsessing over the minutiae of exactly how this stuff is implemented.
It matters, of course. A core is not just a core; the performance of that core for your apps is going to determine bang-for-your-buck if you’re compute bound. The fine niggling details of implementation of fill-in-the-blank-here will result in different sorts of security vulnerabilities and ways that those vulnerabilities are addressed. And so on. The IT buyers who are delving into this stuff aren’t being paranoid or crazy, really; they’re wanting to evaluate how it’s done versus how they’d do it themselves, when you get right down to what’s going through their heads.
It’s a key difference between IaaS and PaaS thinking in the heads of customers. In PaaS, you trust that it will work as long as you write to the APIs, and you surrender control over the underlying implementation. In IaaS, you’re getting something so close to bare metal that you start really wondering about what’s there, because you’re comparing it directly to your own data center.
I think that over time this will be something that simply gets addressed with SLAs that guarantee particular levels of availability, performance, and so forth, along with some transparency and strong written guarantees around security. But the industry hasn’t hit that level of maturity yet, which means that for the moment, customers will and probably should do deep dives scrutinizing exactly what it is that they’re being offered when they contemplate IaaS solutions.
Recent research notes
Here’s a round-up of what I’ve written lately, for those of you that are Gartner clients and are following my research:
Data Center Managed Services: Regional Differences in the Move Toward the Cloud is about how the IaaS market will evolve differently in each of the major regions of the world. We’re seeing significant adoption differences between the United States, Western Europe (and Canada follows the WEU pattern), and Asia, both in terms of buyer desires and service provider evolution.
Web Hosting and Cloud Infrastructure Prices, North America, 2010 is my regular update to the state of the hosting and cloud IaaS markets, targeted at end-users (IT buyers).
Content Delivery Network Services and Pricing, 2010 is my regular update of end-user (buyer) advice, providing a brief overview of the current state of the market.
Is a Cloud Content Delivery Network Right for You? is a look at Amazon CloudFront and the other emerging “cloud CDN” services (Rackspace/Limelight, GoGrid/EdgeCast, Microsoft’s CDN for Azure, etc.). It’s a hot topic of inquiry at the moment (interestingly, mostly among Akamai customers hoping to reduce their costs).
Some of my colleagues have also recently published notes that might be of interest to those of you who follow my research. Those notes include:
- Andrea di Maio’s Criteria for Government to Evaluate Cloud Computing
- PaaS analysts collaborating on VMware and Salesforce.com: The Beginning of a Beautiful Friendship?
- Adam Couture and Stan Zaffos’s SNIA Launches First Cloud Storage Standard
- Matt Cain’s Make or Break Time for Microsoft Cloud E-Mail
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.
CloudPundit: Massive-Scale Computing 