A Simple Path to Automated Network
by Mike Bushong, Vice President, Enterprise and Cloud Marketing at Juniper Networks
Automation is near the top of every enterprise IT list in terms of 2018 imperatives. With so much change in the industry, it is becoming difficult for companies and individuals to keep up. Forced to operate within budget constraints, enterprises are racing towards automation as a means of making their workforces more productive.
Of course, the movement towards a more automated future has cluttered the industry with hype, misinformation, and unrealistic expectations, leaving enterprises aiming in the right direction but grasping for the wrong things to get there.
Cloud companies as a misleading model
Part of the problem with automation is that enterprises look to the cloud providers as their operational models. While it is true that the major cloud companies are excellent models to aspire to, they approach infrastructure in fundamentally different ways.
Most enterprises are device-led, meaning they identify the capacity requirements and power and space constraints, and then select a device that matches the need. When they interact with their infrastructure, they work device-by-device, frequently using CLI or lightweight scripts as the preferred tool.
More mature enterprises are architecture-led. They might settle on a data centre architecture (for example leaf-spine or IP fabric), and then use that architecture to drive requirements into the individual devices. When they interact with the infrastructure, they operate at an architecture level, bringing tools like Puppet, Chef, and Ansible into play.
But, cloud companies are fundamentally operations-led. They decide first on their data models, telemetry, and data distribution strategies, using that to drive requirements into the architecture and ultimately the devices. By elevating operations to the top-tier in terms of design criteria, they optimise for automation. This is in stark contrast to enterprises that look at automation as a thing to be added after a deployment, relegating operations personnel to late-comers in the entire design process.
Nouns versus verbs
Most enterprises also lack nuance in their view of automation. When asked what they want to automate in a data centre network, for example, many will respond with “the network”. The problem here is that automation is about verbs, not nouns. Enterprises cannot automate the network any more than they can automate a table.
The key to automation is understanding what workflows exist within the data centre. Without understanding the workflows, most automation defaults to a set of basic tasks, in which case the true value of automation is heavily blunted by the target. And with very little benefit at the outset, it is difficult to justify sustained investment in the practice, leaving enterprises disillusioned upfront and poorly positioned in the end.
The key to identifying high-value workflows is understanding that automation is most valuable at the boundaries of three things—systems, people, organisations. The highest value automation targets will be workflows that span multiple systems and organisations. Imagine server set up as an example. This requires coordination between the server and network teams. If that workflow is automated so that the provisioning of the server automatically drives edge policy management in the network, the total keystrokes might be reduced by a small amount but the elapsed time is reduced by several orders of magnitude.
Enterprises looking to exploit automation need to bring multiple groups together to identify these workflows. Automation cannot be a pursuit independently pursued by different teams within IT. It requires group participation, which will stretch some enterprise operational models beyond what happens today.
To gain capability, give up control
Anyone who has followed the DevOps movement closely will note that automation and DevOps is as much about cultural change as it is about technology adoption. For operators accustomed to pinpoint control through precise configuration management, automation can be very uncomfortable.
In many ways, it is not unlike public perceptions about the safety of driving a car versus traveling in an airplane. While the statistics are clear, many people prefer the control they feel when behind the wheel. So it is with automation. Losing control is a scary proposition, but pinpoint behavioral specification—by the operator—is incongruous with highly automated environments. The key for enterprises is to move the control from people to machines, elevating the interaction with the infrastructure to higher-level abstractions.
Communities over products
Perhaps one of the most transformative changes coming about as a result of the automation push is the rise of communities over products. Enterprises frequently look to specific products as a means to automate. Increasingly though, those products are forged by communities rather than typical vendors.
There has been a meteoric rise in the use of open source tools and libraries as companies collaborate in the open to drive better operational practices across the entire industry. This means that enterprises looking to take advantage of innovation need to expand their purview to the open source world.
The challenge here is that most enterprises don’t have an open source practice. They are not skilled in dealing with open source. They lack the understanding of how communities work. They don’t understand how to evaluate open source projects, or how to contribute back to the community so that their needs are baked into future iterations of key technologies.
Enterprises interested in automation need to develop an explicit open source practice. They need identified leads responsible for evaluating open source projects for applicability. They should hire from the community to ensure that they are positioned to contribute back. It’s a change to more than technology—this gets to how companies view the marketplace and even how they build their teams.
It’s a journey
Ultimately, though, enterprises need to realise that automation is a journey. There is no shrink-wrapped solution to automation. By the very nature of enterprise workflows, automation is hyper-contextual, it is different in every environment. That means products alone will not solve the problem.
Companies should disavow any notion that there is a quick fix for automation ambitions. Rather, dutiful attention to improvement—executed over quarters and years—will result in tangible results. Of course, in three months it might be difficult to point out the advantages of a few automated workflows, but over the course of a few years, enterprises will look back and declare in hindsight that they have automated their data centre.
A final caution
It is worth noting that the push for automation is happening while the migration to cloud is underway. As companies move from legacy to cloud and multi-cloud environments, they will find that the operational boundaries that have historically existed between different parts of the infrastructure (data centre, campus, branch, and so on) will have to come down.
The real value of cloud will not be realised if workloads are constrained to specific parts of the infrastructure. This means that things like security and automation will ultimately have to evolve to account for what multi-cloud will require. Minimally, security and automation will need to span all parts of the enterprise IT ecosystem, from data centre to campus, which requires careful consideration of how that might impact technology evaluation.
Given the difficulties of managing transitions, enterprises will do well to pursue their automation agendas with multi-cloud in mind. After all, it would be a shame to cross the finish line only to find out you ran the wrong race.