Did the Microsoft Stack Kill MySpace?
91–100 of 206 posts
Re: Did the Microsoft Stack Kill MySpace?
#92".Net programmers are largely Enterprise programmers whom are not constitutionally constructed to create large scalable websites at a startup pace." This is such BS, I can't even read it without physically cringing. I work for a ~400-person business that stands up .NET websites at breakneck speed, and we do it well. People who blame their problems on technical infrastructure decisions almost ALWAYS do so because it's…
Stackoverflow uses .Net stack and scales just fine, using less hardware as well.
Re: Did the Microsoft Stack Kill MySpace?
#93In their defence, what Facebook stumbled upon was really simple and yet very non-obvious (at least initially).
Re: Did the Microsoft Stack Kill MySpace?
#94Twitter had scalability problems and they were on RoR, but it got solved. Scaling to those levels is always going to uncover problems in your architecture. What mattered was the way MySpace chose to execute, not the technology they did it with.
It got solved by moving off of RoR...
Re: Did the Microsoft Stack Kill MySpace?
#95One of the issues that stemmed from this was lack of respect for technology in the sense that no one at the higher levels saw the company as a technology company. They saw it as an entertainment or media company. That created the cultural problems on down that eventually contributed to bad products and shoddy implementation.
Now, the core technical part of the organization was actually extremely competent. MySpace was pushing more traffic than Google at one point in its heyday, and the site scaled just fine then. That wasn't an accident, I have worked with some of the smartest people in the industry there. But because tech wasn't the point for executives, those people were tightly controlled by non-technical management, and so products suffered.
MySpace could (and still can) scale anything, to say that they had a scaling problems by the time they got to their peak is complete gibberish. Over the years they have developed a very mature technology stack. No one knows about it because it's entirely proprietary. The problem was management and product that was basically... incompetent, and lacked anyone at the proper levels who would care to see and fix it.
EDIT: Some typos and missed words. I'm sure still missed some.
Re: Did the Microsoft Stack Kill MySpace?
#96Earlier quoted context omitted.
Friendster: http://highscalability.com/blog/2007/11/13/friendster-lost-l... VB: Can you tell me a bit about what you learned in your time at Friendster? JS: For me, it basically came down to failed execution on the technology side — we had millions of Friendster members begging us to get the site working faster so they could log in and spend hours social networking with their friends. I remember coming in to the offi…
To be fair to the rest of the industry, a single glance at the front page shows size of the TRANSITIVE CLOSURE of your social network. Why would you do that? This is bread & butter algorithm analysis. Don't put O(n^2) analyses on your most-loaded page.
Re: Did the Microsoft Stack Kill MySpace?
#97Let the big karma fire begin.
edit: somewhere else someone mentioned they used Cold Fusion. I consider that another stupid decision. But at least they were migrating out of it.
Re: Did the Microsoft Stack Kill MySpace?
#98Earlier quoted context omitted.
.Net programmers are largely Enterprise programmers whom are not constitutionally constructed to create large scalable websites at a startup pace. For the record, I think it's irrelevant.. but absolutely I think it's true. It doesn't mean .NET isn't capable, or that lots of .NET programmers aren't capable... Just that .NET is way more popular in the enterprise than on the web, and that the work that gets done at most…
So PHP developers are "constitutionally constructed to create large scalable websites at a startup pace"? (Facebook had to a TON of stuff to make it scale). Ruby developers? (Ref: Twitter) Java developers? I think only HTML programmers are the only ones who are constitutionally constructed to create large scalable websites at a startup pace.
Also, it's probably fair to say that as a whole programmers are 'largely' not used to thinking or working in a way that's productive at scale. I didn't argue otherwise.
I just suggested that the percentage of developers in the .NET community who are aligned with values, knowledge, and experience essential to scaling a large site.. is smaller than many other platforms... Yes, I'd argue smaller than all of the ones you mentioned.
Re: Did the Microsoft Stack Kill MySpace?
#99Platform fetishism[1] and attempts to throw developers under the bus[2] aside, the comment from Nick Kwiatkowski states a much better reason: developers weren't empowered do their jobs. The comments state that there was no staging or test environment, no ability to roll back releases, refactoring was a dirty word (engineers wanted to refactor, but couldn't), principal on technical debt was never paid (only the intere…
Completely agree.
> Want ssh access to production? No problem.
This makes me a little uneasy, I'm not sure everyone should have ssh access to the production server.
Re: Did the Microsoft Stack Kill MySpace?
#100The web tier has very little to do with scalability (don't get me wrong, it has a lot to do with cost, just not scalability, except in subtler ways like database connection pooling)--it's all about the data. When MySpace hit its exponential growth curve, there were few solutions, OSS or non OSS for scaling a Web 2.0 stype company (heavy reads, heavy writes, large amount of hot data exceeding memory of commodity caching hardware, which was 32 bit at the time, with extraordinarily expensive memory). No hadoop, no redis, memcached was just getting released and had extant issues. It's funny because today people ask me, "Why didn't you use, Technology X?" and I answer, "Well, it hadn't been conceived of then :)".
At the time, the only places that had grown to that scale were places like Yahoo, Google, EBay, Amazon, etc., and because they were on proprietary stacks, we read as many white papers as we could and went to as many get-togethers as we could to glean information. In the end, we wrote a distributed data tier, messaging system, etc. that handled a huge amount of load across multiple data centers. We partitioned the databases and wrote an etl tier to ship data from point A to point B and target the indices to the required workload. All of this was done under a massive load of hundreds of thousands of hits per second, most of which required access to many-to-many data structures. Many startups we worked with, Silicon Valley or not Silicon Valley, could not imagine scaling their stuff to that load--many vendors of data systems required many patches to their stuff before we could use it (if at all).
Times have changed--imagining scaling to MySpace's initial load is much easier now (almost pat). Key partitioned database tier, distributed asynchronous queues, big 64-bit servers for chat session, etc. But then you factor in that the system never goes offline--you need constant 24 hour access. When the whole system goes down, you lose a huge amount of money, as your database cache is gone, your middle tier cache is gone, etc. That's where the operations story comes in, wherein I could devote another bunch of paragraphs to the systems for monitoring, debugging, and imaging servers.
Of course there's the data story and the web code story. MySpace was an extraordinarily difficult platform to evolve on the web side. Part of that was a fragmentation of the user experience across the site, and a huge part of that was user-provided HTML. It was very difficult to do things without breaking peoples' experiences in subtle or not subtle ways. A lot of profile themes had images layed on top of images, with CSS that read, "table table table table...". Try changing the experience when you had to deal with millions of html variations. In that respect, we dug our own grave when it came to flexibility :).
Don't get me wrong, there were more flaws to the system than I can count. There was always something to do. But as someone who enjoys spending time on the Microsoft and OSS stacks, I can tell you it wasn't MS tech that was the problem, nor was it a lack of engineering talent. I am amazed and humbled at the quality of the people I worked next to to build out those systems.