Monitorama PDX 2018, in Portland, offered an intense, three-day conference program -- by and for monitoring and DevOps practitioners.
You are here
Event Diary: DevOps Days Boston 2018
DevOps Days Boston, held September 24-25, brought together about 500 DevOps engineers and two track/days worth of expert and opinionated speakers. The event was held at Boston's Cyclorama -- a massive Victorian-Industrial brick roundhouse in Boston's quaint and accessible South End (originally built (in 1884) as a steampunk immersive virtual reality venue: used to display a giant, 360-degree cylindrical painting of the Battle of Gettysburg).
Opsview helped sponsor DevOps Days Boston (our US HQ is in nearby Woburn, MA), and Team Opsview had a great time at the show, demoing Opsview Monitor 6.0 EA, handing out the branded purple Opsview swag, and talking shop with engineers in the IT/DevOps/QA/Monitoring trenches. Our thanks and kudos to the organizers, and to the community.
Two tracks meant making some hard choices, so this Event Diary isn't comprehensive -- if you saw an awesome presentation that we missed, please give it a shout-out on the Opsview Slack Channel! Meanwhile, here are some highlights of DevOps Days Boston 2018, from our limited perspective:
Work to eliminate monitoring's noise and growing burden of technical debt: Quintessence Anx (@QuintessenceAnx), Developer Advocate at Logz.io, offered the radical advice of doing a quick post-mortem for every alert triggered. Was it important to alert? How did resolution go? Can we automate this yet? Is this alert permanent (i.e., deeply bound to our architecture or business model) or transitory? Cleaning up the alert cruft ("Sprint Cleaning") helps tune your infastructure and operations, and reduces cognitive and procedural burden on IT staff.
Consider using granular cost as a first-class metric in serverless (and other cloud) environments: Erik Peterson, CEO/Founder at CloudZero, noted that -- especially in public-cloud-hosted serverless computing scenarios, where you pay only for execution time -- low cost is a direct proxy for architectural efficiency and code quality. He suggests monitoring realtime cost -- both of strictly serverless code and of the other, usage-based-billable cloud services that serverless code might harness on the back end. Peterson also dropped the great take-away quote: "Reliability is the trustworthiness of a system's ability to delight the customer."
Abandon staging environments as the shills and delusions that they are: Heidi Waterhouse (@wiredferret), Developer Advocate at LaunchDarkly, made an impassioned and articulate plea for DevOps to stop kidding itself that testing in staging is meaningful, and instead, to learn (very carefully) to test in production. Her take-away quote (one of many great insights): "Monoliths are out. Mono-repos are in."
Avoid simplistic "up and running" communications: Sarah Zelechoski (@szelechoski), VP Engineering at ReactiveOps, talked about how engineers and others who report on tech projects or share content producers persistently degrade their own perceived value -- often in an attempt to obscure the messy details and intrinsic difficulty of what they do. She advises the community to stop saying hard things are simple, even if the goal is to reduce fear in readers.
Realize that "sustaining engineering" is a real thing, distinct from DevOps, and support it: Timothy Bonci, Lead Operations Engineer at Cimpress, offered some important best-practice around "sustaining engineering." He noted that DevOps is (in part) about radical ownership: breaking down silos, and giving developers control of deployment, operations, and delivering business value directly to customers. That's a great model for effective ops, but it's incomplete. If you or other key DevOps folks leave the company, or if structural or mission changes occur, eventually, the systems you build will need to be managed by others. This means creating a handoff and training process for sustaining engineering, and executing consistently against it, despite the pull of other priorities.
DevOps Days Boston will be posting video soon. Check back here for links.
More like this
DevOps is about accelerating delivery of new products and services at scale, reliably and affordably. Doing this requires automation.
So, last Friday night, I decided to turn my infrastructure into code by learning Ansible, and capture the entire demo configuration.