I Love APIs 2016

L’événement européen organisé par Apigee adresse les enjeux actuels du Digital et de l’API.

 

api days

Alors que les API Days se terminaient à Melbourne, nous autres européens pouvions profiter de la journée I Love APIs qui s’est tenue le 2 mars dernier à Londres. Organisée par Apigee, fournisseur de solutions de management d’APIs, cet évènement était l’occasion pour l’éditeur ainsi que pour plusieurs partenaires et clients (SAP, Accenture, Orange, etc.) de partager leur vision de l’importance et de la mise en œuvre des APIs, dans un monde qui se digitalise à grande vitesse. Retour sur une journée pleine d’inspiration et de bonnes pratiques.

I. Keynotes d’ouverture : bienvenue dans un monde d’innovation digitale et de disruption

Chet KapoorLes premiers mots d’introduction ont été pour Chet Kapoor, CEO d’Apigee, qui a posé le contexte de la 4ème révolution digitale que nous sommes en train de vivre : à une époque où l’Internet des Objets, l’impression 3D ou encore la robotique se démocratisent, tous les secteurs d’activité doivent percevoir dans l’économie numérique de nouvelles opportunités pour leurs clients, leurs employés ou leurs partenaires. Les APIs y ont un rôle majeur à jouer, et des plateformes intelligentes de management comme celle d’Apigee permettent d’amener la dimension collaborative, l’expérience développeur, le cycle de vie agile, la scalabilité et bien sûr la sécurité indispensables à ces APIs.

Plus globalement, cette keynote d’ouverture visait à rappeler que le déploiement des APIs dans le cadre d’un processus d’innovation digitale doit absolument satisfaire certains besoins, relevant tant de la révolution technologique que des bonnes pratiques de coopération et de création de valeur.innovation for techno

Ont suivi deux keynotesproposées respectivement par Accenture et SAP, qui ont été l’occasion de marteler le crédo de « Disrupt or Die » avec de nombreux exemples. Faute de disruption, de nombreuses sociétés vont en effet être amenées à disparaître ou à être rachetées, alors qu’elles étaient autrefois leaders de marché – l’exemple de Nokia était très parlant. A l’inverse, de nombreuses sociétés se réinventent aujourd’hui en profitant des opportunités du Digital, telles que PizzaHut ou Burberry. D’autres enfin, telles que Tesla, créent de toutes pièces une nouvelle offre de valeur. La révolution digitale s’accompagne donc d’un impératif de disruption pour tous les acteurs, qui doivent inventer de nouveaux pans de marché, des nouveaux modes de travail et de nouveaux types de partenariat, sous peine de céder leur place.

II. 3 tracks : Technology, Strategy, Developer

Suite à cette introduction inspirante, speakers et participants sont ont été invités à rejoindre l’un des « tracks » de l’évènement. La journée s’articulait autour de 3 tracks de 6 talks chacun, avec des intervenants venant aussi bien d’Apigee que de grands noms du service ou de l’industrie. Des workshops et des démos étaient organisés en parallèle pour ceux préférant passer en « hands-on ». Direction le premier track orienté « Technology » et un premier talk sur le design « API First ».

> Talk #1 : le SI orienté « SOA/Middleware » doit être complété par une vision « API First »

Ce premier talk d’Ed Anuff, SVP Product Strategy chez Apigee, intitulé « API-First : Going beyond SOA, ESB & Integration », a commencé par balayer les différents schémas d’intégration entre une API et le reste du monde. Notamment avec les habituelles « Experience APIs » qui se focalisent sur une expérience unique – comme celle d’une application mobile – et apportent peu d’éléments d’intégration réutilisables, ou à l’inverse les « Ecosystem APIs » qui visent à créer un écosystème d’applicatifs et pour lesquelles le design, la sécurité et l’analytique doivent être des préoccupations fondamentales et encore plus long-termistes. Le challenge consiste à déployer de nouvelles APIs offrant des possibilités d’intégration multiples, tout en complétant avantageusement une architecture existante, reposant typiquement sur les paradigmes SOA et des middlewares de type ESB.

API FIRSTLa notion de vision « API First » a été ainsi progressivement amenée : c’est-à-dire que l’API doit se présenter comme une nouvelle couche du SI, imaginée de manière frontale, indépendante, réutilisable et parfaitement intégrable avec les écosystèmes des clients et partenaires. Cette couche, l’« API Tier », dispose de ses propres solutions de persistance, sécurité, orchestration et de monitoring. Pour ce faire, elle reposera naturellement sur le paradigme des micro-services, spécialisés, disponibles et aisément évolutifs, à l’instar de l’approche employée par Netflix.

Ed a conclu son talk avec quelques éléments de méthodologie, en invitant les participants à garder en tête le cheminement « What/How/Where » suivant :

1) What to ask when people say « We need APIs » ;
2) How to get to an API-centric Architecture ;
3) Where to go once you’ve become API-centric.

> Talk #2 : l’API management à grande échelle passe par la simplicité et l’accompagnement

S’en est suivi un deuxième talk intitulé « APIs in the Enterprise : Lessons Learned » axé sur des retours d’expérience, notamment celui de Thomson-Reuters. L’un des enseignements présentés par les intervenants concernait l’importance d’une définition commune pour la plateforme de management d’API de l’entreprise : différentes populations ayant différents besoins et par conséquent différentes attentes (certains y voient une problématique de gestion du trafic, d’autres de gestion des accès, ou encore de politique d’utilisation), il importe d’investir énormément dans la pédagogie concernant les objectifs des APIs de l’entreprise et surtout des outils associés, et ce auprès de toute l’organisation.

Et dans une organisation comportant des multitudes d’équipes exploitant des dizaines d’APIs internes ou externes, ces objectifs, ces outils et les processus associés doivent être rendus aussi simples que possible. Les standards, les communautés, la documentation sont bien sûr de bonnes pratiques ; Swagger alias l’Open API Definition Format, représente à ce titre une bonne approche. En complément, des SDKs et Proxies permettent de tester rapidement les implémentations des équipes et de vérifier les hypothèses de travail. Enfin, tout ce qui peut être automatisé doit être automatisé. Cet accompagnement des équipes doit être mis en place dès le début de leur réflexion sur les APIs, tout en leur laissant la responsabilité des choix de design collant le mieux à leurs besoins fonctionnels.

> Entre deux talks : à la découverte de la plateforme Apigee

ApigeeLa pause déjeuner a été l’occasion de visiter les stands présents à l’évènement, et notamment celui d’Apigee. A cette occasion, des présentations et des démonstrations de la plateforme Apigee Edge étaient données. La solution se compose de 3 parties principales. La partie « Gateway » contient les fonctions de Management d’API à proprement parler, telles que la définition de nouvelles APIs à exposer à partir des documents de spécification Swagger, la gestion de la sécurité (authentification, autorisation, protection contre les attaques, etc) ou encore le paramétrage de la politique d’utilisation. La partie « Analytics » offre des fonctionnalités intéressantes pour étudier l’utilisation qui est faite des APIs, permettant ainsi d’affiner les stratégies auprès des clients, partenaires et communautés de développeurs. Enfin, la partie « Portal » sert à documenter les APIs exposées via une instance du CMS Drupal, qui peut être personnalisée selon les besoins.

Greg BrailCette pause déjeuner était aussi l’occasion de rencontrer quelques-uns des speakers d’Apigee, et notamment Greg Brail, Chief Architect, en charge notamment du design de la scalabilité de la solution. Pendant son interview, Greg a insisté sur les enjeux du « API Design First » et d’une couche applicative dédiée aux APIs, seule véritable approche viable aujourd’hui pour délivrer les fonctionnalités attendues par les clients tout en les faisant évoluer facilement et en gardant la main sur les leviers de performance. A ce titre, Greg a présenté la solution Apigee-127, reposant sur les technologies Node.js et Swagger, qui permet de séparer la modélisation de l’API de son implémentation afin de disposer de deux couches applicatives distinctes – comme peut le faire l’outil Swagger Inflector. Apigee repose avant tout sur le format Swagger et en a d’ailleurs été un early adopter avant qu’il soit pris en main par la fondation Linux dans le cadre de l’Open API Initiative, dont Apigee est par ailleurs un membre fondateur.

> Talk #3 : les startups sont l’occasion pour les grandes entreprises de se réinventer

new cultureAprès le déjeuner, direction le track « Strategy » avec un troisième talk intitulé « Value Creation Strategies for APIs » présenté par des intervenants d’Orange ainsi que de Dun & Bradstreet. La question de la culture y a été longuement abordée, notamment lors du retour d’expérience d’Orange concernant son implantation dans la région MEA, auprès de populations très éveillées en termes de pratiques digitales et avec une forte culture de la disruption.
Pour y répondre, le groupe a initié des programmes locaux pour accompagner les communautés de développeurs, mettre en place des accélérateurs de Startup, ou encore aider les entrepreneurs dans leur levée de fonds. En parallèle, de nouvelles APIs avaient été créés pour ces développeurs et exposées facilement sous forme de « toolkits clés-en-main » pour distribuer les solutions du groupe de manière plus adaptée : SMS, USSD, Voice, Carrier Billing, etc. Au final, on voit que le fait d’investir dans des startups permet vertueusement à de grandes entreprises de se réinventer en proposant de nouveaux services, en phase avec les attentes d’une population digitale.

> Talk #4 : les pratiques Lean & Agile sont essentielles dans une stratégie API

Toujours dans la track « Strategy », le talk « How to harness Digital for Growth : Becoming an Agile Enterprise » a mis l’accent sur l’importance des pratiques Lean & Agile dans le cadre de la mise en œuvre d’une API. Organisé sous forme de table ronde avec 6 participants intervenant notamment chez Transavia, Accenture ou Apigee, l’échange a notamment permis de rappeler que la valeur des fonctionnalités doit guider la priorisation des développements, et que les équipes IT & Business doivent se rapprocher pour définir ensemble cette priorisation. Dans tous les cas, l’approche doit être progressive au travers de prototypes, par exemple en encourageant la participation à des hackathons.
Le support du talk résume assez bien la pensée Lean & Agile : « Start small, think big. Just do it », « Engage people to embrace change », « Drive on highest customer value ».

> Talk #5 : les APIs doivent être testées fonctionnellement de bout-en-bout comme tout logiciel

Direction à présent vers le track « Developer » et un cinquième talk sur le test des APIs : « End to end testing: bug squashing for API developers ». Sans présenter de méthodologie révolutionnaire, ce talk offrait un bon rappel des bonnes pratiques de test d’applications en général et notamment des APIs. Après une introduction sur le « Test Driven Development », l’approche « red/green/refactor » et l’intérêt de l’automatisation des tests, l’intervenant Apigee s’est longuement attardé sur les principes et les avantages forts du BDD ou « Behavior Driven Development ». En particulier la dimension collaborative transverse que permet le langage Gherkin, ainsi que son interprétation possible à la fois par l’humain et le code, facilitant les interactions entre développeurs, concepteurs et testeurs. De nombreux frameworks permettant la mise en œuvre de cette stratégie BDD ont été mentionnés et deux d’entre eux fortement utilisés par les équipes Apigee – les frameworks Apickli et Amok – ont été présentés plus longuement lors d’une démonstration en séance.

> Talk #6 : la gouvernance des APIs à grande échelle requiert un comité et un outillage complet

Le dernier talk de la journée, intitulé « How to scale 1000s of API integrations and not lose your mind », s’est focalisé sur la question de la gouvernance, en se basant sur le retour d’expérience de la société DigitasLBI concernant l’un de ses clients. Le client en question disposant d’un très grand nombre d’applications web régionales, interrogeant chacune une ou plusieurs APIs, une politique globale de gouvernance a dû être mise en place afin de gérer l’ensemble des demandes d’évolution de ces APIs. La politique de gouvernance choisie passait à la fois par un comité de gouvernance et par la solution Open Source API Designer de MuleSoft, basée sur le langage RAML. Une stratégie de test basée sur le framework Cucumber et parfois sur des mocks, permettait en aval de valider la non-régression sur les changements préconisés par le comité pour pouvoir déployer globalement les changements en toute confiance.

III. Keynote de clôture : l’intelligence de demain passe par un croisement d’APIs issues de différents secteurs d’activité

Complete Ambient IntelligenceLa keynote de clôture a été présentée par Bhupesh Naik, Head of Digital chez Infosys. Faisant écho au besoin pressant d’innovation digitale déjà évoqué fortement pendant la keynote et les différents talks, Bhupesh est allé plus loin en invitant à la création d’écosystèmes intelligents, et à l’émergence d’une valeur ajoutée encore plus forte, à travers la combinaison cross-secteurs de plusieurs APIs : Energie, Transport, Médical, Home, Bâtiment, etc. Pour permettre de mettre en œuvre une telle vision, le management d’API de demain devra intégrer nativement l’organisation d’écosystèmes, notamment en termes d’interopérabilité et d’orchestration, dans des contextes toujours fortement hétérogènes en termes technologiques (objets connectés et solutions de connectivité) et humains (développeurs, partenaires, clients).

Share
Alexandre ESTELA

1354

Leave a Reply

Your email address will not be published. Required fields are marked *