The story of automating the on-prem infrastructure is one of working in the dark for a while. There is so much buzz going around about the cloud infrastructure. I am the last to say that the network is the shining light of the front runner in automation.
On-premise networks are heterogeneous in nature and snow-flaked by design. They are more often historical grown multi vendor stitched environments than not. No true multi vendor deployment or management tools exist. And when there is some level of multi-vendor support it is disclosed for usage by a GUI. Already embedded templates for the one originating vendor is so overwhelming that the thought of having to add a full new vendor support into such a framework is killing. No network engineer in his sane mind is willing to hook his full potential and knowledge into a single vendor framework even if it will support all the different vendors used within his current working topology. The day will come when he will depart willingly or not from that infrastructure. And of course many of us are working on a contract or project basis to begin with and time does not allow us to invest into setting up such an effort.
There is only one way to move forward from this impasse. The adaptation of truly vendor neutral frameworks and tool sets are essential. The tool set could be things like Yaml files and templates in Jinja. I realize that probably by naming those I am already in the camp of an automation framework like Ansible. But the tools and frame work could be replaced by another as long as they are open and neutral from nature and there is no need to buy into a specific vendor in order to unlock the potential.
If your company like mine has adopted a cloud first strategy the on premise world is changing. The fact is that, with a lot of work loads are moving to the cloud, the data-centre infrastructure is now being released from a lot of day to day business. Many of the demands for help and support are moved from my team to the people that have build the infrastructure in the cloud.
The function of the data-centre has shifted from being support for all compute to, compute only for a few legacy applications or yet to be moved resources. But the central function of being a connectivity hotspot has not changed yet. Many company’s still have need to interconnect WAN and cloud infrastructure. And need a place to interconnect branch locations. This shift of course frees up some resource. But this does not mean we can fire our current resources. Minimal teams still need redundancy to absorb hiring and firing and other fluctuations in a team. The resource freed up from daily maintenance should now be invested in lifting the legacy infrastructure back up to the level of the cloud. Driving people should be kept in place to push infrastructure as code. Many company’s don’t have a true exit strategy for the cloud. But the day could come when the new cloud style of vendor lock-in comes to a killing stand of and the need will come for a infrastructure in data-centres that is ready to absorb new workloads. This is why we should stay sharp and work hard and be ready! This not the first wave of centralization and decentralization I have seen in my time as an engineer and it will not be the last.