Velocity 2011

A tribe of web performance and operations pros is pushing the web forward.

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:

tags: , , , , ,