61–70 of 89 posts
Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going.
The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.
Ideally, there would be a generalized way to build scalable applications. Similarly to how mostly everyone got behind React, it would be great to have mostly everyone behind such a project. I'm sure it will happen, but I'm not sure when it will. Right now there are hundreds of new libraries in the JS ecosystem, but there are some clear converging trends. I think new languages and libraries will always exist and be welcome, but it'd be great to have one standard way based on years of experience. Similar to how other industries stabilized (i.e. building bridge). I feel we'll be able to move so much faster when we get to that point. Now, every programmer is reinventing the wheel and keep doing the same mistakes that other programmers elsewhere are doing.
Click-bait speculation. Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going. The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as f…
Instagram still run partly on AWS, not sure about the rest like the actual backends.
> Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.
That's the last thing a startup should worry about. Growth and branding are far more important. Most acquisitions ended up with most of the original team departing from the new company a year or two after the acquisitions, or move on to another production. Your product will be dismantled and re-engineered in house.
Click-bait speculation. Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going. The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as f…
Seems more like a problem with FB onboarding them and their tech. With some of the smartest people in the world they can't solve problems like this?
> Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.
Makes no sense. Startups should focus on product and users. Scaling on AWS is somewhat of a no brainer giving more time for what's important: product and users. This seems more like an outlier situation in which FB really didnt care.
Earlier quoted context omitted.
Parse made no sense as part of Facebook, but would have made sense if part of AWS or even Microsoft.
Wonder if founders knew this but were just happy to get acquired. Can't say I would blame them.
Earlier quoted context omitted.
It didn't make sense to me until I had a.) started a company and b.) saw the historical tech stacks of a number of companies (eg. Google, Facebook, EBay) that had hit it big. I started my career with the belief that your company has one tech stack, the chief architect chooses it when the company is founded, and that you never ever rewrite it because you're in for a world of pain if you do. I learned that basically no…
While I agree completely with your comment, I wished you'd written "made architectural choices based on facts that are no longer true" instead of "is an idiot." Nobody sets out to make bad choices on purpose, and only the extremely lucky make architectural choices that survive massive growth. (I believe Etsy had a policy of rewrites needing to support current needs multiplied by five. This acknowledges that there's a…
Earlier quoted context omitted.
It didn't make sense to me until I had a.) started a company and b.) saw the historical tech stacks of a number of companies (eg. Google, Facebook, EBay) that had hit it big. I started my career with the belief that your company has one tech stack, the chief architect chooses it when the company is founded, and that you never ever rewrite it because you're in for a world of pain if you do. I learned that basically no…
And, personally, I think that this stack rewrite path makes a _lot_ of sense and probably should be planned from the beginning. The business requirements to the architecture — not functionality! — change over time. At first, you have to be lean as hell and try a lot of different stuff. Then, you need to scale, and performance becomes an issue. Some time afterwards, you want to add more features to increase monetizati…
Earlier quoted context omitted.
your second paragraph would be incredibly unfortunate. most of the sane large companies i've worked at or know people who work at have settled on 2-4 languages -one of which is usually the legacy starting language-which they provide tier-1 support through dedicated teams providing "the stack" in various forms. everything else is community owned and caveat emptor. its why startups should be able to use whatever langua…
The "2-4 official languages" dictum is usually put in place after the company churns through those 2-4 languages in the first 2-4 years of its existence. Basically everybody realizes how costly it is and says "no more". At least that's how it was at Google, which is perhaps the most famous example of the "We have 4 official languages, and you're not introducing a new one" policy. I've worked in startups that tried to…
I believe those 4 languages were Java, C++, Javascript, and Python. Nowadays they also use Go, Dart, Groovy (in Android Studio), and I guess a lot more. (When I say Groovy, I mean the tiny non-Turing Complete subset of the syntax used as a DSL in typical Gradle build scripts.)
Click-bait speculation. Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going. The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as f…
all the smart people left, and migrations are hard. very hard. you have to know how the internet actually works, and most people don't have the foggiest fuckin' clue about how anything really works, especially in today's advanced abstraction-driven world.
they should have written it into the vesting contract, probably will in the future.