5 Things I Learned About DevOps (But Was Afraid to Ask)

We were honored last week to be a sponsor of the Canadian Executive Cloud and DevOps Summit held in Vancouver, BC and hosted by our partner Trinimbus. It was the inaugural event in the area and was sold out with a room packed full of AWS customers and users who are aggressively moving their businesses to the cloud. Did you know that there are over 2,000 AWS user group members in Canada that are active in the cloud community?! If you’re not already, be sure to get involved.

The day was dedicated to the principles around DevOps – communication, collaboration and culture. I was surrounded by small managed service providers that support the local Vancouver, BC area to huge Enterprises such as Samsung. A few things that I learned from the day I’ve outlined here.

Lesson #1 – The definition of ‘DevOps’ is still unclear and undefined (not that there is anything wrong with that).

The essence of breaking down silos within the business to help them work smarter, not harder, prevail. But undoubtedly DevOps has gone beyond just a buzzword, yet it still does not have a formal definition which makes it challenging for companies who get the signal to ‘do DevOps’ to determine where to start and what to emphasize.

Lesson #2 – It’s about the people and for the people.

Whether you’re talking about infrastructure as code, CI/CD or the world’s coolest Kanban board, the reality is that DevOps is all about people. As developers, operations managers, security architects and system administrators all try to figure out the best and easiest way to work together, it always seems to come back to discussions around tooling such as “Should we use Puppet or Chef or Ansible for configuration management.” While that is an important question that is worth a separate debate, we all should start with making sure we’re having empathy for our co-workers as the demands of the business increase.

Lesson #3 – If you can’t feed the team with two pizzas, then it’s too big.

A very cool rule of thumb that Amazon uses internally is their two-pizza team model. These teams all work on a single problem and have full ownership & accountability. They call themselves “service teams” in that they build it, they run it, they QA it and they’re on-call for it. Makes perfect sense as long as they are autonomous while being aligned as part of a larger strategy.

Lesson #4 – Most organizations are under-investing in tools to measure the infrastructure.

In order to make data-driven decisions, organizations must have the proper metrics in place that give them clarity around their assets, utilization, costs, security posture and more. And by focusing on making small, incremental gains (think in terms of 1%) in everything you do you can quickly determine what’s working and what’s not.

Lesson #5 – Security in DevOps must be continuous.

In order to move at the speed of DevOps, security must empower users to continuously detect security threats as well as identify indicators of weakness across their heterogeneous environment. In addition, security must be actionable. Too often does security tell the patient they are sick but provides no self-healing mechanisms to return them to a known, good state.

Essential Understanding for DevOps Success

In order for DevOps to be successful in your organization, our suggestion is to focus on the customer, not on the infrastructure. Be sure you’re continuously optimizing the customer experience and your DevOps journey will undoubtedly be a successful one. Remember: continuous deployment is optional, but continuous delivery is not!