Blog Archives
Citrix buys Cloud.com
(This is part of a series of “catch-up” posts of announcements that I’ve wanted to comment on but didn’t previously find time to blog about.)
Recently, Citrix acquired Cloud.com. The purchase price was reported to be in the $200m+ vicinity — around 100x revenues. (Even in this current run of outsized valuations, that’s a rather impressive payday for an infrastructure software start-up. I heard that VMware’s Paul Maritz was talking about how these guys were shopping themselves around, into which some people have read that they ‘had’ to sell, but companies that sell themselves for 100x trailing revenues don’t ‘have’ to be doing anything, other than sniffing around to see if anyone is willing to give them even more money.)
Cloud.com (formerly known as VMOps) is one of a great many “cloud operating system” companies — it competes with Abiquo, OpenStack, Eucalyptus, Nimbula, VMware (in the form of vCloud Director), and so on. By that, I mean that you can take Cloud.com and use it to build cloud IaaS of your very own. While you can use Cloud.com to build a private cloud, the reason that Cloud.com commanded such a high valuation is that it’s currently the primary alternative to VMware for service providers who want to build public cloud IaaS.
Cloud.com is a commercial open-source vendor, but realistically, it’s heavily on the commercial side, not the open-source side; people running Cloud.com in production are generally using the licensed, much more featureful, version. Large service providers who want to build commodity clouds, particularly on the Xen hypervisor (especially Citrix Xen, rather than open-source Xen), are highly likely to choose Cloud.com’s CloudStack product as the underlying “cloud OS”. We’re also increasingly hearing from service providers who intend to use Cloud.com to manage VMware-based environments (using the VMware stack minus vCloud Director), as part of a hypervisor-neutral strategy.
Key service provider customers include GoDaddy and Tata Communications. A particular private cloud customer of note is Zynga, which uses Cloud.com to provide Amazon-compatible (and thus Rightscale-compatible) infrastructure internally, letting it easily move workloads across their own infrastructure and Amazon’s.
Citrix, of course, now has a significant commitment to OpenStack, in the form of Project Olympus, their planned commercial distribution. The Cloud.com acquisition is nevertheless complementary, though, not competitive to the OpenStack commitment.
Cloud.com provides a much more complete set of features than OpenStack — it’s got much of what you need to have a turnkey cloud. Over time, as OpenStack matures, Cloud.com will be able to replace the lower levels of its software stack with OpenStack components instead. For Citrix, though (and broadly, service providers interested in VMware alternatives), this is a time-to-market issue as well as a solution-completeness issue.
In my conversations with a variety of organizations that are deeply strategically involved with OpenStack and working in-depth on the codebase, consensus seems to have developed that OpenStack is about 18 months from maturity (in the sense that it will be stable enough for a service provider who needs to depend on it to run their business to be able to reasonably do so). That’s forever in this fast-moving market. While Swift (the storage piece) is currently reliable and in production use at a variety of service providers, Nova (the compute piece) is not — there are no major service providers running Nova, and it’s acknowledged to not be service-provider-ready. (Rackspace is running the code it got via the acquisition of Slicehost, not the Nova project.) Service providers want to work with proven, stable code, and that’s not Nova right now — that’s Cloud.com. (Or VMware, and even there, people have been touchy about vCloud Director.)
It’s not that the service providers have a deep interest in running an open-source codebase; rather, they are looking for an alternative to VMware that is less expensive. Cloud.com currently fills that need reasonably well.
Similarly, it’s not that most of the members of the OpenStack coalition are vastly interested in an open-source cloud world, but rather, that they realize that there needs to be an alternative to VMware’s ecosystem, and it is in the best interests of VMware’s various competitors to pool their efforts (and for vendors in more of an “arms merchant” role, to ensure that their stuff works with every ecosystem out there). Open source is a means to an end there. Cloud.com’s stack, whether commercial or open source, is only a benefit to the OpenStack project, in the long term.
This acquisition means something pretty straightforward: Citrix is ensuring that it can deliver a full service provider stack of software that will enable providers to successfully compete against vCloud — or to have hypervisor-neutral solutions peacefully coexist, in a way that can be easily blended to meet business needs for a broad range of IaaS solutions. While Citrix would undoubtedly love to sell more XenServer licenses, ultimately the real money is in selling the rest of its portfolio to service providers — like NetScaler ADCs. Having a hypervisor-neutral cloud stack benefits Citrix’s overall position, even if some Cloud.com customers will choose to go VMware or KVM or open-source Xen rather than Citrix Xen for the hypervisor.
It certainly doesn’t hurt that Cloud.com’s Amazon-compatible APIs (and thus support of RightScale’s functionality) is also tremendously useful for organizations seeking to build Amazon-compatible private clouds at scale. No one else has really addressed this need, and VMware (in an infrastructure context) has largely targeted the market for “dependable”, classically enterprise-like infrastructure, rather than explored the opportunities in the emerging demand for commodity cloud.
In short, I think Cloud.com is a great buy for Citrix, and VMware-watchers interested in whether or not their vCloud service provider initiative is working well should certainly track Cloud.com wins vs. vCloud wins in the service provider space.
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.
Shooting sparrows with a (software) cannon
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“.
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.
Shifting the software optimization burden
Historically, software vendors haven’t had to care too much about exactly how their software performed. Enterprise IT managers are all too familiar with the experience of buying commercial software packages and/or working with integrators in order to deliver software solutions that have turned out to consume far more hardware than was originally projected (and thus caused the overall project to cost more than anticipated). Indeed, many integrators simply don’t have anyone on hand that’s really a decent architect, and lack the experience on the operations side to accurately gauge what’s needed and how it should be configured in the first place.
Software vendors needed to fix performance issues so severe that they were making the software unusable, but they did not especially care whether a reasonably efficient piece of software was 10% or even 20% more efficient, and given how underutilize enterprise data centers typically are, enterprises didn’t necessarily care, either. It was cheaper and easier to simply throw hardware at the problem rather than to worry about either performance optimization in software, or proper hardware architecture and tuning.
Software as a service turns that equation around sharply, whether multi-tenant or hosted single-tenant. Now, the SaaS vendor is responsible for the operational costs, and therefore the SaaS vendor is incentivized to pay attention to performance, since it directly affects their own costs.
Since traditional ISVs are increasingly offering their software in a SaaS model (usually via a single-tenant hosted solution), this trend is good even for those who are running software in their own internal data centers — performance optimizations prioritized for the hosted side of the business should make their way into the main branch as well.
I am not, by the way, a believer that multi-tenant SaaS is inherently significantly superior to single-tenant, from a total cost of ownership, and total value of opportunity, perspective. Theoretically, with multi-tenancy, you can get better capacity utilization, lower operational costs, and so forth. But multi-tenant SaaS can be extremely expensive to develop. Furthermore, a retrofit of a single-tenant solution into a multi-tenant one is a software project burdened with both incredible risk and cost, in many cases, and it diverts resources that could otherwise be used to improve the software’s core value proposition. As a result, there is, and will continue to be, a significant market for infrastructure solutions that can help regular ISVs offer a SaaS model in a cost-effective way without having to significantly retool their software.
What’s the worth of six guys in a garage?
The cloud industry is young. Amazon’s EC2 service dates back just to October 2007, and just about everything related to public cloud infrastructure post-dates that point. Your typical cloud start-up is at most 18 months old, and in most cases, less than a year old. It has a handful of developers, some interesting tech, plenty of big dreams, and the need for capital.
So what’s that worth? Do you buy their software, or do you hire six guys, put them in nice offices, and give them a couple of months to try to duplicate that functionality? Do you just go acquire the company on the cheap, giving six guys a reasonably nice payday for the year of their life spent developing the tech, and getting six smart employees to continue developing this stuff for you? How important is time to market? And if you’re an investor, what type of valuation do you put on that?
Infrastructure and systems management is fairly well understood. Although the cloud is bringing some new ideas and approaches, people need most of the same stuff on the cloud that they’ve traditionally needed in the physical world. That means the near-term feature roadmaps are relatively clear-cut, and it’s a question of how many developers you can throw at cranking out features as quickly as possible. Some approaches have greater value than others, and there’s inherent value in well-developed software, but the question is, what is the defensible intellectual property? Relatively few companies in this space have patentable technology, for instance.
The recent Oracle acquisition of Virtual Iron may pose one possible answer to this. One could say the same about the Cincinnatti Bell (CBTS) acquisition of Virtual Blocks back in February. The rumor mill seems to indicate that in both cases, the valuations were rather low.
Don’t get me wrong. There are certainly companies out there who are carving out defensible spaces and which have exciting, interesting, unique ideas backed by serious management and technical chops. But as with all such gold rushes to majorly hyped tech trends, there’s also a lot of me-toos. What intrigues me is the extent to which second-rate software companies are getting funding, but first-rate infrastructure services companies are not.
Smoke-and-mirrors and cloud software
On my more cynical, read-too-many-press-releases days, I wonder if there’s some hapless, tortured PR gnome at Amazon whose job consists solely of vetting one empty cloud fluff piece after another, proclaiming how such-and-such a vendor is now offering deployments on EC2, and how this therefore gives them an on-demand cloud offering (“please think of me as hip and visionary!”), when in reality, the vendor is doing nothing other than packaging up its software as an AMI (an Amazon machine image, basically a disk image of a server with the application installed).
Packaging something up as an AMI doesn’t make it a cloud service. It doesn’t make it massively scalable, automatically scalable, transparently scalable, on-demand, multi-tenant, or any one of a vast number of other terms that get fatuously lavished on anything with a whiff of cloudiness. If a piece of software doesn’t have any cloud traits when it’s deployed in your data center, it won’t have them when it’s deployed on EC2 (or any other cloud infrastructure service), either.
![[the cake is a lie]](https://cloudpundit.files.wordpress.com/2009/03/cake_lie.jpg?w=150&h=150)
Cloud infrastructure services today, whether EC2 or from one of Amazon’s competitors, are basically servers in the sky. They are almost always a hypervisor-virtualized server with a normal operating system installation, on top of which you install normal applications. There is no magic cloud pixie dust that settles on these instances and turns them into application faeries of scalability and joy.
Building massively and horizontally scalable, multi-tenant software with elastic economics is hard. It’s even harder if you’re trying to take some legacy software package and re-engineer it. This is why practically no one does that kind of re-engineering, and why software vendors have to resort to puffed-up “yes, we run on EC2!” claims, rather than genuinely delivering on-demand cloud services.
Don’t be fooled.
Marketing and PR folks at software vendors: I forgive you for these releases because I know you’re under pressure to put something out, but every time I read them, I cringe on your behalf, and hope that you’re not genuinely entertaining the belief that releasing an AMI meaningfully moves you forward along the cloud path.
IT folks: When your CEO / CFO / CIO comes to you and asks you why you aren’t taking advantage of your software vendor’s awesome new money-saving cloud service, you can tell him it’s because the PR release is just artfully painting a unicorn — a mythical beast everyone talks about but doesn’t actually exist.
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.
CloudPundit: Massive-Scale Computing 