devopsy.kinsta.cloud

Tag: NetOps

  • Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare Unveils Platform to Programmatically Unify Cloud Networking

    Cloudflare today launched a Magic Cloud Networking platform that makes it simpler to programmatically manage multiple cloud networking environments using Terraform code.

    Based on a platform the Cloudflare gained when it acquired the core technology from Nefeli Networks late last year, the Magic Cloud Networking platform presents IT teams with a console through which they can use the existing Cloudflare One secure access service edge (SASE) platform to securely manage multiple cloud networks. The Cloudflare global network spans more than 310 cities in over 120 countries and interconnects with more than 13,000 networks worldwide.

    Annika Garbers, director of product for Cloudflare, said this addition to the Cloudflare portfolio promises to make it simpler to integrate network operations (NetOps) with DevOps workflows in a way that makes it simpler to enforce zero-trust IT policies.

    The degree to which NetOps and DevOps are integrated tends to vary widely from one organization to the next. It’s still not uncommon for DevOps teams to be able to provision a virtual machine in seconds or minutes but then be forced to wait days for a NetOps team to provide then network access. Arguably, those kinds of delays defeat the purpose of investing in DevOps in the first place.

    That’s becoming a more problematic issue as organizations start to deploy workloads across multiple clouds, each with its own construct for managing software-defined networking infrastructure. The Magic Cloud Networking platform provides DevOps teams with a higher level of abstraction for programmatically managing those networks using Terraform code that is already widely used to manage infrastructure-as-code, noted Garbers.

    That approach eliminates the need to rely on cumbersome virtual routers that IT teams don’t want to manage. In fact, more IT teams than ever just want to be able to access network services versus having to build, deploy and manage physical routers and switches, said Garbers. In the age of the cloud, the physical network underlay is typically managed by the cloud service provider, so all that’s required is a way to programmatically unify the management of multiple cloud networks that can be invoked via lower-level application programming interfaces (APIs).

    The one thing that is certain is that as networking services become more programmable, the pace at which applications can be deployed is only going to accelerate. Each organization will need to determine which teams are best suited to manage any given layer of the networking stack. Still, regardless of approach it’s clear networks are finally catching up to rest of the IT infrastructure that is already being managed using code. The challenge, as always, is making just as easy for network administrators that lack programming skills to manage those networks as easily as a DevOps team that already has extensive experience using code to manage the rest of the infrastructure used to provide IT services.

    Of course, there will still be plenty of routers and switches to manage in on-premises IT environments but it’s only a matter of time before they become part of a larger DevOps workflow.

  • What NetOps Teams Should Know Before Starting Automation Journeys

    What NetOps Teams Should Know Before Starting Automation Journeys

    Automation has captured the human imagination since the earliest days of recorded history. A fanciful example of this comes from Homer’s classic “The Iliad” in the form of a bronze robot called Talos, which was designed to automatically monitor and defend the island of Crete from marauding intruders. The appeal of automation for IT organizations, including network operations (NetOps) teams, may not be so life-and-death but it’s undeniable, nonetheless. More and more NetOps teams are turning to automation to achieve higher network uptime (by reducing manual errors), increase efficiency and reduce costs and help deliver a better and more consistent operational experience for all users.

    Due to the allure of these promised benefits, the temptation for NetOps teams to integrate automation as soon as possible may be strong. However, it is important for these teams to remind themselves that automation is a tool, not the destination itself. Indeed, simply overcoming the technical challenges of deploying automation may not result in the successful outcome teams want, without identifying and defining the intended outcome of what their automation journeys should be.

    This article will explore some practical steps and best practices that NetOps teams should use throughout their own automation journeys.

    Getting the Journey Started on the Right Step

    A well-known maxim in business is that you should visualize success and start with the end in mind when embarking on a major project or initiative. This is a good reminder for NetOps teams as they begin their automation journey. That is, these teams should be able to answer the question, “What is our desired end state when it comes to automation?” before they even evaluate what tools or technologies they may want to consider.

    Teams who have this mindset will have a clearer understanding of their overall mission as well as an enhanced view of the various projects, processes and products they can improve through automation. It is critical for NetOps teams to take the time to put in the work of defining the desired IT experience at the end of the automation journey, even if the task itself may be difficult. For example, this experience may help define how NetOps engineers will interact with an automation tool through its code, its dedicated user interface, or even its generic service portal. As the saying goes, “no pain, no gain.” The teams who invest in the time and effort to plan ahead will be far more likely to maximize the benefits of automation.

    What to Automate?

    In addition to visualizing what success looks like, it is important for NetOps teams to identify what tasks or processes they should be automating. This is important because there is a vast universe of NetOps tasks that can be automated. Taking the time to identify tasks to be automated will generate huge benefits for the NetOps team as it will help them select the correct automation strategy and toolset that will deliver them the results in an efficient way. And while specific projects may be unique to each NetOps team, in general, there are two broad categories of tasks that are ideal for automation:

    1. Highly repetitive tasks. These are manual or semi-automated tasks that are not necessarily hard but can be cumbersome for NetOps teams. Examples of repetitive tasks that can be automated include assigning an interface into a specific VLAN or perhaps updating network security policies or rules.

    2. Highly complex tasks. These can be more strategic and difficult tasks that can be prone to human error due to their scope, scale, and complexity. Automating these tasks may require additional planning and steps to ensure success. Examples of complex tasks that are ideal for automation include service redirection from one device to another or BGP peering with third parties.

    Think Big, Start Small With NetOps

    Like all people, NetOps professionals enjoy the results of a job well done. So, while the vision of their automation journey may be big, it’s important to start with a small, short-term project that can be completed quickly. There are a couple of benefits to this approach:

    1. Quick automation wins will give NetOps teams confidence for future projects.
    2. Projects like this can generate data and feedback that NetOps teams can convert into learnings and insights for the next project.

    This approach can also be applied to bigger, more complex automation projects. Instead of taking on the entire scale of the project at once, NetOps teams can break it down into smaller components. For example, infrastructure-as-code (IaC) is a broad category of automation entailing the managing and provisioning of systems through machine-readable definition files. There are many considerations to large-scale IaC projects such as identifying the use case, e.g., Day 0 or Day 2 operations. The advantages of this approach are the same as with the quick-win scenario: There is a better likeliness of success and more immediate feedback and data to guide the NetOps teams through this entire process.

    Finally, as talented as most NetOps teams are, they are not likely to have all of the automation expertise in-house at any given time. So, it is important that they address skills gaps (automation, programming) through strategic vendor partnerships, internal/external recruitment and additional training for their teams. Again, instead of recruiting or investing en masse, NetOps teams are well-advised to take the time to plan, execute, learn and modify as they go along.

    Summary

    The human fascination with automation is stronger than ever. The industry buzz around one particular form of automation—especially artificial intelligence and machine learning—is indicative of this. NetOps teams have much to gain from investing in the tools and skills required to do automation right.

    Automation of data center network pods, self-contained zones that represent a section of the overall data center, is a good example of a strategic project requiring forethought and planning to execute well. A logical first step in this process might be to anticipate how to manage future changes when automation is in place. Options for this may include code manipulation, Git (open source code management) or CI/CD pipelines, all elements of infrastructure-as-code automation. Or it may involve improving user experience through a specific UI interface or through a self-service portal. The next step then might be to decompose this large configuration into smaller bits starting with the registration of the new switches into the controller. Once this is done, we can now go into port configurations and then eventually move toward larger and more sophisticated elements such as the automation of VLAN assignments and L3 peering.

    For long-term and large-scale automation projects like this, it is especially important to follow the recommended key steps outlined in this article, which are:

    1. Start with the end in mind. It’s critical that the teams take the time and effort to define what success looks like, especially in the form of the IT experience they want to achieve.
    2. Know what you want to automate. There is an endless supply of tasks and processes that can or should be automated. Prioritizing automation projects that NetOps wants to take on is a major milestone in any automation journey.
    3. Think big, start small, learn as you go: Quick automation project wins are key to building confidence and “muscle memory” for future projects. For bigger projects, the best approach is to break them down into more manageable projects that can provide vital data and insights during the journey.

  • The Importance of NetSecOps in Network Management

    The Importance of NetSecOps in Network Management

    The IT landscape has changed beyond recognition in the past decade or so. The vast majority of businesses now operate largely in the cloud, which has had a notable impact on their agility and productivity. A recent survey of 1,900 IT and security professionals found that 41% of organizations are running more of their workloads in public clouds when compared to just one quarter of respondents in 2019. Even businesses that were not digitally mature enough to take full advantage of the cloud will have dramatically altered their strategies in order to support remote working at scale during the COVID-19 pandemic.

    However, with cloud innovation so high on the boardroom agenda, security is often left lagging behind, creating a vulnerability gap that businesses can little afford in the current heightened risk landscape. The same survey found the leading concern about cloud adoption was network security (58%).

    Managing organizations’ networks and their security should go hand-in-hand, but, as reflected in the survey, there’s no clear ownership of public cloud security. Responsibility is scattered across SecOps, NOCs and DevOps, and these teams don’t consistently collaborate in a way that aligns with business interests. We know from experience that this siloed approach hurts security, so what should businesses do about it? How can they bridge the gap between NetOps and SecOps to keep their network assets secure and prevent missteps?

    Building a Case for NetSecOps

    Today’s digital infrastructure demands the collaboration – perhaps even the convergence – of NetOps and SecOps to achieve maximum security and productivity. While the majority of businesses do have open communication channels between the two departments, there is still a large proportion of network and security teams working in isolation. This creates unnecessary friction, which can be problematic for services-based businesses that are trying to deliver the best possible end user experience.

    The reality is that NetOps and SecOps share several commonalities. They are both responsible for critical aspects of a business and have to navigate constantly evolving environments, often under extremely restrictive conditions. Agility is particularly important for security teams to keep pace with emerging technologies, yet deployments are often stalled or abandoned at the implementation phase due to misconfigurations or poor execution. As enterprises continue to deploy software-defined networks and public cloud architecture, security has become even more important to the network team, which is why this convergence needs to happen sooner rather than later.

    We somehow need to insert the network security element into the NetOps pipeline and seamlessly make it just another step in the process. If we could automatically check whether network connectivity is already enabled as part of the pre-delivery testing phase, that could, at least, save us the heartache of deploying something that won’t work. And then, if we do need to open new ports, an automated process that could also raise a change request would save even more time. Better yet, if it’s one of those “make this like that” changes, the change could be automatically implemented on the firewalls – in minutes, not weeks.

    With NetSecOps, application developers can get creative without worrying about security slowing them down, and network security teams can sleep soundly, knowing that risk and compliance checks are built in to the continuous delivery process with a full audit trail, so they can even get time back to do some fun stuff.

    If we could do all this with only the rare cases of new connectivity requiring approval by security, the NetSecOps dream could become a reality, allowing fast, high-quality delivery. With NetOps and SecOps working together, organizations can establish a collective approach to network management and security, offering equal opportunity for both teams to present and prioritize issues and agree on the fundamental rules from the start; a match made in heaven.

  • Languages and DevOps: Network

    Languages and DevOps: Network

    It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

    *Finally – so far, at least

    And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

    One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

    Python and Shell

    Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

    Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

    But Wait, There’s More

    The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

    We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

    Carry On

    Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

  • Bringing NetOps Up to Speed With DevOps

    Bringing NetOps Up to Speed With DevOps

    Automation can be an unwieldy topic for network operations and DevOps teams who have enough challenges working together cohesively. Networks have been traditionally viewed as the long pole in the tent for emerging DevOps practices.

    But for DevOps practitioners and business leaders alike, there’s good news: NetOps are more prepared than ever to embrace automation and programmability—increasing the likelihood of on-time service delivery, with far less friction between IT teams.

    According to Enterprise Management Associates (EMA), a strong majority (77%) of organizations deem network automation a high priority, and 58% have already implemented or are planning to implement, approved solutions. This is an important and promising shift.

    Traditionally, network leaders have favored an operating model that emphasizes stability and resiliency over agility. Understandably so, as any network interruption can have a cascading impact on the business’ operations and profitability.

    While ensuring five 9s of availability remains a top priority for NetOps, the growing need to support DevOps, containerized infrastructure for applications and cutting-edge digital services—among other initiatives—continues to highlight some of the glaring inefficiencies of traditional network management tools that are too error-prone and bound by scalability issues.

    With the right automation framework, NetOps can play an equal part in enabling DevOps practices by becoming more adaptable to evolving business and application requirements in the cloud and locally.

    Centralizing Management With Cloud-Based Service Delivery

    For decades, improving agility has been a dyed-in-the-wool practice for network teams. Organizations worldwide have now realized enormous benefits by implementing new software-defined management tactics that allow the network to become more centralized, programmatic and dynamic in nature. By disaggregating software from hardware, networking teams now can manage many more services and devices with less effort and resources.

    Among NetOps’ new arsenal of tools and best practices, centralized management has become one of the key ingredients driving toward greater efficiencies. Utilizing a cloud-based approach for provisioning, deploying and managing network services closely mirrors the way IT has spun up cloud storage and compute over the last decade. Now, DevOps teams no longer have to wait days or weeks for the NetOps team to provision the right networking resources so that they can begin designing, testing and deploying new applications.

    Along with the added efficiencies, NetOps teams have greater and more uniform control over device configurations and policies, where security vulnerabilities lie in wait if these do not establish a zero-trust environment. Orchestrating these elements centrally, rather than device by device, places far less burden on individual network operators for protecting high-value corporate assets. Rock-solid network access control also reduces the risk of security or performance degradation that commonly arise from using an ad hoc patchwork of scripts, templates and CLI commands.

    Advancing Network Automation Frameworks

    Because creating a cloud-native network infrastructure does not all happen with the press of a button, network operations won’t become fully automated overnight. Other factors come into play that inhibit broader adoption of automation frameworks, including budget constraints, difficult technology implementations that lack integration with legacy systems and skill gaps for existing staff.

    It’s essential that NetOps teams embrace a network automation framework that aligns to current and future operating models. Through proactive collaboration, NetOps folks can extend the value of automation platforms already used by their DevOps or application counterparts.

    Fortunately for NetOps teams, myriad networking vendors today readily offer pre-built, certified solutions for DevOps platforms, making it easier to get started on a cloud-native journey by automating activities such as device onboarding and configuration changes. This way, network administrators can leverage existing vendor partnerships, in-house knowledge and technology that is already proven within the larger IT environment.

    Additionally, network engineers shouldn’t need—and won’t have the extra time—to become top-notch developers to take advantage of programmability during their cloud-native journey. Developing basic programming skills is advantageous, but network management systems that offer Python scripting, a consistent set of APIs and webhooks can perform the “heavy lifting” when it comes to enabling extensibility with third-party IT platforms.

    Today, this level of extensibility includes being able to integrate with third-party IT service management tools. A common use case that can realize significant time savings and greater network and application availability is to auto-trigger and assign an incident ticket when a performance SLA is breached. It’s very easy to collect and use machine learning-based tools to correlate all of the relevant diagnostics data in order for a network operator to immediately begin a root cause analysis and quickly resolve the issue.

    On the Horizon: AI-Driven Operations

    Another core aspect of DevOps is continuous improvement—both in terms of elevating service levels, as well as enhancing user experiences. But faster rates of change resulting from continuous improvement processes can negatively impact application performance, and the network is often the first to be blamed.

    But there is a huge silver lining within this cloud created by faster rates of change, which also highlights another growth area for NetOps teams to learn and master. That is, the use of AIOps.

    Today’s networks are bound by human scale. When things break, it takes a human to realize it broke, research the issue and then apply the fix. While traditional management and monitoring tools can alleviate some of the burden, alert fatigue often becomes a huge problem—in other words, too many false alarms, false positives or, worse yet, drawing attention away from more critical issues.

    AIOps tools and technologies mitigate these issues and limitations by combining artificial intelligence, machine learning, and advanced network analytics to automate many aspects of traditional monitoring and troubleshooting. Once deployed, IT organizations have the ability to predict and preempt failures,\ or quickly recover from issues when they do occur. This includes being able to:

    • Leverage ML-trained data sets to continuously monitor network performance and detect anomalies.
    • Eliminate guesswork by prioritizing fixes or improvement efforts and validating that those efforts have the desired business impact.
    • Continuously optimize network performance based on benchmarks.

    Put another way, AIOps systems are worth their weight in gold by helping networks move toward a self-healing, self-securing and self-optimizing model. Even in the interim, during the early phases of deployment, such AI-assisted operations can help IT identify and resolve network- or user-impacting issues faster and easier. The results are that dramatic.

    Next Steps: Bring a DevOps Mentality to NetOps

    Contrary to popular belief, the goals of NetOps are not diametrically opposed to DevOps. Both groups want to deliver more value and help the business innovate.

    Equipping NetOps teams to build on existing DevOps-based automation frameworks, paired with AI-driven insights and modern management tools, will go a long way in ensuring frictionless delivery of new services.

    Now is the time for network operations teams to get to know your DevOps team, learn how they operate and come together to create new methods for advancing the organization’s IT mission. The investment in time and effort should be a creative win-win for both groups and produce a big payoff in IT’s strategic position and importance to the organization.

  • Cisco Acquires ThousandEyes to Advance Network Visibility

    Cisco Acquires ThousandEyes to Advance Network Visibility

    Cisco Systems this week announced its intent to acquire ThousandEyes, provider of an internet monitoring platform that Cisco plans to leverage to embed ThousandEyes agent software into a range of devices including network routers and switches, security tools and application performance management (APM) software from AppDynamics.

    As part of that effort, ThousandEyes will become the foundation of a newly formed Networking Services business unit in Cisco led by ThousandEyes CEO Mohit Lad. The terms of the acquisition were not disclosed.

    Todd Nightingale, senior vice president and general manager for enterprise, networking and cloud at Cisco, said the goal is to employ the data collected by ThousandEyes agent software to drive intent-based automation across the entire IT environment.

    ThousandEyes provides a networking intelligence service by deploying its software on points of presence across the internet. The data collected is then fed back to data centers operated by ThousandEyes to help organizations understand why, for example, a particular software-as-a-service (SaaS) application is performing suboptimally in one geographic region versus another.

    Nightingale said with multi-cloud computing now becoming a reality in the enterprise, the need for that level of insight into what are becoming highly distributed computing environments has dramatically increased.

    Once the deal closes, it may take Cisco a while before it can embed agent software from ThousandEyes across its portfolio. However, DevOps teams that deploy applications in IT environments with Cisco networking equipment should be able to troubleshoot applications more easily once the agent software from ThousandEyes is embedded in Cisco networking hardware and software.

    At the same time, Cisco will be feeding that data into AppDynamics, the application performance management (APM) platform it acquired in 2017. The AppDymanics platform is employed mainly by cloud operations teams to optimize the performance of applications deployed on various cloud computing platforms, noted Nightingale.

    Lad said by becoming part of Cisco, ThousandEyes will become the central nervous system through which organizations will be driving user experiences.

    Less clear at the moment is to what degree open source networking software initiatives may have on Cisco’s long-term ambitions. Open source agent software is now being widely deployed to instrument applications that in turn feed metrics back to a wide variety of platforms, including AppDynamics. It’s not only a matter of time before various open source initiatives extend agent software to the networking level.

    Regardless of that approach, DevOps teams should be able to count on attaining deeper insights into how network congestion is impacting application performance. As that analytics data becomes more accessible, it should become more feasible to dynamically reroute application traffic to maintain service levels.

    In the meantime, network operations and DevOps teams will continue to move closer together. The NetOps team may not necessarily be completed folded into DevOps. However, as networking becomes more programmable, it’s apparent DevOps teams will be exercising more programmatic control over networking services. The challenge and the opportunity now are to find a way to bring those disparate cultures together to minimize the inevitable friction that will ensue.

  • Cisco Aligns With Google to Meld DevOps and NetOps

    Cisco Aligns With Google to Meld DevOps and NetOps

    The extension of a partnership between Cisco Systems and Google to drive tighter integration between their respective software-defined wide area network (SD-WANs) offerings and cloud platforms promises to accelerate the convergence of NetOps and DevOps.

    John Apostolopoulos, vice president and CTO for Intent-Based Networking Group at Cisco, said in the wake of the COVID-19 pandemic it’s clear more organizations will be employing SD-WANs as an alternative to virtual private networks. Many of those SD-WAN deployments, however, will be on public clouds rather than in a traditional on-premises data center, he added.

    As that transition occurs, DevOps teams will increasingly invoke SD-WAN services via application programming interfaces (APIs) residing in the cloud to provide users with access to cloud applications, noted Apostolopoulos.

    Cisco and Google have a technology alliance in place that spans everything from Kubernetes to cloud management software. That partnership is now being extended to include forthcoming deployments of Cisco SD-WAN software on Google Anthos, a cloud platform based on Kubernetes that can be deployed on any cloud or on-premises IT environment, sometime in the first half of 2021.

    The availability of SD-WAN services from Cisco on multiple cloud platforms will naturally have significant implications for NetOps teams. Rather than having to manage individual routers and switches, the future of SD-WANs is moving more toward being a set of software services that are programmatically invoked. It’s not clear to what degree NetOps teams might be folded into DevOps teams as that transition occurs. IT teams will always require networking experts to optimize networking services to one degree or another, said Apostolopoulos. However, the days when DevOps teams had to wait days or weeks for a NetOps team to manually provision network services on their behalf are coming to an end.

    Apostolopoulos said in the wake of the COVID-19 pandemic, flexibility has become a highly prized IT asset. As such, more applications will soon be deployed in the cloud than ever. Cisco is betting that rather than having to manage multiple cloud network services, more organizations will prefer to extend enterprise networking services from Cisco across multiple clouds. That approach will enable IT organizations to more easily centralize the management of network services via a management console built on top of a consistent set of APIs, he noted.

    Just as importantly, Cisco will provide the integrated tools needed to secure those network services, added Apostolopoulos.

    In effect, Cisco is betting that enterprise IT organizations are going to consolidate networking and security services as part of an effort to reduce the total cost of IT. Cisco may not always be the least expensive provider of an individual router or switch. However, the total cost of integrating networking and security offerings from multiple vendors can add up quickly. The degree to which organizations have the political will and economic capital required to achieve that goal, of course, remains to be seen. Nevertheless, it’s also clear that maintaining the current networking and security status quo is not going to be able to hold for very much longer.

  • F5 Networks Surfaces Application Insights

    F5 Networks Surfaces Application Insights

    F5 Networks, at its Agility 2020 online event today, unfurled Beacon, a software-as-a-service (SaaS) platform that enables IT teams to better monitor and troubleshoot applications using telemetry data collected from networking equipment from both F5 and third-party sources.

    In addition, the company announced an update to NGINX Controller that enhances application analytics along with improvements to the declarative application programming interfaces (APIs) that NGINX Controller provides.

    Finally, F5 Networks unveiled an update to BIG-IQ, a set of tools for managing application services delivered via its network operating system. Version 7.1 of BIG-IQ adds visibility into legacy application services, streamlines management workflows and adds security management functionality.

    Hitesh Patel, senior director of product management for automation, orchestration and ecosystems at F5 Networks, said all three offerings are part of an ongoing effort to make it easier for IT organizations to meld network operations (NetOps) and best DevOps practices. Beacon, for example, ingests telemetry data streams from multiple sources to provide visibility and surface actionable insights via an application-centric view of the IT environment, he said, adding that approach makes it easier for NetOps and DevOps teams to collaborate.

    A companion Beacon Insights tool can be employed to detect anomalies and run analytics to determine the root cause of an issue, he said.

    Patel noted as IT environments become more complex, the need to eliminate silos that make managing IT holistically has become more pressing. For example, modern applications based on microservices are especially difficult to manage across an increasingly distributed computing environment.

    Less clear currently is how much or even whether DevOps and NetOps teams will merge. Network resources increasingly are being exposed via APIs that developers can programmatically invoke to provision resources. However, many IT teams are trying to control how much network bandwidth is allocated to any given application. As a result, many NetOps teams are setting up portals through which DevOps teams are given access to a maximum amount of bandwidth for specific sets of applications.

    On the plus side, Patel noted that as applications become more instrumented, thanks in part to the rise of DevOps, it’s becoming easier to apply analytics. That capability makes it easier for developers and NetOps teams to troubleshoot issues using a common set of metrics and dashboards that can feed data back to a continuous integration/continuous delivery (CI/CD) platform, he said.

    It may be a while before each IT organization finds the optimal level of convergence between their respective DevOps and NetOps teams. However, as applications become more distributed in the age of the cloud, networking will have a greater impact on application performance. The trouble is, most DevOps teams aren’t sure whether application performance issues are the result of the code written by developers or the latency being introduced by the network. Whatever the root cause, many IT teams are spending an inordinate amount of time trying to determine the root cause of application performance issues.