DevOps Days Austin 2016 Logo
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.