Simpler cloud services try to undercut the established giants | Hacker News Reader

Simpler cloud services try to undercut the established giants

bloomberg.com

32 pointssomberi14 comments

"The startups have managed to underbid the giants in certain markets by keeping expenses relatively low, either by writing their own versions of the software needed to run a cloud or by handcrafting the hardware needed to house one."

It's funny to see a description of the exact opposite of your own strategy put to print.

We[1] are overbidding "the giants" by providing personal support and allowing people to use their own tools and writing nothing that's non-standard or provider-specific.

Yes, we do build and own our own infrastructure (of course) so perhaps that's a commonality. Honestly, we never even referred to what we do as "cloud storage" or "cloud anything" until two years ago...

[1] You know who we are.

The reason why most cloud services seem to work is because of economies of scale. Google compute engine will only ever represent a small percentage of their total server utilization, and all they've learned in serving Google.com, and such enables them to serve GCE better.

Backblaze had their backup business that enabled them to figure out storage, and buy a ton of it. DigitalOcean is really a Linode competitor. Not really a EC2 / GCE competitor. I wouldn't call it "cloud."

Why do you think so? Why would cloud services work worse without economies of scale?

For virtual machines, whether economies of scale are important depends on whether you define cloud based on minimum time units - hourly or minute increments - or in service expectation - the provider doesn't work particularly hard to keep your machine up on a given server but it's automatically brought back up when the underlying hardware has a failure. If you define it based on minimum time of compute, this means having enough spare capacity to handle highly variable demand and the resources to absorb the costs of having the hardware sit idle.

If you own your own datacenter and there are physical machines, you can turn off the power and not pay for it so as long as the initial investment is paid off, it doesn't hurt too much financially. Without your own data center, the cost is fixed regardless of whether the servers are in use or not which is why we (prgmr.com) do not plan to offer hourly pricing any time in the foreseeable future. Someone with a larger user base is also going to be able to negotiate better rates such that idle machines do not hurt as much.

DO is currently "cloud" based on pricing and not necessarily how it globally provides service, as at least some subset of VMs are subject to routine maintenance or downtime. But to bring up a server almost immediately on another machine if one has a hardware failure is a more tractable problem and it is a service we eventually intend to offer. Xen has a feature called remus http://wiki.xen.org/wiki/Remus which effectively does continual live migration which would be pretty cool to implement, though support on Linux is not mainstreamed yet.

I see. But I'm not convinced, let me explain why:

- Until proven otherwise I assume that the demand for VMs in clouds follows the general "internet load curve" (peak demand = 1.5x avg demand; plateau during the day; peak at 19:00). With the normal monthly billing you just see the variable load on the host node, and the server must have spare capacity to handle the peak load. With hourly billing, the peak load will not vary, only the fact that your customers spin down VMs on non-peak times.

So basically my point is that hourly vs monthly billing doesn't change anything demand/load-wise. The only difference is the billing; you basically have to recoup your lost revenue from the non-peak times by generally higher hourly pricing.

- If you colocate your (few) servers you can also shut them down to save energy. If you have a contract with usage based power bills.

I wonder whether this article was initiated by a PR department from either DigitalOcean or Blackhaze, which are the only two providers mentionned. I does talk about a new trend, but it brings little new facts.

Hiya - I wrote the article, it wasn't from PR. As far as I know the supplier stuff, revenue numbers, signup numbers, are new.

I concur: it is a new trend and DigitalOcean or Backblaze are not the only one playing this game. I work for a start-up in this market. We also design our own hardware and software, all packaged under an IaaS offering: https://scaleway.com/faq/#-What-is-Scaleway

> Four-year-old DigitalOcean now has more host computers in its cloud (almost 200,000) than any other company but Amazon (which has about twice that), says researcher Netcraft.

As someone who works on an IaaS offering, I'm really curious how Netcraft is doing this estimation. As a curiosity, I also wonder what they estimate our count of 'host computers' at.

However, it's also a meaningless number, given that VMs are sold in terms of (mostly) cores and RAM. If you're buying an 8 core VM with 16 GB of RAM, do you care if the physical host has 8, 16, 32, or 64 cores? Probably not (and you shouldn't). Those eight cores perform however they perform; you won't know unless you benchmark them, and you won't know what your variance is in prod unless you collect continuous metrics.

This is a good 2012 article about estimating AWS size [1]

[1] https://huanliu.wordpress.com/2012/03/13/amazon-data-center-...

The IP probing is an interesting methodology, although it would not work for GCE as VM IPs are entirely virtualized[0]. That said, the methodology's biggest flaws (even with AWS as I see it) are that they don't know the machine-count of individual racks (and this number can vary more than you might expect) and, more importantly, they don't know the sizing on individual hosts.

Putting my original point differently: DigitalOcean may be big or small, but counting physical hosts is a terrible way to estimate its size. Better would be to count available cores and RAM, but of course those are much harder numbers to pin down as cloud providers tend to go to some lengths to abstract away the details of physical hosts.

[0]: Supporting live migration for individual VMs mostly necessitates that the IPs within a virtual network be meaningless w.r.t. the physical host locations -- also GCE advertises a /32 subnet via DHCP and requests the guest route all packets to their 'gateway'. Handling actual routing (to avoid a needless extra hop) is done via the Andromeda SDN.

Netcraft have a somewhat vague article on their methodology on their site eg.

>By arranging for a number of IP addresses to send packets to us near simultaneously, low level TCP/IP characteristics can be used to work out, within an error margin, if those packets originate from the same computer, by checking for similarities in a number of TCP/IP protocol header fields. To build up sufficient certainty that IP addresses on the same computer have been identified, many visits to the sites in the Web Server Survey are necessary, which takes place during a period of over a month.

>Informal checking with two of the largest dedicated server companies suggests that the survey counts about 2⁄3 – 3⁄4 of the machines in their datacenters.

http://www.netcraft.com/internet-data-mining/hosting-provide...

And because DigitalOcean doesn't have load balancing as a service, people generally just expose their Droplet to the internet as their website. Netcraft's methodology works fine here, likely misses or undercounts Droplets behind nginx/HAproxy and is wildly off for people behind load balancers like Google's Load Balancer Or AWS's ELB.

Disclaimer: I work on Compute Engine, but I also knew plenty of people at DigitalOcean.

"Four-year-old DigitalOcean now has more host computers in its cloud (almost 200,000) than any other company but Amazon (which has about twice that), says researcher Netcraft."

I am not seeing how netcraft can distinguish between a VPS and a host computer by the way they crawl the web.

Reply on news.ycombinator.com