I recently attended DevOpsDays Toronto 2017, my first proper DevOpsDaysTO event. I had the pleasure of attending and being able to immerse myself in this openly collaborative and supportive culture of IT professionals. The variety of considerations expressed for delivering software features in a rapidly, frequently and reliable release focused manner was really intriguing….but not without its own complexities. These conferences are also like a true support group for those pushing the envelope broad technology expertise and moving at speeds that put highways to shame. Or simply a support group for those in need 🙂 …Let’s take a look….
Okay…there are NO answers here, at least not coming from me. I’ve had enough experience in the technology trenches to understand the different pain points technology professionals endure, but also had enough successes to understand why it can be such a thrilling field to work in, especially these days. Here, I’ll share some highlights from the Toronto DevOpsDays event. My comments won’t be comprehensive but I’ll present some highlights that stood out for me. If you visit the DevOpsDaysTO twitter account, they’ve posted some Youtube videos of certain presentations from this 2017 event. I highly recommend reviewing those YouTube videos. It’s always useful to help learn from other people’s pain…..so we can avoid repeating it ourselves. In the context of this event, its all about learning from each other.
Dev & Ops Alignment
Okay…I suppose I always “assumed” DevOps meant a complete integration between Developers and Operations in that there was one team doing both. I’ve learned its not necessarily cut and dry like that. I guess I assumed as I’ve worked in that dual role for a long time as a DBA. Being on-call for 4 years straight can blur these perspectives a bit.
There were two presenters from Capitol One (which redefines itself as a technology company) who work in the DevOps technology team. The two of them spoke about how the DevOps team is structured, such that Developers are co-located in the same office area as the Operations team. From an operations perspective, they have a rotation amongst themselves. Part of the team fields “ad-hoc”questions/etc from the Devs. This is called the “Foreground” (fg) team. The other members of operations can then engage in “Deep Work” (a whole topic in itself) and are part of the “Background” (bg) team. This team works on project tasks focused to get deliverables done! This team design helps prevent what they call “Interruptitis”….where essentially nothing gets done. They also had cool little lights on the tops of their computer screens to identify to the Developers who the Foreground member of the Operations team was on that day…or at that moment.
Dev & Ops Mutual Support
One of the first speakers Bridget Kromhout had a great talk at the beginning of the event. She focused on how each of these Dev and Ops teams can help enable the other to increase their teams overall success. She had mentioned the idea that Operations could focus on automating much of their management, then document and share it with the Dev team. In this way, the documentation enables the Dev team members to really understand the operations perspective of the environment they deploy code into. It gives the Dev team insight that may help inform themselves how they build their apps to coordinate.
The advise for the Dev teams to design for observability, implement debug-ability and describe the reality for the Ops team to be supported in their role and make application more successful. Observability and debugging is about monitoring and being able to answer questions that Ops (or anyone) didn’t know to ask. Particularly useful is for Devs to guide on specialized health checks. “Reality” refers to sharing/documenting known weaknesses in the application to help out operations in advance of potentially mysterious on-call scenarios.
Feature Release and Feedback
The area around “successful feature release” as a focus seems to me to be what DevOps is really all about. In the talk from Andreas Grabner from Dynatrace, he talked about how they moved from “waterfall” development that took 6 months to release a large set of features to a DevOps development approach that allows them to release code from start to finish in 1-hour. Having a DevOps development pipeline that can provide automated testing, both unit-based and full-build performance testing for all changes as part of it to be able to assure success. A core idea being that anything worth committing should go to production.
Product release cycle from 6-months down to 1-hour!
Andreas had one of the most fantastic analogies in this fast release cycle and the feedback that comes with it. He used his girlfriend posting photos on Facebook and getting “likes” as her own immediate feedback system as a reflection of what DevOps provides for his team on a 1-hour release cycle capability. What per-se did he use to demonstrate their old “waterfall” approach….Film-based cameras and the long period of time it used to take to fill up a roll of film before bothering to go and get it developed. If your out on a vacation and need to wait until you return home, you’ll never have time to review your film to see how the photos turn out…if some really interesting shots didn’t turn out…then its too late to go back. It’s now a missed opportunity. That is how “waterfall” based development will impact business in our modern world where by the time a feature is released, the market you designed it for has already moved on.
The land of Containerization
If you ever needed incentive and an equal amount of fear and bravery to take your company into the container-based development, then ensure you attend any DevOpsDays event or otherwise find an equivalent support group. Why? Because all of this high-speed feature-release customer-oriented and quality driven development seems to focus around the use of containers. In my next post, I’ll feature a number of blogs from companies or developers who managed to take the time to tell their own stories. Until then…I hope you enjoyed.