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.
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.
Re:Migrating From AWS to FB
by conorgil145 on Thursday June 26, 2014 @07:13PM
(#7952010)
> 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.
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.
This article mentions nothing about latency.
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.
That's not multiple clouds, though.
Run in multiple clouds from day one. Take the pain. It gives you flexibility. Basic vendor management 101.