En mettant l'accent sur les avancées en matière d'API et en s'engageant à développer une plus grande communauté de développeurs, Cisco manifeste encore une fois sa volonté de devenir un acteur majeur du logiciel. Selon le fournisseur, une entreprise moyenne utilise 1 935 applications, soit 15 % de plus qu’il y a cinq ans. Et chacune de ces applications est accessible via des dizaines d'API provenant de fournisseurs, de développeurs et de sources internes. « Nous effectuons 8 milliards d'appels d'API par mois, contre 20 millions à la fin de 2018, c’est dire si l’adoption est importante ! », a déclaré Anne Gentle, responsable de l'expérience des développeurs chez l’équipementier de San Jose. Annoncée l’an dernier, la stratégie API First de Cisco donne la priorité au développement d'API dans tous les produits Cisco afin de garantir une communication efficace entre les applications, les services et les systèmes. « API First signifie que l'API est traitée comme un produit, avec une garantie de qualité pour les entreprises qui doivent avoir la certitude qu’elles pourront construire quelque chose de solide sur cette base », a déclaré Mme Gentle. « Incontestablement, les API sont l'avenir », a-t-elle ajouté.

La rétrocompatibilité est un autre élément clé de la stratégie API First. Les entreprises doivent être sûres que les API de Cisco continueront à fonctionner avec chaque version de logiciel. Selon Alicia Lorenzetti, leader mondial de l'écosystème et du marché chez Cisco Meraki, les processus de conception, de documentation et de support pour les API stratégiques de Cisco sont construits autour de la rétrocompatibilité, et cela inclut l’implementation de journaux des modifications, de délais de notification appropriés pour tout changement d'API, d'avis de dépréciation et de versions d'API. « Les développeurs veulent qu'une API dure des années, afin de continuer à écrire du code et que le code continue à fonctionner. Nous nous engageons à ne pas changer cette API particulière, et si nous le faisons, nous les en informerons et nous leur fournirons une alternatve », a encore déclaré Mme Lorenzetti. « L'idée est de créer un produit sur lequel les clients et les développeurs pourront compter dans la durée et sur lequel ils pourront bâtir leur entreprise », a-t-elle ajouté. 

Support d’API Insight 

Dans un premier temps, Cisco a promis une rétrocompatibilité pour plusieurs de ses offres principales, notamment l'API Meraki Dashboard, l'API Identity Service Engine (ISE), l'API Nexus Cloud, l'API SecureX Threat Response, les API Cloud Security Open, l'API Partner Experience (PX) Cloud et l'API Webex. Une compatibilité descendante est prévue pour ThousandEyes API, Spaces API, AppDynamics Cloud API, DNA Center API, NSO Northbound API, Crosswork CNC API, et SD-WAN (vManage) API. « Les clients peuvent trouver les API et la documentation pour les différentes lignes de produits sur le site developer.cisco.com », a indiqué Grace Francisco, vice-présidente des relations avec les développeurs, de la stratégie et de l'expérience chez Cisco, dans un blog sur API Insights.

Un autre aspect de l’effort de Cisco en faveur de l'API concerne le support au projet open source API Insights. « API Insights permet aux développeurs d'évaluer les problèmes techniques, l'exhaustivité de la documentation et les problèmes de qualité des API avant leur mise en production », a expliqué Anne Gentle. Le projet promeut la spécification OpenAPI (OAS), un format de description ouvert et neutre pour les API REST, régi par la Fondation Linux, qui permet aux applications métiers de partager des informations avec des applications internes ou tierces sur Internet. « Avec API Insights, les entreprises et les développeurs peuvent suivre et améliorer la qualité des API de manière cohérente, avec un niveau de détail et de transparence impossible à atteindre avec des processus manuels », a indiqué Cisco. « Grâce aux informations fournies par API Insights pendant qu'ils travaillent, les développeurs peuvent voir rapidement si leurs API répondent aux normes de qualité et de sécurité de leur entreprise. Ils peuvent aussi facilement voir l'historique des versions, les journaux des modifications, la compatibilité ascendante, les changements de rupture entre les versions, et plus encore », a aussi écrit Grace Francisco, dans le blog sur API Insights. « Ce langage commun, établi par API Insights entre développeurs et DevSecOps pour mettre en évidence les faiblesses des API, rend la collaboration plus efficace entre les équipes, et casse les silos traditionnels qui ralentissent souvent la productivité et le temps de résolution des problèmes quand ils surviennent », a encore déclaré Mme Francisco.

Des outils pour compléter Kubernetes 

Cisco soutient aussi le développement des API par le biais du projet OpenClarity, une suite d'outils API open source pour la sécurité et l'observabilité des environnements Cloud natifs. Le projet OpenClarity comprend VMClarity, récemment annoncé, qui permet aux développeurs de s'attaquer aux vulnérabilités liées à l'utilisation de machines virtuelles dans les environnements natifs du cloud. « VMClarity fournit une détection et une gestion sans agent des nomenclatures logicielles (Software bill of materials, SBOM), et parce qu'il est sans agent, la sécurité et l'observabilité cloud-native sur les machines virtuelles sont améliorées sans écrire ou modifier de code », a déclaré Cisco. Les autres suites du projet OpenClarity comprennent APIClarity, un outil de visibilité open source et cloud natif pour les API qui utilise un framework de maillage de services pour capturer et analyser le trafic API et identifier les risques potentiels ; et KubeClarity, qui se concentre sur la visibilité et la vulnérabilité des environnements basés sur Kubernetes. 

Cisco est impliqué dans d’autres projets axés sur le développement des API, notamment : 

- Nasp : ce projet fournit des capacités de type service mesh à des points d'extrémité non-cloud et à des environnements cloud plus petits. Léger, basé sur une bibliothèque et open source, ce service mesh étendu peut exécuter des applications sur des appareils de périphérie, des VM héritées et des clients mobiles dans le service mesh de Kubernetes.  

- Media Streaming Mesh : ce projet open source exécute plus efficacement des applications multimédias en temps réel dans des environnements Kubernetes natifs. 

- APIx Manager : intégré dans les environnements de développement intégrés, il aide les développeurs à améliorer la qualité et la sécurité des API dès le début du cycle de développement. 

Incontournable OpenTelemetry pour l’observai lité

« Le framework d'observabilité OpenTelemetry (OTEL) a aussi un impact sur la manière dont sont développées les nouvelles applications », a déclaré Anne Gentle. Sous les auspices de la Cloud Native Foundation, la technologie OpenTelemetry est développée par des contributeurs d'AWS, Azure, Cisco, F5, Google Cloud et VMware, entre autres. Le groupe définit OpenTelemetry comme un ensemble d'outils, d'API et de SDK utilisés pour instrumenter, générer, collecter et exporter des données de télémétrie afin d'analyser les performances et le comportement des logiciels. « On peut voir ses données et son équipement, et OTEL rend ces informations accessibles. Et quand on combine toutes ces données, elles deviennent exploitables pour les entreprises », a déclaré Mme Gentle. Selon les analystes, beaucoup de fournisseurs ont envie de créer de bonnes API et de bons programmes de développement. « Concernant les efforts de Cisco en matière d'API et de programmes de développement, l'objectif est d'encourager les développeurs à tirer parti de ce que fait Cisco et à s'en inspirer pour vendre davantage de produits Cisco », a déclaré pour sa part Tom Nolle, président de CIMI Corp. (Dans un blog, M. Nolle a récemment évoqué les défis auxquels sont confrontés les fournisseurs pour utiliser les API et encourager le développement de logiciels).

 « Si un tiers développe quelque chose pour des API qui améliore la vente de produits d’un fournisseur, c'est gagnant-gagnant parce que ça ne lui coûte rien », a déclaré M. Nolle. « Les logiciels sont beaucoup plus faciles à différencier que le matériel ; toutes les fonctions utiles des réseaux sont créées par des logiciels », a-t-il ajouté. « Le défi consiste à mettre en place un programme qui en vaille la peine », a encore déclaré M. Nolle. « Cisco est un acteur important, et c’est une aide incontestable. Mais beaucoup de développeurs cherchent à travailler avec Cisco, et plus il y a de développeurs, moins il y a de chances qu'un développeur donné attire l'attention qu’il mérite. Les développeurs travaillant pour des fournisseurs s'inquiètent souvent aussi du fait que le fournisseur décide d'introduire sa propre fonction/son propre produit si la demande est suffisamment forte. Les programmes de développement d'un fournisseur ne sont pas un facteur déterminant dans le choix du fournisseur, mais ils peuvent être considérés comme un avantage », a ajouté Tom Nolle. « Les clients ne disent pas que les programmes de développement sont un critère primordial dans le choix du fournisseur, mais ils bénéficient de ces programmes. Les opérateurs (telcos) apprécient les bonnes API et les bons programmes, car ils voudraient souvent être eux-mêmes des 'développeurs' », a encore déclaré M. Nolle.