Takeaways from DevOpsDays PDX 2017

For those of you who are new to the term, DevOps refers to the intersection between operations and development engineers. DevOps is often summarized by the acronym CAMS: Culture, Automation, Measurement, and Sharing. The people who play in the DevOps space are an opinionated bunch. There are a lot of competing definitions and internal spats on what it is (doing your job right) and isn’t (tools), but in my opinion, these differences are often just semantics, and the heart of DevOps persists through the various definitions.

This was my first time to a DevOpsDays conference. DevOpsDays have been going on for the past eight years and are a truly global movement connecting developers, sys-admins, QA, and InfoSec people to learn, share, and explore ways people are doing the art of shipping software. 

The DevOps world has a broad lexicon of terms and tools that connect to those terms. As an emerging developer at my first DevOps conference, a decent amount of my energy was spent like a stranger in a strange land trying to grok the meaning of how things connected to each other and were used to make development and deployment a better process. 

Here are a few of the core terms:

• Continuous Integration / Continuous DeliveryContinuous Integration and Continuous Delivery (CI/CD) is a way of doing fluid test-driven software development. When a developer or team submits a change to the software code base, tests for QA (and security) run and only when those tests pass the application updates. Some popular CI/CD tools are Jenkins and TravisCI.
• PipelineAn automated software delivery process.
• Containers / OrchestrationContainers are lightweight, scale-able, isolated environments where you can run your apps. Examples of containers would be Docker or rkt. Software like Kubernetes, Chef, Puppet, and Ansible are used to orchestrate these containers by balancing their load, managing their configurations, and handling their health, etc. in various ways.

And here are some more terms to go and search for if you want to learn more because I know you don’t just want to read a bunch of terms and their definitions in this blog post: ChatBots, Canary Deployments, Chaos Monkeys, MttR, MtbF, NoOps, DSL, AMI, DogFooding, Pet Servers, Snowflake Servers, Microservices, Monolith, Rugged Devops, Baremetal, Clear Containers, RPMs, Registries.

And then there is the term that sounds cheesy, but often could be practiced better: Assume Awesomeness. Assume Awesomeness in your interaction with your team, your testers, your product managers, your sys-admins. As Steve Desmond said at DevOpsDaysPDX, “They are trying their hardest to do the best job they can.” A culture of assuming awesomeness encourages creativity, productivity, trust, and problem-solving. 

As a young developer, I went to DevOpsDaysPDX with tools and terms in mind. I thought the chief benefit of being there would be the takeaways of tools and languages to experiment with like ELK, Go, Docker, Kubernetes, Chef, Inspec. I got some good book and thought leadership recommendations (Phoenix Project Book, State of DevOps, Spotify Developer Videos), and ideas on hacking life (gettingstronger.com), but the best takeaways were rooted in people and interpersonal communication dynamics.

“DevOps is selling culture.  It’s selling change.” – Kris Buytaert

Selling culture. Pitching why we should trust each other.  Verbalizing that trust.  Explaining intentions consistently and why you think certain changes would be good. Selling it.  Articulating why it is in other’s self-interest for certain changes to happen. Isolating pain points. Getting to the why. Pair-programming solutions to lead by example and gain internal cheerleaders. Assume awesomeness and chant mantras to block doubt that tries to whisper traitorous divisive heresy. 

“Don’t go in with guns blazing. There are reasons things are the way they are” – Steve Desmond

Status quo is status quo for a reason. In some ways, it works. It’s the equilibrium of tolerable(?) pain points. It gets the job done. People have their responsibilities, and they execute on them.  DevOps is big on shared responsibility and sharing risks. This means to embrace it involves others. That can be threatening and misunderstood. It rocks the boat. And you will see the Peter Drucker’s Cuckoo Effect: “Any foreign innovation in a corporation will stimulate the corporate immune system to create antibodies that destroy it.”

“Ask your developers, ‘Where should I focus my tests?’” – Lucy Wyman

It seems obvious, but without intentional communication, this can often be overlooked. Everyone is busy; you don’t want to interrupt.  Developers know best areas in their code that are ripe for bugs or security risks to slip in. Simple communication can isolate important tests to run and speed up development time by finding those bugs earlier which may involve a more complex solution by the developer.

As a new member of the Daylight team, it was great to get to participate in this thought-leading conference and take away inspiration on how our development team can continue to build great web experiences for our clients.