5 ms·

Called it, five years ago: http://www.web2expo.com/webexny2009/public/schedule/detail/9537 http://www.web2expo.com/webexny2009/public/schedule/detail/9... Run

by aristus 12y ago

Called it, five years ago: http://www.web2expo.com/webexny2009/public/schedule/detail/9537 http://www.web2expo.com/webexny2009/public/schedule/detail/9... Run in multiple clouds from day one. Take the pain. It gives you flexibility. Basic vendor management 101.

serge2k 12y ago
This article mentions nothing about latency.
- sumbry 12y ago
  We're undertaking a similar project and the latency is almost negligible. In fact the latency is lower bridging between classic and vpc in the same availability zone than between two classic availability zones.
  - ceejayoz 12y ago
    That's not multiple clouds, though.
- rhoml 12y ago
  They mentioned AWS direct connect which helps to reduce latency.
codeka 12y ago
Maybe it's worth the pain if every startup became the size of Instagram and got bought by Facebook, but that's only true for a tiny, tiny fraction of a % of all startups.
- davidw 12y ago
  Yes - truth be told, I am not sure if there's much to take away from this article if you're not really aiming for something huge. And even then, maybe you should spend time on what'll get you traction rather than trying to design an architecture for what you hope to become. Instagram is very much an outlier.
conorgil145 12y ago
> Run in multiple clouds from day one. Take the pain. It gives you flexibility. Basic vendor management 101. While "taking the pain" may yield flexibility in the long run, the most important thing in the short run is making sure that you are building something that people want, listening to users, and iterating the tech side of things as quickly as possible. I suspect that most devs have enough trouble dealing with a single cloud provider and that trying to work with multiple would could a significant decrease in iteration speed. I think that approach would kill most startups because of the technical overhead incurred.
jordo37 12y ago
This seems like exactly the sort of advice that is great in retrospect once you reach scale but is effectively useless until you hit that point. There are far more important things for a startup to worry about (product market fit, retention, stability) than how to make the tech side of an acquisition easy.

by aristus 12y ago

serge2k 12y ago

This article mentions nothing about latency.

sumbry 12y ago
We're undertaking a similar project and the latency is almost negligible. In fact the latency is lower bridging between classic and vpc in the same availability zone than between two classic availability zones.
- ceejayoz 12y ago
  That's not multiple clouds, though.
rhoml 12y ago
They mentioned AWS direct connect which helps to reduce latency.

codeka 12y ago

Maybe it's worth the pain if every startup became the size of Instagram and got bought by Facebook, but that's only true for a tiny, tiny fraction of a % of all startups.

davidw 12y ago
Yes - truth be told, I am not sure if there's much to take away from this article if you're not really aiming for something huge. And even then, maybe you should spend time on what'll get you traction rather than trying to design an architecture for what you hope to become. Instagram is very much an outlier.

conorgil145 12y ago

> Run in multiple clouds from day one. Take the pain. It gives you flexibility. Basic vendor management 101. While "taking the pain" may yield flexibility in the long run, the most important thing in the short run is making sure that you are building something that people want, listening to users, and iterating the tech side of things as quickly as possible. I suspect that most devs have enough trouble dealing with a single cloud provider and that trying to work with multiple would could a significant decrease in iteration speed. I think that approach would kill most startups because of the technical overhead incurred.

jordo37 12y ago

This seems like exactly the sort of advice that is great in retrospect once you reach scale but is effectively useless until you hit that point. There are far more important things for a startup to worry about (product market fit, retention, stability) than how to make the tech side of an acquisition easy.