Taking a look at the current issues affecting the Web operations and performance space.
Editor’s note: The European edition of our Velocity conference wrapped up a few weeks ago, and now that the jet lag has passed I’ve had a chance to reflect on the talks and excellent hallway conversations I had throughout. And while I thoroughly enjoyed all the sessions I introduced, one of the downsides to being a chair is that I can’t attend all the other sessions at the same time. As such, I always look around for excellent dissections of the conference from other people; this summary by Peter Arijs from CoScale closely reflects some of the themes I saw, including a few of the standout talks.
November in Barcelona was full of action for web and big data practitioners, with the Velocity and Strata-Hadoop conferences and side events such as WebPerfDays and Papis.io. As a startup in the web application monitoring and analytics space, it was the perfect time to get a pulse on the state of the art, and talk to some of our clients and prospects. Below is a summary of personal take-away points from selected Velocity sessions and personal interactions.
Memory Management, Stream Processing, Robot's Google, and Emotive Words
- tigon — an open-source, real-time, low-latency, high-throughput stream processing framework.
- Robo Brain — machine knowledge of the real world for robots. (via MIT Technology Review)
- The Structure and Interpretation of the Computer Science Curriculum — convincing argument for teaching intro to programming with Scheme, but not using the classic text SICP.
Update: the original fourth link to Depeche Mood led only to a README on GitHub; we’ve replaced it with a new link.
Tools to develop massively distributed applications.
Editor’s Note: At the Velocity Conference in Barcelona we launched “A Field Guide to the Distributed Development Stack.” Early response has been encouraging, with reactions ranging from “If I only had this two years ago” to “I want to give a copy of this to everyone on my team.” Below, Andrew Odewahn explains how the Guide came to be and where it goes from here.
As we developed Atlas, O’Reilly’s next-generation publishing tool, it seemed like every day we were finding interesting new tools in the DevOps space, so I started a “Sticky” for the most interesting-looking tools to explore.
At first, this worked fine. I was content to simply keep a list, where my only ordering criteria was “Huh, that looks cool. Someday when I have time, I’ll take a look at that,” in the same way you might buy an exercise DVD and then only occasionally pull it out and think “Huh, someday I’ll get to that.” But, as anyone who has watched DevOps for any length of time can tell you, it’s a space bursting with interesting and exciting new tools, so my list and guilt quickly got out of hand.
An argument against the Five Whys and an alternative approach you can apply.
Before I begin this post, let me say that this is intended to be a critique of the Five Whys method, not a criticism of the people who are in favor of using it. This critique I present is hardly original; most of this post is inspired by Todd Conklin, Sidney Dekker, and Nancy Leveson.
The concept of post-hoc explanation (or “postmortems” as they’re commonly known) is, at this point, taken hold in the web engineering and operations domain. I’d love to think that the concepts that we’ve taken from the new view on “human error” are becoming more widely known and that people are looking to explore their own narratives through those lenses.
I think that this is good, because my intent has always been (might always be) to help translate concepts from one domain to another. In order to do this effectively, we need to know also what to discard (or at least inspect critically) from those other domains.
The Five Whys is such an approach that I think we should discard.
A humanist approach to automation.
Editor’s note: At some point, we’ve all read the accounts in newspapers or on blogs that “human error” was responsible for a Twitter outage, or worse, a horrible accident. Automation is often hailed as the heroic answer, poised to eliminate the specter of human error. This guest post from Steven Shorrock, who will be delivering a keynote speech at Velocity in Barcelona, exposes human error as dangerous shorthand. The more nuanced way through involves systems thinking, marrying the complex fabric of humans and the machines we work with every day.
In Kurt Vonnegut’s dystopian novel ‘Player Piano’, automation has replaced most human labour. Anything that can be automated, is automated. Ordinary people have been robbed of their work, and with it purpose, meaning and satisfaction, leaving the managers, scientists and engineers to run the show. Dr Paul Proteus is a top manager-engineer at the head of the Ilium Works. But Proteus, aware of the unfairness of the situation for the people on the other side of the river, becomes disillusioned with society and has a moral awakening. In the penultimate chapter, Paul and his best friend Finnerty, a brilliant young engineer turned rogue-rebel, reminisce sardonically: “If only it weren’t for the people, the goddamned people,” said Finnerty, “always getting tangled up in the machinery. If it weren’t for them, earth would be an engineer’s paradise.”