Sexy But Useless DevOps Trends

What's sexy but useless? A Ferrari in a traffic jam. It's beautiful, but all that power means nothing. When trapped in traffic, it can't live up to its full potential.

Same with DevOps. While there are some critical DevOps functions that you absolutely need, there are some sexy but useless DevOps trends that are good to be aware of. Truth be told, there's no recipe that will tell you how to succeed in DevOps. Everyone will have different opinions, and what worked for others might not work for you. But you can trust one thing: there are some actions that will guide you directly to frustration with DevOps.

With the amount of information out there about DevOps, you might get overwhelmed and think it's not for you. You also might think the learning curve is too steep---that you need to change too many things before you get started. Maybe you'll need a new team, new tools, more metrics, more time... you name it.

My advice is this: don't get distracted by all things that people say about DevOps. These things I'm going to talk about here, for instance, are all style and no substance.

1. Having a Separate DevOps Team

The idea of DevOps is to remove silos. It doesn't make sense then to include another team that will be in charge of handling or easing the communication between developers and operations. Historically, these two teams have had conflicts, so adding a DevOps team is similar to adding therapists for each team. Having a DevOps team might look sexy because now you can tell the world you're doing DevOps. Your team will hurry to update their LinkedIn profile. But in reality, you're just adding more complexity.

What would a potential problem with a DevOps team look like? Well, developers and operations could start saying, "It's not my job to automate the release; it's the DevOps team's responsibility." And what about accountability and ownership? You'll lose it.

Another downside is that you'll need to have a "full-stack" team that has a background in development, operations, testing, and security. I don't doubt there are people with these skills, but you lose a lot when someone isn't specializing in one thing.

So instead of having a separate team that will create more handoffs, what you can do is identify where the problem really is. It could be as simple as changing a culture that doesn't share knowledge. Are developers thinking about using a new NoSQL database? Great. The developers should let operations know so they can learn it too. Is operations thinking about adopting containers? Nice. They should let developers know about it---I bet the devs would appreciate a production-like environment.

So, please, don't add a new team to your DevOps initiative. Say no to silos. Instead, target the real problems: the ones that made you think you needed a DevOps team in the first place.

2. "Going DevOps" By Virtue of Adopting Some Tool

As the great Grady Booch once said, "A fool with a tool is still a fool." While using the fanciest, most-almighty-seeming tool for DevOps might seem sexy, it's useless if you're hoping it will magically make you a practitioner of DevOps. Same for things like cloud, microservices, or containers. You don't need any of those things to provide value. If you don't know what problem a tool or technology stack is solving, ask yourself why they even exist.

This doesn't mean that tools aren't important and they can't be useful. Some of them will help you speed up, but you shouldn't fully depend on them. They're always evolving.

In fact, you can embrace DevOps without tools, and James Shore's post on how to do continuous integration with the bare minimum sets a baseline for what I'd say about tools and DevOps. The post basically says that you only need an old computer that you're not using anymore, a rubber chicken, a desk bell, a script, and Kool-Aid to do continuous integration. Sounds silly, but it helps you understand that you don't need a tool to start things; you can use what you already have in place. You just need to be creative.

3. Having Developers Manage Production Environments

You might be tempted to do this, especially after hearing that companies like Netflix and Amazon are letting their developers push changes directly to a production environment several times a day. But you shouldn't forget that, in order to achieve this, the delivery pipeline needs to be deterministic and accompanied by a trustworthy set of tests. While I believe that DevOps encourages freedom, I don't think giving the keys to production to everyone will be beneficial. Folks have been fired on their first day of work because they were allowed---and proceeded---to screw things up badly. Imagine giving everyone at a bank a key to the vault. It's like that.

I'm not saying that developers shouldn't be trusted, nor am I saying that companies that give full permissions to developers are nuts. It's just not for everyone. Giving this type of access could make you ask why you need an operations team.

Instead, consider giving developers indirect access to production. By indirect access, I'm saying the operations team should provide all the tools developers need to make better decisions. For example, you could give developers read-only access to the system you're using to administer infrastructure (e.g., AWS or vSphere).

You could also give developers access to the log management tool or to whatever you use to store infrastructure metrics. If developers have visibility into things like CPU, memory, requests per second, error rates, and other such things, it will help them be accountable. You don't need to give them full permissions. Just give them the proper tools to make their work easier. And in the end, remember that operations folks have way more to do than just releasing and operating systems, and most people are just trying to help.

4. Giving Yourself X Months to Become "DevOps Compliant"

Are you looking for a crystal ball that can tell you when you'll finish with your DevOps initiative? That would be Ferrari-style sexy. You could, in fact, reach the point of doing several deployments per day, being always ready to deliver. That sounds next-level sexy, especially to top-level management. But the ambition to finally have "arrived," as far as DevOps is concerned, is fool's gold. This should be something that you constantly improve upon. What if suddenly, for some reason, you're not delivering quickly, securely, and reliably? Your process might need to change. Are you going to stop working on new features? I'd hope not.

You should take a more conservative approach initially, but as you progress, know there's always an opportunity to improve. The architecture will evolve, features will be removed, technology will need to be upgraded, etc. So as the Agile Manifesto says, you should always respond to change over following a plan. Don't expect that you'll need X time to be DevOps. It's a continuous improvement process.

What Worked for Others Might Not Work for You

In conclusion, your own DevOps path might be easy. Or it might make you suffer a bit. But just as organizations are different, cultures and processes can be different---even in the same industry. So why bother with sexy-but-useless rules that not only may not apply to you but also might hold you back? Just keep learning from others, taking what you think will work for you, and then trying things out. Pinky and the Brain were trying to take over the world every night, and they never did it.

It's important you're aware that DevOps trends that are sexy but useless exist. But here's some things that will help you.

• Remove silos instead of adding more of them.
• Know you don't need a certain tool or technology to provide value to your customers. Some will make your life easier and will improve productivity, but they alone won't solve all your problems.
• Make sure every person in your organization knows how they are providing value. Doing so will reduce complaints about lack of access.
• And most importantly, know that it's helpful to take the approach of always improving in small batches.

Experiment, adjust, and don't forget to enjoy the journey.