Live data from Hacker News

$250k of DigitalOcean credits for YC startups

blog.ycombinator.com

21–30 of 223 posts

Re: $250k of DigitalOcean credits for YC startups

#21
post #10
post #2

Enjoy your free service, but I would avoid paying for Digital Ocean for any serious project. No custom kernel support 1. Digital Ocean does not allow you to run your own kernel natively. 2. Digital Ocean droplet kernels are infrequently updated. 3. These kernels often contain relevant security vulnerabilities. 4. This has been a known issue since 2013. 5. You can kexec a kernel, but this is an annoying workaround. ht…

> No custom kernel support How many people run custom kernels? I have used a kernel with realtime extensions enabled but that was a very special case and wouldn't run that in a VM anyway.

Very few people run actual custom kernels, but most people want to run the distro-supplied kernel for their distro of choice (including security updates to it) and most decent providers configure their VMs to allow custom kernels so that their users can do this.

Re: $250k of DigitalOcean credits for YC startups

#22
This is nice and long due regardless of DigitalOcean's actual merits. AWS, Google (100k), IBM (120k) and Microsoft (500k) all offer credits to YC companies. More options will compel cloud providers to provide better service offerings to startups.

I wonder to what extent YC companies default to AWS though. Based on what I've heard from acquaintances at Microsoft, I'm not sure they're getting the traction they'd like.

Re: $250k of DigitalOcean credits for YC startups

#23
post #15
post #2

Enjoy your free service, but I would avoid paying for Digital Ocean for any serious project. No custom kernel support 1. Digital Ocean does not allow you to run your own kernel natively. 2. Digital Ocean droplet kernels are infrequently updated. 3. These kernels often contain relevant security vulnerabilities. 4. This has been a known issue since 2013. 5. You can kexec a kernel, but this is an annoying workaround. ht…

> 1. Your private IP addresses are accessible by everyone in the same datacenter. This is pretty bad compared to an AWS VPC -- you basically have to manage and sync your own iptables between all your nodes.

Perhaps, but at the same time, you shouldn't be using IP addresses as a security mechanism. Assume the connection between your hosts is compromised, and code accordingly, with encrypted/authenticated connections between hosts.

Re: $250k of DigitalOcean credits for YC startups

#24

Aren't there a bunch of offers of free cloud hosting for Startups? We should list them here. And you don't need to be a YC company...... Microsoft Azure gives hosting to startups under their Bizspark program - get over your prejudice - it's a great way to run Linux machines. Softlayer and Rackspace I think also have programs for startups. Any other companies offer free hosting to startups?

Unfortunately, all of these require that you be part of some accelerator or receive VC funding before you can take advantage of the discounts. Founders trying to bootstrap a company without external funding are SOL.

It strikes me that these cloud hosting companies are really interested in businesses that value growth above profits and are willing to ignore startups who try to manage costs to get to profitability more quickly.

Re: $250k of DigitalOcean credits for YC startups

#25
post #15

Earlier quoted context omitted.

> 1. Your private IP addresses are accessible by everyone in the same datacenter. This is pretty bad compared to an AWS VPC -- you basically have to manage and sync your own iptables between all your nodes.

Perhaps, but at the same time, you shouldn't be using IP addresses as a security mechanism. Assume the connection between your hosts is compromised, and code accordingly, with encrypted/authenticated connections between hosts.

Not that I want to wade into the "don't use D.O." part of this argument, but, in practice, nobody does this. Virtually every deployment environment I've ever seen with more than 4 hosts in it would be fatally compromised by an attacker who could reach any IP address in that environment.

Re: $250k of DigitalOcean credits for YC startups

#26
post #21
post #10

Earlier quoted context omitted.

> No custom kernel support How many people run custom kernels? I have used a kernel with realtime extensions enabled but that was a very special case and wouldn't run that in a VM anyway.

Very few people run actual custom kernels, but most people want to run the distro-supplied kernel for their distro of choice (including security updates to it) and most decent providers configure their VMs to allow custom kernels so that their users can do this.

> people want to run the distro-supplied kernel

I read "custom kernel" as in "replace distro-supplied kernel and compile your own with some custom flags and patches".

Re: $250k of DigitalOcean credits for YC startups

#27
post #21
post #10

Earlier quoted context omitted.

> No custom kernel support How many people run custom kernels? I have used a kernel with realtime extensions enabled but that was a very special case and wouldn't run that in a VM anyway.

Very few people run actual custom kernels, but most people want to run the distro-supplied kernel for their distro of choice (including security updates to it) and most decent providers configure their VMs to allow custom kernels so that their users can do this.

This is especially big for RHEL, OEL, and friends. Yeah, CentOS is cool for your startup but a big portion of the valley wants support contracts so they can stop doing OS grunt work, and if your provider doesn't roll RHEL you get to deploy your own, and AFAIK that is not possible on DO (and requires quite a bit of work on Linode, its closest competitor in the space; DO is not AMZN). Deploying RHEL in a supported way requires using their kernels.

It's your virtual machine. You should be able to pick a kernel. This isn't for running Andrew Morton patches, as some of the comments imply.

Re: $250k of DigitalOcean credits for YC startups

#28
> their customer success team offers excellent support

Just one piece of anecdotal evidence, but I did not find this to be case. I received terrible support, responses, and lack of responses from Digital Ocean to the point that I no longer use their services for anything serious.

Here's one of the issues I experienced before I pulled the plug:

I wanted to perform the simple task of creating an image from a backup and spinning it up into a server so I could have a duplicate dev server. Seemed very straightforward. Clicked a few buttons in their "dead simple" control panel.

Their timer said "57 seconds remaining" but it never finished. I tried to contact support. 3.5 hours later I received a message saying that it could take hours to complete due to them:

"zeroing out the storage space to be used in order to ensure previous data in those blocks are erased."

I was further told that the advertised timer works for their images they have already setup, but everything else they couldn't give any ETA on. So, the timer was just eye candy not really attached to anything:

"Unfortunately, this part of the process can take a while, especially for larger droplets or droplets based on backups or snapshots. Smaller droplets and those that are based on images we provide are generally faster and should finish creation within the advertised 55 seconds, as long as the system is not under high load.

It's hard to give an accurate ETA for droplets of this size since there are many variables that go into the provisioning process, but note that the process could go up to three or so hours if there's high load at the time. I apologize for any inconvenience with this."

I was attempting to recreate an image from a backup they did. It was of the smallest droplets they have available and it wasn't near capacity.

The server never did actually get setup. Instead, just falling off of my "dead simple" dashboard every time, never hitting active. I mentioned this in the support ticket I had open, since the problem was obviously not resolved. Here was the response:

"Glad to be of assistance.

We appreciate you being a Digital Ocean customer and please let us know if we can be of further assistance!"

This was the third person to respond on my ticket; a different person for every response.

I left them and never looked back. You can find similar experiences on this website or by some brief Googling.

Ultimately, DO is probably still fine to get things going or play around, but I wouldn't trust it for anything serious or anything where you would expect a timely or decent response to help you ensure you can get work done that day. I certainly wouldn't trust DO with anything even close to $250k worth of operations.

Re: $250k of DigitalOcean credits for YC startups

#29
post #2

Enjoy your free service, but I would avoid paying for Digital Ocean for any serious project. No custom kernel support 1. Digital Ocean does not allow you to run your own kernel natively. 2. Digital Ocean droplet kernels are infrequently updated. 3. These kernels often contain relevant security vulnerabilities. 4. This has been a known issue since 2013. 5. You can kexec a kernel, but this is an annoying workaround. ht…

"IPv6 support 1. Took forever to implement, and the timetable broke promises to customers. 2. Inferior. Digital Ocean still won't give you a /64 per standards."

Far more egregious is that they silently drop port 25 on IPv6. This means that enabling IPv6 will cause mail problems for some destinations (destinations that support IPv6, like Google). When asked they say it's because a /64 is too much address space in the hands of potential (ab)users. This fails to understand that an IPv6 /64 is conceptually similar to an IPv4 /32. (In fact, there are pretty reasonable arguments for assigning IPv6 /56s or /48s with the same semantics as how IPv4 /32s are assigned.)

Re: $250k of DigitalOcean credits for YC startups

#30
post #25

Earlier quoted context omitted.

Perhaps, but at the same time, you shouldn't be using IP addresses as a security mechanism. Assume the connection between your hosts is compromised, and code accordingly, with encrypted/authenticated connections between hosts.

Not that I want to wade into the "don't use D.O." part of this argument, but, in practice, nobody does this . Virtually every deployment environment I've ever seen with more than 4 hosts in it would be fatally compromised by an attacker who could reach any IP address in that environment.

True. I haven't heard folks other than Google explicitly talking about this as a best practice.
Post reply on HN