Cisco continues to signal its desire to become a major software player, most recently with its emphasis on API advancements and its commitment to building a bigger development community around that effort.
The average enterprise uses 1,935 applications—a 15% increase from five years ago, according to Cisco. And each of these apps is accessible via dozens of APIs from vendors, developers and homegrown sources.
“We are conducting 8 billion API calls on a monthly basis. And just to give you an idea of the proliferation of that adoption, at the end of 2018 it was 20 million,” said Anne Gentle, developer experience manager with Cisco.
Last year, Cisco announced its API First strategy, which prioritizes API development in all Cisco products to ensure efficient communication among applications, services and systems.
“API First means the API is treated like a product, so organizations should expect quality and they should expect to be able to build on top of this and trust that it’s going to work,” Gentle said. “APIs are absolutely the future.”
Backward compatibility is a key part of API First so that enterprises can be confident that Cisco APIs will continue to work with every versioned software release. Design, documentation, and support processes for strategic Cisco APIs are built around backward compatibility, and that includes implementation of changelogs, appropriate notification timelines for any API changes, deprecation notices, and API versioning, according to Alicia Lorenzetti, global ecosystem and marketplace leader with Cisco Meraki.
“Developers want an API to last for years, so that they can continue writing code and the code keeps working. We are saying we won’t change this particular API, and if we do, we’ll notify you and we’ll give you another option,” Lorenzetti said. “The idea is that we are making something that customers and developers know will last for a long time, that they can build a business on.”
Cisco initially promised backward compatibility for several of its core offerings, including Meraki Dashboard API, Cisco Identity Service Engine (ISE) API, Nexus Cloud API, SecureX Threat Response API, Cloud Security Open APIs, Cisco Partner Experience (PX) Cloud API, and Webex API. Future backward compatibility is planned for ThousandEyes API, Cisco Spaces API, AppDynamics Cloud APIs, Cisco DNA Center API, NSO Northbound API, Crosswork CNC API, and Cisco SD-WAN (vManage) API.
Customers can find the APIs and documentation for the different product lines at the developer.cisco.com site, Grace noted.
Another part of Cisco’s API push is its support of API Insights, an open-source project that lets developers assess technical issues, documentation completeness, and quality concerns with APIs before production, Gentle says.
The project promotes the OpenAPI Specification (OAS), a vendor-neutral, open description format for REST APIs that’s governed by the Linux Foundation and is meant to allow business applications to share information with home-grown or third-party applications over the internet.
API Insights lets organizations and developers track and improve API quality consistently, and with a level of detail and transparency that is impractical through manual processes, Cisco stated.
“API Insights provides information to developers as they work. Developers can quickly see if their APIs meet their organization’s quality and security standards. They can also easily see version history, changelogs, backward compatibility, breaking changes between versions, and more,” wrote Grace Francisco, vice president of developer relations strategy and experience at Cisco, in a blog about API Insights.
“By establishing a common language for developers and DevSecOps to address weaknesses in APIs, API Insights fosters more effective collaboration between teams – breaking down traditional silos, which often slow productivity and time to resolution when issues occur,” Francisco stated.
Cisco also supports API development through the OpenClarity project, which is a suite of open-source API tools for cloud-native security and observability. The OpenClarity project includes the newly announced VMClarity, which lets developers tackle the vulnerabilities of using virtual machines in cloud-native environments.
VMClarity provides agentless detection and management of software bill of materials (SBOM), and because it is agentless, cloud-native security and observability on VMs are enhanced without writing or modifying any code, Cisco stated.
Other suites within the OpenClarity project include APIClarity, an open-source, cloud-native visibility tool for APIs that uses a service mesh framework to capture and analyze API traffic and identify potential risks; and KubeClarity, which is focused on visibility and vulnerability of Kubernetes-based environments.
Additional Cisco API development areas include:
- Nasp, a new project created to provide service mesh-type capabilities to non-cloud endpoints and smaller cloud environments. This lightweight, library-based, open-source service mesh extender can bring applications running on edge devices, legacy VMs, and mobile clients into the Kubernetes service mesh.
- Media Streaming Mesh, an open-source project that runs real-time media applications in cloud-native Kubernetes environments more efficiently.
- APIx Manager, which helps developers improve API quality and security early in the development lifecycle and is integrated into integrated development environments.
The OpenTelemetry (OTEL) observability framework is also driving the way new applications are developed, Gentle said. Under the auspices of the Cloud Native Foundation, OpenTelemetry technology is being developed by contributors from AWS, Azure, Cisco, F5, Google Cloud, and VMware, among others.
The group defines OpenTelemetry as a collection of tools, APIs and SDKs used to instrument, generate, collect, and export telemetry data to help analyze software performance and behavior.
“You can see your data and your gear, and OTEL makes that information accessible. And when you combine all that data together, that’s when it gets actionable for businesses,” Gentle said.
Analysts said the desire to build successful API and developer programs is central to many vendors.
With respect to Cisco’s API efforts and developer programs, the goal is to encourage developers to leverage what Cisco does, and build on it to sell more Cisco products, according to Tom Nolle, president of CIMI Corp. (Nolle recently penned a blog about the challenges vendors face in using APIs and encouraging software development.)
“If you can get a third party to build something to your APIs that sells your products better, it’s a win-win because it costs you nothing,” Nolle said. “Software is much easier to differentiate than hardware; all the real features in networking are software-created.”
The challenge is building a program that’s worthwhile, Nolle said. “Cisco is a big player, and that helps. But there are a lot of developers who’d be looking to work with Cisco, and the more [developers] there are, the less chance for a given developer to get attention. Vendor developers also tend to be worried about the vendor deciding to field their own feature/product if the demand is good enough.”
A vendor’s developer programs aren’t a big factor in vendor selection, but they can be considered a benefit, Nolle said.
“Customers don’t tell me that they look at developer programs as a primary factor in picking a vendor, but they do benefit from the programs. Operators (telcos) like good APIs and programs because they often intend to be ‘developers’ themselves,” Nolle said.
Copyright © 2023 IDG Communications, Inc.
