At the end of April I made my way up to Seattle for DevOpsDays Seattle. It occurred to me upon arrival that while I’ve spent the past several years very close to DevOps circles and methodologies, this was my very first DevOpsDays! The crew organizing the Seattle event was definitely a great introduction, in spite of the gender ratio that always plagues these events attendee-wise I felt safe and welcome at this event. They also had a diverse selection of speakers without sacrificing quality (Something I tell people all the time is totally doable! Here’s the proof!).
Bonus: My walk to the event both days gave me a great view of the Space Needle. So pretty.
The two day event had the format of a single track all morning, a talk just after lunch, and then Ignite-style talks (5 minutes, 20 auto-advancing slides). From there attendees had the option of one last talk in the main auditorium, or to join fellow attendees in a more interactive series of open spaces (unconference). Put together by the attendees, unconference topics were whatever people had proposed earlier in the day and wanted to have round table discussions about with their peers at the conference. The open spaces then continued through the end of the day.
I won’t give an overview of all the talks, but I do want to highlight a handful that stood out for me.
The first day we heard a talk from Suzie Prince titled “Continuous Integration: A Bittersweet Love Story”. I wasn’t sure what to expect from this talk, but I was eager to hear from her since CI is so near and dear to my heart. She began by discussing two of the most important things about CI: Collaborating on master/trunk (rather than your own branches) and committing code daily (or more!). Coming from the OpenStack world, this wasn’t news to me, yeah, this is CI how we did it! Great!
The big reveal for this talk was that’s not how everyone does it. In fact, based on some research she did last year, most people do CI wrong and suffer in ways they really shouldn’t if they were doing CI properly. The research asked a variety of questions about what people knew about CI and what the pain points are. It was quite astonishing for me to hear some of the results, it sounds like we’ve done a poor job as a community of explaining CI and making sure organizations are implementing it correctly. A blog post about their findings is up here: No One Agrees How to Define CI or CD.
Full video of the talk is available on YouTube, here. I recommend watching it if you’re interested in this topic, her presentation and slides do more justice to the topic than my summary!
My talk was that afternoon. It was my first time giving a Day 2 Ops talk, and I had spent a lot of time while preparing the talk to communicate the right message without being patronizing. Essentially, things get complicated when looking at cloud-native systems where you have an underlying platform (whether it be bare metal or a cloud provider), then whatever you’re running your application in (container?) and then your app itself. You need to be able to get metrics about what all the layers are doing, maintain some kind of monitoring system that understands the setup and can dynamically adjust as your system grows, have a way to access logs and troubleshoot problems down all the layers and have a system for maintaining everything. Plus, you want to give the appropriate access to everyone in your organization based on what they are working on, developers want access to their applications, operators of the physical cluster may need access to the infrastructure but need to know less about the applications.
I had some good talks with folks after this talk, several admitted their organizations accepted the turn-key offering of easily running apps and really got into trouble when things went sideways and they had to debug the actual issue down the stack. No one cares about metrics, logging and troubleshooting until something goes wrong, but more care should be put here in the planning stages, since it does take time and attention, and ultimately it’s all pretty important.
Slides from my talk are up here (PDF) and the video is on YouTube here. I’d like to give this talk again, based on feedback from folks who have seen it, I could use a more formal checklist of things to consider when building a cloud-native system. Plus, I’ll add some talk about integration with existing platforms, we all run complicated things with many moving pieces, no one wants yet-another-tech-specific-dashboard or non-standard tooling that only works when it’s assumed it’s working in isolation.
The second day opened with a talk from Jez Humble on “Continuous Delivery Sounds Great But It Won’t Work Here”. This was a really fun and inspiring talk (though I had heard some of the examples before). He began by going over the top reasons people claim they can’t do CD in their org:
- We’re regulated
- We’re not building website
- Too much legacy
- Our people are too stupid
His general premise was that these “excuses” for not doing CD in an organization are surmountable with the right culture, and walked the audience through examples that proved this. These included: checks for compliance that can be put into your CI pipeline, the fact that HP’s printer division wasn’t building websites either, but saw significant improvements once adopting CD methodologies, the idea that legacy applications should never hold the rest of the org back and new things should be built to meet new goals (like CD!) and a car production line example that showed how the same employees did higher quality work once their culture changed.
Super interesting stuff. Video of his talk is available here.
I also want to highlight a talk by Jeffery Smith on “How to Elevate Your Contributions as an Ops Engineer”. He very correctly pointed out that IT teams are often very insular and so focused on the tech of the infrastructure, that they don’t poke their heads out to really understand the business, or the specific value they’re providing. He walked through several examples of engineers in a company taking a broader view of the company and what it needed, and being able to make direct impact on the bottom line since they understood where things were going. Plus, this helps you too. He suggested that specific technologies come and go, they get automated or commoditized, and suddenly knowing how to configure something is not as valuable. You bring value by understanding the industry and helping people outside your specific sphere get their work done too, and proving that up the chain. He’s a great speaker so I recommend watching the talk for yourself! It’s up here
Then there were the Ignite-like talks! There were a bunch of great ones, but two really stood out for me, and since they’re only 5 minutes each and really fun, you should just go watch them:
- Why So Angry, Soo? Or How I Learned To Stop Worrying And Love Public Speaking by Soo Choi
- CoffeeOps by Jason Yee
Finally, huge thanks to the organizers of DevOpsDays Seattle. They were really friendly, and I got a kick out of my name being on the back of the conference t-shirts. Usually that’s where conferences put the sponsors! But sponsors get their names on plenty of things, this was a great way to make the speakers feel like rock stars :)
All the videos are up on a YouTube playlist here and more photos from DevOps Day Seattle 2017 that I took are here: https://www.flickr.com/photos/pleia2/albums/72157680011962503
I’m now about to get on a plane to attend and speak at my second DevOpsDays. This time I’m headed off to Salt Lake City! Here I’ll be speaking on “The Open Sourcing of Infrastructure” on Wednesday morning.