A Statement by the LISA Steering Committee on behalf of the USENIX Association
Starting in 2018, LISA will run for three days, rather than six.
We heard you! You couldn’t get your boss to agree to let you go for six days, or stepping away from other responsibilities for that long was too hard. It was also a firehose of content, and trying to keep it all in your brain upon returning to work was a real challenge. Could we take LISA and make it into a reasonably sized conference that still had amazing talks and training? Yes, we could, and we have.
When you attend a talk that starts with a Google engineer asking, “What would happen if all of the machines you are running on restarted right now?” you might get really worried. Think about the Google services we use on a daily basis and what would happen if they suddenly stopped working—Google Maps, for example. Hopefully, we’d be able to get home from the office, but if we were travelling or looking for a business location, that would become a disaster. What about Google Search? Would we be able to even do our job if it went down?
What makes a good conference so special? With vast amounts of information available virtually on any topic imaginable at a click’s distance, would it not be more efficient to spend time in comfortable home setting learning new technology?
I’ve taken a lot of classes in my several years attending LISA, and over that time, I’ve gotten to see a lot of different teaching styles and techniques. My least favorite style (and probably yours, too) is a strict lecture, where the instructor occasionally flips through slides, but mostly reads from notes, and has no engagement, no interaction, and no interest in whether the people in attendance are getting anything from the talk.
I write this while looking out over Treasure Island and the beautiful San Francisco Bay that surrounds it. Off in the distance, a veritable armada of ships hauls millions of containers under the Bay Bridge, into and out of the Port of Oakland.
It is not lost on me that I’m watching the physical manifestation of the classes I’ve been going to for the past couple of days: the literal orchestration of containers and pods.
It’s 2017. Containers are “a thing.” For real. A few years ago, we were kind of wondering if they were, or if they were just a passing fad. Those of us who were busy Getting Things Done(™) don’t have time for all of the fly-by-night technologies that show up on HackerNews for a week, only to fall by the wayside. That’s the cheap excuse I’m using to justify my lack of experience with Docker, Kubernetes, and the whole containerization movement that has crept up in the past few years.
I’ve been coming to LISA since 2009, and I’ve always wondered why the official conference opening was on Wednesday, when the party really starts on the Saturday prior. This year’s LISA in San Francisco is no different.
I’m a fan of documentation. I have been, ever since I first inherited an infrastructure and had to try to figure out what the previous admin had done. I try to write decent documentation—documentation that I wish had been was there when I first tried to learn about a particular system. I also find myself doing so much that what I can keep in cache in my brain is limited, and stuff I’ve worked on tends to “page out,” so to speak. Writing good docs is an excellent way to do your future self a favor.
Working in IT operations these days can be challenging as it seems like there’s an ever-increasing curve in terms of the knowledge you need to have. Fortunately, there are tools that help simplify what we need to do. Rather than constantly observe workloads and manually respond by building the services we think we'll need, pretty much all production-ready cloud providers and services offer autoscaling and demand-driven resources. But what are the implications of handing off this decision-making?
The following post has been collaboratively written by the co-chairs for the SREcon17 Americas conference (Liz Fong-Jones and Kurt Andersen) and several of the program committee members (Murali Suriar and Betsy Beyer). It is intended to provide greater insight into the selection process which we used for this conference and may not entirely match the strategies which other conference committees employ.