Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

Velocity 2011

This year is our fourth Velocity conference on web performance and operations. What began with a meeting between Steve Souders, Jesse Robbins, Tim O'Reilly, and others at OSCON 2007, has become a thriving community. We're expecting this year to sell out again, even with significantly more space than we had last year. It will be the largest Velocity yet.

According to Tim O'Reilly, the motivation behind the 2007 meeting was a call to "gather the tribe" of people who cared about web performance and create a new conference. The audience for this conference, in 2007 as it is today, is made up of the people who keep the web running, the people behind the biggest websites in the world. The participants in that first meeting reflected a change that was underway in the relationship between web development and web operations. Even saying that there was a single "tribe" to be gathered was important. Participants in the 2007 meeting had already realized that there was a single web performance community, uniting both developers and operations staff. But in many organizations, web performance and web operations were disciplines that were poorly defined, poorly documented, and insufficiently recognized. In some organizations, then and now, people involved with web operations and web development were hardly even aware of each other.

The participants in that 2007 meeting came from organizations that were in the process of finding common ground between developers and operations, of making the cultural changes that allowed them to work together productively, and wanted to share those insights with the rest of the Web community. Both developers and operations staff are trying to solve the same problems. Customers aren't happy if the site isn't up; customers aren't happy if the site is slow and unresponsive; new features don't do anyone any good if they can't be deployed in a production environment. Developers and operations staff have no trouble agreeing on these unifying principles. Having agreed on these unifying principles, developers and operations staff quickly discover that they speak the same language: they both know the code intimately, understand performance issues, and understand tweaking servers and hand-tuning code to optimize performance. And when we held the first Velocity conference in 2008, it was indeed a "meeting of the tribe" — two groups that found they were really allies.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

Agility, infrastructure, and code

Velocity became the ground for discussing and testing a number of important new ideas. Perhaps one of the most important was the idea of agile operations. Agile development methodologies had taken the software world by storm: instead of long, waterfall-driven release cycles, software developers started by building a minimal product, then iterating quickly to add features, fix bugs, and refactor the design. Continuous integration soon became part of the agile world, with frequent builds and testing of the entire software package. This practice couldn't help but affect operations, and (with a certain amount of trepidation), forward-thinking companies like Flickr started deploying many times a day. Each deployment represented a small change: part of a new feature, a bug fix, whatever. This was revolutionary. Frequent deployment meant that bugs surfaced before the developers had moved on to their next project, and they were still available to fix problems.

At the same time, tools for managing large networks were improving. They had to improve; we were long past the stage where networks of computers could be set up and managed by hand, on a one-at-a-time basis. Better tools were particularly important in a server environment, where software installation and configuration were increasingly complex, and web companies had long since moved from individual servers to server farms. Cfengine, the first tool for automating software installation and configuration, started a revolution in the mid-'90s, which is carried on by Puppet and Chef. Along with better tools came a change in the nature of the job. Rather than mumbling individual incantations, combined with some ad-hoc scripting, system administration became software development, and infrastructure became code. If there was any doubt about this shift, Amazon Web Services put an end to it. You can't administer servers from the console when you don't even know where the servers are, and you're starting them and shutting them down by the dozens, if not thousands.

Optimizing the client side

One of the discoveries that led to Velocity comes from Steve Souders' "High Performance Web Sites." We've long known that performance was important, but for most of the history of the Web, we thought the answer to performance problems lay in the infrastructure: make the servers faster, get more out of the databases, etc. These are certainly important, but Steve showed convincingly that the biggest contribution to slow web pages is stuff that happens after the browser gets the response. Optimizing what you send to the browser is key, and tuning the servers secondary for creating a faster user experience. Hence a hallmark of Velocity is extended discussions of client-side performance optimization: compression, breaking JavaScript up into small, digestible chunks that can be loaded as required, optimizing the use of CSS, and so on. Another hallmark of Velocity is the presence of lead developers from all the major browser vendors, ready to talk about standards and making it easier for developers to optimize their code so that it works across all browsers.

One talk in particular crystallized just how important performance is: In their 2009 presentation, "Performance Related Changes and their User Impact," Eric Schurman of Microsoft's Bing and Jake Brutlag of Google showed that imperceptibly small increases in response time cause users to move away from your site and to another site. If response time is more than a second, you're losing a significant portion of your traffic. Here was proof that even milliseconds counted and users clearly respond to degradation that they can't detect.

But perhaps the companies the speakers represented were even more important than their results: developers from Microsoft and Google were talking, together, about the importance of performance to the future of the Web. As important as the results were, getting competitors like Microsoft and Google on the same stage to talk about web performance was a tremendous validation of Velocity's core premise that performance is central to taking the web into the next decade.

Mobile, HTML5, Node, and what lies ahead

We're now in the next decade, and mobile has become part of the discussion in ways we could only begin to anticipate a few years ago. Web performance for mobile devices is not the same as desktop web performance; and it's becoming ever more important. Last year, we heard that users expect mobile websites to be as responsive as desktop sites. But are the same techniques effective for optimizing mobile performance? We're in the process of finding out. It looks like client-side optimization is even more important in the mobile world than for the desktop/laptop web.

With those broader themes in mind, what's Velocity about this year? We have plenty of what you've come to expect: lots of material on the culture and integration of development and operations teams, plenty of sessions on measuring performance, plenty of ways to optimize your HTML, CSS, and JavaScript. There's a new track specifically on mobile performance, and a new track specifically for products and services, where vendors can showcase their offerings.

Here are some of the topics that we'll explore at Velocity 2011:

  • HTML5 is a lot more than a bunch of new tags; it's a major change in how we write and deliver web applications. It represents a significant change in the balance of power between the client-side and the server-side, and promises to have a huge impact on web optimization.

  • Node.js is a new high performance
    server platform; you
    couldn't go very far at Velocity 2010 without hearing someone talk
    about it in the hall. Its event-driven architecture is particularly
    suited for high performance, low-latency web sites. Sites based wholly
    or partially on Node are showing up everywhere, and forcing us to
    rethink the design of web applications.

  • Since mobile is increasing in importance, we've given it a
    whole conference track, covering mobile performance measurement and
    optimization, realtime analytics, concrete performance tips, and more.


  • In the past, we've frequently talked about building systems that are
    robust in the face of various kinds of damage; we've got more lined up
    on resilience engineering and reliability.


  • We're finally out of IPv4 address space, and the move to IPv6 has
    definite implications for operations and performance optimization.
    While we only have one IPv6 talk in this year's program, we can
    expect to see more in the future.



This year, we're expecting our largest crowd ever. It's going to be
an exciting show, with people like

Nicole Sullivan
looking at what's really important in HTML5 and CSS3;

Steve Souders
introducing this year's crop of performance tools;

Sarah Novotny
discussing best strategies for effective web caching;

John Allspaw
on conducting post-mortems effectively;
and
much more.

Finally, Velocity doesn't end on June 16. We're planning Velocity conferences to take place in Europe and China later in 2011 — details are coming soon and we hope to see you there. And if you can't make it to either of those locations, we'll see you again in June, 2012.



Related:


Don't be the product, buy the product!

Schweinderl