Category: General

Speaking at DevOps Days Austin a few months back on the topic of “DevOps vs NoOps,” led to this post. Ignite presentations are great conversation starters, but can’t convey much substance. It’s a great incendiary title, however I wanted to offer a bit more context on the two “NoOps” applications I’ve been a part of the last few years.

Example #1: DevOps for a Ruby on Rails application deployed to Heroku

The facts:
This application managed the user experience for tens of thousands of customers at WP Engine. It scaled horizontally with the help of HireFire. We managed the log files with Papertrail. It had a Postgres database as the backend data store. As well as a caching layer. Everything managed directly through the Heroku Portal & CLI.

The pros:
Heroku handled much of the security. HireFire was there for horizontal scalability. Easily turn on and scale up services at the push of a button.

The cons:
Obviously, cost. You get what you pay for. Additionally, having a UI for management instead of CLI/scripts for some things. It was difficult for on-call to do more than “restart the dyno’s” due to visibility.

Example #2: DevOps for PHP & Laravel deployed on EC2 directly

The facts:
These applications supported more than a thousand customers. Laravel, Forge & Envoyer gave the team the ability to easily manage deploys and various environments. It provided us with turn-key configuration management of our application servers.

The pros:
Configuration management for initial server setup comes out of the box. It is easy to set up commit/webhook based deploys.

The cons:
Unfortunately, it did not give a true security blanket like Heroku does. Patch management was a required add-on. Additionally, much of the Envoyer/Forge configuration is not tracked by default in the version control system, so configuration drift was common. No built-in or suggested solution for monitoring.

So, do I still need DevOps?

Obviously, both of these applications still required some amount of operations support, but for the most part it was manageable by the existing team of developers as opposed to needing a specialist in monitoring, security, patching or other core DevOps structures.

I truly love DevOps for what it has done to bring development into the operations camp, and operations experience into the development side of things. Anytime we’re talking about breaking down the walls between development, operations, quality, product, or any other collaborator, I’m all for it. I’ll still be hiring DevOps engineers, and looking to build resilient platforms that make every engineer that much more effective.

Where did this phrase “only new mistakes” come from?

It originally came from a process our development teams used of allowing people to make mistakes, but encouraging them to always learn from the mistake and to not repeat it. Each review period, quarterly when I first encountered this mentality, we would look at the three things you could have done better. Those mistakes or opportunities were a chance to place a mental speedbump on that memory so that going forward you’ll always remember the mistake and the connected ways you can handle it better going forwards.

As I moved into management, I was looking for a short, sweet version of this process so that I could say it to the members of my team and help them learn this trick and at one point I began using the phrase that it was my goal to only make “new mistakes.” Using my learning from my previous roles, companies and other life events to avoid the known mistakes I’ve seen before, or at the very least to discover new ways to make some of the same mistakes.

Where does this principle apply?

I believe it works great in the business context, but that it’s also very useful in parenting and so many other areas of life. This blog is going to focus on the types of mistakes and learnings you can use to build a great engineering team, but that doesn’t mean the learnings will end there.

This blog will primarily focus on how to apply this principle to leading software development teams, but will draw on experiences in parenting, volunteer work, business, and so much more.