Living in the Era of Policy Harmonization – The Prequel
“Never have been better days for the networking” – they say; “How come?” – the others ask. “I am supposed to become expert in automation and program templates, which then translate implicitly into my network configuration? Forget it!”
Well, yes and no. Things are not as black and white as may initially appear, but indeed, it is time to acknowledge the changes happening, and there are millions of ways to see the achievements. It feels like it is the best time to step out of the old habits and grasp the technology towards joint prospects. Resist, but try, fail then improve, but keep experimenting – it is well worth!
This blog is a time-machine that will take you through the age of technological changes
In the first journey, we will explore the events that preceded the disruption in the networking technology and how Cisco joined that journey. As we travel further, we will look closer on the policy model – from inception to expansion, (Blog 2).
The third stage of travel will finish with the datacenter evolution period (Blog 3). The forth and final trip, will guide you through the discoveries of the contemporary datacenter (Blog 4). Exploring specific technologies, recurrent innovations and novel solutions, we will eventually complete our journey with the current age – “The Policy Harmonization”.
We’ve observed a profound process changes throughout business organizations, campus and service provider space in the last years. These changes were initially driven by the digital era, which raised the number of IT applications that run within a single organization. To cope with the demanding business requirements on scale, virtualization has been identified as a key technology in the process of optimizing the application space by exploiting the hardware capabilities.
The revolution of Cloud
Settled on the well-established virtualization principles, the Cloud has revolutionized this technology into a winning model for CAPEX cost reduction. But it wasn’t until the new concepts were served (pay-per-use, on-demand, elastic, scalable, self-service) that the users started to realize all the beats and pieces required to establish a suitable service deployments in the cloud. The cloud providers anticipated the early-adoption caveats, by coming up with hybrid cloud offers.
This set the stone for mixed private-public datacenters, as a potential match for any type of service. Moreover, slicing the cloud stack into – IaaS, PaaS, and SaaS layers, was recognized as a sound approach to decoupe the application from the underlying infrastructure. Some were finally happy that the time of running cumbersome networks on-premise, was over. They found the public cloud to be the Jedi of their service infrastructure.
The breakthrough of Software Defined Network
Meanwhile in the datacenter chambers, a group of people did not find it quite conforming. The network became tedious and unable to sustain the burden of the complex cloud services. In other words, a network-level configuration was applied once, with a permanent effect to the running services and applications. The lack of adaptation to a dynamic behavior, and access to a higher-level (REST-based) management entity, preserved the network control exclusive to administrators and inflexible to changes. Now, let’s recall that the public cloud is hosted on private datacenter premises – a bonding that quickly urged for essential network improvements. And all these events, also pushed by a group of enthusiastic researchers, became a catalyst for the upcoming changes in the networking world.
Software Defined Networking (SDN) made a breakthrough that shifted the networking behavior to a new level. The concept of full visibility and control over the fabric data plane, seemed suddenly so appealing, despite the perpetual doubts for its full potential in leveraging prospective use-cases. Reality however marked a slight deviation from the scope: discussions were raised on tools, protocols and standards, less focus was turned towards exploitation. The “gurus” took the hard way of revamping the entire set of protocols, prior to aligning the gradual advances with the traditional networking environment. We admit, network changes are complex and take the burden of everything running on its shoulders. And yet somehow the message related to the SDN’s achievements for simplified network management and operations, wasn’t conveyed to the utmost.
Over time, everybody – from enthusiastic entrepreneurs to big enterprises – recognized in SDN an eventual enablement for their multi-location, large-scale datacenter deployments. Additionally, the majority of them contributed in promoting SDN adoption and improving its toolkit. One of the challenges that some SMEs encountered, was the lack of short-term strategy on how to capitalize using SDN. After investing in major infrastructure redesign, they found the initial benefits insufficient. Something was missing, which led us to search the rationale in the core of the solution. In addition to the lessons learnt, we created an action plan on how to apply the solution in order to solve relevant customers’ problems. SDN originated to revolutionize the traditional way we do networking. It made a huge impact, but the disruption was not meant to end there.
The Application Centric Infrastructure (ACI) form Cisco combined together, the lessons learnt from SDN and the networking innovations raised to a higher level – the application. ACI granted networking insights to the entire applications department, rather than allowing an exclusive networking visibility to a single control entity (centralized SDN), governed by the networking team alone. The “application defined network” is a distributed and robust way to introduce network changes using an abstracted, application-centric approach. Powered by the ACI policy model and a simple policy language, ACI stands out as a solution due to: (1) The unique way to dismantle the application’s network features into comprehensive objects; and (2) The seamless mapping between business requirements, and rules that enforce network adaptation in a coherent manner. ACI entrusted to the application – the puppet master role of the network. Acting as a mediator, APIC – the ACI’s SDN controller, takes the application requirements a.k.a. policies, and applies them to the network in a form of enforcement rules. Hence, such a setup makes a trade-off between the application’s emphasis on the network configuration on the one hand, and the network’s control of the fabric setup, on the other.
We’ve seen in this first journey, how some of the digital era events pursued a network to turn into software-defined. As a closure, we introduced the way ACI hooked into this trend. But why does ACI relies on policies, and how this relates to the Intent-driven datacenter? Stay tuned for the next blog, to travel through the datacenter evolution period and find the answers together.
Tags:
