I am a full-stack web developer. It's the place I feel most comfortable. I am not a DevOps engineer by any stretch of the imagination, but I am interested in many technologies. In addition, I am fascinated by the progression of technology throughout history. Still, I have very little understanding of DevOps, containers, deployment pipelines, or subjects centered around that space.
So why I found myself attending DevOps days in Austin, Texas, listening to some of the founders of the DevOps movement is strange, to say the least, but that's exactly where I found myself. A web developer aimlessly wandering in a land filled with acronyms, tooling, and buzzwords like Kubernetes, which sound more like a Greek restaurant than a technology, hanging out with DevOps engineers. Out of my area of expertise, out of my comfort zone, and out of my league. At least, that’s what it felt like at first.
For my entire career, I believed the DevOps team were the people you ran to when things went sideways; you approached them cautiously and with your tail between your legs, knowing that your code just broke their magnificent system and took down production. Of course, they were always willing to help, but they were a different breed. If developers are wizards to the average person, to me, these guys are Hogwarts professors— IT geniuses who can take some rough sketch of an infrastructure plan and turn it into executable code that makes my application usable.
Going to DevOps Days in Austin, I fully expected to be the least intelligent person in the room, alienated from the rest of the group due to a lack of understanding. Instead, I found a welcoming community and a group of thoughtful individuals whose sole purpose in life is to share their knowledge and ideas with a group of like-minded peers.
Like most of the tech world, the attendees and speakers alike were all excited about technology and eager to share their latest projects or talk about the most recent technology they found and why it makes everything else obsolete. However, unlike other parts of the tech world I am familiar with, DevOp wasn't as canonized or rigorously laid out from the beginning as I had believed.
I thought I would be attending lectures much like the courses I had taken in school. I expected to learn about technologies and techniques established by subject matter experts for generations. I was prepared to sit through hour-long deep dives into each subject and, occasionally, be allowed to try some methods hands-on and finally understand what went into taking my code from my local environment to production. I've never been more wrong in my life. The experts did give presentations, but not on tools, technologies, or techniques. Instead, they spoke about DevOps' journey, from ideas to current practices and becoming its own field.
A Decade in Review
DevOps had not been a "field of study" from the beginning, as I previously thought. Instead, while sitting and listening to the people who were there when the movement was founded more than ten years ago, I learned that DevOps began as an idea that changed the way teams work. However, unlike some standard methodologies and ideas, it doesn't have a manifesto. DevOps is simply a movement to try and make our lives better through the use of technology.
It started as a way to, quite literally, bring developers and operations engineers together to break down the silos that existed in the past and create a workflow that helps us get from point A to point B as quickly and simply as possible. Previously, the IT and Operations world was more like firefighting than technology. Everything worked so long as nobody touched it. However, when it stops working, there is utter chaos. It wasn't enjoyable or fulfilling and was in desperate need of a "refactor." Over the last ten-plus years, the DevOps movement has done just that. Those within DevOpshave created tools and technologies and set up best practices to help prevent the need to put out fires.
In previous years, talks about DevOps tools were prevalent. At this year's conference, every presentation was centered around the event's theme, "Devops days a decade in review ." The entire week was a retrospective of how far DevOps had come. Rather than being about how we do DevOps, it was about why we do DevOps.
I learned the history of DevOps from Patrick Debois, one of its creators. How "DevOps" started as an open space discussion posted by Andrew Clay Shaffer at the Agile Conference in Toronto, Canada, in 2008, and Patrick was the only one who showed up. Together they shared their unique ideas about operations and IT, which sparked the discussions that would eventually become DevOps. From there, it spread across the globe.
They used these conferences to get together and discuss a better way to collaborate. One such way to collaborate was through open spaces to talk about ideas outside of the topics presented by the scheduled speakers. Open spaces are not a new concept, and I'm sure, not unique to this conference, but it was something I had never experienced up to this point.
I Found a New Home
Open spaces are the highlight of DevOps days. Here's how it works: Members of the audience write on a sticky note something that they want to discuss and "propose" it to the general assembly. The sticky note is placed on a timeslot and given a "space or room." After participants finish proposing topics, the group disperses to attend and discuss whichever space sounded attractive to them. The subject didn't necessarily have to be about DevOps; it could be about anything. Participants bounce from discussion to discussion to either teach or learn about whatever the topic was in that session.
The basic idea is that people can come and go as they please. If you feel you are not contributing or learning, get up and move to a new one. You get out what you put in; if you don't learn anything, that's on you. In my opinion, this practice makes the DevOps community thrive. Out of these spaces came new friendships and new ideas about technologies that had nothing to do with the conference but were discussed in detail as people transitioned from one session to the next.
From these open space conversations, I learned:
- Imposter syndrome affects everybody, and you are never alone
- Meeting the developer in their space is super important. DevOps practices and tools need to fit seamlessly into a development workflow which means being in an extensible editor like VSCode or Atom
- What GitHub Codespaces are and how to keep one dev environment to rule them all
- Ways to onboard new devs faster in a remote work environment
- How to talk to your peers and break down communication
- DevOps slang and how to communicate with your devs in a way they understand
- How to mitigate security risks on the web from an infrastructure perspective
- Your value and compensation may be more than your paycheck, and how to navigate compensation discussions when your employer may not understand what your job entails
- DevOps is for everyone, technical or not.
Jumping from space to space, I met others like me, developers among DevOps engineers who had no idea what they were getting themselves into or where to start. They were newbies, too, just jumping into DevOps. Everyone helped each other learn what they needed.
A Toast to DevOps
I came away from the conference with a new understanding of the role that every other Web Developer and I have to play in DevOps. For someone who focuses on web development, I learned that DevOps isn't something that I should shy away from and isn't someone else's "problem." It is the most critical part of my job. Without it, nothing I create would ever be used to help people. DevOps isn't a set of technologies that focuses on getting your code from dev to prod. That's the result of what they do. DevOps is an industry that focuses on people and making their lives easier and enjoyable by making complex technology simpler to use. They automate the mundane and tedious tasks that pull us away from what we genuinely want to be doing: building cool applications.
My previous notion that DevOps engineers were the people you approached with caution, hat in hand as if you were an inconvenience, was utterly wrong. To be clear, none of the DevOps teams I have worked with in the past gave me this idea. I created my own false pretenses based on the complexity of their work and a misunderstanding of DevOps. This conference helped me realize that DevOps engineers are working to make my life better. Everything they do is to help the developer.
From a Web Developer perspective, DevOps is my job too. I need to be responsible for ensuring the things that I build make it to the customer. The only way to do that is to jump into DevOps with both feet and learn by doing. If you feel like you're drowning, the DevOps lifeguard team is there to rescue you; all you have to do is ask for help.
To the DevOps teams who have had my back in the past, thank you for helping deploy my code effortlessly. To the developers who look down on your DevOps teams because they "do IT," or to the juniors who are nervous about approaching the DevOps cave, change your mindset. They are some of the most excellent and interesting people you will ever meet. There is tremendous value in what you do, and I appreciate your work. Thank you for wading through the complexity of infrastructure, so I don't have to. Finally, to the organizers of DevOps days, Austin, and any DevOps days worldwide, keep up the excellent work. You are an incredible group of people and put on one of the best self-run conferences. Thank you for welcoming me into the fold. I will for sure be back next year.