Live data from Hacker News

Did the Microsoft Stack Kill MySpace?

highscalability.com

91–100 of 206 posts

Re: Did the Microsoft Stack Kill MySpace?

#91
I'm not sure these technology-based analyses are correct. I had four teenagers at the time and they all switched from MySpace to Facebook because the MySpace pages got cluttered with glaring ads. The Facebook layout was cleaner and had no ads (at the time). There was no problem with site speed.

Re: Did the Microsoft Stack Kill MySpace?

#92
post #64

".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.

Stackoverflow has a tiny fraction of the traffic MySpace had when it was relevant. I bet it has a fraction of its traffic now.

Re: Did the Microsoft Stack Kill MySpace?

#93
I really doubt the MS stack had anything to do with it. I think it's more of case of a combination of a different online social shift (from scrapbooking to social circle behavior tracking) and resting on your laurels (e.g. refusing to evolve before Facebook became dominant).

In their defence, what Facebook stumbled upon was really simple and yet very non-obvious (at least initially).

Re: Did the Microsoft Stack Kill MySpace?

#94
post #6

Twitter 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...

Not exactly. It got solved by a lot of changes to the underlying storage structure.

Re: Did the Microsoft Stack Kill MySpace?

#95
I worked at MySpace, specifically the middle tier where these technical issues supposedly existed (scalability), although I also worked on a number of user and non-user facing projects during my time there. You may consider me biased because of that, but I'd say I also have a pretty good view into the issue. The reason for MySpace's downfall is crystal clear to anyone who worked at the company and cared to look around and make sense of what was happening - it was catastrophic lack of leadership and vision in management and product, paralyzing political infighting, and general lack of competence at the top levels of the company's management. The people making the decisions would change their mind and requirements constantly because of this. There were numerous entire features that were simply not launched and abandoned AFTER they were completed because the management couldn't agree on how they wanted to "position them" (and they were great features). The top management level was in a constant state of political infighting, and that most likely came from fox and the way they ran shit. There was no one to judge and reward competence at that level, it was simply about who could cover their ass better or come out looking better. MySpace was huge, and everyone just wanted a piece of the pie.

One 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?

#96
post #16

Earlier 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.

I actually respect that. While facebook brags about their "social graph" (IE: A list of friends they don't do anything with), friendster tried to take on the hard CS problems. Sure they failed, but they were never fake about it. And they were one of the first.

Re: Did the Microsoft Stack Kill MySpace?

#97
I may be incinerated for saying this, but maybe stupid decisions are a symptom of the incompetence that doomed MySpace to failure.

Let 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?

#98

Earlier 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.

Haha. Excellent point about HTML programmers.

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?

#99
post #31

Platform 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…

> Contrast this with Facebook, Google et al-- where every process (from corporate IT to production operations to HR and recruiting) is designed with needs of the engineering organization in mind:

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?

#100
As someone who was fairly intimately involved in the entire evolution of the MySpace stack, I'm dumbfounded at the number of inaccuracies in this article (actually, it's hard to call them inaccuracies so much as an exercise in "I'm going to write an article based on some stuff I heard from disgruntled people."). I developed in non-Microsoft technologies before and after MySpace, and I can tell you that, like all technologies, the Microsoft web stack has strengths and weaknesses. Performance was a strength, non-terseness of the code was a weakness. Modularity was a strength. Etc. Have any of you encountered a technology where, as much as you like it, you can't rattle off a bunch of problems and things that could be done better?

The 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.

Post reply on HN