Sessions at Surge 2010 about Scaling on Thursday 30th September

Building scalable architecture is not rocket science — it's computer science. The tome "Design Patterns" shows us two things: (1) that there are many applicable approaches to solving common programming problems and (2) people misapply them all the time. In this talk, we'll take a whirlwind tour though different patterns for scalable architecture design and focus on evaluating if each is the right tool for the job. Topics include load balancing, networking, caching, operations management, code deployment, storage, service decoupling and data management (the RDBMS vs. noSQL argument).

Web Services are often conflated with Service Oriented Architecture (SOA). This talk is about REST, JSON, HTTP. And not about SOAP, WSDL or even XML. It will describe the long path from a monolithic two-and-a-half-tier LAMP architecture to decoupled webservice oriented approach.

About 70 developers, product-owner and scrum master in 8 Scrum teams had to be coordinated on tasks dealing with daily business, new product features and the "open heart surgery" to transform Germany's biggest website without downtime to this new model.

Nowadays Federated Autonomous Services (FAS) have their own dedicated developer and operations team, their own release cycle. They still serve over 18 Billion dynamic HTTP requests a month. They expose their interface via HTTP and have a standardized way to deal with Access Control, Service Configuration and Event Handling. They have no real-time dependencies to any other service, except for infrastructural ones.

The talk will show how Open Source Software like Nginx, HAProxy, Tornado, memcached or jetty power the backbone of the VZ infrastructure. It will also show how one can reduce complexity and cost by moving away from centralized, expensive HA components (aka NetApp, HDS) to commodity hardware.

The most common mistakes are easy to avoid however many startups continue to fall prey, with the impact including large re-design costs, delays in new feature releases, lower staff productivity and less then ideal ROI. All growing and successful sites need to achieve higher Availability, seamless Scalability and proven Resilience. Know the right MySQL environment to provide a suitable architecture and application design to support these essential needs.

Some details of the presentation would include:

• The different types of accessible data (e.g. R/W, R, none)
• What limits MySQL availability (e.g software upgrades, blocking statements, locking etc)
• The three components of scalability - Read Scalability/Write Scalability/Caching
• Design practices for increasing scalability and not physical resources
• Disaster is inevitable. Having a tested and functional failover strategy
• When other products are better (e.g. Static files, Session management via Key/Value store)
• What a lack of accurate monitoring causes
• What a lack of breakability testing causes
• What does "No Downtime" mean to your organization
• Implementing a successful "failed whale" approach with pre-emptive analysis
• Identifying when MySQL is not your bottleneck

We often have clients approach us looking for help in scaling their systems, and all too often their long term vision is a mixed reality based on the approaches read about on popular blogs trying to solve very different problems. Hey, scaling your database can be difficult enough by itself, you don't want to get tripped up by not understanding where you're going. In Database Scalability Patterns we will attempt to distill all of the information/hype/discussions around scaling databases, and break down the common patterns we've seen dealing with scaling databases.

"Buzzwords" we'll cover (and hopefully debuzz) include:

• Vertical Scaling
• Horizontal Partitioning
• Horizontal Scaling
• Read Slaves
• Multi-Master
• Monitoring
• Vertical Partitioning
• Federated Data Storage

More important than just describing what these things are (although that's a good first step), we'll also discuss along the way different points in the life-cycle of your database when you need to be thinking about the different options in front of you. We'll factor in the types of application that your working on (think OLTP vs OLAP, or Social Networking vs. Corporate Application), the environment you'll be working on (Scaling "in the cloud" is very different from DIY in the datacenter), and we will talk about the types of tools you'll need to accomplish these goals (All replication systems are not the same, and some won't help at all).

Scaling LinkedIn to be the largest professional network in the world. Have you ever wondered what architectures the site like LinkedIn may have used and what insights teams have learned while growing the system from serving just a handful to close to a hundred million of users? Ruslan will share his experiences after facing many complex challenges through the years of hyper growth and will answer questions about LinkedIn architecture and the way LinkedIn engineers approach building innovative products of the future with scale.

Facebook is now the #2 global website, responsible for billions of photos, conversations, and interactions between people all around the world running on top of tens of thousands of servers spread across multiple geographically-separated datacenters. When problems arise in the infrastructure behind the scenes it directly impacts the ability of people to connect and share with those they care about around the World.

Facebook's Technical Operations team has to balance this need for constant availability with a fast-moving and experimental engineering culture. We release code every day. Additionally, we are supporting exponential user growth while still managing an exceptionally high radio of users per employee within engineering and operations.

This talk will go into how Facebook is "run" day-to-day with particular focus on actual tools in use (configuration management systems, monitoring, automation, etc), how we detect anomalies and respond to them, and the processes we use internally for rapidly pushing out changes while still keeping a handle on site stability.

Wikia hosts around a 100 000 wikis using the open source Mediawiki software. In this talk I'll take a tour through the process of taking a legacy source code and turning it into a globally distributed system. Wikia runs across 6 datacenters in US and Europe, with half of them being CDN nodes and half being full datacenters. Traffic is directed to closest node depending on traffic situation. In a case of degradation the system turns into a read-only mode. The multiple level of redundancy and distribution contributed to a 99.995% availability to end users.

Specific issues involve:

• Varnish - caching and loadbalancing
• Memcache - implementing cache coherency across distributed datacenters
• Session management -- using Riak to transparently failing over
• Mysql replication
• Filesystem
• Monitoring
• Small footprint -- high throughput using SSD based machines
• Mediawiki
• Dealing with loadspikes like Lost Season finale.