Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Digital Ocean’s journey from TechStars reject to cloud-hosting darling

techcrunch.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#51

Post by xur17 »

priyankt wrote: post #28

My opinion. I am a DO user and I don't think you can use it for production application. Casual hosting is fine. For production servers, deterministic backups are very important. DO does not provide that. I faced a lot of issues when transitioning my server from non-backup to backup mode. To do that, you need to take a snapshot(server shutdown is required for this)of server. Then, you need to destroy it to get the sam…

Are those the only backups you take? I have all of my code stored in git, and my database (and assorted files) get backed up each night to aws. I figure a snapshot is my first line of defense, and aws is my backup in case this doesn't work.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#52

Post by Nux »

gaadd33 wrote: post #29
Nux wrote: post #14

Earlier quoted context omitted.

What I meant is Rackspace (also RedHat, HP, Mirantis etc) would have you believe that if you're not running Openstack then your "cloud" is shit and has no future. DO clearly demonstrated otherwise. They're inflating the hype because they generate $$$ this way - from their public cloud, private deployments, training, certifications etc etc. Nothing wrong with that I guess, it's business.

Does Digital Ocean's "cloud" offer all the same things that OpenStack does? I've been looking for another file storage provider (like S3/CloudFiles/Azure Files) but wasn't aware there were any other options than OpenStack based.

Check https://www.greenqloud.com/storageqloud/

They run Cloudstack for compute, but not sure what they run for storage.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#53

Post by coreymgilmore »

ycombasks wrote: post #21
coreymgilmore wrote: post #19

DO really is a tremendous product. The simplicity, pricing, and speed of setting up an instance is awesome. For setting up a quick dev environment or a simple host for X or Y, it is definitely easier than through AWS. I use DO pretty often and I hope they have some cool new offerings in the future. Maybe really simple load balancing?

I wish they could address these issues: http://www.redbottledesign.com/blog/five-reasons-why-you-sho... I think "There's no way to increase storage space without major down-time" is the most important one. One hour of downtime is no good for production.

I do agree with this. Adding storage to an existing droplet would be nice. Even if it required adding a separate "disk", this would be useful. But obviously, adding, for example, 20GB disk after disk after disk could lead to a lot of annoyance.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#54

Post by mobiplayer »

ycombasks wrote: post #21
coreymgilmore wrote: post #19

DO really is a tremendous product. The simplicity, pricing, and speed of setting up an instance is awesome. For setting up a quick dev environment or a simple host for X or Y, it is definitely easier than through AWS. I use DO pretty often and I hope they have some cool new offerings in the future. Maybe really simple load balancing?

I wish they could address these issues: http://www.redbottledesign.com/blog/five-reasons-why-you-sho... I think "There's no way to increase storage space without major down-time" is the most important one. One hour of downtime is no good for production.

You don't care much about downtime if you're using only one droplet for your app in production, do you?

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#55

Post by ycombasks »

mobiplayer wrote: post #54
ycombasks wrote: post #21

Earlier quoted context omitted.

I wish they could address these issues: http://www.redbottledesign.com/blog/five-reasons-why-you-sho... I think "There's no way to increase storage space without major down-time" is the most important one. One hour of downtime is no good for production.

You don't care much about downtime if you're using only one droplet for your app in production, do you?

What if you start out small with one server, but then need to expand to multiple droplets? You won't be able to without powering off and making an image.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#56

Post by mobiplayer »

ycombasks wrote: post #55
mobiplayer wrote: post #54

Earlier quoted context omitted.

You don't care much about downtime if you're using only one droplet for your app in production, do you?

What if you start out small with one server, but then need to expand to multiple droplets? You won't be able to without powering off and making an image.

That's bad planning, but unfortunately also a very common situation. If you really can't afford a couple late hours downtime when you're small then this is what I think I'd do:

- Get a new pair of droplets in front of your current droplet to load balance the traffic (HAProxy, Nginx, you name it). Point the NS records to those :)

+ Why two? Well, you can't afford downtime so there we go.

- Get a new droplet and manually clone the initial one, i.e. copy over config and assets. Add this second droplet to the LB pool for your site/app.

+ Manual work? Well, again you can't afford downtime so you'll need to put some man-hours on this.

- Now you can shut down the initial droplet and image it while the second one gets the traffic coming from the LB.

Eventually you'd want to separate functionality on different servers, so try to also plan that in advance. Also bear in mind that each 512MB costs like $5/mo, that makes this solution work for $20/mo, how cool is that?

I agree there's room for improvement on DO's service, but there's nothing that a good architect can't work around.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#57

Post by ycombasks »

mobiplayer wrote: post #56
ycombasks wrote: post #55

Earlier quoted context omitted.

What if you start out small with one server, but then need to expand to multiple droplets? You won't be able to without powering off and making an image.

That's bad planning, but unfortunately also a very common situation. If you really can't afford a couple late hours downtime when you're small then this is what I think I'd do: - Get a new pair of droplets in front of your current droplet to load balance the traffic (HAProxy, Nginx, you name it). Point the NS records to those :) + Why two? Well, you can't afford downtime so there we go. - Get a new droplet and manual…

You're absolutely right. How about your MySQL write server? You typically have one master that you update to and one or more slaves where you read from. If you get a sudden burst of traffic and your master can't handle all the writes, what do you do?

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#58

Post by mobiplayer »

ycombasks wrote: post #57
mobiplayer wrote: post #56

Earlier quoted context omitted.

That's bad planning, but unfortunately also a very common situation. If you really can't afford a couple late hours downtime when you're small then this is what I think I'd do: - Get a new pair of droplets in front of your current droplet to load balance the traffic (HAProxy, Nginx, you name it). Point the NS records to those :) + Why two? Well, you can't afford downtime so there we go. - Get a new droplet and manual…

You're absolutely right. How about your MySQL write server? You typically have one master that you update to and one or more slaves where you read from. If you get a sudden burst of traffic and your master can't handle all the writes, what do you do?

I understand how HTTP works so I know how to scale it, but unfortunately I don't have the knowledge to scale DB infrastructure.

Anything I say would be a shot in the dark, but I'm interested on your point of view about this one. Caching? Write on two servers? In the second case do you setup a cluster or you just load balance it with a third device/service?

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#59

Post by ycombasks »

mobiplayer wrote: post #58
ycombasks wrote: post #57

Earlier quoted context omitted.

You're absolutely right. How about your MySQL write server? You typically have one master that you update to and one or more slaves where you read from. If you get a sudden burst of traffic and your master can't handle all the writes, what do you do?

I understand how HTTP works so I know how to scale it, but unfortunately I don't have the knowledge to scale DB infrastructure. Anything I say would be a shot in the dark, but I'm interested on your point of view about this one. Caching? Write on two servers? In the second case do you setup a cluster or you just load balance it with a third device/service?

I'm still learning this myself, but from the research I've done I've figured this out:

1. Most people don't go with two writes to a relational database (like MySQL). Syncing is hard, and when it is done, it loses its relational features. 2. Common set up is one mysql write server, scaling it up to fit your traffic, and automatically syncing it with additional servers where SELECT statements only will be made. A random read server is selected if there are multiple to choose from. 3. This also means that in the application, doing a write and immediate read on what you just wrote won't work, so you have to code your application around that. 4. In you app you separate your connections for the reads and writes.

Now, in terms of making changes to the write server is what I'm trying to figure out. Perhaps there's a way to make upgrades on one of the slaves (the reads), then automatically make that slave the master and the master a slave? Not sure, I'm reading a MySQL book (The MySQL Bible) right now that I hope will point me in the right direction.

Re: Digital Ocean’s journey from TechStars reject to cloud-hosting darling

#60

Post by mobiplayer »

ycombasks wrote: post #59
mobiplayer wrote: post #58

Earlier quoted context omitted.

I understand how HTTP works so I know how to scale it, but unfortunately I don't have the knowledge to scale DB infrastructure. Anything I say would be a shot in the dark, but I'm interested on your point of view about this one. Caching? Write on two servers? In the second case do you setup a cluster or you just load balance it with a third device/service?

I'm still learning this myself, but from the research I've done I've figured this out: 1. Most people don't go with two writes to a relational database (like MySQL). Syncing is hard, and when it is done, it loses its relational features. 2. Common set up is one mysql write server, scaling it up to fit your traffic, and automatically syncing it with additional servers where SELECT statements only will be made. A rando…

Well, that was quite interesting, thank you!
Post reply on HN