Tag: sdn

  • Managing a New Kind of Complexity in Software-Defined Networking

    Managing a New Kind of Complexity in Software-Defined Networking

    Software-defined networking (SDN) has moved up the enterprise IT agenda in recent years. And it’s easy to see why–in theory, SDNs are far quicker and easier to control and alter than traditional networks. By using open protocols to apply controls from the network edge, SDNs enable network engineers to shape traffic from a single centralized console, rather than working with individual switches across the network.

    In turn, this makes software-defined networks far more agile than traditional networks, with opportunities for automatic load balancing, streamlined processes, on-demand provisioning of new applications and traffic flows–in short, a network that works much harder for the organization. So, it’s no surprise that organizations are embracing SDN. A 2019 Verizon study found that while just 15% of respondents said their companies had implemented SDN, 57% expected to do so within two years.

    However, deploying SDNs can introduce new challenges for network staff revolving around complexity–in particular, complexity in relation to managing network security. Let’s take a closer look at what this means.

    A Shift in Complexity

    Any organization that moves to a software-defined environment essentially moves from datacenter-focused firewalls into a model where its security policies are defined by software within its fabric. This requires a far more granular level of security policies, on a much larger scale and with far more agility, than in traditional networks. Why? Because security controls are much more diverse.

    In a traditional setup, network security policy is relatively monolithic. A set of servers is protected by a perimeter firewall, filtering so-called north-south traffic that enters the network from the outside. Traditionally, east-west traffic within the datacenter itself is not subject to any filtering, which introduces security risks–particularly in terms of enabling malicious parties to laterally explore the environment once they have compromised a single endpoint.

    By contrast, in an SDN environment, built-in firewalls are considered part of the infrastructure. It is likely that the organization will have multiple tenants, each containing a unique set of granular security policies dictating which assets can connect to which other assets within the SDN fabric. An SDN environment is likely, for example, to incorporate one contract with Cisco Application Centric Architecture (ACI), VMWare NSX distributed firewalls and so on. There is a lot of complexity to manage.

    Ultimately, the organization in question needs to identify which elements within the newly software-defined network need to connect to each other. Then, create granular security policies that enforce this, dividing the network into smaller zones to prevent lateral infiltration by malicious parties. In short, they need to introduce micro-segmentation. 

    Managing Micro-Segmentation

    There are two main challenges associated with micro-segmentation from a security point of view. First, the organization needs to define the micro-segmented zones, and second, it needs to enforce and maintain the security policies that enable that micro-segmentation.

    How do we define micro-segmentation zones? This is all about understanding the assets within your environment, which databases contain the most sensitive data and therefore need to be segmented off from each other, which assets are talking to each other and how traffic is flowing throughout the network. Crucially, all this should be contextualized in terms of business applications–in other words, you need to understand the traffic that makes business applications work. This enables you to design a micro-segmentation architecture–and the security roles to enable it–that are centered around your business-critical services. Solutions that automatically discover and map all of the traffic flows within and through a datacenter are invaluable at this point.

    Then we move onto enforcement and maintenance of those rules on an ongoing basis, and this is where a security policy management solution is truly critical. All this complexity and dynamism cannot be managed manually. Each time a new business application is introduced, or an existing one removed or amended, the security policies also need to change–and these changes could be happening on a daily or even an hourly basis in a large organization.

    Automating the Management Process

    So, given the flexibility and rapid changes that SDN enables, how should organizations approach managing and maintaining security policies across their entire enterprise network? The most effective way is with an automation solution that holistically supports the SDN environment and its security controls, alongside existing traditional on-premise firewall estates.

    It’s important to note that the SDN deployment will be subjected to the same compliance and auditing requirements as existing networks. The security management solution must be capable of providing visibility across both physical and virtual network functions so that the overall compliance status can be centrally monitored and logged for audit purposes.

    Automated security policy management solutions generate filtering policies based on enabling only the traffic required for every application in the datacenter. This is a way of approaching intent-based networking, which comes back to looking at the components of each individual application and how they are communicating with each other. Furthermore, automated security policy management solutions audit and record every single change that is made across the network, making it easier to demonstrate compliance continuously.

    With the right automation solution, IT and security teams can eliminate time-consuming, error-prone manual security processes, such as connectivity discovery and mapping, migrating and ongoing maintenance of their environments. This frees up the teams to strategically maximize the benefits of the SDN deployment, and reap its rewards of increased flexibility and enhanced network security.

  • Why SDN’s Hot Streak Continues in 2020

    Why SDN’s Hot Streak Continues in 2020

    The software-defined networking (SDN) market is expected to grow by double-digits between now and 2023, driven by the increasing mainstream adoption of this technology. And for good reason: SDN gives IT the ability to make changes through software code instead of reconfiguring each device, and manage data traffic from a central console to move it in any direction.

    Communication gear still drives the physical movement of bits, but software drives the data plan and the control plan. This allows network managers—and even applications—to dynamically manage network resources based on complex system needs. SDN supports real-time integration across multiple servers, services and clouds, and it also processes huge volumes of data. IT departments can now overcome traditional networking issues such as performance bottlenecks and develop a more responsive network strategy.

    SDN Plays a Critical Role in Cloud Adoption and Improves Security for IT Departments

    SDN architecture integrates easily with cloud-based environments, both public and private ones. This gives network managers greater flexibility, speed and automation in managing their network clouds.

    On the security front, SDN allows an IT department to divide a network connection between an end user and the data center, and provide different security settings for the various types of network traffic. For example, a network could have one public-facing, low security network without any sensitive information. But another network segment could have a software-based firewall and encryption policies that allow for more sensitive data to travel over it. Having the ability to match security policies to specific workloads is a key advantage of SDN. 

    One of the hottest trends with SDN is microsegmentation, where IT professionals customize security settings to different types of traffic. With this security model, the goal is to apply segmentation rules down to the workload or application. This mitigates the likelihood of an attacker migrating between compromised workloads or applications to others. Basically, microsegmentation creates intelligent groupings of workloads based on their characteristics as communicated inside the data center. This approach does not depend on dynamically changing networks, specific business or technical requirements which means microsegmentation provides enhanced security.

    The software-defined wide area network (SD-WAN) takes SDN even further by connecting enterprise networks over large geographical areas, such as branch offices and data centers. Traditional WAN connections typically needed technology that required special proprietary hardware. SD-WAN moves more of the network control into the cloud through software, allowing for greater scalability, flexibility and reduced hardware costs. SD-WAN is expected to grow even faster than SDN in the coming years for several reasons:

    • Greater reliability of application performance, a huge advantage for users in today’s digital workspaces.
    • High level of connection security for cloud applications without performance trade-offs.
    • Increased bandwidth which reduces congestion and slowdowns.
    • More business agility through faster deployments of new applications.
    • Simpler IT administration through a centralized console instead of in-field configurations.

    SDN and its offspring of SD-WANs continue to defy expectations in creating greater agility, flexibility, security and reliability. Leading-edge IT organizations are embracing the imperatives of digital transformation through SDN and SD-WAN to provide for agile deployment, provisioning and operational management.

    — Melinda Cross

  • Why the Buzz on Software-Defined Everything (SDx)?

    Why the Buzz on Software-Defined Everything (SDx)?

    You’ve likely heard the buzz getting louder the last few years around software-defined everything (SDx). You’re probably finding a swarm of companies knocking on your door selling a host of services around implementing software-defined networking (SDN), software-defined storage (SDS) and software-defined data center (SDDC). What you may not realize is that this software-defined movement is truly a disruptive technology shift that is dramatically changing the way an organization accesses storage, networks and data centers.

    The overarching mission of SDx is to break down the discrete IT silos (compute, storage and networking) by using software to bridge the technological and organizational gaps. By giving software systems a starring role in managing different kinds of hardware, the premise is that productivity will increase through more robust network access from both portable and traditional devices. 

    What are the true potential and outcomes of SDx that an IT administrator can tout to management? For starters, early adopters have reported being able to deliver significant cost savings and greater speed of delivery. They cite benefits such as decreased hardware costs, greater automation, more rapid deployment of IT resources and shorter timelines to implementation—to name the key ones. 

    Let’s take the traditional data center, where most organizations grapple with the high costs of ongoing management and maintenance of network switches, servers, storage devices and other hardware. Keeping these resources updated can be complex and expensive for an IT department. Moving to an SDDC, for example, can lower the total cost of ownership by reducing hardware costs (servers, racks, disk and tape, routers, etc.), and minimizing the data center size and the use of power, cooling and ongoing maintenance. With an SDDC, the IT department enjoys the benefits of a more simplified process that increases the speed of appropriating and provisioning networking. Software-automated provisioning can enable application deployment within minutes, for example.

    Instead of the IT department being considered a hindrance, SDDC allows developers to create applications that are best for the business, instead of what works based on the hardware.

    “Every technology organization needs to be able to transform ideas into working functionality that creates value for customers. That means you need not only world-class development processes but infrastructure processes as well—and that’s where software-defined data centers become absolutely relevant,” said Gene Kim, co-author of  “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.”

    The main elements of an SDDC include:

    • A software implementation of a computer, which is called virtualization.
    • An SDN where hardware and software resources are merged into a software-based virtual network.
    • An SDS that includes storage virtualization. 
    • Automation software that allows an IT administrator to provision, control and manage all SDDCs components.

    The second big driver of SDx adoption by IT departments is the increased agility they experience in responding to business demands. Much of this is made possible with SDS, which is an innovative way to restructure your infrastructure by separating hardware from software, and using software in place of disks and networking devices. SDS uses standard servers to manage storage requests by virtualizing your physical storage. This gives you more control over where and how data is stored.

    Some of the key benefits of SDS over traditional storage include:

    • Automatic storage management capabilities reduce the number of manual tasks for your storage administrators. They adapt to different needs without any human oversight or new hardware requirements.
    • Flexibility to increase your storage requirements while decreasing the capacity of your existing hardware.
    • Lower costs since SDS solutions run on standard hardware, and the automation reduces the number of administrators required. 
    • More scalability options, depending on your business requirements, by adding extra storage arrays or including additional CPUs and memory.

     

     

    As business requirements continue to increase in speed and number, forward-thinking IT departments are moving away from hardware commitments and rigid architectures that constrict their ability to react and adjust to changing needs. Software-defined technologies are becoming the innovative powerhouses behind building more efficient and agile IT services for today and well into the future.

    — Melinda Cross

  • IBN’s Success is Driven by Formulating the Right Test Validation Strategy

    IBN’s Success is Driven by Formulating the Right Test Validation Strategy

    Intent-Based Networking (IBN) is widely considered to be the next big innovation in networking industry. IBN is all about simplifying the process of implementing new upgrades and changes in any networking environment to ensure the results match the original intent. IBN can be considered a successor to software-defined networking (SDN) as it seeks to automate networking operations while better aligning networks with business intent.

    IBN helps to automate operations that were traditionally performed by network analysts or network support engineers through an intent based model. This is achieved by creating a level of abstraction that through certain orders, points out the service or application to be added, which automates all network configuration and management activities.

    The Challenges Posed by SDN and NFV Based Networks

    A number of organizations are making long-term investments in the cloud and are just beginning to realize the benefits of NFV and SDN. As a result, we’re still in a transitionary phase until the transformation is complete. As businesses continue to make this transition, there are a few key considerations from an INB architecture point of view that need to be considered before embarking on this journey:

    • Analyze each networking program in your roadmap and define if intent-based networking can be added to these projects well before integrating IBN into the network architecture.
    • Ensure robust and thorough monitoring and assurance systems are in place.
    • Identify and examine the application programming interfaces (APIs) in the network architecture to determine if they will work with IBN. For instance, Nemo API in ODL/ONOS Controller.
    • IT network teams should have a single pane of view across architectures, data centers, campuses, branches and cloud platforms.
    • Ensure the network architecture has considered the necessary security elements required.

    How IBN Ensures a Holistic Approach to Network Intelligent Verification

    Unlike the traditional interpretation of network verification, the intelligent network verification I’m alluding to is able to consider network design, configurations and prevailing or existing network states to accurately assess network activity. It does not consider live traffic flows and pre-defined testing scenarios hence aiding in the verification of a negative scenario–something traditional testing can seldom accomplish.

    As IBN possess the ability to consider the complete network as a single entity, it facilitates a comprehensive approach to network verification. As a result, organizations are more effectively able to validate the behavior of the network, based on its configuration and state, with the higher-level intent.

    IBN Necessitates a Fundamental Shift in Network Design and Testing

    IBN is shifting the network IT model from a reactive approach to a more proactive software-driven approach where an automated analysis of current network designs can virtually eliminate human errors and misconfigurations. The automation verification enables is helping to replicate and augment the network expertise of the IT staff in troubleshooting and triaging issues during outages, verifying fixes provided by vendors and documenting procedures and workflows.

    There are newer testing challenges popping up due to factors arising from multi-vendor software platforms, protocols and APIs operating together in this environment.

    One good practice to be adopted before designing a new testing approach would be to look deeply at the critical dependencies in designing an IBN Solution. However, while migrating from an existing network to a virtual network, both networks must be re-validated thoroughly.

    Designing a Testing Validation Strategy that Delivers Value

    To tap into the full benefits, it is clear SDN and IBN must be integrated together to exploit their potential. Hence, it is critical to have a testing approach focused on five important areas.

    These areas along with the relevant tests that need to be considered are highlighted below:

    1. Business Policy: Policy conversion to technology and map test, service design and logical topology test, username to host mapping test and REST API functionality test.
    2. Automation: Service placement test, service functional test, service performance test, policy validation test (user intent and policy change validation).
    3. Assurance: End-to-end monitoring test, performance of user intent and usage of resources test, performance of SLAs and service profiles test (traffic throughput, latency, jitter).
    4. Programmable Network Infrastructure: Southbound API test (NEMO API), OpenFlow test, Ovsdb test, network management test.
    5. Security: Service convergence test, conformance test (IBN customer specs conformance, Intent vulnerabilities reporting).

    Testing is Critical to Ensuring the Success of IBN Automation

    With constant transformation of the network and associated technical complexities faced by network engineers, verification becomes an important step for enabling IBN to achieve its objectives in an SDN-based IBN network architecture. While companies are still allowing software to drive their IT upgrades completely, a focus on a well-defined testing approach is critical to provide the much-needed predictability and assurance required for a successful IBN implementation.

    Adopting a layered and integrated approach provides significant benefits related to early detection of bugs, improved test cycles through automation, predictability of outcomes, increase in confidence levels, enhanced scalability, improved security guidelines and adequate testing to ensure smooth delivery.

    After all, when the Intent is right and more importantly validated, all the pieces come together to drive business agility.

    — Jason Chandralal

  • DevOps: Embracing the Telco Cloud

    DevOps: Embracing the Telco Cloud

    Ongoing developments in technology have led businesses to look to the cloud for greater flexibility, scalability and processing power. The telecoms industry is no different. Under growing pressure to meet the demands of the internet of things (IoT) and 5G, service providers are increasingly adopting cloud and virtualization technologies such as network functions virtualization (NFV) and software-defined networking (SDN) to provide them with the capacity they need to manage the explosion in data traffic.

    In an environment in which traditional telco revenue has been eroded by OTT (over-the-top, or IP-delivered) players, the commercial advantages offered by a telco cloud have never been more important. It’s hardly surprising then, that the global market is expected to grow at CAGR of 20 percent, reaching $29 billion within the next two years.

    Don’t Believe the Hype

    Despite the messages of benefits, however, operators have reservations, with many expressing concern that the hype around the promise of NFV and SDN is just that—hype.

    During a panel discussion at the MPLS, SDN and NFV World Congress 2018 in Paris, representatives of Orange and Nokia, among others, raised questions over the current level of investment in the technology. SDN was described as “not really a new concept” and NFV as being a “bubble.”

    It was additionally suggested that the benefits of virtualization weren’t particularly economical. Operators are becoming increasingly aware that the cost savings that NFV promises often are offset by the need to deploy entire racks of compute resources to handle processes that previously would have been supported by a single appliance. When you factor in the CPU and server requirements, along with the necessary power and physical rack space, the cost of delivering the same performance as a dedicated solution can be at least as expensive as a custom-designed alternative.

    Performance and Power

    Given the fundamental role that both SDN and NFV play in underpinning telco cloud, opinions such as those expressed in Paris are concerning—particularly when publicly voiced and apparently widely held. It’s clear then, that if they’re not already doing so, operators need to address these issues to realize the potential of telco cloud in the most cost-effective and efficient way possible. Indeed, time is of the essence, as the performance and scaling problems that operators face with generic NFV infrastructure are only set to get worse once 5G networks are fully implemented. The sheer volume and speed of data traffic through a 5G network, for example, will bring entirely new requirements in terms of scalability and performance.

    Encouragingly, though, steps are being taken to tackle technical challenges around performance and power consumption, particularly with regard to generic hardware. By distributing workloads between x86 general purpose processors and software-reconfigurable, FPGA-based SMARTNICs that are optimized for virtualized environments or VNF re-architecture, operators are turning to hardware acceleration as a means of improving performance both now and in the future.

    Look into the Cloud

    The analyst forecast mentioned at the beginning of this article illustrates that, while discussions continue around the relative economic benefits of virtualization, there’s no denying that cloud-based network infrastructure is beginning to take root across the telecoms industry.

    Increasingly we are seeing operators moving workloads on to virtualized or containerized infrastructure, for example, as they look to improve performance, reduce costs and hyperscale as required by their various network functions, applications and services.

    What’s more, inspired by other sectors that have successfully leveraged cloud-native functionality, operators are embracing Agile and DevOps development practices. Telco cloud provides operators with the development agility they need to combine and re-combine existing functions that, when tested and proven for scale, can deliver entirely new network capabilities. With the ability to quickly bring innovative new ideas to market, operators now have a new avenue of revenue to explore.

    The benefits extend into the wider ecosystem, too. Not only will an open multi-vendor platform running on open source software improve operational and cost efficiency, but by allowing software from multiple vendors to be more quickly integrated, it will enable the creation of innovative new network services and IT functions that, in turn, could led to new revenue streams.

    And, of course, the new paradigm shift will improve the customer experience. Shortly after last year’s Mobile World Congress (MWC), for example, Verizon and Colt carried out the first demonstration of two-way, inter-carrier SDN orchestration, making near real-time bandwidth changes in each other’s production networks. The implications of this are significant, offering enterprise customers in particular flexibility on demand.

    The 5G networks and the new generation of handsets, including foldable devices, dominated this year’s MWC. One look at the show’s agenda, however, shows just how important the cloud has become. And in meeting the demands of 5G and all it entails, its importance will only grow. It’s time, then, for operators to take a serious look into the telco cloud.

    — Naveen Kumar

  • OpenStack and Open Source MANO: Technologies for NFV Deployment

    OpenStack and Open Source MANO: Technologies for NFV Deployment

    We have experienced how open source software technologies revolutionized the application development process, which ultimately resulted in digital transformation across various industry verticals. Open source technologies now are disrupting the telecom sector for building 5G internet, which will be powered by network functions virtualization (NFV) and software defined networking (SDN). With NFV and SDN, multiple network functions and control and management operations in telecom networks will be software-driven; enabling the cloud-native and DevOps approach.

    There are various communities emerged to innovate the software stack behind NFV and SDN technologies such as OpenStack, ONAP, ETSI Open Source MANO (OSM), OPNFV, OpenDaylight, Open Networking Foundation (ONF), Open Contrail, Open Baron, On.Lab, CORD, Kubernetes, ONOS and Open-O. In this article, we will take a look at how a combination of data center management platform management platform, OpenStack and ETSI Open Source MANO (OSM) will be useful for NFV deployment.

    OpenStack for NFV

    As we know, OpenStack is mainly known to be the largest pool of open source projects that collectively form the software platform for cloud computing infrastructure. This infrastructure is used widely in private cloud use cases by many enterprises. After an introduction of NFV by ETSI, OpenStack has emerged as a key infrastructure platform for NFV. In most of the NFV deployments, OpenStack is used at the VIM (virtual infrastructure manager) layer to give a standardized interface for managing, monitoring and assessing all resources within the NFV infrastructure.

    Various OpenStack projects (including Tacker, Neutron, Nova, Astara, Congress, Mistral and Senlin) are capable of managing virtualized infrastructure components of NFV environments. As an example, Tacker is utilized to build a generic VNF manager (VNFM) and NFV Orchestrator (NFVO), which help in the deployment and operation of VNFs within NFV infrastructure. Additionally, integrating OpenStack projects introduces various features to NFV infrastructure, including performance features such as huge pages, CPU Pinning, NUMA topology and SR-IOV; service function chaining, networking slicing, scalability, high availability, resiliency and multisite enablement.

    Telecom service providers and enterprises that have implemented their NFV environment with OpenStack include AT&T, China Mobile, SK Telecom, Ericsson, Deutsche Telekom, Comcast and Bloomberg.

    Open Source Mano (OSM) for NFV

    The management and orchestration (MANO) layer is responsible for orchestration and complete lifecycle management of hardware resources and virtual network functions (VNFs). In other words, the MANO layer coordinates NFV infrastructure (NFVI) resources and maps them efficiently to various VNFs. There are various options available as three-dimensional software stacks for MANO. But ETSI-hosted OSM is largely preferred due to large activity at the community level as well as its highly mature framework, production readiness, ease of initiation and constant feeding of use cases by members.

    Virtual network functions (VNFs) forms network services and may need updates for feature addition or patch for functionalities. OSM provides a method to invoke the VNF upgrade operation with minimal impact in the running network service.

    With the continuous community support and involvement for feature innovation, OSM has now evolved to bring a continuous integration and continuous delivery (CI/CD) framework at MANO layer.

    The latest release 4 of OSM has brought a large set of features and enhancements to the OSM framework, impacting functionality, user experience and maturity, which enables various enhancements for NFV MANO from usability and interoperability perspective.

    OSM has steadily adopted the cloud-native principles and can be easily deployed in the cloud, as installation is container-based and runs with the help of container orchestration engine. A new northbound interface aligns with ETSI NFV specification SOL005 and provides dedicated control of the OSM system. Monitoring and closed‐loop capabilities have also been enhanced.

    The next version of OSM release 5 is expected to be launched in November and will be bundled with more 5G-related features such as network slicing and container-based VNFs.

    Why OpenStack and Open Source MANO for MANO layer in NFV?

    Both OpenStack and OSM have a large community known for its rapid pace for innovating NFV and higher contribution by all scale companies to enhance current features and develop new capabilities for core projects under it.

    For NFV, OpenStack standardizes interfaces between NFV elements and infrastructure. OpenStack is used for commercial solutions offerings by companies including Canonical/Ubuntu, Cisco Systems, Ericsson, Huawei, IBM, Juniper, Mirantis, Red Hat, SUSE, VMware and Wind River. A large percentage of VIM deployments are based on OpenStack due to the simplicity in handling and operating various projects targeted toward providing full potential storage, compute and networking for NFV.

    With last two releases (3 & 4), OSM has evolved to support integration for cloud-native approach by enabling CI/CD frameworks into orchestration layers. Cloud readiness involvement of OSM is the key benefit along with OpenStack, which has proven architecture for private as well as public clouds. OSM deployment into NFV infrastructure has become very lean, where one can start with importing docker containers into production. On the other hand, OpenStack is known for enabling simplicity to manage virtualized and containerized infrastructure. Organizations can realize the full benefits out of integration as NFV MANO using OSM and OpenStack due to lean and simple management and deployment.

    Conclusion

    Since the introduction of NFV and SDN, telecom service providers and vendors were evaluating the use case offered for telecom networks, and due to this application of both, were in under maturity stage. Service providers and vendors were concerned about dynamic orchestration and automation of infrastructure deployment and constantly upgrading virtual network functions (VNFs). But due to contribution by open source communities such as OpenStack and Open Source MANO (OSM), they are now at the stage to apply cloud-native principles to 5G network implementation and operations. Furthermore, with contributions by communities to OpenStack and OSM projects, we will see more enhancement to 5G network enhancement technologies including network slicing, mobile edge computing (MEC) and cloud radio access network (cRAN), which will benefit emerging technologies including IoT, AI/machine learning, real-time analytics, augmented reality (AR) and virtual reality (VR) with low latency and high-bandwidth features.

    — Sagar Nangare

  • SDN/NFV DevOps: Release Automation for Network Operators

    SDN/NFV DevOps: Release Automation for Network Operators

     A powerful force is waiting to be unleashed. Software defined networking (SDN) and network functions virtualization (NFV) are already acknowledged as exciting possibilities in the world of telecom and media. Leading providers, such as Verizon Enterprise Solutions and My Republic, along with original equipment manufacturers including Cisco Systems and Ericsson, have unveiled their SDN-based services.

    In the near future, all physical devices in the network will undoubtedly be replaced by SDN/NFV. Analysts predicted millions of additional devices on network because of the internet of things (IoT) and smart home intelligent devices, which necessitates the need to automate release and deployment on the networking layer to deploy components and upgrade patches to both the southbound network components and northbound applications. So far, release and deployment is successful on the application layer, but network administrators will be challenged in the near future to manage the surge in demand without a seamless automation solution to manage new devices on the network.

    In this article, we’ll take a look at various real-life scenarios to build a business case to solve bigger problems in networking—including reducing overall provisioning time, mean time to recover from failure, round-trip time for a packet to enable a usable application or time to free up/repurpose a network resource—that apply to all edge technologies. The solution lies in leveraging DevOps container-based solutions and scaled agile and SDN/NFV controller engine module customizations, and a non-prescriptive approach to products or solutions.

    These technologies are the new beasts in the market, but how can SDN go beyond merely saving money for telecom and media companies? How can it provide an enhanced, immersive digital experience, reduce customer churn rate and create new revenue streams? That is where DevOps steps in.

    The DevOps Approach to SDN

    With mobile, cloud, and IoT creating futuristic applications, consumers require strong underlying network speed and reliability.

    The DevOps solution to SDN/NFV is an ideal means for network operators to transition seamlessly from physical networks to futuristic SDN/NFV networks, to provide uninterrupted digital experiences for users, and to achieve high customer retention. DevOps enables a close collaboration between developer and network operators to eliminate many of the pains of introducing new software and services to market. Similar to the system development life cycle, the automated release and deployment process of DevOps enables frequent and incremental updates of network components in near-real time.

    The symbiotic relationship between SDN/NFV and DevOps is a dream. The software-defined and virtualized network elements remove the hassles of configuring and upgrading the physical networks’ devices. DevOps adds to this agility and programmability to streamline and shorten the implementation cycles, paving the way for automated service delivery. In turn, SDN and NFV create an elastic network environment, managed from a central location, to program and rapidly deploy new functionality on the network.

    Service providers can drastically reduce the time it takes to create and provision those network services, gaining a significant time-to-market advantage that helps them acquire new customers and retain existing ones. In the process, they can achieve higher revenues and cost savings, too.

    Creating New Dimensions in the Customer Experience

    Tech support has moved from phone to video, but before long, a centralized monitoring system will be able to auto detect and self-heal all issues related to virtual assets on the network. This will provide a more continuous experience for customers. For example, in case of any unexpected service interruption, TV channel providers’ AI-enabled systems will be able to record live programs and play back those interrupted periods to their viewers.

    Deploying a vendor-agnostic reliable SDN is a wait-and-watch situation for TV channel operators and telcos. Replacing their physical devices (including the conventional routers and switches) with software-enabled virtual devices will bring down printed circuit board (PCB) replacement costs and other associated maintenance fees. As reliable network bandwidth becomes all the more critical to improving channels’ television rating points (TRP), telecom carriers and TV channel operators are converging.

    Digital operators looking beyond TV and telcos anticipate millions of smart home appliances (such as security systems, microwaves, refrigerators and temperature control devices) controlled through the network by users from any remote location. Network administrators want to apply patches and upgrades to any SDN/NFV device, and to proactively fix any network-related issues without bothering their customers. Consumers may be controlling those home appliances from connected cars using mobile devices, so they may not be available physically to read glowing and blinking lights or to reset undecipherable, hard-to-access conventional modems and routers. Network providers are expected to manage millions of devices and provide uninterrupted service, so this paradigm shift, aided by technology transformation, has become imperative not only to reduce the call volumes of help desks but also to retain customers and acquire new ones. 

    Future-proofing for Technology Shifts    

    It is important to realize that telco carriers and TV channel operators are no longer merely confined to the communication and entertainment industry. With their scope vastly expanding into managing and controlling millions of household devices on their networks, it is imperative to future-proof technology with automated release-and-deployment processes over the network to support those devices.

    Some of the latest DevOps zero-touch release automation (RA) solutions can reduce the overall service provisioning time from months to a few hours. The scope is not just limited to configuring the southbound virtual software devices but may also be required to configure and manage northbound SDN/NFV applications to fulfill the ever-growing market. Having a graphical user interface (GUI)-based orchestration dashboard for network management can enable existing admins to continue without needing to acquire additional, niche skill sets to manage the new, massive networks.

    While release automation has been successful on the application layer, it has yet to prove itself on the networking layer. For SDN/NFV, release automation is just an engine that can be fitted into any controller to do virtual local area network provisioning, virtual management of firewalls and network functionalities management. Since there will be a shift from physical devices, there will be a desperate need to automate release and deployment of software versions on such networks.

    Adopting a DevOps strategy into SDN deployment requires a cultural shift from the traditional “big-lab,” acceptance-testing mindset to the “here-and-now” daily incremental changes in a live network. It calls for engineers to collaborate in managing the critical network-applications relationships. Consulting skillsets might be needed to assess the extent of customization required for legacy systems and to understand which technology solutions can deploy SDN, NFV and DevOps.

    It is clear that this industry will undergo a paradigm shift, and this technology is just crossing the chasm. Early adopters can give themselves an edge by leveraging compelling value propositions.

    — Ramesh Ganapathy

  • NetOps: Thorn in the Side of Continuous Deployment?

    NetOps: Thorn in the Side of Continuous Deployment?

    Over the last few years, we have definitely gotten continuous integration and continuous deployment (CI/CD) down. We now can maintain a relatively constant flow of deployable code sitting and waiting for the actual deployment step to take them to production.

    Moving to production has been the point at which caution is introduced into the system, though, and that’s certainly not always a bad thing. Deployment to production seems to be following the motto our parents taught us: “Just because you can, doesn’t mean you should.” In many environments, multiple deployments a day would be a ridiculous goal; in some, even multiple deployments a month are unreasonable.

    Let’s face it, in an enterprise that had 18-month waterfalls for even mid-level projects, the ability to deploy at any time (and, thus, near-continuous test) is an improvement of nearly unimaginable proportions. And deploying three times in a day makes little sense if you need user input to adjust the project.

    Other Reasons Exist

    But there are other reasons that continuous deployment is not as pervasive as the other portions of a continuous pipeline. We’ve talked a bit about security, but let’s cover another bit today: the network.

    There are several reasons why networking slows deployment efforts, and all of them are real reasons that an organization that  aims to increase deployments over time should consider.

    First, the network is the corporate lifeblood. Operations is naturally very careful about changing settings and loads rapidly, which can result in problems for the corporate network. This concern is lighter for products deployed to the cloud, because things such as virtual private clouds (VPCs) can isolate the impact network changes have on the overall production architecture. But there are still security concerns around making rapid, automated changes to the network environment, even in the cloud. The network (and the apps it exposes) is the point of entry for a large number of security compromises, and we’ve seen some whoppers in the cloud of late.

    Second, and only barely behind standard ops network concerns is integration of networking into standard CI/CD tools. It’s coming, but we’re not there yet. On the Ops side, things have moved along better: Puppet, for example, can plug commands in to networking devices from stalwarts including Cisco Systems and F5 Networks. But the support is still somewhat limited, partially by the level of APIs the vendors offer, partially by the maturity of those APIs and partially by the implementation on the DevOps tool side.

    And That’s a Good Thing

    Even if automation came along full-bore, it is likely that networking concerns would still slow the CD pipeline, as admins want to make certain changes are not going to leave them spending the night trying to put things right.

    And I think that’s a good check on DevOps. I love DevOps and the increased delivery timelines it enables. In the end, the entire business becomes more agile because IT is able to deliver at a faster rate. But sometimes it—the pace at which things go out—feels reckless. In certain areas—security and networking primarily, but also load distribution on servers—there should be sanity-checking before rolling out. Anything that can impact the entire application, or even the entire infrastructure, is worthy of a last double-check.

    I know I’m not in the majority on this one. DevOps fever can have people saying nothing should slow the pipeline, but I know from experience. Long weekends fixing what could have been caught on the way to production have taught me to be cautious. Save rush deployments for a time when there’s a reason to rush. Sometimes it’s necessary to get it out the door today, but talking about slower deployment in a continuous environment as if it’s a fault ignores the strengths it offers as the last stop to public-land.

    Do What’s Best for Your Org

    Networking vendors will continue to improve the programmability of their devices, and what software-defined networking (SDN) has grown/is growing into will offer a different place to flip the levers for continuous deployment. So if you need to deploy many times a day, and make changes to networking, focus on security and let networking support grow on its own. If you don’t need multiple deployments per day, then relax and don’t get all pressured about how long deployment might take. You’re faster than you were, and if you need more speed, take advantage of the growing support of automation tools.

    — Don Macvittie

  • Why DevOps Should Care About SDN

    Why DevOps Should Care About SDN

    Software-defined networking (SDN) and DevOps are not mutually exclusive. Actually, DevOps wants SDN, whether it knows it yet or not.

    Why?

    If software is going to eat the world, then SDN is going to eat networking.

    Networks are becoming more complex, and one way to manage them more effectively is through SDN. Also, organizations are demanding faster changes, yet networking changes traditionally have been a manual process.

    In a profession where network engineers typically work in seclusion and use significant manual processes, it can provide a set of tools to align with DevOps. This is why DevOps needs to care about it.

    Software-defined networking leads to infrastructure as code (IaC), which makes network automation possible.

    Software-Defined Networking and Infrastructure as Code

    SDN, in its simplest form, is controlling networking hardware with software. But there is more to it: Software-defined networking means networking switches and routers no longer need to be controlled with proprietary software. This creates an opening for innovation and is how we now have OpenFlow.

    This implies that networking now can culturally align itself with DevOps. The question will become whether it wants to. IaC is where networking will find its home with the DevOps team—it is like SDN for Ops.

    Why Does SDN Matter for DevOps?

    Software-defined networking will open communication and make automation possible—two ideas that are fundamental to an effective DevOps team.

    Open communication between networking can be easier when the mindset and tools are enabling a similar process. For DevOps, the current stack is providing tools to do exactly this. We see this with the Ansible and Red Hat DevOps networking partnership.

    What’s more, SDN enables network automation. Automation is an important goal for DevOps, which before SDN was not workable. Network automation can mean a better integration of DevOps and networking, as networking comprises many manual processes and, as such, is a bit isolationist. Aligning goals can provide better communication and collaboration.

    The Power of Network Automation

    SDN, IaC and DevOps networking are providing a set of tools and ideas that can push widespread adoption of network automation.

    Network automation is not a new topic, but implementation has been difficult. Technology had to catch up with demand: Before OpenFlow, networking infrastructure ran on proprietary software, which meant manual changes and configurations were commonplace and one-off scripts are the norm.

    With SDN and a technological environment conducive to network automation, we can begin to test different network automation strategies. Currently, however, organizations using automation only use it for segmenting their firewalls. We are in the early stages of what network automation can do.

    Just as DevOps is still finding ways to use automation in testing and development, networking is on its own discovery path to automation. The only difference is DevOps has a goal to automate and networking still views automation as a “nice to have.”

    Using NetDevOps to Bridge the Gap

    We have the conversation about SDN, IaC and network automation because networking does not have its functions accurately defined within the DevOps framework. That is why NetDevOps is a topic of discussion.

    The fact that SDN is still in its infancy stages and network automation is being discussed as “how to implement” shows there is a need for a cultural shift in networking that aligns with DevOps. This will help DevOps with communication and collaboration.

    DevOps wants automation and NetDevOps shares this goal. SDN is what makes this possible, and is exactly why DevOps should care.

  • Cisco DevNet: Cisco’s Window into DevOps

    Cisco DevNet: Cisco’s Window into DevOps

    SusieWee DevNetAgain recapping some of the events and people I spoke to this summer, I wanted to report on a really great person I had the chance to chat with. Susie Wee is the VP & CTO of Networked Experiences at Cisco Systems. Beyond that (as if that wasn’t enough), she also is the founder and lead for Cisco’s developer community, Cisco’s DevNet. It was one of the most delightful and enlightening conversations I had this summer.

    Now I know what you are thinking: Shimmy, it’s Cisco. The company is about networking and boxes. Where is the DevOps? Well, you would be surprised. First of all, putting aside the increasing importance of DevOps, Agile and lean in the world of software-defined networking (SDN), Cisco DevNet is so much more than SDN. I don’t want you to even think about SDN for a moment because what Susie has built with DevNet is so much more than even that.

    It’s not easy to go into an organization the size of Cisco and, from scratch, foster a community as enthusiastic and popular as DevNet has become. But the reason I am convinced is Susie herself. Her enthusiasm and passion is contagious. She told me about the first DevNet get together at Moscone Center and how it was overrun with developers. In spite of the crowd, Susie and team made sure everyone was part of the community.

    That community has since grown to tens if not hundreds of thousands of developers. Whether you’re working with Cisco APIs or Python or Java script, DevNet has something for you, no matter where in the world you are. The community partners with companies large and small, other communities and groups.

    I really had no idea of the scale and scope of this community. After speaking with Susie I realized that the DevOps community needs to be more aware of what is happening at DevNet and we need to bring more DevNet members into the DevOps community proper. My promise to her is that, going forward, we are going to try and facilitate this mingling of the tribes.

    The good news is that in her typical fashion Susie was all for this. She has committed to bring DevNet to DevOps. So be on the lookout, as the DevNet community will become regular contributors here at devopsy.kinsta.cloud. We may start a separate neighborhood for their contributions once we build up some library of content.

    In the meantime, though, check out some of the cool things DevNet has going on. Chances are there is some sort of event happening near you too. You don’t have to be into Cisco or networking, even. There is something there for everyone.