The Meteoric Rise of DigitalOcean(news.netcraft.com)
news.netcraft.com
The Meteoric Rise of DigitalOcean
http://news.netcraft.com/archives/2013/06/13/the-meteoric-rise-of-digitalocean.html?lucy=true
195 comments
Is "meteoric rise" really an expression? Meteors generally go down with tremendous speed...
Meteoric: similar to a meteor in speed, brilliance, or brevity: a meteoric rise to fame
I think the phrase exists in a quantum state of dumb and not-dumb.
I think the phrase exists in a quantum state of dumb and not-dumb.
DigitalOcean need to get their technical side up to scratch. Still not having IPv6 at this point makes them a total joke, and the security issues around host keys and VM deletion seem amateurish. My main issue with them, and a reason I wouldn't use them even with the IPv6 issue fixed, however, is the censorship on-demand for the owners' friends.
I have used AWS, DO, Linode.
If you don't need the advanced functionalities that are only available on AWS infrastructure, go with DO. DO beats the price performance compared to Linode while the API, documentation, and support are comparable.
If you don't need the advanced functionalities that are only available on AWS infrastructure, go with DO. DO beats the price performance compared to Linode while the API, documentation, and support are comparable.
To be fair, linode has better documents, the library, DO is getting better and better meanwhile linode's documents grow slowly, partly because they already have a large volume, I have VPSs at both of them.
Uhm.. yes.. So to read those numbers correctly:
"Amazon, Alibaba and Hetzner each get more NEW servers online in 6 months, then what DigitalOcean created in its entire lifetime".
It's all about the wording.. Not to downplay DigitalOceans achievement, though. But people should look at those statistics in another way...
"Amazon, Alibaba and Hetzner each get more NEW servers online in 6 months, then what DigitalOcean created in its entire lifetime".
It's all about the wording.. Not to downplay DigitalOceans achievement, though. But people should look at those statistics in another way...
Have you taken a look at www.bluemix.net ? The beta version of IBMs new open cloud platform for developers that includes access to Watson - the cognitive computing platform that won Jeopardy
yeah they are growing, we noticed: my "ids" sensors grab malicious traffic originating from their ranges more frequently, compared to those originating from aws (which are plenty as well).
have you taken a look at www.bluemix.net the new beta platform from IBM for developers ? It includes access to Watson - the cognitive computing capability
The growth chart is missing "IPv6 Addresses".
Based on your comment, I'm not sure if you know this, but DigitalOcean doesn't offer Ipv6 at any of their data centers right now, so it'd just be a flat line at 0.
I think he means that the statistics do not include IPV6 space other providers use.
I'd be very interested to know if DO make a positive margin on their $5 droplets. I feel like I push a fair amount of data through mine, and plan to push more in the future using a bunch of $5 droplets and round-robin DNS. I'd feel better if I knew I was still a +EV customer.
The hardware cost is the same. 128 * $5 == $640, they charge a fixed $10/GB RAM.
They do have higher support costs, credit card transaction fees, and ip address costs. They would probably lose money if the primary users of the $5/month plans were doing punishing things like video encoding, but my guess is the vast majority are no load users.
I once read someone that was doing hosting, said the larger plans were actually more challenging. 4 high volume forum sites on the same host would cause IO contention. Digital Ocean has SSDs and they mix and match sizes on the physical host, so it should be less of a problem for them.
They do have higher support costs, credit card transaction fees, and ip address costs. They would probably lose money if the primary users of the $5/month plans were doing punishing things like video encoding, but my guess is the vast majority are no load users.
I once read someone that was doing hosting, said the larger plans were actually more challenging. 4 high volume forum sites on the same host would cause IO contention. Digital Ocean has SSDs and they mix and match sizes on the physical host, so it should be less of a problem for them.
Until Digital Ocean came around, I'd always thought it bizzare that there weren't more serious competitors to AWS.
Under the 'competitive advantage' model, it is somewhat unusual that a diversified company like Amazon could be the most efficient vendor at providing a 'commodified', targeted offering like cloud hosting.
Under the 'competitive advantage' model, it is somewhat unusual that a diversified company like Amazon could be the most efficient vendor at providing a 'commodified', targeted offering like cloud hosting.
I dunno... it seems like the likely winner in a commoditized market would be the one with the greatest economies of scale, since that would drive down their costs and allow them to underprice their competitors. (If a product is truly commoditized, then price is the only thing vendors have to compete on.) And few companies have economies of scale to the degree that Amazon does.
This also provides a classic "moat" -- the more sophisticated AWS' offerings become, the more it would cost potential competitors to even attempt to compete with them.
This also provides a classic "moat" -- the more sophisticated AWS' offerings become, the more it would cost potential competitors to even attempt to compete with them.
The costs of your own hardware are significant. A decent initial foray will be at least $1m when you think about servers, routers, switches, etc. Against VC money flowing around, that doesn't seem like much, but it is a big stretch for many start-ups to have that much cash tied up in Capital.
It would be interesting to see how many of those customers come and go.
I have and know people who use DO but it's mostly for early stage development prior to moving to a dedicated/customers infrastructure.
I have and know people who use DO but it's mostly for early stage development prior to moving to a dedicated/customers infrastructure.
[deleted]
I feel like DO has no competitive advantage. They sell servers but then anyone with a reasonable infrastructure and programmers on payroll can scale the way they have. So while it's an impressive rise, it can't be taken for granted. Because all could falter over night. That's just the nature of the business and industry.
There are 4 avenues I think you can take in this market -
1) Price
2) Scalability/API (As in AWS style of instant spinup/spindown)
3) User experience for the dashboard and creation process
4) Configurability of your instances
DO is currently fighting on 1 and 3 with a dash of two, which I think is very smart. They're not fighting with lowendbox providers for the lowest possible price, but they're competing with linode and AWS for relatively low cost, but with good stability and ease of use. You can't spin up/down quite as easily as amazon, but they're not targeting that exact use case anyway.
I've moved a few things over to DO from linode and will continue to, because although performance is a bit less, the price points are far cheaper. I think there are a lot of people who use Linode/AWS for boxes that just hum along doing some simple server task(s) that would gladly move to DO for 1/4 of the price, as long as the stability/customer service is there.
I read a rumor on a previous post that they were working on a way to customize an instances storage & RAM but at the current low price points, which I think would be huge.
1) Price
2) Scalability/API (As in AWS style of instant spinup/spindown)
3) User experience for the dashboard and creation process
4) Configurability of your instances
DO is currently fighting on 1 and 3 with a dash of two, which I think is very smart. They're not fighting with lowendbox providers for the lowest possible price, but they're competing with linode and AWS for relatively low cost, but with good stability and ease of use. You can't spin up/down quite as easily as amazon, but they're not targeting that exact use case anyway.
I've moved a few things over to DO from linode and will continue to, because although performance is a bit less, the price points are far cheaper. I think there are a lot of people who use Linode/AWS for boxes that just hum along doing some simple server task(s) that would gladly move to DO for 1/4 of the price, as long as the stability/customer service is there.
I read a rumor on a previous post that they were working on a way to customize an instances storage & RAM but at the current low price points, which I think would be huge.
> You can't spin up/down quite as easily as amazon, but they're not targeting that exact use case anyway.
I found the opposite to be true, spinning up instances on DO is quicker and easier, using the web interface or the API. Or are you referring to auto-scaling and such?
I found the opposite to be true, spinning up instances on DO is quicker and easier, using the web interface or the API. Or are you referring to auto-scaling and such?
You hit the nail on the head in a way I didn't regarding the core competencies in the market.
I think RAX and Amazon kick ass at 2 and 4, and DO is working on 1 and 3.
I think RAX and Amazon kick ass at 2 and 4, and DO is working on 1 and 3.
I think #2 is a strong advantage of digital ocean.
curl https://api.digitalocean.com/droplets/new?client_id=$DO_CLIE...
I didn't need to look that up. It's a pretty standard REST API, with a bit of overuse of GET to make it even simpler. AWS's API is a lot harder to use.
curl https://api.digitalocean.com/droplets/new?client_id=$DO_CLIE...
I didn't need to look that up. It's a pretty standard REST API, with a bit of overuse of GET to make it even simpler. AWS's API is a lot harder to use.
absolutely, I used AWS EC2 for 1 year, and now I only keep linode and DO, and put most of mine at DO
What do you mean by no competitive advantage? When they launched, they were selling Linode's offerings with SSD for 1/4 the price.
Article is from November 2013.
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.
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.
> 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).
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.
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
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
- 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.
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.
> 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.
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.
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.
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
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?
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.
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!").
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](3)
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.
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).
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.
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.
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.
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](2)
> 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.
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.
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
https://www.digitalocean.com/community/get-paid-to-write
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.
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
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'.
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.
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.
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.
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.
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.
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!
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.
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.
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.
Serious question: is it really worth it for a company like DO to support Windows? It seems like they maintain their edge by avoiding the kind of complexity that Windows would entail.
It's a significant market, not just in size, but in willingness to spend money.
I didn't find Windows complex -- One nice thing about the MS world is the homogeneity of the stack, which makes a lot of things easier if it works for you. If you want to run something else, you probably don't want to run it on Windows anyway.
I didn't find Windows complex -- One nice thing about the MS world is the homogeneity of the stack, which makes a lot of things easier if it works for you. If you want to run something else, you probably don't want to run it on Windows anyway.
One nice thing about the MS world is the homogeneity of the stack, which makes a lot of things easier if it works for you.
Yeah, one of things I miss about the MS stack. The whole freedom is slavery thing. If the MS stack has what you need it usually has a 'this is how to do X' and it works well together.
Yeah, one of things I miss about the MS stack. The whole freedom is slavery thing. If the MS stack has what you need it usually has a 'this is how to do X' and it works well together.
I tried them out a few months ago looking to move my infrastructure from AWS to DO. I was experiencing terrible IO performance on a fairly expensive instance. Submitted a support ticket about it. Their response was 'this is normal'. Killed all my droplets and canceled my account the next day.
To me they are running a pretty transparent pump and dump scheme. Promise a great service, sell it at a loss, get a ton of users, do a shit job of supporting it, take on investment money, cash out early, profit.
To me they are running a pretty transparent pump and dump scheme. Promise a great service, sell it at a loss, get a ton of users, do a shit job of supporting it, take on investment money, cash out early, profit.
They were having SERIOUS issues a few months ago. I had been scaling up to around $600/month in droplets, and almost canceled and walked away. The IO was horrible, packet loss was massive and droplets were crashing all the time. Fortunately, they've gotten much better again and I haven't had a single issue in 3 months.
I think they got really popular suddenly and couldn't handle the explosive growth.
I think they got really popular suddenly and couldn't handle the explosive growth.
I created a droplet that I was going to use for the production site. It is currently sitting in a totally crashed state. I have no idea when it crashed, or why, I just know it happened some time in the past month.
I am now nervous about moving to them.
I am now nervous about moving to them.
Any server you have running in any kind of environment where reliability is a factor should have some kind of monitoring system. Maybe DO should offer this feature like others do, but it's not out of the question to have another droplet running a heartbeat monitor. That'd be akin to them charging another $5/mo for the same service.
I would of course do that before I migrated. I did have munin running, but without alerts. The problem is that is crashed at all. My production server has been up for 668 days, and the temporary DO server didn't last 30.
On the production server, I do ping the server every five minutes, but the customer complaints always reach me before that system.
On the production server, I do ping the server every five minutes, but the customer complaints always reach me before that system.
You can do what nagios does: ping more frequently, but not send an alert until several pings have failed. It guards against a packet lost to the ethers, but still picks up a failed service. Maybe ping every 30 secs, four missed pings = raise alert?
Even better than vacri's suggestion: set up load balancing so that you always have a server to fall back on if one goes down. Once you get the alert, you can fix the down server without the pressure of getting a down website back up.
I have production servers that have been up 3+ years, and others that died within 30 days. On AWS. So having a similar experience on DO wouldn't worry me unless it was every node.
I tried DO for a side project last year.
The Good: - easy setup via the Web UI - instances provision fast - They had a 960GB instance type for only $960/mo
The Bad: - Support was lackluster, kind of like "stuff happens, so your servers may or may not keep working" - DDOS mitigation was overly aggressive. A DDOS likely targeted at the prior owner of the IP caused DO to take the box offline for two days with no warning or even a note saying it had been done. It took ~30 hours for them to even figure out that they had done this. - No SAN storage, so no practical way to store data in excess of what the largest instance type will hold. This limits the utility of the largest instance type. - The killer: they have no capacity of 96GB droplets, so if our box died, we would be unable to restore from the DO snapshot. This ultimately caused us to migrate off of DO (to AWS).
So I still run a couple of nonessential projects there (total spend < $20/mo), but I wouldn't trust my paycheck to services run at DO just yet.
The Good: - easy setup via the Web UI - instances provision fast - They had a 960GB instance type for only $960/mo
The Bad: - Support was lackluster, kind of like "stuff happens, so your servers may or may not keep working" - DDOS mitigation was overly aggressive. A DDOS likely targeted at the prior owner of the IP caused DO to take the box offline for two days with no warning or even a note saying it had been done. It took ~30 hours for them to even figure out that they had done this. - No SAN storage, so no practical way to store data in excess of what the largest instance type will hold. This limits the utility of the largest instance type. - The killer: they have no capacity of 96GB droplets, so if our box died, we would be unable to restore from the DO snapshot. This ultimately caused us to migrate off of DO (to AWS).
So I still run a couple of nonessential projects there (total spend < $20/mo), but I wouldn't trust my paycheck to services run at DO just yet.
My benchmarks (and real world usage with a database I rough up pretty badly) say you're wrong.
So do most blog posts reviewing DO out there as well. Give it another shot, or document exactly what you did and I'm sure someone will figure out the issue.
So do most blog posts reviewing DO out there as well. Give it another shot, or document exactly what you did and I'm sure someone will figure out the issue.
Thank you for telling me about my own personal experience which you know nothing about. I guess if it didn't happen to you personally then it just didn't happen, right?
LOL, I have no dog in the fight. I just think that if you're going to call something a "pump and dump scheme" that gave you "terrible IO performance" when practically nobody else has such issues, you might want to add a bit more information. Maybe try helping someone who has your similar conditions where DO is not the best way to go.
No one's saying your personal experience is wrong, just your extrapolation to "this is a pump & dump scheme"
That their support organization does not care about actually supporting the product is very telling to me. Especially when you have somebody willing to spend $160/mo or more and you basically tell them to 'go away'.
That's definitely a negative and I appreciate you sharing the anecdote, but it's still an awfully big leap from one bad support experience to criminal enterprise.
[deleted]
Why is your particular anecdote worth more than everyone else's?
It isn't, but I'm not trying to negate the experience of anybody else either. If you had good luck with them then great, that is your experience. But don't come and tell me that what happened to me is invalid or didn't happen. Sorry, I do not keep exhaustive benchmarks for every poor product that I decide not to use. I can tell you that it was taking MINUTES to open and read the contents of a file that took seconds on AWS and my local development machine.
Same here. Have been tinkering with moving from Linode to DO for a couple years but keep getting scared and staying put. Linode remains solid.
As the article is from Jun 2013 I should point out the following link (also linked at top of article):
http://trends.netcraft.com/www.digitalocean.com
We have been publicly tracking DO at that address on a monthly basis (I work for Netcraft).
http://trends.netcraft.com/www.digitalocean.com
We have been publicly tracking DO at that address on a monthly basis (I work for Netcraft).
Seems no one here so far has mentioned Rackspace.
Let's start by saying that DO has fewer features for a complex deployment:
No load balancing,
no private subnets,
(IIRC) no IPv6 at the moment.
No "cloud files" or S3 equivalent,
the scaling isn't as automatic as RAX or AWS can provide.
DO can't host Windows (which still matters for many existing operations, don't fool yourself).
RAX gives more information and granularity on its VM levels.
Finally, support. RAX can do managed services, dedicated advisors, IT support and servers for sensitive data. DO has none of this.
---
There are two things DO does that I appreciate (though neither concept is new):
* $5 hosting. RAX is a minimum of $16/mo now, for the same VM strength.
* Application deployments. The ability to one-click deploy Wordpress/Gitlab/etc. is pretty damned awesome.
DO is great for technically competent people who don't need a lot of infrastructure, or otherwise have a consistent level of server/bandwidth requirements for their servers.
Let's start by saying that DO has fewer features for a complex deployment:
No load balancing,
no private subnets,
(IIRC) no IPv6 at the moment.
No "cloud files" or S3 equivalent,
the scaling isn't as automatic as RAX or AWS can provide.
DO can't host Windows (which still matters for many existing operations, don't fool yourself).
RAX gives more information and granularity on its VM levels.
Finally, support. RAX can do managed services, dedicated advisors, IT support and servers for sensitive data. DO has none of this.
---
There are two things DO does that I appreciate (though neither concept is new):
* $5 hosting. RAX is a minimum of $16/mo now, for the same VM strength.
* Application deployments. The ability to one-click deploy Wordpress/Gitlab/etc. is pretty damned awesome.
DO is great for technically competent people who don't need a lot of infrastructure, or otherwise have a consistent level of server/bandwidth requirements for their servers.
I moved some servers from Linode to Rackspace, mainly to consolidate billing since we already had regular dedicated servers there.
I imagine the change was a lot like going from DO to AWS - much more complicated, but at the time Rackspace had only owned Slicehost for a few years and the interface was awful and the setup was confusing with 1st gen and 2nd gen cloud servers and it was just a mess.
I imagine the change was a lot like going from DO to AWS - much more complicated, but at the time Rackspace had only owned Slicehost for a few years and the interface was awful and the setup was confusing with 1st gen and 2nd gen cloud servers and it was just a mess.
Every time I look at rack space it looks phenomenally expensive.
As far as I can tell it's 5 times the cost of digital ocean.
As far as I can tell it's 5 times the cost of digital ocean.
It does seem to be. We are relatively small, and admittedly have a whole bunch of data in S3, but aside from that, our $10K/mo at Rackspace (primarily VMs, some load balancing) is looking to go down to about $6K/month at AWS when we port across 40 or so VMs (then we also don't have to deal with $4K/mo of S3 data transfer, too).
See, I don't get why anyone doing that simply wouldn't just go dedicated.
You know you need it, so why pay a huggggeeeeeee premium and get relatively poor performance compared to dedicated for on demand VM services?
I get the impression a significantly smaller subset of people using AWS/Rackspace/Azure should actually be using them.
Obviously I know nothing about what you're doing, so it may be that you have a perfectly good use case.
You know you need it, so why pay a huggggeeeeeee premium and get relatively poor performance compared to dedicated for on demand VM services?
I get the impression a significantly smaller subset of people using AWS/Rackspace/Azure should actually be using them.
Obviously I know nothing about what you're doing, so it may be that you have a perfectly good use case.
Definitely true. I've actually only been with this company five weeks as their Ops guy, so these are questions I need to get answers too - the founder freely admits Rackspace was his first choice due to good history. But AWS is probably a better fit for us, so I'm doing due diligence on all that. Dedicated is probably not going to work for us at least initially. But definitely worth investigation too.
> * $5 hosting. RAX is a minimum of $16/mo now, for the same VM strength.
You should start with this. How are they even comparable if one is more than thrice the price of the other?
You should start with this. How are they even comparable if one is more than thrice the price of the other?
But the simplicity (less features) and lower cost is exactly why people choose DO over rackspace. Probably the easier referral program too.
Awesome.
Actually Rackspace does have a deployments option under servers that can deploy Wordpress, GitLab, and others. It even handles some of the configuration details right out of the box.
Actually Rackspace does have a deployments option under servers that can deploy Wordpress, GitLab, and others. It even handles some of the configuration details right out of the box.
Agreed, all of these features prevent me from using DO beyond weekend projects. But these features are all on their to-do list. They are tackling them with the most requested features first. BTW, they just added Private Networking in NY2 (maybe more by now).
It is in all of their new data centers (NY2, AMS2, Singapore 1).
I like the Rackspace cloud offering a lot too. We use it exclusively for our business. I see Rackspace as being in the middle of the spectrum if DO is at the bottom and AWS is at the top in terms of more features/higher price.
Also the VPS up-time we have experienced on over 20 nodes for the past 3 years on Rackspace cloud has been pretty great, all things considered.
Also the VPS up-time we have experienced on over 20 nodes for the past 3 years on Rackspace cloud has been pretty great, all things considered.
> RAX is a minimum of $16/mo now, for the same VM strength
I don't see this on their site (http://www.rackspace.com/cloud/servers/pricing/). Minimum pricing there is $29.20/mo for a 1gb instance.
I don't see this on their site (http://www.rackspace.com/cloud/servers/pricing/). Minimum pricing there is $29.20/mo for a 1gb instance.
They hide it (which I think is foolish). They in fact have a pre-Openstack infrastructure where 256M instance is $11.
http://www.rackspace.com/cloud/pricing/
http://www.rackspace.com/cloud/pricing/
Meteors don't rise.
I currently use digitalocean for my blog, but I was recently pointed towards this article which concerns me greatly: https://vpsexperience.wordpress.com/2014/01/05/digital-ocean...
If I cannot have freedom of speech on my blog, I will have to find a new provider that respects my freedom.
If I cannot have freedom of speech on my blog, I will have to find a new provider that respects my freedom.
Nearly Free Speech (nearlyfreespeech.net) is a great choice for hosting a blog. I've been using them for ages. Fees are based on actual usage (network traffic, CPU, storage, etc.) and they take legal rights seriously.
Only downside is that they're a bit limited in what kinds of platforms they support.
Only downside is that they're a bit limited in what kinds of platforms they support.
That's a bit of a stretch, even for equivocation.
Did you read the article in question? http://vpsexperience.wordpress.com/2014/01/05/googler-speaks...
It took four comments, out of context, and made it into a slam. Bias of the rant aside, DO says that it was because of a TOS violation on privacy and defamation. It comes pretty close to outing where the person lives, what websites they run, and certainly makes plenty of assumptions about the four comments.
It reads like someone bitter lost an internet argument when they couldn't bait the employee into saying something incriminating, and they wanted revenge.
Did you read the article in question? http://vpsexperience.wordpress.com/2014/01/05/googler-speaks...
It took four comments, out of context, and made it into a slam. Bias of the rant aside, DO says that it was because of a TOS violation on privacy and defamation. It comes pretty close to outing where the person lives, what websites they run, and certainly makes plenty of assumptions about the four comments.
It reads like someone bitter lost an internet argument when they couldn't bait the employee into saying something incriminating, and they wanted revenge.
> It reads like someone bitter lost an internet argument when they couldn't bait the employee into saying something incriminating, and they wanted revenge.
Exactly this. This guy baited someone to say something about his employer, posted quotes out of context and with obvious bias. The guy seems like an asshole.
Exactly this. This guy baited someone to say something about his employer, posted quotes out of context and with obvious bias. The guy seems like an asshole.
I don't care what it said. There is no reason for a provider to take down a blog post short of it being illegal and someone standing on their doorstep with a warrant.
Except a TOS agreement violation with a person who is obviously trolling.
Normally I would be right there with you - but in this case it was a troll who was asked to anonymize his clearly defamatory attacks, and predictably he blew up over it.
DO is a private provider, not government affiliated, so 1st amendment doesn't apply and they are protected under §230, but still they have a TOS that prevents it from becoming a safe haven for cyber bullies like this troll. TBH I'm okay with this, especially since the troll agreed to the TOS to begin with.
Normally I would be right there with you - but in this case it was a troll who was asked to anonymize his clearly defamatory attacks, and predictably he blew up over it.
DO is a private provider, not government affiliated, so 1st amendment doesn't apply and they are protected under §230, but still they have a TOS that prevents it from becoming a safe haven for cyber bullies like this troll. TBH I'm okay with this, especially since the troll agreed to the TOS to begin with.
To take this to the extreme: you could shut down an innocent business that hosts on DigitalOcean by posting a threatening or defamatory comment on their blog, then making an abuse report. This puts them in the position of hosting such speech, and permits DO to cancel the service without recourse as a TOS violation. That's what you're OK with if you're OK with that being a term of the agreement. You point out that there's no first amendment issue here, but there's a lesson to be taken from the bill of rights anyway -- that sometimes protecting the rights of everyone means also protecting the rights of specific individuals you disagree with.
There may be small risk of this scenario happening, but if you are comparing to another host that doesn't make service contingent upon policing of content you host, then any risk is infinitely larger than necessary. In general, minimizing the ways my business could be wiped out by some service provider helps me sleep better at night. If a user uses a service I provide to host something defamatory, I want there to be a court order before the web host goes flipping power switches on my racks, as it's likely I'll have been contacted by someone before it gets to that point.
There may be small risk of this scenario happening, but if you are comparing to another host that doesn't make service contingent upon policing of content you host, then any risk is infinitely larger than necessary. In general, minimizing the ways my business could be wiped out by some service provider helps me sleep better at night. If a user uses a service I provide to host something defamatory, I want there to be a court order before the web host goes flipping power switches on my racks, as it's likely I'll have been contacted by someone before it gets to that point.
True, that is an extreme. It seems like DO is willing to evaluate each case and give the blog host a chance to remedy the situation. Evidence thus far shows that they at least stick to their guns on the troll posts.
If you're looking for fully managed, you can always use European Privacy-Law Compliant Cloud Instances at tailoredclouds.com
No cheap VPS in latin america, unfortunately... at least we have AWS in SP.
I'm trying to find a VPS provider that can do IPv6 and multiple IPv4. Digital Ocean really surprised me in having no IPv6 offering. What really surprised me is that you can't get IPv6 on Amazon's EC2. You can get a v6 address for a load balancer, but that's surely not the same thing.
Linode does actually almost fit the bill, except that they require manual authorization for an additional IPv4 addresses. So there's no way to script deployment of such a system.
I have gone through about 10 VPS providers and the message is clear: IPv4 is fast running out. So it's especially frustrating when we can't even get v6 addresses yet.
(To pre-empt, no, it's not ssl web hosting in which I require an extra address.)
Linode does actually almost fit the bill, except that they require manual authorization for an additional IPv4 addresses. So there's no way to script deployment of such a system.
I have gone through about 10 VPS providers and the message is clear: IPv4 is fast running out. So it's especially frustrating when we can't even get v6 addresses yet.
(To pre-empt, no, it's not ssl web hosting in which I require an extra address.)
I've used Ramnode to good effect, so far.
You get 16 IPv6 addresses by default, without even having to ask for 'em.
You get 16 IPv6 addresses by default, without even having to ask for 'em.
16 addresses? Or 16 /64's?
16 addresses total. I suspect they've got loads of addresses available if you ask.
Maybe check out 6sync (http://6sync.com/)? They are both ipv4 and ipv6 capable.
Bytemark are a well-known UK hosting company, and they have their own cloudy/scalable setup at http://bigv.io/
Their legacy virtual machines, dedicated hosts, and the new cloud stuff all comes with native IPv6.
Good company, smart people. (Disclaimer I used to work for them.)
Their legacy virtual machines, dedicated hosts, and the new cloud stuff all comes with native IPv6.
Good company, smart people. (Disclaimer I used to work for them.)
It's because it's hard to do right, and securely. With IPv4, it's been around so long that all the secure issues are well understood, and software just expects it to be there.
IPv6 has a bunch of possible security issues, and breaks in all sorts of unknown ways.
It's not impossible to do, but it's a lot harder then just installing some software. As an example, libvirt comes with all sorts of network filters that will prevent IPv4 guests from doing all sorts of bad things (IP spoofing, ARP poisoning, etc). In contrast, it comes with exactly zero similar filters for IPv6.
You need to explicitly ask for this from providers. While you might not get it right away, having the demand there is the only thing that's going to encourage companies to spend time on it.
IPv6 has a bunch of possible security issues, and breaks in all sorts of unknown ways.
It's not impossible to do, but it's a lot harder then just installing some software. As an example, libvirt comes with all sorts of network filters that will prevent IPv4 guests from doing all sorts of bad things (IP spoofing, ARP poisoning, etc). In contrast, it comes with exactly zero similar filters for IPv6.
You need to explicitly ask for this from providers. While you might not get it right away, having the demand there is the only thing that's going to encourage companies to spend time on it.
Dumb question: what do you use IPv6 for? What am I missing by not having it?
Unfortunately not much yet, but you're helping make way for the future.
I say unfortunately because IPv4's limitations are going to hurt more and more as the Internet gets more hosts online.
I say unfortunately because IPv4's limitations are going to hurt more and more as the Internet gets more hosts online.
Can we please stop using "headline grabbing math?" You know what would be a more impressive growth percentage? Starting at when they had 1 server. If you look at the chart, every other competitor save linode had faster growth by the unit (as opposed to percentage).
However, with that said, my complaint is just regarding the article and not with Digital Ocean themselves. I think they're pretty kick ass...
However, with that said, my complaint is just regarding the article and not with Digital Ocean themselves. I think they're pretty kick ass...
I just setup a webserver and it literally took 3 minutes and one piece of documentation reading. Very, very impressive. I remember doing this for the first time on AWS, and it took a while!
http://162.243.202.22/
http://162.243.202.22/
If you are writing a Python, PHP, Go, or Java web app, I think using Google App Engine is the easiest way to get your app live. DigitalOcean is easy, but it still requires you to know a bare minimum of Linux-Fu. App Engine is just brain-dead easy. You literally execute a deploy script locally. And as an added bonus, if you use the Google datastore instead of their RDBS it should scale smoothly too.
I ruled out GAE due to the vendor lock-in issue and reports they raised their prices 3X+ on short notice.
That's more Heroku style. I get the impression that DO is for those WITH Linux-foo.
It works until you want to use PIL or LXML and need to compile a python library with native extensions, or if you want to use a datastore other than google's.
At least, you couldn't do those things a few years ago.
At least, you couldn't do those things a few years ago.
Your point about compiled python libraries is correct in principle, but it's worth pointing out the GAE python comes with PIL and LXML (and a bunch of other libraries) pre-installed these days:
See https://developers.google.com/appengine/docs/python/tools/li... for a complete list.
But,yea if you need a library that's not on that list and uses native extensions, then you're kind of screwed.
See https://developers.google.com/appengine/docs/python/tools/li... for a complete list.
But,yea if you need a library that's not on that list and uses native extensions, then you're kind of screwed.
Oh, that's cool. It makes GAE a lot more appealing.
My FOSS app [0] lets you easily configure a full stack LAMP (and other configurations) server using Vagrant/Puppet, which you can then use to easily deploy locally or Digital Ocean (and Rackspace, and AWS, and coming soon Azure).
PRs welcome :)
[0] https://puphpet.com
PRs welcome :)
[0] https://puphpet.com