London-based OnApp is to my mind one of the most interesting cloud players out there. It began as a software provider for telcos and hosting firms that want to get into public cloud services, but then it started federating its customers’ spare capacity in a way that lets those companies – and others — offer the kinds of services they couldn’t possibly muster on their own.
The big showcase example here is OnApp’s federated content delivery network (CDN), which uses the company’s clients as a source of points of presence (POPs), which in turn make it possible to deliver online content to end users from a location that’s as close as possible to them. Federation appears to offer a smart way of quickly gluing together a network to rival big CDN players like Akamai(s akam) and Limelight(s llnw) – but how good is the end product in practice?
According to the U.K.’s CDNify, which launched a year ago as a reseller of OnApp’s CDN business-in-a-box, the reality of the federated approach leaves a lot to be desired. This week CDNify revealed a drastic retooling of its product, and OnApp is out the door, replaced by an in-house platform.
There are two sides to this story, so let’s examine them point-by-point.
Speaking to me on Wednesday, CDNify founder James Mulvany said there were a variety of reasons for the decision, a major one of which was inconsistent quality:
“Overall we are impressed [with OnApp] but it’s quality versus quantity. There are a lot of providers and you can launch a CDN with a lot of POPs, but for a lot of providers selling through that marketplace, a CDN is a secondary thing for them. With some of them the POPs ran slow – some were technically online but not responding very well.”
Kosten Metreweli, OnApp’s chief commercial officer, was understandably loath to address CDNify’s case specifically when I spoke to him on Wednesday. However, on the quality point, he had this to say in more general terms:
“We have many customers on who are at a much larger scale, using federation very successfully. One of the important things to realize about our federation is it’s a proper market, it’s an open market, and just as when you go down to the supermarket and you buy certain apples or lower grade apples, we have [differing] quality of infrastructure in our market.
“Different types of infrastructure have different price points; you can choose infrastructure with a higher price point for higher quality, or a lower price point for lower quality… [you may] have something that doesn’t require 5 9s. One of the pros and cons of the marketplace is you have to have a level of understanding of those concepts to use it in the most effective manner. We put star ratings against each POP in the market, and it’s up to the customers to choose the right POPs for their specific use case.”
As CDNify marketing manager Mike Cunsolo told me, the plus side to OnApp’s model was that it allowed CDNify to “validate our business model really simply” — it was easy to get up and running. But here’s another issue that was perhaps predictable: it’s really tough to differentiate from the other virtual CDN operators doing the same thing.
One big new selling point in CDNify’s revamp is free custom SSL, allowing website owners to offer content through a secure connection using their own domain names and SSL certificates. That is a handy feature if you’re providing embeddable web apps or e-commerce platforms, and if branding is a concern. CDN providers typically charge for this (Amazon(s amzn) CloudFront wants $600 per month per custom SSL certificate, for example), and CDNify saw an opportunity to set itself apart.
However, OnApp also charges for this feature, so if it stayed on OnApp and wanted to offer free customer SSL, CDNify would have had to absorb a loss. “The way we thought about it is this should just be standard, you shouldn’t be charging for it, and every CDN is doing that,” Cunsolo said. “It’s important for us to be able to provide value to customers.”
On this particular point, Metreweli said OnApp incurred costs in handling custom SSL and “we unfortunately have to pass that on; it’s just a commercial consideration for us.”
Regarding the wider differentiation issue, though, he did have this to say:
“The reality is, if you go to any CDN provider out there on the market I would say it’s quite difficult to differentiate between the offerings of most of them, to be frank. The bundles they create are very much the same – they offer similar coverage, similar add-ons – so it’s difficult to differentiate if you’re playing the same game as everybody else.
“One of the clever things about the OnApp federation is it does enable different business models. If you look for example at CDN.net [Editor’s note: This is OnApp’s own implementation of its CDN business-in-a-box], one of the things that does that’s different to mainstream providers is it allows you to choose your own points of presence… [Providers] can offer different geographical packs, emerging markets acceleration CDNs, gold-plated CDNs.”
Growing out of the federation?
Mulvany noted that CDNify was also about to launch its own API so end users can purge content, create and remove resources on demand, and so on. Having that API depend on OnApp’s API would have “limited what we could have done,” he said, also pointing out that OnApp had not delivered on certain feature requests, such as the ability to let customers see which files are getting the most traffic (handy for marketers).
CDNify also encountered another, rather bizarre problem: a “couple of times”, Mulvany said, the firm found that other OnApp resellers were copying images and copy from its website. After all, if everyone’s selling the same thing, it’s an easy shortcut to take. “One incident was literally cutting and pasting,” Cunsolo added.
Metreweli said he could not comment on these particular points (the latter, certainly, is nothing to do with OnApp).
Overall, I get the impression that CDNify had outgrown OnApp’s platform in terms of ambition – it certainly wasn’t a practical basis for offering free custom SSL – but some of its complaints are difficult to evaluate. A lot of it probably comes down to the federated CDN concept not being right for everyone, which those considering it should bear in mind.
I’m sure the ups and downs of the model will come up for discussion at Gigaom’s Structure 2014 conference, which will take place in San Francisco from 18-19 June.