Most of the sales pitches you hear encourage you to spend millions of dollars to implement new tools, define models for everything you do, and embed IT-like tasks and functions into your network engineering organization in a big bang approach that will change your world overnight. World hunger will be solved, everybody gets raises, and your network will run itself. Sounds realistic, doesn’t it?
To be honest, if I go back and read my own blogs I am probably as guilty of this as anybody in some of them. It is just more fun to talk about the future, where all the pain of implementation isn’t something to think about anymore…not to mention the costs involved.
I decided a while back to stop doing that and, instead, to start focusing on how we can help you get started on that journey. Hopefully more recent blogs are more in this vein. This one is, for sure.
I want to focus not at all on that future in this one. I want to talk about today, and what you can do tomorrow. How about some things you can do that might cost you a little time, but may not cost you anything else? How about those things also being things that fit into a larger plan that will put you in a position to invest in a way that might pay for itself over time with efficiency gains, and enables all of that really cool stuff we all like to talk about more in blogs?
The diagram below illustrates a different view of the operation journey I like to bring up. I wanted to break it into 3 simple timeframes: Right Now, an Evolutionary period, and an Acceleration period.
Today, most companies have some limited automation that is relegated to only their high volume tasks. This means, if you are a large service provider, you may have automated the heck out of your residential offerings. This is because they are extremely “cookie cutter” in nature, and the per customer margin is so low that you just can’t afford NOT to automate it. However, your internal network management and business customer activities are likely not automated much at all, if any. If you are an enterprise networking engineer this is even more likely to be the case.
This puts us in the “Now” bucket in the diagram. You likely log into devices and do most of your config, troubleshooting, and other management activities using the CLI. You may have even written a few scripts in the language of your choice, maybe a little Python programming has entered your world and you have been looking at those things your IT colleagues use like Ansible, Puppet, Chef, Salt, etc.
If you have looked very much into those items you may have built a few templates, Runbooks, Playbooks, etc. These seem like the greatest thing in the world, and it didn’t cost you anything to find a spare server and deploy some of these open source tools. This places you squarely in the “Evolve” bucket, but don’t feel bad if you aren’t quite there yet…or if you are VERY early in getting there. This is normal for where most people are today, except for some of the very biggest providers that have deep enough pockets to have moved beyond this.
This “Evolve” bucket is exactly where we find many of our customers. They are either entering this part of the journey, or they are still thinking about it and just aren’t sure what to do next. At many points in our early days we would encourage a jump straight to that “Accelerate” phase, and we have certainly been successful getting customers there. However, jumping straight there can be painful, both for the vendor and the customer, and can be quite costly.
Our strategy has evolved to better accommodate what we like to call an “onramp” to automation. It is fine if you aren’t ready to start building YANG models and introducing complicated orchestrators to your toolset. There are incremental gains to be had using some simple to learn open source tools to progress through the Template, Runbook, and Playbook phase. Layering a good workflow solution over the top of this can get you tremendous benefits, especially if that workflow system is purpose designed for network automation, like the Itential Network Automation solution is.
A proper workflow overlay should integrate with your Template/Runbook/Playbook tools for management and execution. It must provide more than just a task list you check off as you use other tools to execute those first level automations.
The reason we refer to this approach as an “onramp” is that it gives you and your team a chance to truly understand what is possible with automation, but do so in a controlled, low-cost manner. It also avoids many of the more complicated learning curves involved with modeling and orchestration, and firmly positions you for the step into those areas when ready.
The last phase, “Acceleration”, is when you have to make that leap. Models and orchestrators provide you with flexible, reusable components that can greatly increase the speed at which you can automate tasks. They also allow you to abstract even more of the complexity from the user than the lower level tools do, but the implementation costs – both financial and intellectual – are very high. It is a complicated effort that is best eased into.
I have tried to stay very high level here, but hopefully still clear and understandable in my point of view. Automation of the network is not simple, but there is an approach that can make it less complicated than most people think. Take what you have now, evolve your approach with open source tooling, apply some vendor tooling that brings some pre-built capabilities to the table, and then see your automation take off when you do finally move into that last phase. Don’t jump straight there.