I recently had the honor of speaking on Day 1 at DevOpsDays Kansas City. I work as a DevOps Engineer at C2FO and I absolutely love my job. Naturally, I was very excited to share how we were employing DevOps practices to meet the needs of our business, especially the need to move to a multi-cloud architecture.
I’m fairly aware that I’m not the greatest of public speakers. However, I got a few people who came up to me after and said that the content was quite relatable:
Businesses are moving faster than ever and expect projects to be completed in months rather than years.
Even if it wasn’t that relatable to others, I thought my memes were pretty entertaining. If nothing else, hopefully people walked away from my talk being slightly amused.
Fast forward to Day 2 of the conference. The Open Spaces were the last event of the day. If you aren’t familiar, Open Spaces are self-organized groups that talk about a particular topic suggested and voted on by attendees throughout the conference. To be honest, I had been to some good ones in the past, but had half written them off as not that worthwhile. Some people had decided to head out for an early start to their weekend and I debated on doing the same. I resisted this urge though and decided to attend an Open Space where people were talking about failure and their lessons learned.
While listening to another member of the group talk about their experience, I had a revelation. This person mentioned how their team got saddled with everything not considered development work. They talked about how they were the bottleneck to the development team. And then it hit me like a thousand pound sack of irony: Our DevOps team is our bottleneck.
You see, the thing I neglected to mention in my talk was that even though:
- We had all our build & deployments automated.
- We could deploy multiple times per day.
- Anyone could spin up a full prod-like development environment in about 10 minutes.
- We were employing other DevOps processes like post-mortems and knowledge sharing in other areas.
If they wanted to deploy a new application to a production environment, they would need our help to do so. The deployment tool we built was full of features. The downside is it required a large amount of domain knowledge to create the necessary files that plugged into the system(think AWS CloudFormation files, systemd unit files, and bash scripts for building). Despite that, it worked quite well and we get fast and reliable deploys. But that doesn’t mean much if every time someone wants to deploy a new application, even as a test for beta users, they have to attend our team’s sprint planning meeting. God forbid we are busy fighting fires or have some other priority.
The more I think about it, our process ensures that developers throw their code over the wall to our DevOps team to deploy.
And when something goes wrong during a deploy, guess who has to be dragged in to resolve the issue? What if we had something more self-service? Something well documented that didn’t require too much understanding of all the cloud features. Something where its easy for developers to deploy and test out ideas. If only…
But, wait! We made the move to Kubernetes in our multi-cloud effort! And Kubernetes provides just that! Maybe all hope is not lost. Maybe we can remove ourselves as a bottleneck.
The morale of this story is stay till the end! Listen. Really listen to what others are saying. Ask yourself, “Could this be me or my organization?”
tl;dr: Thought we were doing DevOps. Turns out we missed something big.