Digital transformation sparks innovation in networking
The network needs to keep pace with the demands of exciting new technologies like containers and microservices, according to presenters at a recent industry event. The first step in that process is changing the culture.
As companies embrace digital technologies to gain agility, flexibility, and speed, applications take center stage. With the rise of container-based virtualization, lightweight, portable applications are being launched as discrete microservices that can be consumed anywhere and on all types of devices.
The underlying network that supports, secures, and delivers containerized applications needs to keep up with this new, build-once, run-anywhere style of application deployment or face the prospect of becoming a drag on digitization efforts. In other words, the network needs to automatically react to the connectivity requirements of the containerized app. It needs to become self-provisioning and self-healing. It needs to have security built in. And networking needs to shed the old “set it and forget it” mentality in favor of the DevOps mindset of continuous delivery and continuous improvement.
According to Zeus Kerravala, founder of ZK Research, “Legacy networks are rigid and operate in their own silo, making it difficult to align changes to the business and to applications with the network. Our research shows that the average time to implement a networkwide change is about four months, which is far too long for a digital business.”
Transformations are not driven just by technologies or products. It’s about how to put a business need into production, about people and processes, about how to create new services.
Pere Monclus, VMware Chief Technology Officer for Networking and Security
Kerravala added in an interview, “Networks need to evolve along two vectors. First, they need to become programmable so application changes can automatically trigger network changes, eliminating the need for manual intervention. Second, networks need to become more cloud-like, with network functions becoming available as services so that apps can trigger the use of a specific function instead of having to invoke the entire network stack.” That’s a tall order for an IT function accustomed to manual processes and hamstrung by a lack of modern tools. But there is reason for optimism, as evidenced by the fresh ideas presented by industry leaders Mastercard, Google, LinkedIn, and Microsoft, as well as startups Zingbox, SnapRoute, Kong, and Netifi, at VMware’s third annual FUTURE:NET 2018 conference on Aug. 30 in Las Vegas.
Speakers agreed that technology — software-defined networking (SDN), intent-based networking, and this year’s hot topic, service mesh — is important. But it all starts with people, with changing the culture and making sure that every team within IT, including networking, is fully on board and driving digitization efforts.
Culture, people, organization
“As technologists, it’s always easy to fall into how the next great technology is going to change the world. But in reality, transformations are not driven just by technologies or products. It’s about how to put a business need into production, about people and processes, about how to create new services,” said Pere Monclus, VMware chief technology officer for networking and security.
Ken Owens, vice president of cloud-native engineering at Mastercard, said he was brought in to transform the company’s credit-card processing capabilities from monolithic applications to digital architectures and cloud-native environments. “They didn’t tell me how painful it was going to be,” quipped Owens.
He said changing the culture is the most important aspect of his job. “You can’t just walk into a 30-year-old company and say, ‘All of you guys are going to move away from monolithic application development and do things with microservices and containers and go now. Start.’”
Owens said his approach is to take small steps, to deliver tangible results, and to continue to iterate and innovate. One key tactic is to identify people willing to become change agents. It’s also important to have a clear objective and to have the support of the company’s leadership team, he said.
From an organizational perspective, companies must break down silos between application development, operations, security, and networking teams, so that when an application goes live, all of the services that it needs automatically follow, no matter where that application is deployed.
Owens said most of his networking people remain busy keeping the lights on. But he also created a cross-disciplinary platform team that includes networking and storage, plus VMware, Windows, and Linux admins. The purpose of this team is to make sure there is an underlying platform to support new applications.
“At the end of day, I can make any technology work,” said Owens. “It’s really about how you can get people and process aligned in a way that you can execute at a much faster pace than you can today.”
Kerravala agreed. “The change in network technology needs to be aligned with a change in culture. The majority of network professionals fear automation as they believe it threatens their job. The fact is, network professionals are struggling to maintain the day to day and are not able to develop the software skills they need to compete in the future. Automation should be viewed as an invaluable tool as it can eliminate many of the mundane tasks that bog people down today.”
Managing microservices via service mesh
The momentum toward containers, microservices, and serverless computing can be seen as one continuous push to break applications into smaller and smaller components. The benefits are the speed, agility, and flexibility companies seek.
However, the end result is that each microservice needs to talk to multiple microservices in a specific sequence to accomplish a complete business process. It’s important to ensure the network meets the needs of each particular application. Visibility into that process is needed, in case something goes wrong and needs to be fixed. And security provisions must be baked in.
That’s where service mesh – a way to manage microservices – comes in, according to Louis Ryan, principal engineer at Google, which launched an open source service mesh project called Istio. With Istio and other service mesh offerings, companies can control the flow of traffic and API calls between microservices, provide security, apply policies, gain visibility, and make the network more robust.
Deepal Bansal, general manager for Microsoft Azure, describes the microservices architecture as “a swarm of worker bees.” He says companies can find themselves trying to manage hundreds of thousands of microservices.
Bansal added that what is required now is an integration between service mesh and SDN so companies can more easily manage their entire networking and apps infrastructure.
Innovation in networking
Cloud-native companies like Google and LinkedIn are rethinking networking in exciting ways that could spark innovation at more established companies with legacy infrastructures.
For example, segmentation or micro-segmentation is one of the cornerstones of networking security – networking teams create subnets for different types of traffic and apply the appropriate level of security based on the sensitivity of the data flowing across that network segment. Subdividing the network also reduces the attack surface, so a hacker who succeeds in breaching one segment doesn’t have access to the entire network.
But Google flipped this concept on its head. Google doesn’t use segmentation at all; every machine can talk to every other machine across Google’s entire network, according to Ryan. Google’s novel approach is to give every workload an identity and then to require mutual verification before any communication can occur. Also, data is encrypted as it travels across the network. This approach can reduce security risks and simplify security administration.
Networking in the driver’s seat
LinkedIn based its self-healing network on a do-it-yourself approach and open-source software, said Zaid Ali Kahn, senior director, infrastructure engineering.
LinkedIn’s original core network was unable to scale to keep pace with the company’s growth, according to Kahn. Approximately 590 million members use the platform today.
To step up scalability and to simplify its network topology, LinkedIn decoupled switching hardware from software, ditched traditional management tools like Simple Network Management Protocol (SNMP) and System Logging Protocol (Syslogs), and used its own scalable messaging system called Kafka, which currently manages 4.5 trillion messages per day. It also replaced a three-tier core network topology with a flat spine-and-leaf design, deployed an open source network operating system developed by Microsoft called SONiC, and began using machine learning to anticipate network failures. “We’re building toward a self-healing infrastructure that auto-remediates,” said Kahn.
In the traditional enterprise network environment of manual processes and fixed maintenance windows, it could take weeks for a firewall change request to be implemented. That doesn’t cut it anymore.
Networking needs to move at the speed of DevOps. It needs to become application aware, self-service, on-demand, and fully automated, said Guido Appenzeller, chief technology strategy officer for networking and security at VMware. And it starts by changing the culture so that networking teams see themselves as key drivers of digital transformation.
See how CenturyLink can help with your digital transformation and network strategy.
This article was written by MIT Technology Review Insights from MIT Technology Review and was legally licensed through the NewsCred publisher network. Please direct all licensing questions to email@example.com.
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.