LAS VEGAS -- Ever since server virtualization and cloud computing accelerated the provisioning of compute and storage...
resources, network infrastructure has been a notorious bottleneck. Enterprises that want an agile infrastructure want automation, but the question arises: How much network automation is too much? Enterprises need to find a balance.
During an Interop session, The Next Generation of IT: Service is King, panelists discussed how to establish the right amount of network automation in an enterprise infrastructure.
Network automation is not a simple matter because networking is not a simple discipline, said panel moderator Ethan Banks. "Networking guys spent a lot of time developing a skill set -- and that just covers Layer 1 through 3. Then you add load balancers and firewalls and deep packet inspection in the form of IDS/IPS [intrusion detection system/intrusion prevention system]. How do you make that simple?"
The complexity in networking arises from the persistence of manual processes that don't need to be manual anymore, said Jon Hudson, principal engineer from Brocade's office of the chief technology officer. "It [has] gotten to the point where you don't need to know routing anymore," he said. "There are a lot of things that we used to do by hand, that we enjoyed doing. But you reach a point where it's just not useful anymore. There are so many moving parts. You need to be able to push off more work to automated systems."
Hudson even suggested some enterprises might not even need oxygen in their data centers. Engineers could strive to have no human intervention in the physical infrastructure once components have been racked and stacked. Then they could fill their environment with a gas more conducive to cooling equipment.
But some of the resistance to automation is understandable. There are questions of risk and trust that network engineers must address.
"We often encounter that question of what is the limit to which people want to automate something," said Steve Riley, technical director of the office of the CTO at Riverbed Technology. The automation of quality of service (QoS) is a good example, he said. An enterprise may want to apply a certain level of QoS to a voice conversation, but automatically prioritize a higher level of service if someone elevates that call to video.
"But what if we [accidentally] automate higher QoS for some malicious payload or a very unusual payload that we don't normally allow?" Riley said. "Do we want to automate some changes to firewall rules and capacity? I don't know."
"With great power comes great responsibility," Brocade's Hudson said. "If you have a very powerful [automation] tool, it can do a lot of creation. But it can also do a lot of destruction if you are not careful."
One engineer in the audience said he was comfortable with automating tasks that are typically performed by low-level administrators. But tasks done by high-level engineers are too strategic and present too much risk for automation, he explained.
Another engineer said he is comfortable automating things that can accelerate time-to-market and troubleshooting, but is "less comfortable automating things that can be disastrous if things go wrong."
The industry has seen those disasters, according to Steven Carlini, senior director of data center global solutions for Schneider Electric. When a circuit breaker caused an outage at Amazon Web Services that lasted nearly 36 hours, Amazon's service techs didn't have the tools to deal with it quickly. "They were down for a day and half because they didn't have the necessary staff in place. It's important when taking on automation that you understand risks are involved," Carlini said.
That outage made news, Riverbed's Riley said. But AWS customers who had embraced automation were minimally affected. "If you are a customer who designed your service appropriately, that outage is a non-event. A lot of that has to do with automating moves around data centers from region to region."
Let us know what you think about the story; email: Shamus McGillicuddy, news director, or follow him on Twitter @ShamusTT.