
Simpler cloud services try to undercut the established giants - somberi
http://www.bloomberg.com/news/articles/2015-10-08/cloud-computing-finally-gets-some-startups
======
rsync
"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.

------
sargun
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."

~~~
ju-st
Why do you think so? Why would cloud services work worse without economies of
scale?

~~~
sn
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](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.

~~~
ju-st
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.

------
tajen
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.

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

------
jsolson
> 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.

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

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

~~~
jsolson
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.

~~~
tim333
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...](http://www.netcraft.com/internet-data-mining/hosting-provider-
server-count/)

~~~
boulos
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.

------
larrys
"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.

