Tag: networking

  • Can DevOps Be Applied to Production Networks?

    Can DevOps Be Applied to Production Networks?

    The key goal of DevOps is to bring development and operations together, bound by a common set of practices. For this to become reality, developers need to think more like the operations team—focusing on stability and reliability—while operators need to think more like developers—focusing on agility and speed. But how widely can this be applied?

    We say regularly the goal of application development is to deploy new features into production continuously—daily, weekly or monthly, if possible. But what about the production infrastructure itself? Can we apply DevOps practices to making changes to the production infrastructure on which these applications run?

    Recently, I met with customers who want to implement DevOps practices to how they manage their operational network, applying continuous deployment to the production network. For example, they would like to design, test and then deploy new network services such as load balancing and firewalls into production immediately to enable new applications and services—actions that currently could take weeks or months. Is this kind of continuous deployment to be expected, or is it pushing DevOps too far?

    Let’s look at how key concepts of DevOps might be applied to adding network services to a production enterprise network:

    1. Virtualize services: To enable rapid deployment of applications, it was first critical that they be enabled with virtualization and in the future, with containers to make them portable. We would need to apply this same approach to production network infrastructure if we expect to enable rapid deployment of new infrastructure. Unfortunately, there is no standard way to make physical network equipment portable. Of course, shifting heavily to software-defined networking (SDN) enables virtualization for free, but it doesn’t make even virtual network equipment “standard.” In the world of networking, there are a number of “standard” interfaces and modeling languages: SNMP, NetConf, Yang and TOSCA (though not originally designed for networking), to name a few. Using one of these standard interfaces, in combination with virtualization, potentially could enable the agility required for continuous deployment of network services.
    2. Automate: DevOps success depends on automating the entire process of development, test and deployment so the process can be continuous. The same level of automation would need to be provided throughout the process of designing, testing and deploying new network services onto production networks. Network testing is very similar to other types of hardware and software testing so most test automation frameworks can be applied. However, network testing requires automation of the environment setup, and it also requires traffic generation to test with realistic network conditions.
    3. Continuously deploy: While this is still a dream for many companies attempting to achieve DevOps nirvana, a key requirement for using DevOps for production network configuration is to be able to deploy new services continuously into a live production network. Most of the configuration management tools available today are good at configuring servers and software, but are more immature when it comes to configuring networks, which are far more complex and inter-dependent than a single server. A tool would be required that allows the configuration of the tested network to be deployed automatically in exactly the same way within a production network.
    4. Monitor Operation: A good DevOps practice monitors applications in production and uses that information in planning new services. While it would seem that network monitoring is quite mature, an open question is whether that data is useful in planning future network services for improved operation.

    Sandboxes for Network DevOps

    Sandboxes are tools for defining and testing infrastructure configurations (physical, virtual and application). A good sandbox allows users to model any infrastructure, including any type of network infrastructure. This model also can serve as a way to implement “virtual services.” Models can be created in Yang or TOSCA, and under the covers these models can automate access to network infrastructure using CLIs, SNMP and/or NetConf where appropriate. This allows network services to be defined and tested using a high-level model, rather than the low-level interfaces.

    Sandboxes also address automation by providing a context for automating not just individual network components but also entire configurations and connectivity that are required for a “network service.” In addition, automation can encompass traffic generators and test tools as part of the testing process.

    Sandboxes also are designed to set up and tear down a network service automatically so they can be used for continuous deployment of new services. The same automation used to create the sandbox for a network service also can be used to deploy it into production.

    Finally, monitoring used in production also can be performed in the Sandbox to compare performance between testing environments and production so future services can be improved.

    While applying DevOps to production infrastructure and services is challenging and immature, in principle it can provide significant improvements in the speed of deployment of new network services—and the applications that depend on those services.

    About the Author / Joan Wrabetz

    Joan-CasualJoan Wrabetz is the Chief Technology Officer for Quali. Most recently, she was the vice president and Chief Technology Officer for the Emerging Product Division of EMC. Ms. Wrabetz holds an MBA from the University of California, Berkeley, an MSEE from Stanford University, and BSEE from Yale University. She has taught as an adjunct faculty member at the University of St. Thomas, St. Mary’s University, and at the Carlson School of Business at the University of Minnesota. She holds patents in load balancing, distributed systems and machine learning classification and analytics.

     

  • 5 Reasons DevOps Needs NetDevOps

    5 Reasons DevOps Needs NetDevOps

    Networking’s role in DevOps is not accurately defined.

    Up to this point, networking has been integrated into DevOps through infrastructure as code (IaC), which has been around since the beginning of the DevOps movement. Although important, this does not quite encompass all of what networking needs within DevOps.

    A few of the current terms being used for networking in DevOps are:

    • Infrastructure as code (IaC)
    • DevOps networking
    • NetOps

    We have not agreed upon a universal, concrete philosophy to determine how to effectively bring networking into the DevOps conversation.

    This is why we need NetDevOps.

    NetDevOps is a construct of principles that aligns the networking team more closing with DevOps in your organization. It takes what traditionally are manual procedures in network infrastructure and applies the principles of automation and scalability.

    Why do you need yet another term or concept? This isn’t a new term; it just needs to be widely adopted.

    Therefore, here are five reasons you need NetDevOps.

    Networking + DevOps = NetDevOps

    DevOps needs networking and networking needs DevOps. The two may not admit this, but the open communication is essential. Networking’s biggest concern is network uptime, while DevOps’ ultimate goal is continuous delivery. The result is DevOps having a high interest in network availability to ensure updates can be delivered.

    Adopting a NetDevOps approach promotes networking to apply the same principles as DevOps. The goal of replicating and automating tasks—not automating for the sake of automation, but to take the processes that work effectively on one server and apply them to multiple servers.

    Remote Deployment for Cloud Adoption

    As cloud adoption increases, the need to deploy updates and changes remotely is essential. Cloud computing provides the necessary environment to implement the NetDevOps approach, which installing a hardware infrastructure allows for code deployment.

    In a cloud environment, such as AWS, infrastructure needed to implement this approach is available already. For example, AWS CloudFormation provides the necessary infrastructure for IaC.

    Infrastructure as Code

    IaC has been fundamental to the DevOps movement, and this is the foundation for NetDevOps: The ability to take network hardware and apply a set of code to the environment. The code allows you to automate an environment, which typically has needed to be updated manually.

    Automation is one of the core principles DevOps and NetDevOps share. Automation results in predictable network uptime, which provides an environment to better assist DevOps in achieving continuous delivery.

    Software-Defined Networks

    Software-defined networks (SDN) are a subset of the IaC discussion. It is the enterprise network version of cloud architecture. NetDevOps works in this environment through the use of white-box switches.

    Implementing white-box switches and installing Linux will create an SDN environment, which is conducive to NetDevOps. It is the necessary infrastructure for NetDevOps.

    Current Stack is Providing the Tools

    Once the above is implemented, a NetDevOps environment is ready to integrate with your current Ops stack. Ansible, Red Hat, Puppet and Chef already are providing the tools necessary to create a NetDevOps environment. Now you and your team need to implement it.

    NetDevOps is taking the traditional manual nature of networking and applying a set of DevOps principles. It is an environment of automation that brings networking full circle with DevOps.