This might be the first BbWorld/DevCon that I’m bummed to be back. The energy, excitement and awesomeness of DevCon was amazing. I’ve been to 10 DevCons and never felt this way at or after the conference. We had a solid audience of about 350 developers, administrators and of course those who straddle the lines of both with the moniker “DevOps”.
I didn’t share the same enthusiasm with the big conference. It has really nothing to do with the size or even topics of BbWorld, but rather that our DevCon was simply two days of fun and networking. It was also the most I’ve ever worked at DevCon. The team of me, Mike McGarr, David Ashman and Chris Borales have put months planning, rehearsing, changing ideas, etc…Given the volume of changes we made even five minutes up to the show, it’s amazing we didn’t fall on our faces.
I could spend this entire blog talking about how great DevCon was and how sad I am to be back here, but that would be a total waste of a blog. So rather, let me capture some of the key themes and topics from the conference. The list is long, but I’ll focus this blog on five key topics/takeaways:
- DevOps: Culture of shared ownership and accountability
- Tools do matter: Get the right tools in everyone’s hands
- Not enough folks are monitoring with passion
- Where are the open source B2s? Has anyone heard of Github?
- The Developer VM is huge
DevOps: Culture of Shared Ownership and Accountability
The term DevOps is not new to me. I’ve been hearing this term for years as a member of the Velocity community. I am pretty sure that half of the folks in the audience had never heard the term DevOps before. The other half may have heard it, but never put too much context around the term. Remember that half the audience at DevCon tends to be developers and half are administrators. A lot of folks where both hats in the audience, but never put too much thought into a new classification of role.
What were we trying to accomplish by spreading more gospel about DevOps? I’ll tell my perspective and then look for Mike to maybe post his message on his blog “Early and Often“. First, I wanted to blur the lines between developer and administrator. It’s better to go to battle each day as a team of one rather than two individuals, who only think about their individuals roles and responsibilities. I want my developers to think about what their code is doing at 2am in the morning. I want my administrators to understand the code so they can measure, monitor and log the crap out of the code to give good feedback to the developers.
Do I really care about the blame game that happens when disasters happen? Nope…it’s not about blaming. It’s about working together to solve the problem as fast as possible, learn from the mistakes (because there are always human mistakes) and then make the developer/admin alliance even stronger so that disasters simply become small nuances.
I think a whole bunch of us talked about so many of the DevOps mantras that I can easily say the DevOps message was more than just a token statement about take a developer with a white shirt and an admin with a black shirt, stick them in a room for a hug-a-thon and watch them come out with two grey shirts. Mike covered C.A.M.S (Culture, Automation, Monitoring and Sharing). Gene Kim, author of the Phoenix Project covered the “Three Ways” and I brought up the rear with turning on the lights with efficient logging tools.
As I mentioned, we only gave the audience a taste. Now we need to take the message further with more focused sessions that mix culture, infrastructure as code, monitoring and logging, collaborative development, sharing of data, etc…
There was a great presentation worth checking out called “There’s No Talent Shortage” from a recent DevOps Days in Australia.
Tools Do Matter: Get the Right Tools in Everyone’s Hands
So a couple of weeks ago I went to my fifth Velocity conference. It was good…not the best though. Everyone says the best tracks are the hallway tracks, which to some degree I believe as well. I like to go to sessions. I expect to be entertained and learn something from my peers and our industry’s experts. This year I didn’t learn as much as year’s past. Well maybe this year I learned that a lot of tools meet their fate of non-existence in the Performance community. The tools everyone were talking about were WebPageTest and mPulse (from SOASTA). The tools no one was talking about were YSlow (to a smaller degree), PageSpeed, Fiddler, TrueSight or any tool that attempted to “fix” the so-called Web Performance rules.
On the infrastructure side, we continue to see better tooling in the spaces of both monitoring and logging. Etsy’s presentation about 250k metrics still makes me shake my head. I think they are making matters way too complicated. It’s not like they are launching the space shuttle, but rather are providing store fronts for artists and craftsmen. Heck, maybe I want this level of granular monitoring accessible at any time for forensic recall…who knows.
I personally did a session on Logstash, which could have gone a lot better. Though, I got my key takeaway out to the audience. I wanted them to take accountability for studying, measuring and automating their logs. I wanted our audience to know of tools that were out there to aggregate and visualize their logs. If I’m lucky we can get the community to contribute to a LogStash initiative. We have to be the lightening in the bottle to spark the initiative. We need to post our work to the Blackboard Github page and get the community to either contribute or fork. Either way we are accomplishing our goals around log centralization, mining and awareness.
Not Enough Folks are Monitoring with Passion
We talk a lot about monitoring at DevCon every year. I don’t think the audience is doing more than the minimum. I don’t think us as presenters are making monitoring more tangible. It’s one thing to reference a tool, but it’s another thing to put the tool in action. We have done some of that with Zabbix, but not enough. We need the community to start the conference call. It’s almost like we need a monitoring summit to talk about what we need to monitor, how we monitor it, what frequency we monitor, how we visualize, what we store, etc…etc…
How cool would that be to do a monitoring summit inside of DevCon? I kind of just thought of that as I wrote it by the way. I’ll take credit for that one, but really it’s this blog entry that stir up the creative juices. I’ll write another blog about the “Monitoring Summit” with CAPs meaning it could and should be a real thing or idea.
I personally love monitoring. Heck, McGarr has a laptop sticker that says “I Love Monitoring” though I just believe he likes the idea of monitoring and what he’s really in love with is automating monitoring 😉 I’m the data geek on the tea and make is the automation geek. Expect a rebuttal blog from McGarr about he loves monitoring and that I just love myself.
This year there was a little bit of a drop-off about monitoring. There was a session about the Admin Console and then a client presentation by Nck McClure about System Administrator basics which touched upon monitoring. We need more sessions if not a full fledge track on monitoring (well, it can continue to be with the Performance and Security track), or at a minimum we should have had 3 or 4 in-depth sessions on monitoring approaches, tools and solutions.
Where are the Open Source B2s? Has Anyone Heard of Github?
Every year I leave DevCon asking why don’t more developers in our community put their stuff out on Github for others to contribute to or fork. Why aren’t we collaboratively building more B2’s? This year I’m going to ask it differently…Why aren’t we doing that first ourselves? I bet if we started putting B2’s out there and of course marketed the heck out of them, several developers would download, fork or contribute to the initiative. Isn’t that what we want? I know that’s something I want. Just need to convince others that it’s ok.
The Developer VM is Huge
I knew before I even took off for Vegas that the Developer VM that our DevOps team built was going to be a huge hit. Not because it’s running on Centos…not because it has Postgres…It’s mainly because we provided a fast, efficient and simple way to get developing. Now that I think about it, a lot of Bb’ers may want to make use of this as well that are outside of development. It’s a game changer in my mind. I had demos up and running within minutes.