Boston DevOps Observability Meetup and Open Spaces Recap
CHAOSSEARCH had the pleasure of hosting last night’s Boston DevOps meetup. Every month the local Boston DevOps community gets together for a night of networking and presentations. For this event, the organizers took a slightly different turn and set up the event for a series of "open space" style discussions. Laura Stone, one of the Boston DevOps organizers, kicked off the event by having everyone go to the whiteboard and write down the different topics they are most interested in having a discussion about.
If you have been to a DevOpsDays event, you will be familiar with the open space format. It’s a way for attendees of the event to create different topics that they want to discuss, and the attendees then vote on which discussions they want to be involved in.
After voting, the groups were split out into a few different rooms. Patrick Flaherty (CHAOSSEARCH Employee) reports on the two spaces he visited:
The first talk I went to was "Opensource Observability Tooling". We dug into some use cases for the TIG stack (Telagraf, Influx, Grafana) for a bit, and then realized half the people in the discussion were still running Nagios and derivatives. It was 2010 all over again — passive service checks, check_mk, despair, pestilence. In the back of my head I got worried about the widening technology gap between first movers and people using already deployed tooling. It feels like Stats/CollectD and Graphite came out a million years ago — I mean TIG is the second gen of that tech, but there are probably still more people using Nagios graphite and its descendants than its replacements. It made me question if we need a "How can I start to move away from Nagios?" (and other questions I'm too afraid to ask), or maybe a "Why I'm not moving away from Nagios (and I don't feel bad about it)" talk.
After a quick regroup to select next topics, I went to the "Have I over-engineered my platform?" space. I suggested the topic based on my experience here at CHAOSSEARCH. We've built our entire operations stack on our own product. It's forced me to re-evaluate all the things I thought a modern IT operation needed. Do you really need Chef if you have cloud-init and AWS Userdata? If everything's in a container and source control, why are you building RPMs? Kubernetes has about a thousand knobs you're probably not going to turn — why are you so obsessed with using it if you don't *need* to turn those knobs yet? Those questions are rhetoric. There's a ton of value in all of those products, but I wanted to see how other people viewed over-engineering. I *adored* the discussion. There were some great points about delivering at a startup vs delivering a solution to a hospital, as well as a debate on what the concept of architecture really is. I don't know that we built a consensus, but the discussion was great. I think I'm still in the headspace of "if you're not feeling some amount of pain a few months after deploying, you may have spent too much time architecting the solution", but I think that's to counter my tendency to over complicate the solution. Good conversation though. Totally worth my time.
It was a fantastic night for the Boston DevOps community. I always enjoy seeing old friends and meeting new folks at events like these. It’s great to learn what people are working on, what kind of challenges they are facing, and hearing from others how they might help solve them. A huge thanks go out to the organizers and all of the attendees who joined us and helped to make this yet another great event.
See you next month!