Working together effectively
Standardizing the toolset across groups (let's all play tuba) isn't really practical. The people doing the work are effective with the tools they know. While there can be movement *within* groups toward some standards (the brass section settles on trumpet), selecting a single tool *across* these groups is likely to fail as some tools are better suited for certain contexts than others.For example, we can't just all use spreadsheets to solve our problems as they don't address the ability to configure the networking domain. Another example is that it's not practical that we all become software developers as the cost is high to build new network management products when there are already apps that address some of our needs. Some tools are well suited to solving one, targeted problem, and it'd be a pity to not use it in those situations.
Script automation without being used with orchestration is subject to the following:
- hardcoded values
- applicable to only one piece of hardware
- hard to maintain beyond the original script developer
- once there are hundreds of scripts with hundreds of lines, it's difficult to:
- get a view to what scripts are applied to what hardware and
- how frequently (applied by schedule or continuously or ...)
Points 1, 2, and the second bullet of 4 can be mitigated by the scripts being driven by orchestration. Points 3 and the first bullet of 4 is aided by the use of source control.
Communication through Code
Just as development teams preserve their efforts in source control so everyone on the team or organization has visibility, placing the configuration of devices into source code should:
- make visible what automation is affecting what production devices
- become a system of record
That resolves the first part of the above fourth bullet.
Orchestration
Wouldn't it be nice if you learned to play ONE instrument well, you could operate thousands of others? Then later, if you had to add a new one, perhaps a voxophone, everyone else who could play piano could immediately GET, at some level, how to work with the voxophone? Then later, if something were to go wrong with the voxophone, everyone knew the scope of the problem and where to start, even if they weren't the voxophone player.
This is orchestration. One of its benefits is that there is a layer of standardization across a diverse toolset, without ruining the ability to get things done with the best specific tool at hand.
This ability to "normalize" interacting with a variety of automation (python, tcl, CLI, webAPIs,...) through one or a few well known tools would:
- simplify the effort to get a high level understanding of what's happening
- allow others (those who have less experience with the automation script or tooling) to make orchestration adjustments to a script without requiring digging into the body of the script
- anyone can understand how, when, and what (devices) is being managed
- greater ownership, beyond the script author, of what's happening across all the tools
For example
One way Ansible can orchestrate scripts is through the use of the Scripts module and then Ansible facilitates execution by:
- transfers the script to the remote node for execution
- passing arguments from the playbook to the script
- executes the script in the shell environment on the remote node.
Nice Article!!!
ReplyDeleteDocker Online Training
Docker and Kubernetes Training
Thanks for sharing this blog. This article gives lot of information.
ReplyDeleteDevOps Training
DevOps Online Training
DevOps Online Training in Hyderabad
DevOps Online Training institute
DevOps Training Online
DevOps Online Course