This year is our
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
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
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
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:
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
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
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;
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.