I keep doing the automation dance, there are a lot of different tooling products out there. I have been trying to understand a use case around using it with network automation. Recently I have been dancing around with Ansible. My personal belief is that using any type of these tools would be helpful but it can be a steep learning curve if you really don’t have any programming knowledge. This is not something that is relatively easy to use or understand, don’t expect to have a working network automated tool in production on day one. I think this is great for learning, and using this in a network sandbox. If you don’t have programming mindset it might make your job harder on day one before it gets easier, but just like learning to dance you have to learn the steps, the moves, and maintain the rhythm. So with that let’s at least figure out the starting points, and begin learning the steps of the automation dance. 😉
All of these automated frameworks are tools, Ansible, Puppet, Chef, Saltstack, etc. These are all tools that can be used to automate your device to do whatever you’re trying to accomplish without manual configuration, that’s the goal. All of these tools are “freemium”, they are available on Github and you can use them however you want, The catch with all of these tools is they are a framework, if you want something fancy integration or some web interface, and have additional smarts with the product, then you’re going to pay for it or you could build it yourself and stick to the man.
Just need to increase payroll and hire developers, which just takes your goal of automating your network infrastructure to maybe day 365? Remember you still have to maintain it, patch it, upgrade it. (Does it still work after all of that?)
You’re not in the business of developing a platform that makes these tools easier to work with, that’s the reason they all have paid options.
“I’m just going to use the CLI of one of those tools and develop my own playbooks, cookbooks, manifests, salt states, and make it work!”
I would say most people exploring automation go this route, and it’s not a bad starting point when looking at all of these tools they all have these common themes:
- Deprecated feature that was referenced on the internet somewhere long ago and it worked at that time, but now the tool does this instead of that.
- Documentation is lacking and it becomes difficult to find what you are looking for, like config examples, error messages, and overall architecture of the tool, how does it work?, best practices?, etc.
- Tools are used incorrectly when referencing what other people posted online. An example is like seeing playbooks, cookbooks, manifests, or salt states have plain/hashed passwords in them! Some tools (Ansible) offer a vault for passwords but people don’t use them or know about them!
These aren’t showstoppers but keep these in mind when starting out. All of these tools come with a foundation that doesn’t change so learn from that and then begin to branch out, and it might help to buy a book if you are committed.
Call it quits?
I wouldn’t, this is where you need to stop and think, before even exploring these tools and ask yourself what would automation (tool) help at XYZ? If you are not thinking about automation you should start! Crawl, walk, run when exploring automation It’s important to learn first, sandbox next and develop continuelsy.
I saw this post on Reddit last week (For those who if they keep hearing “DevOps”, “Python “, “Automation” are gonna kill somebody… read on) and totally agree, I don’t think we are expecting someone with superhero skills that can whip up automation and have us say.. “Alexa..fix the network” but I do think we need to shift focus on it by thinking about it, learning about it, and then using it. 😉