Tell me if this rings any bells.
You walk into a meeting (or let’s be honest these days, you connect into your favorite or least favorite video conference application) and suddenly you have an executive on the line saying, “WE NEED TO DEVOPS EVERYTHING RIGHT NOW!” And then they throw up a pretty picture that shows how you’re going to get from “silo” to “DevOps” with a comprehensive plan of how you’ll get there and what steps you’ll need to take with executive sponsorship and buy-in to get there.
Hahaha. Sorry, I'm kidding about that last part, all of it really. Well, all of except for the, "WE NEED TO DEVOPS EVERYTHING RIGHT NOW!"
The reality of the matter is, irrespective of the role you play in the organization—Engineering, Architecture, SysOps, NetOps, SecOps, or a member of the Dev Team, a deconstructed siloed organization, or the one man/woman shop—chances are the expectations and realities of achieving a DevOps methodology are as unrealistic as trying to become ITIL compliant. (We’ll save that discussion for another day!)
But how do we get from our siloed or disconnected worlds to something more comprehensive and integrated like DevOps?
As anyone who has sailed into, or more appropriately flown into the DevOps Triangle, you might think, to get from point A to point B is the shortest distance between two points, so like here, a flight from San Francisco to Dubai, easiest done flying across the ocean, solid!
Sadly, not exactly. It might seem commonsensical from a mapping perspective to get from A to B you just draw a straight line, if the world were flat. (We can discuss flat-earth network mapping next time!)
The world, just like our networks, organizations and team structures, is not as much flat as it is three-dimensional and dynamic. So, while the executive sponsor wants you to take the straight-line approach illustrated above, the reality is you'll need to cross the arctic circle to take the shortest journey between these two points!
How do we get from here to there?!
I'm glad you're all here, ready to figure out the shortest distance between DevOps! The truth is, it's not easy, but it shouldn't be. Also, you cannot expect to do everything yourself, because after all, it is a process; practices paired with software development, IT operations, and so much more. When you're in the NetOps space you might have read my article, 2020 is the Year of the Networked API and if not, you should check it out!
One way you're going to help yourself get there is through the power of automation, and whether you're accepting the reins of adopting this for "DevOps" reasons, or merely to make your life better and easier, you can never go wrong with automation when it is working in you and your organization's benefit. Aruba's Steve Brar does a great job explaining this in his article “Welcome to the 2020s: What Does It Mean for Your Data Center Network?” and a must-read is “Top 7 Requirements for a Next-Gen, Edge-ready Network.”
Another way you'll be successful is by very early on identifying the parameters of success for your organization and your particular portion of the organization. People will often consider the principles and practices to be about 'want' instead of 'need', and unrealistic expectations that aren't fulfilled by requirements. I'll share a few first-hand examples to give you a gauge of the want vs. the need and being unrealistic to help set the stage.
Have you ever heard something like this?
"We need four 100G NICs for our application!" when even at peak it isn't scraping past 1K, or the back-end servers it's interfacing with aren't even running close to capacity on a single 1G link? Is it unrealistic to want to improve the throughput and bandwidth to an application? Absolutely not! But without an assessment of where your bottleneck is, if there even is one, throwing wants or demands vs. aligning the request to the needs or requirements of an application or services can be very extreme. Often, one of the disconnects of DevOps culture is thinking if you simply "DevOps" things, it will make fulfilling unrealistic expectations become a reality. While not true, it's not a rare belief in the culture.
Another example for my server cadre of SysOps friends is about an app owner of a random application that I don’t want to pick, so let’s just call it SharePoint. So, these “SharePoint" admins (see, not a real application!) are asking for more and more CPUs and more and more memory, because their application isn't performing. It's SLOW! The data doesn't index well! So, on and so forth.
I have heard before, "We need to be DevOps so I can provision as many CPUs as I want!" (That really happened.) That's not how this works, either in system architecture, application management, nor in SQL management for good deployment practice. But this is how you get lost at sea when navigating these confusing waters and airways of the DevOps Triangle.
Escaping from the DevOps Triangle
It can be such a scary and complicated measure to even understand how did you get there, and how you can get out of there, but if I had to pick three things you can start doing today whether you’re adopting DevOps principles or not, I can offer the following words of advice.
1. Identify your needs and your requirements. Whatever you'll be working on and working with, should be driven around what is needed to be successful, and not feelings or emotion. Does something "seem" slow, or are there KPIs that show it is not performing and it's measurably slow? When you make people tell you what they need versus what they want, their actual requirements will often come out instead of how they want you to achieve those requirements. DevOps is about working together, and not one party dictating how things will be delivered. Everyone should be working off the same playbook and working towards the same goals
2. Embrace automation. Automation should become the core of everything you do. When we can make things do what needs to be done consistently and successfully, we can minimize or possibly even eliminate the chance for error and that can improve the speed of things, speed of delivery, speed of testing, speed of troubleshooting, everything.
Should everything be automated? No. But if you do something three times for the first time, or you do something dozens or hundreds of times a day, every single day (that is fundamental to the operation of a system) you should look at and invest the time to make that process automated. This is especially true if it is at all possible to make a mistake when you are doing it manually. Automation should work toward your benefit vs. your demise.
3. Embrace your team and different ideas. Just like in my original example of flying from San Francisco to Dubai, both ways can technically get you there successfully. One way may be better than another, and you might be in the camp that it is your way or the skyway! But a team needs to work together, toward the same goals, the same objectives, and the same ideas.
It can help you think about things differently and sometimes those ideas can fundamentally shift and change how you go about accomplishing things, perhaps in ways you may never have thought of. The smartest person in the room isn't the one with all the answers but can help engage and encourage others to come up with those best ideas. Imagine how exhausting it must be to have to be the person who comes up with all of the ideas, instead embracing a culture of sharing and teamwork where you'll all be successful together!
Hopefully you found this blog helpful or at least learned that the shortest distance between certain points truly is over the Arctic circle, and for those playing along at home, yes it does get VERY cold when making that flight, so stay warm, embrace DevOps and stay safe everybody!
