Hacker News Reader

Comment by crazygringo | Hacker News Reader

To people wondering if this is a temporary thing, or what Digital Ocean's competitive advantage is (since someone else can come along with the same price point):

It's that the web interface, and process for starting a "droplet", is dead-simple and super-elegant, their support docs are comprehensive and easy to use, and they even do things like let you manage your own DNS records. And it all just works.

Digital Ocean is 100x easier and quicker to use than AWS, without exaggeration. It's easy to start a hosting provider -- it's really hard to make one that is also really high quality, intuitive and easy to use, and then cheap on top of it.

I've used Digital Ocean for a couple of years for small personal things, I'm actually currently in the process of moving a bigger site from AWS to Digital Ocean, at this point it's turning into a no-brainer.

View on HN

> Digital Ocean is 100x easier and quicker to use than AWS

100% agree. I really think the markets for DO and AWS are different. DO aims at the "I need a few boxes" sort of user, and AWS aims at the "I boxes and other infrastructure" where other infrastructure is databases, auto-scaling services, etc.

DO feels like Linode felt like four years ago: just the basics at a great price point. (I still like Linode, but they are probably competing with both AWS and DO, which is a tough spot to be in).

>> I really think the markets for DO and AWS are different. DO aims at the "I need a few boxes" sort of user, and AWS aims at the "I boxes and other infrastructure" where other infrastructure is databases, auto-scaling services, etc.

This is the typical pattern for market disruption: competitor enters the market at the low-end and moves up-market to eventually dislodge the incumbent.

Is that really disruption though? It kinda just sounds like regular ol' business. I only ask because your comment is making me question my understanding of "disruption".

Thanks for the feedback, one thing to remember is that the other companies mentioned in this thread have had quite a few years to put their products and service together.

We spent most of last year dealing with the challenges of scale as we grow quite a bit.

There was the need to scale infrastructure, engineering, customer support, as well as the misc odds and ends of running a business (office space, etc.).

As we grew from 5 people to over 50 today that definitely slowed us down on our product roadmap substantially but now that we've scaled out most teams (and we're still hiring! =]) we are able to once again refocus our efforts on engineering.

That means more updates to the backend for stability and also rolling out new features. During the next couple of months customers should see the benefits of those efforts.

There are other challenges that come from scaling rapidly including making sure that we can retain our culture as new team members join. Aside from rolling out new features and diving into some of those we'll also be writing blog posts on the scale challenges we faced as a startup so that it hopefully provides some insights to other startups as they go through their growth phases as well.

As always if there are any questions please reach out to me direct - Moisey -- digitalocean.com - It may take me a day or two to respond depending on how much work is piled on top, but I always read every email and get back to everyone and we very much appreciate the feedback.

Thanks, Moisey - cofounder digitalocean

It's actually the most widely accepted mechanism for "disruptive" innovation. See:

- http://en.wikipedia.org/wiki/The_Innovator's_Dilemma

- http://en.wikipedia.org/wiki/Disruptive_innovation

I thought "disruptive innovation" was things like car vs horse, e-mail vs postal mail etc - things that are fundamentally different, not an evolution of the existing market.

AWS vs DO seems more like Ford vs Toyota than cars vs horses.

Sometimes the 'different' thing is inferior though - one of the examples in the cited book talks about excavators:

> An example that has nothing to do with “high tech” comes from the mechanical excavator industry. This industry was dominated by steam shovels until the 1920’s, when gasoline powered engines began to replace them. This was, however, not a disruptive innovation, but a sustaining one, even though the design of the machines changed radically from that of a steam-powered system of cables, to that of a gasoline engine driving a system to extend and retract the cable connected to the bucket. The new engines were more capable than the old ones, and were better at doing more work more reliably, and cheaper than the old system. Despite the radical change in the industry, the same firms that were strongest in steam shovels stayed on top. The disruptive change came with the introduction of hydraulic-actuated systems after World War II - a change that eliminated nearly all of the established players by about 1970, in favor of companies that entered the market with hydraulics. The first hydraulic-based excavators were less capable than the cable systems that were in existence, and certainly couldn’t compete with them. However, they were small enough that they could be deployed for jobs previously done by hand, opening up a new market, in which the desired attributes were quite different from the big jobs that the cable actuated excavators were used for. The technology involved in hydraulics continued to improve, however, and with time eventually equaled and then surpassed the needs formerly filled by cable-based systems. In the meantime, though, the established firms were still going strong, and didn’t do much, if anything, to deal with the new competitor (because it wasn’t really seen as a competitor, not being sufficient for their existing clients’ demands) until the new arrivals were “in the midst of their mainstream market”. By the time the established companies introduced their own hydraulics, however, it was too late, and the later entrants were by then better positioned with the new technology.

From http://www.squeezedbooks.com/articles/the-innovators-dilemma... - a site I sold on a few years ago.

I've been using DO for a few months. I recently set up an AWS instance to use as a proxy, as I wanted something cheap in East Asia temporarily, and AWS's Tokyo region fit the bill.

Holy crap is AWS bizarre to set up. I got it done without too much trouble in the end, but man, the UI is just atrocious. It took way too long just to find the right place to go to get started with the process.

I felt the same way for a while, but eventually, while working on a large cloud-based project, I had an epiphany: the GUI is basically the phpMyAdmin interface of AWS.

phpMyAdmin is great when you're first learning to work with the LAMP stack; it lets you fiddle with values, manually create databases, munge columns, etc.

But.

If there are multiple instances of your system running "in the wild" (even just within your own company), and their versions will ever have even the slightest chance of getting out-of-sync? You really want the entire change-history of your modifications to the database checked into git. You want to be able to take any previous sorta-known database state, and move it toward the current well-known database state. To do that, you need programmatic migrations.

And as soon as your software ships a "db/migrate" folder, (non-readonly) phpMyAdmin access becomes anathema to proper configuration management.

AWS can be thought of as a big database that contains your EC2 instances and snapshots, your S3 buckets, etc. At scale, you only want to interact with this database programmatically.

So: if this was the correct hypothesis for why the GUI sucks, what would be an expected prediction? That the programmatic APIs for manipulating AWS would be great.

And they are! All the HTTP APIs for AWS--the ones you would use in any automated provisioning script--are simple, clear, and pain-free. They're definitely the "first-class" road to AWS, documented to heck, and it's clear that Amazon itself dogfoods them directly.

I would suspect AWS makes most of their money from clients that manage instances that are in the mid to high double digits and beyond. For these clients its likely that at some point automation has kicked in and the APIs get the job done much better versus having someone spend time clicking away in a browser.

Most of their revenue, probably.

But I think there are plenty of mid-sized comapnies with multiple AWS accounts, with many machines in each one where no one is quite sure what they do or if they can be switched off.

Sounds like they need to hire someone to take care of that then.

Disclaimer: Sysadmin/Devops

I know this is the case with probably all major clients to them. If I remember correctly from talking to Dropbox employees during a recruitment visit, they had spoken about how they helped Amazon AWS reach milestones as they accounted for approximately 50% of AWS's file storage service usage. Obviously this is done all programmatically as everything is at an extremely high scale.

But DigitalOcean also puts their APIs forward. It made me feel like: Wow, it's nice to use and they're geeks!

So how does DO's api compares to EC2?

They're a billion times saner, they have a very simple REST API that just takes a couple GET parameters and spits out nice JSON. I built a wrapper in scala using the dispatch http library and json4s in about 15 minutes, most of that was writing a couple functions to handle the difference between the formatting conventions used by DigitalOcean's JSON and scala/java standards ("droplet_id" vs "dropletId").

Meanwhile AWS has this nasty outdated SOAP API that you don't want to touch by hand with a 10-foot pole, you had better have a good AWS library for your existing language of choice or know how to make sense of a WSDL.

> AWS has this nasty outdated SOAP API that you don't want to touch by hand with a 10-foot pole, you had better have a good AWS library for your existing language of choice or know how to make sense of a WSDL.

Um, no. Every AWS service has a REST API. The only difficult thing is calculating authentication headers, but that's nitpicky for a good reason.

S3's API is extremely RESTful -- not perfect, but really good. Some of Amazon's newer APIs aren't as RESTful, but they're usually still better than what many people call "REST" today (i.e. "Hey it's not SOAP, so who cares if every flipping thing is a GET request, it must be REST!").

Ironically, your comment on the outdated SOAP API is based on knowledge that is quite outdated. AWS has had a REST API for basically the entire existence of DO.

Deleted comment

Ok I got way off topic. I don't understand why Amazon.com is so intuitive but Mechanical Turk and AWS are so "bizarre".

I work with a few ex-AWSers. Apparently work conditions are terrible and there's a lot of churn. That would explain why the design is so inconsistent.

Keep in mind that I was writing this as someone who mostly uses Riak these days. ;)

I think you will find that was OP's point.

I've never really used phpMyAdmin but I think I take your meaning. And I've always assumed that AWS made way more sense at large scale, since that's what it seems to be aimed at. So what you're saying makes a lot of sense.

I would go one step further and say that both of them are missing critical features. I recently posted a more holistic discussion of cloud devops at https://news.ycombinator.com/item?id=7384393 but it received no comment.

heaven help you if you manage to start an instance that has n permanent storage then reboot it. apparently that's the default, and you need to (imo) go out of your way to get permanent storage. I understand the use case for the former, but the UI and docs for the latter use case were, last I looked, pretty difficult to grok.

Yeah, AWS has some functionality/scaling features that DO and Linode don't, but it's a smaller set of functionality than I think some people initially assume.

Rebooting an EC2 instance never causes you to lose your data (no matter what type of storage you pick).

EC2 has two types of storage: local disk "ephemeral/instance storage" and network storage "EBS". Digital Ocean only provides local disk. In EC2 you can mix and match, but EBS is the most convenient.

If you do a stop and start on EC2 (very different to picking "reboot"). You will lose what's on local disk because stop/start is basically requested that you be moved to a different physical box. Data stored on EBS is not affected. On Digital Ocean if you "power off" you remain on the same host, but get billed at full rate whereas on EC2 you don't get billed for the time it's stopped. Rebooting on EC2 is the same as rebooting on DO.

If you use EBS for storing everything your data survives even if the hardware your instance is running on breaks. If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data. It's the same story on DO as it is on EC2. The only difference is that EC2 gives you the option of storage which can survive the physical box you are on dying (EBS).

> If the hardware breaks on Digital Ocean or on EC2 if you only use ephemeral (local) storage you lose your data.

Is that really the case - neither are using a SAN or RAID or other backup method to ensure data is preserved in (almost) all circumstances? Not so bothered about EC2 (due to EBS) but for Digital Ocean..? Poor show if that's the case.

Its a bit deep to understand at first, but once you've been on the platform for a while, its pretty straightforward. I'm going to respectfully disagree with the "smaller set than people initially assume" -- there are huge differences.

Some examples:

* DNS can be set up to round robin * auto-scaling can be built in * load balancers are available and easy to use * For companies with multiple employees various levels of access can be granted to the system via IAM roles * you can add and subtract hard drives from an instance on the fly (EBS volumes) * You can set those volumes up as RAID if you so desire. * You can easily move IP addresses from one instance to another.

These are just the ones off the top of my head as I've been off AWS for about 6 months now. This doesn't even count how well the servers play with other amazon web services, like SQS, SNS, SES and RDS (queue, notifications, email, database).

That being said, I use DO for a few small sites I host because I don't need any of the features AWS provides.

linode has load balancing available.

I'd think round robin DNS has nothing inherently to do with the infrastructure - that's a function of the DNS server, right?

Yes, there are some things AWS has that other services don't. My own experiences have been that people default to thinking AWS==cloud and that's the 'best' option, and this thinking was prevalent years ago, well before SES, SQS, RDS, etc were extra reasons for integration. They've got good services, but have done a hell of a branding job over the years as well.

That confused the hell out of me. I still don't actually understand it. I was just after an ssh host that I could bounce a SOCKS proxy through so it didn't really matter to me, but I tried to figure out what the different storage options meant and just couldn't.

Have you tried IBMs Cloud? When you're done with AWS you're still struggling with IBM ridiculous contract papers and aren't even anywhere near launching any servers.

Isn't Linode exactly the same? Easy to use web interface, a lot of documentation on getting the things up and going and the ability to resize linode on the web.

I haven't used Linode in a few years, but if they offer exactly the same thing, then DigitalOcean wins handily just based on price for many. I know there are other factors that can go into choosing a VPS or similar service, but price is a big deal for many customers.

Linode doesn't do hourly billing either. They will credit your account for what you don't use, but you get charged for the month upfront.

They've recently released an hourly billing model into beta: https://forum.linode.com/viewtopic.php?f=26&t=10817

My mistake then, thanks for correcting me.

I believe they now offer hourly billing. If you choose it, you are billed hourly, not monthly, but the hourly rate maxes out at the monthly rate. I got an email about it a month or two ago but haven't tried it.

Deleted comment

Linode is twice as expensive per MB of RAM, but less expensive per CPU or MB of disk space.

Linodes cheapest offer starts with $20, while DO only with $5. It's awesome for experimenting.

Do you have data to back up the CPU claim? With Linode, it really depends who you're sharing a server with. I don't have as much experience with D.O. However, dollar for dollar, I think D.O. is slightly faster.

Yeah. For me it was price and performance, both of which DigitalOcean wins.

I couldn't possibly care less about an admin panel. I'm a Linux guy.

I want cheap speed and reliability. With DO, you get all of them. Sorry Linode, but you're old news now.

I share exactly the same feelings and experience with the person who replied to your comment previously.

I have a server in each and I like them both. However;

- Linode support is second to none. DO is not bad either but much slower and less responsive. You feel the difference when you really need it.

- I had a CC payment issue with DO since the beginning. I mentioned it to the support twice but unsolved as of yet, using paypal.

- You can't assign multiple IPs to your instance in DO. I have 6 IPs in one of my Linodes for SSL reasons. This is more than enough to compensate the price diff, actually Linode is cheaper because of that.

- No built in, easy-to-use load balancer in DO.

- Networking feels much faster and stable on Linode, at all occasions.

- Small things like "no more Amsterdam based droplets due to IP restrictions" when you urgently need a server don't usually happen on Linode.

Things like these pile up in the long run and you can easily justify the price difference. If have a very serious/critical project I'd definitly chose Linode over DO.

Is SNI (https://en.wikipedia.org/wiki/Server_Name_Indication) an option for you?

Well, mainly not, due to some of the target visitor groups using Win XP.

Why would you choose Linode for a serious/critical project ?

Do you not know about their major security incidents ?

Like the disk scrubbing issue?

http://venturebeat.com/2013/12/30/iaas-provider-digitalocean...

I am aware of them and yours is a valid point. I, however, was referring to relying on the infrastructure, expandability, customer support etc. Aside, a fair comparison in terms of security can only be made in the long run as it is natural to think that Linode has been around much longer and it is much bigger meaning it has a greater window of opportunities to be targeted by attacks.

I've got a fair bit running on both DO and Linode. Fairly happy with both but still for anything CPU bound (to me the speed part of that), Linode is substantially outperforming DO still and both leave Rackspace Cloud in the dust.

So for me, on average a $20 Linode has less RAM but performs better for CPU bound tasks than a $20 DO Droplet.

> their support docs are comprehensive and easy to use

Yes, I've even used them several times on non-DO servers because they're quite good and rank high on Google.

They will pay anyone $50 per document if it passes their quality check. I say all the power to them; knowledgeable people get a free dinner for writing an article, they're given credit for their work, and you and I end up with quality articles.

To add to this:

I find Digital Ocean's community/blog content impressive. In most instances I can google "Install X on Digital Ocean" and they have a solid, well updated walkthrough.

They've got pretty good bounty program for those who've got the knowledge, and are willing to write easy to understand tutorials.

https://www.digitalocean.com/community/get-paid-to-write

I contacted them 1 month ago for the same. Too bad, didn't even receive a reply. I am still a happy customer for the past year, though.

Amazing program, the best idea for content marketing

I think in a nutshell you're describing Clayton Christensen process of disruptive innovation (or more specifically low end disruption). AWS is catering more and more to its most demanding users. This exposes them at the lower end to developers who aren't as demanding but prefer something simpler that better fits their needs. The way this narrative ends is that DO eats up AWS from below

I think you mean "DO gobbles up the fruit that fell from the AWS tree". Why on earth would AWS be particularly concerned that DO gets all the people who want to spend $5/server and have a handful of servers, when AWS get all the people with four-figure-plus spends? One $1000 spender is worth 20 people who rave over $5 boxes. And there are plenty of $1k spenders.

AWS does have some cheap offerings - some micro instances for your first year are free, which is less than "$5/month, good for tinkering", but for the most part they're not interested in folks who have only a couple bottom-end boxes, because that market doesn't have a lot of money in it.

The logic you present is correct from the incumbent's perspective. But followed to its logical conclusion, it leads to the downfall of the incumbent according to Christensen's model of disruptive innovation. The incumbents will continually cater upmarket to their higher value customers while the challenger picks up more and more low value customers. But there's only so far upmarket you can go until you run out of customers and that's when the low end challenger has completely consumed the incumbent.

I think much of this thread is a testament to the lower value customers being ignored. Things about how DO is much less complex, simpler and as a result cheaper.

Here's part of a great talk from Christensen describing the same logic but in the Steel industry: http://www.youtube.com/watch?v=B5FxFfymI4g

This must be how BSD/Linux has killed Windows.

The problem with the 'logical conclusion' that you're offering is that it works entirely in a vacuum. It assumes that AWS does not innovate itself, but steams on with a stolid product. Nothing could be further from the truth - barely a week goes by without them announcing a new service or improvements to an existing one. DO is behind the 8-ball-that-is-AWS, but AWS isn't just sitting there on the felt, it's moving too.

Given the culture of innovation that exists at AWS, it's not hard to see how they could adjust themselves if DO actually does become a threat. AWS is not head-in-the-sand Microsoft, and even if it were, the might of all other operating systems combined - including that of the company so successful that it has $100 billion just lying around in cash - still hasn't knocked Windows off the top spot. Hardly the 'downfall of the incumbent' suggested.

And Microsoft is still undisputed king in the realm of enterprise user software. Unix has always shared the server room with MS (actually, MS is the interloper there), but outside the server room, enterprise users live on MS. There is a myriad of cheaper enterprise and/or office software out there, and MS isn't particularly threatened by it.

Things about how DO is much less complex, simpler and as a result cheaper.

And then when you need the big stuff... the stuff for which you need to pay the big bucks... the complexity isn't there and you move to the vendor that does supply it. When DO makes those kinds of offerings, then AWS will see them as a serious competitor, and you will see prices drop sharply. Until then, it keeps on truckin'.

Not sure I buy this premise. For one thing, I just had to decide between DO and AWS. I wanted something I could jump in and try something, and then later scale out. I was heavily leaning towards DO. But then I noticed AWS gives you a free year of their micro instance. DO isn't beating that.

Has that ever happened in the tech industry? It seems, following that logic, that Dell should have beat Apple long ago and be the dominate player in hardware as they have historically catered to the lowest value customers.

Well, the history of computing is the bottom end cannibalizing the top end over time. Amazon's entire model is based on using many small, relatively cheap commodity servers to replace larger, more expensive computers. They are susceptible to a point to what's happening at the lower end.

IMO you are underestimating that AWS expands all the time in _every_ direction.

When they added cloudfront, RDS or elastic beanstalk they were offering "something less flexible but very simple" even while they were adding glacier or MFA through IAM which are for more "complex" customers.

> IMO you are underestimating that AWS expands all the time in _every_ direction.

I think I can see where you're coming from but I strongly disagree that AWS will protect its market share by adding more products.

Each new product doesn't just bring utility in terms of what customers can do - it also brings disutility in other areas. New products dilute marketing (what are you selling?). It dilutes the allocation of internal resources (maintenance, R&D, marketing). It increases cognitive overhead for customers (E.g. the product range is a mess -EC2/S3/SWF/SQS/SES/SNS/FPS How is a customer to keep track of what's going on?).

My assertion is that for the average customer - new AWS products only bring headache and zero benefit. Because most people just won't find the need for it. Also AWS don't need to care. They will not meaningfully improve the core offering to the average user because it's the high end customers that will move the needle at the end of the day.

What AWS gives you is much more flexibility and a broad ecosystem of services. So you can start small with a micro in the free tier but be able to scale to Netflix-level if/when you need it. If you want one-click like deployment capabilities you can use third-party software like Bitnami images http://bitnami.com/stacks , which are also available in the AWS marketplace (disclaimer, I am a cofounder of Bitnami). We have also a Cloud management tool that offers a similar Digital Ocean experience on top of AWS http://bitnami.com/cloud and that has a free tier.

Sure, and AWS is great but it's also not magic. It's unlikely you can literally just take the code that was running on a micro instance and scale it up to a big site in multiple zones without a lot of work.

I completely agree, you would have to re-architect the whole app! I am just saying that it gives you the option to because it provides the services and scale to do so. Digital Ocean is great for $5 dev servers, but it is lacking (at least for now) the rest of services and functionality and scale that makes AWS great.

DigitalOcean is cheap enough to be really great as a stand-alone offering period. That includes their $80 or $160 type plans. They're definitely not just great for $5 dev servers.

I agree completely. DigitalOcean is a classic case of an improved experience through restricting options. You're not able to customize your vps, you have to fit your stuff into their categories, but for many of us that's all we want. It's a factor to keep in mind when building things for others.

Something I noticed when taking a new job at a startup recently is that people seem to latch onto the idea of a USP being some fancy bell or whistle. The idea that "everything else in the market is terrible, we're making it easier" can set you apart seems to be lost on a surprisingly large number of people.

LOL. So funny that people always say things like this, that the real reason is its simpler.

Bullshit. The real reason is it is MUCH, MUCH cheaper.

And it works. That's the reason I use it. I am an honest person though, so most people probably won't share the same viewpoint.

[citation needed]

The extremely low barrier to entry isn't just price point. It's hard to say which is more important, but the simplicity difference between DO and competitors is greater than the price difference.

Linode seems to me to be simple enough, but more expensive.

Cheaper than free? And "most people" are dishonest?

The real reason is (obviously) a combination of cost and simplicity.

Are there any good monitoring tools out there for letting you know if your droplet is having problems? I know DO has a REST api and you can obviously check stuff out via the DO web interface, but I am curious if there are any third party tools too?

Pushmon, Pingdom, New Relic come to mind.

It's easy to get started with D.O. but Linode's interface is much easier if you need to upgrade. Last I checked, D.O. doesn't even have an option to add more disk space. With Linode it's just a few clicks to resize.

With D.O. there's an ambiguous list of things you need to do to upgrade to a new plan. For example, after shutting down to upgrade, I heard you need to backup your disk image to multiple datacenters because sometimes an image can get deleted by accident. One night I spent several hours trying to (safely) upgrade and support was slow to respond, eventually I gave up. With Linode it's just a few clicks and you can see the progress of the migration in the dashboard, it's very easy.

I use both Linode and D.O. but for personal projects, Linode is my choice because their tech support team is very responsive 24/7. I am not a heavy user of tech support but when I do need help I need it fast!

competitive advantage compared to Linode - SSD drives, cheaper. That's it. Start process on Linode is just as easy and docs are as good or better, DNS support is there etc.

Linode packages have more cpu available and their drive speed is actually pretty good for being non SSD as well. As I'm sure people will point out, neither one of them has a perfect reputation lately, but I've used both for various purposes, just nothing mission critical on DO, just basic quick stuff that doesn't need security or much cpu

Linode has a long history of major security incidents and withholding information from their customers.

So unless your data is worthless then Linode is a terrible choice.

I'm not concerned about that given the recent disk-scrubbing revalation from DigitalOcean. They're as bad as each other.

Fortunately, my data's not that important.

Half price and SSDs are pretty compelling advantage.

There's a few smaller ones out there like vultr.com that match DO's price. Not sure about their reliability. I've had good luck with DO in that department.

Reply on news.ycombinator.com