What the Ops is NoOps?

Our industry is not shy about inventing new terms to describe what new things they’re doing.

We have DevOps, which is all about the culture shift from the old style of writing some code, then throwing it over the wall for some guy to run in production for you. As the Project Phoenix novel outlines, this rarely works, so DevOps is about moving the development team and the operations team closer together, to improve communication and collaboration, allowing deadlines to be shared rather than fought over.

For me, NoOps takes “moving the dev and ops teams closer” to the next level. Every developer should deploy, and regularly.

So what is NoOps? #

For me, it’s important that Developers don’t speak to Ops anymore. That’s because they are the Ops team too. There’s no dedicated Ops person on my teams, each individual developer has the knowledge and access to do deployments as regularly as possible.

The teams let the pipelines do all the heavy lifting, I’m talking about letting your Continuous Integration (CI) tool do all the hard work. When a branch in git is code reviewed, approved, and subsequently merged, get your CI to build your releasable artifacts straight away.

This follows the premise that your main or master branch is always releasable, and you have the artifacts built and published to do so immediately.

As part of automating as much as possible, you could think about deploying to your development/test environments from your CI pipeline. Welcome to Continuous Delivery to the dev environment!

The Enterprise Challenge #

Is Continuous Delivery, and NoOps even possible in an Enterprise environment? In short, yes, but it can be tricky.

First you’ll want to own your own infrastructure as a development team, this will allow you to move quickly, try new things out, and implement change fast. The easiest way is to leverage the cloud, as trying to procure and deliver hardware into an on-premise situation will unlikely end up with your team being able to own the full infrastructure.

The Cloud is probably a new-ish venture for most Enterprise level companies, so there will likely be teams of people (DBAs, Networking, SysAdmins) who will require taking control of parts of your infrastructure.

Resist.

Explain to those teams, that you’re reducing the load on their team. It’s usually easier to ask forgiveness than it is to get permission, when done responsibly. Also make sure you and your team contribute back to any internal shared repos made by those teams, as this will help build the relationship.

The one team I have failed to mention is Enterprise Security. Their primary purpose is to keep the environment safe and secure. Help them to help you, be engaging early and often on your project. Don’t just throw the rugby ball of code when it’s done and expect an immediate answer.

You can further improve this “often” part, by starting down the path of DevSecOps NoSecOps. This in the first instance means adding a security tool into your CI pipeline, preferably a tool that Security are already familiar with and use the output of to analyse your application.

What we learned #

When you’re working in an Enterprise environment, sometimes other teams don’t always move at the same speed as your own team. This can be frustrating and can lead to delays and missed deadlines if not quickly resolved. Resolve by engaging earlier, escalating quicker and building relationships!

The more you manage to automate and put into your pipeline, the easier your life will be come. Deployments will be come a breeze! Remember that you don’t need to make the automation perfect on the first try, iterate and make it better over the course of several weeks/months.

So give it a go, reduce your reliance as a Dev team on the Ops team, understand your application architecture, how it runs, and learn how deployments are done. Then start to do deployments, have a say in the architecture, and design your application to run better in the environment you have (or improve it!)

Let me know how your NoOps journey goes - @florx

Thanks to Thomas Kvistholt and Quino Al for their photos on Unsplash.