Hacker News new | past | comments | ask | show | jobs | submit login

Which is better? Having a day of downtime each year, or not launching at all?



Which is better? Using a fallacious comparison to suggest cloud computing is the only viable option, or comparing the pros and cons of different computing models to choose the best one for you?


While the argument was perhaps coming on a bit too strong, it's hard to deny the ease of deployment on cloud services. It's probably a safe bet to say that for most early stage startups the cloud is a good move.


I'm at a loss in these discussions. I don't understand this developer-point-of-view.

Can you specifically give me examples of why using a cloud provider is better for a startup than, for example, using a couple desktops in your garage?

You can't say it's because of backups because the cloud doesn't provide a backup (unless you purchase an extra data backup solution with your cloud provider?). And correct me if i'm wrong, but you still have to set up your development environment on your local computer to write the code, install libraries to test with, etc.

What exactly are the steps involved in "deploying" that you couldn't do on your laptop, or a VPS?


The Germans referred to a Schwerpunkt (focal point and also known as Schwerpunktprinzip or concentration principle) in the planning of operations; it was a center of gravity or point of maximum effort, where a decisive action could be achieved. Ground, mechanised and tactical air forces were concentrated at this point of maximum effort whenever possible. By local success at the Schwerpunkt, a small force achieved a breakthrough and gained advantages by fighting in the enemy's rear. It is summarized by Guderian as “Klotzen, nicht kleckern!” (literally "boulders, not blots" and means "act powerfully, not superficially"). [1]

For a product prototype, the initial primary goal is "get it online so that we can start validating our assumptions". System administration skills and in-house server administration teams are valuable but not necessary.

[1] http://en.wikipedia.org/wiki/Blitzkrieg#Schwerpunkt


This is a much more succinct explanation than my own. This is the point I was trying to make.

Even given that I have a good bit of sysadmin skills, I am needed more as a software developer right now in the early goings. I expect, as you've pointed out, that priorities will change with time and growth. We may even move to bare metal eventually, if we find ourselves needing and able to do so.

Excellent analogy.


So to summarize you both: You want a rapid development platform that doubles as a production system and costs nothing to maintain. That does sound useful!


What? Did you read any of what was written? Point-by-point breakdown for you:

> You want a rapid development platform

No, we want low-maintenance infrastructure.

> that doubles as a production system

It is a production system. It does successfully serve many thousands of users for us every day. We've yet to have an outage that wasn't our own fault.

> and costs nothing to maintain

What? I specifically said we're willing to pay more not to have to spend as much time on infrastructure.

It's OK if you're too set in your ways to even attempt to level with alternative points of view, but at least try to read a little more thoroughly. And maybe admit that you're not willing to budge, so nobody wastes time trying to explain an alternative point of view.


I wasn't dismissing your point of view. Heroku is what I described. AWS, to a certain extent, is what I described. And I said it was a production system, too; you didn't have to over-emphasize what I had already said, as if I didn't just say it. "Costs nothing to maintain" is in comparison to paying to maintain it yourself. But thanks for knee-jerking.


> Can you specifically give me examples of why using a cloud provider is better for a startup than, for example, using a couple desktops in your garage?

For us (a small three-man team), the full portfolio of AWS services lets us shove responsibility for some of our infrastructure off to Amazon, which saves us loads of time (EC2, ELB, S3, CloudFront, SQS, Route53, SES, and some light DynamoDB in our case). Even with their repeat EBS issues, we've engineered around the common failure points, and do so with a tiny number of self-managed VMs relative to our traffic. Even if we were to go down every few months, our hosted services do better than a one-man devops team could ever do on his own in his garage, or even in a co-lo. Though AWS is not expensive, we gladly pay up in order to focus on our own software. Sure beats hiring another person, in our case.

The common counter-argument is that if we managed it ourselves, that we'd have the ability to resolve outages on our own, because it'd be our responsibility. That is just the thing, we don't want it to be our responsibility, we've got one ops guy (me), and we need to be iterating on our product fast at this point. We'll instead plan for failure, design our architecture to continue operating under some degree of failure, and keep shipping.

Not to say that the "cloud" is a silver bullet. It's not. However, especially from the developer point of view, it lets our entire (tiny) team stay more focused on product development.

Addendum: I've managed servers in my basement, in co-lo, and in the "cloud". Each of these routes is more (or less) appropriate in various cases, but AWS has been a boon to our particular usage case.


For what it’s worth, Heroku’s PG Backups addon is free of charge.

https://addons.heroku.com/pgbackups


We also perform our own backups regardless of PG Backups and use Continuous Protection to protect recent data, even in the event of irrecoverable volume failure: https://devcenter.heroku.com/articles/heroku-postgres-docume...


It's not just the cloud itself, but your connection into it. I'm more concerned that my connection to the internet is lost so many times a day (traveling underground etc.) and that this is enough to prevent many devices in my vicinity from acting in a coherent way. They should be able to synchronize among themselves without the central intermediary.

Obviously this doesn't happen because it's hard, but also companies have a vested interest in piping all sorts of data through them for analytics purposes. This is not in the interest of the users at all.


That depends on how much long-term reputation damage you take from having availability that low before a large audience. Which in turn depends on how important your service really is—"can't play my game" is drastically different than "my landlord didn't receive my payment".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: