Harnessing Explosive Growth: Infrastructure Strategies and Tactics
The session I am now waiting for is Harnessing Explosive Growth: Infrastructure Strategies and Tactics. The official description of the session is:
SJ: 99% architecture
JH: Product is what drives architecture. We have more than 10,000 servers. For chat, they built a separate network. www.facebook.com/eblog.
JR: The biggest consideration is how their servers work with Facebook.
When's it broken? When did you know your first architecture was broken?
AG: First million users. Then they started focusing on caching and sharding.
JB: eBay had a few catastrophic issues near 2000. People were very forgiving of availability issues. They give refunds when there is downtime.
JR: They moved a lot of their technology to EDGE.
SJ: Since Meebo is just one page, javascript delivery is a major issue for them. They are not generating pages. Dynamic loading and background computation is really important.
RP: Application and infrastructure is going to break. If you look hard enough you can find where are the scalability issues.
JR: They are very metric driven. It's not often they see outages. They have number of Facebook's ops folks on their IM lists and they talk continously.
JH: We work through problems together.
JH: They have had to turn off some applications because other applications were being affected.
JB: At eBay they have created a central application login system. They can flag and identify problems really quickly. If you don't have it, you're shooting in the dark.
Rolling your own stuff? Off-the-shelf vs. custom:
Did you roll your own? Do you regret it?
SJ: For cash restraint startup, off-the-shelf can work. But for scale, you'd want to build yourself. Open Source is awesome. No one can scale your system as well as you can. Off-the-Shelf can be bulky. You have to get your hands dirty.
JR: We built our own caching backend. Invest time in core stuff, anything that's not core, don't focus there.
What also needs to scale as you grow? What non-technology things you had to scale?
JB: Need to scale out your business as well as technology.
AG: Building anti-spam features into the product that are scalable.
JH: Make community part of the process in translations as you grow.
JR; They introduced user moderation for photos. Hard to find what's porn and what's not. It's about a dozen people looking at photos full-time to hunt down porn.
How should we handle the fallout? If you were Twitter what would you have done last month?
JB: You have to be transparent. Tell them what's going on. Setup message boards for communication. You've got to communicate.
AG: Setting realistic timelines is very important
JH: We do it often. We roll in small chunk and if things don't look right, we roll back.
JB: You cannot operate a large system without the ability to turn things on and off.
JR: If you have an aggressive competitor, you don't have the luxury of downtime.
RP: You can't roll out something that can't be rolled back.
What worked in the garage can rarely be scaled effectively for the boardroom. This panel will bring together some of the biggest names in web infrastructure to share their thoughts, insights and tactics for harnessing explosive growth, with a focus that goes beyond simply which technologies are available but how to best deploy them. This panel is not to be missedPanelists include:
- Sandy Jen Meebo
- Akash Garg hi5 Networks
- Jeremiah Robison: Slide
- Jonathan Heiliger Facebook
- James Barrese eBay
SJ: 99% architecture
JH: Product is what drives architecture. We have more than 10,000 servers. For chat, they built a separate network. www.facebook.com/eblog.
JR: The biggest consideration is how their servers work with Facebook.
When's it broken? When did you know your first architecture was broken?
AG: First million users. Then they started focusing on caching and sharding.
JB: eBay had a few catastrophic issues near 2000. People were very forgiving of availability issues. They give refunds when there is downtime.
JR: They moved a lot of their technology to EDGE.
SJ: Since Meebo is just one page, javascript delivery is a major issue for them. They are not generating pages. Dynamic loading and background computation is really important.
RP: Application and infrastructure is going to break. If you look hard enough you can find where are the scalability issues.
JR: They are very metric driven. It's not often they see outages. They have number of Facebook's ops folks on their IM lists and they talk continously.
JH: We work through problems together.
JH: They have had to turn off some applications because other applications were being affected.
JB: At eBay they have created a central application login system. They can flag and identify problems really quickly. If you don't have it, you're shooting in the dark.
Rolling your own stuff? Off-the-shelf vs. custom:
Did you roll your own? Do you regret it?
SJ: For cash restraint startup, off-the-shelf can work. But for scale, you'd want to build yourself. Open Source is awesome. No one can scale your system as well as you can. Off-the-Shelf can be bulky. You have to get your hands dirty.
JR: We built our own caching backend. Invest time in core stuff, anything that's not core, don't focus there.
What also needs to scale as you grow? What non-technology things you had to scale?
JB: Need to scale out your business as well as technology.
AG: Building anti-spam features into the product that are scalable.
JH: Make community part of the process in translations as you grow.
JR; They introduced user moderation for photos. Hard to find what's porn and what's not. It's about a dozen people looking at photos full-time to hunt down porn.
How should we handle the fallout? If you were Twitter what would you have done last month?
JB: You have to be transparent. Tell them what's going on. Setup message boards for communication. You've got to communicate.
AG: Setting realistic timelines is very important
JH: We do it often. We roll in small chunk and if things don't look right, we roll back.
JB: You cannot operate a large system without the ability to turn things on and off.
JR: If you have an aggressive competitor, you don't have the luxury of downtime.
RP: You can't roll out something that can't be rolled back.
Labels: ebay, Facebook, hi5, meebo, scalability, slide, structure08, yahoo
posted by Frank at 1:36 PM
0 Comments:
Post a Comment
<< Home