Decisions around developing, testing, deploying, operating, and maintaining enterprise applications are not being made in a silo. In days past, it may have been the case that network operations personnel were the ones who were in control, who were the last stop before anything of consequence could take place. And to be honest, most of them probably liked it that way.
But things have changed. Now, rather than exercising tight control, NetOps is being bombarded with people (DevOps people, if we’re being honest) who prefer to do things on their own. Things that NetOps wish you would not do (like going around security protocols for your new app or messing with the load balancing settings for that app update).
Now, arguably, DevOps folks are just trying to make things better. More adaptive. More self-managed and less micro-managed. More Agile (with a capital A).
The thing is, in today’s enterprise environment, DevOps needs NetOps if it’s going to maintain its Agile workstyle. DevOps simply can’t do it alone (all those applications do run on an underlying infrastructure, after all). And they can’t expect NetOps to take a back seat and relinquish all their traditional responsibilities. Nor would you want them to. NetOps plays an important role in maintaining security and performance of all the apps that DevOps creates, and they bring important skills and capabilities to the CI/CD workflow.
If you’re in DevOps and are trying to bring your NetOps colleagues more deeply into the CI/CD workflow, you first need them to want to participate, to see the value in changing the status quo. This is actually quite easy to do, given that the low-hanging fruit that automation easily solves for are all the tedious, time-consuming, routine tasks that have to be done over and over again. The kinds of tasks that any sane worker would be happy to relinquish to a bot.
Change orders are a great example. Picking your way through a stack of orders, manually entering every change, and then double-checking that you did it right because after all this is your ninth one just this morning and they’re all starting to run together and why did you get into this field in the first place? Filling change orders all day, every day? I don’t think so.
There is a better way. And that is to automate the heck out of all those redundant, oft-repeated tasks that bog down an otherwise interesting and productive day.
The folks up in corporate wanted us to lead with this one, because it’s all about the product, right? Who cares if the men and women making it love their jobs, right? (Wrong!)
Nevertheless, robust performance and security for your apps is actually a pretty sweet side effect to your job being less mind-numbingly redundant.
By automating the services that make your applications reliable and secure, you not only free up time for more interesting, less repetitious, projects—you also improve the quality of those services. That’s because well-crafted, automated workflows don’t just come into being on their own. It’s the role of the NetOps engineer to create the optimal model on which each automated workflow operates, in turn generating optimal results over and over again.
The beauty of automation is, if you do it right the first time, you know it’ll be done right every single time after that.
In an automated workflow, not only does NetOps get to retain control over their areas of expertise (which makes your apps faster, more reliable, and more secure), they can generate automated processes that are so simple to use, DevOps will never again consider going rogue (which, again, makes your apps faster, more reliable, and more secure).
It’s almost always the case that neither the DevOps nor the NetOps teams are capable of figuring out all the solutions involved in maintaining an organization’s critical apps and data on their own. It has always been the case that these two teams need to work together. And today’s automation capabilities go a long way to reduce the friction around these interactions.
DevOps, NetOps, SecOps… no Ops is an island. In the modern CI/CD workflow, success comes through developing clearly defined, proven methodologies that can be quickly and easily (i.e., automatically) replicated throughout complex systems. Creating solid groundwork for these automated workflows requires a solid partnership between DevOps, NetOps, and SecOps, with each lending their expertise in support of the others.
No matter the environment (cloud, container, etc.), your apps rely on underlying application services, network services, and security services. NetOps has a role in keeping data flowing through the network, making sure apps are scalable and responsive, and ensuring data is available when needed and secured always. And every Ops team has a role to play in reducing risk—whether it is the risk of your app not working as intended, the risk of your network being overwhelmed, or the risk of outside threats trying to attack your assets. And it’s interesting to note that the DevOps principles that drive good outcomes for software development—culture, automation, measurement and sharing—happen to be the same principles that drive good security outcomes, according to the 2019 State of DevOps Report by Puppet.
This interaction between the various Ops teams is constant. It’s the way IT has operated throughout the internet era. But there is always room for improvement, such as when the Agile software development process came on the scene, pushing the boundaries on how quickly apps could be developed and deployed. At that time, DevOps began to make the big change to a more Agile approach to development, adopting a faster way to get “from code to customer.”
That increase in speed is driving the sea change that DevOps is now witnessing. It has a good side, in that DevOps is able to move faster and be more proactive; and it has a bad side, in that it can create friction when other departments’ processes are not set up to work in the same manner.
Simply ignoring those other departments or disregarding any coworkers that haven't quite caught up to your new way of doing things is a bad idea. When DevOps tries to do it all themselves, it’s both inefficient and inadequate. That’s how processes get broken (inadvertently or not), and broken processes can lead to all kinds of things going wrong. And not just for DevOps, but for everybody, including your customers, who are the last people you want to negatively impact.
For DevOps to really do your job properly, you need NetOps as a partner, not a foe. And the linchpin to any solid partnership is communication. DevOps needs to communicate with the network team about how to get the services you need to support your apps.
Often the DevOps team will be the experts in automation, in the overall framework, and with things like infrastructure as code; but the network team are the experts at understanding the actual architectural resources that need to be provisioned and which tools are available for that provisioning. Through conversation and mutual respect, DevOps and NetOps can identify where automation is needed, and how best to bring it about.
You’ve got nothing to lose, DevOps, and much to gain by helping your NetOps counterparts extend the role of automation throughout the CI/CD workflow. The key is to recognize that, just as you are the expert in developing code, one or more of your co-workers are experts at provisioning network and security services to support that code. Don’t miss the chance to help them be the best expert they can be.