I was talking to a banking customer in Northern Europe the other day and they asked me about configuration management. They had many different vendors with different management methods in their infrastructure and wanted to know how they could speed up management.
This specific customer had an outsourced infrastructure. They picked what hardware they wanted to run, but then paid a managed services company to deploy the infrastructure in a colocation facility and perform day-to-day operations.
The issue arose in the speed of deployment. When they launched a new application that required a new service in their data center, the application engineers would need to contact the network team in this bank. The network team would then open up a ticket with the managed services company to provision VLANs and open up ports on their firewalls to allow access to the application. The issue was that this process took up to one week to complete.
This bank contacted us with the hope we could help them unify their management under one framework, so that they could insource the firewall configuration to accelerate their application deployments. They asked me about automated management best practices.
Normally when I have this conversation, we have to address three topics:
- Management pane
- Multivendor support
- Level and scope of automation
The management pane is probably the most important question. How do you want to interact with this multivendor management solution? In the simplest form, I always tend to lead with an open source automation tool and programmatic code that is executed via a CLI. An example of this is using Ansible or Puppet as the automation tool and using playbooks or manifests as the programmatic code. Ansible is an open source and free solution that can be downloaded via APT on Ubuntu machines. Playbooks are YAML format files that provide a series of instructions.
This format requires your operations team to learn a more CI/CD based workflow to operate the network. Specifically, configurations will be stored in a centralized code management repository like Github or Gitlab. And any changes will need their own pull request via a unique branch. This enforces more of a software development style workflow, which has great perks. But if your network operations team isn’t trained in these skills, they’ll have to spend some time learning them.
On the opposite end of a management spectrum from a CLI based solution is a GUI based solution. Right now, there are a few players in this market, including Apstra and Ansible Tower, who provide a front end GUI to manage your infrastructure. This is a more traditional approach, and segways nicely into the next topic.
The second factor is the multivendor support of a unified management solution. It is much more difficult to create a vendor agnostic solution when the underlying vendor has a proprietary management API. I always rep that the native Linux implementation of Cumulus Linux Network Operating System makes it perfect for multivendor application management. But the more closed vendors you have in your infrastructure, the more difficult it becomes for a management solution to support all vendors and maintain feature velocity.
The challenge mainly comes from how a management application takes abstracted configuration contexts and translates them into vendor specific language. Building on my previous post about Linux as the language of the data center, using an open solution such as Linux helps manage all these solutions more fluidly.
Most companies address this challenge in one of two ways. One method is making it the vendor or community’s responsibility to code and maintain plugins. The other is bringing it in-house and owning the modules and plugins that are used to manage each unique vendor in your infrastructure.
The last topic that arises from this management question is the level of integration. There is an industry dream where configuring one part of your infrastructure will automatically configure other parts of the infrastructure. An example for this bank customer would be for the firewalls to dynamically provision open ports at the edge of the network based on the application that is launched, removing the whole user interrupted workflow. I’ve found that most customers want this, but are unwilling to be the first customer to deploy something this connected.
Let’s bring this back to my original conversation with this customer. Ultimately, I was able to whittle down their requirements to only wanting to manage their firewall ACL policies in-house so they can react faster to port availability. All their firewalls only came from two different vendors, and they were looking for a short-term tactical solution rather than a long-term strategic solution.
Though it’s hard to hear this when talking to a customer, I understand that time and people are fleeting resources, so not every problem can be solved in the most strategic or optimal way. I explained all these important points to the customer and they opted to start with seeing if Ansible will integrate with their firewall solution, as they are already using Ansible in their application and server space. I told them that’s a good start and wished them best on their journey.
The important message I wanted to get across was that they needed to consider their workflow and the interactivity with the underlying solutions when picking a management solution. Management is more about workflow than it is about technology. The technology primarily drives the workflow. And, once you start diving deeper into the solution, you’ll realize that open solutions such as Cumulus Linux are much easier to integrate into a unified management solution than closed solutions.
Eager to learn even more about configuration management? Watch our how-to video series about centralized configuration management to get an in-depth lesson on how it can optimize your networking configurations.
<< This article was originally published on blog here. >>