Catégories
Start-up et applications

Les entreprises d'API ne méritent pas d'exister à moins qu'elles ne s'agrègent

En grandissant, j'ai étudié le piano. Au lycée, je m'ennuyais à réciter Scott Joplin et le synthétiseur Casio auquel j'avais accès ne me tirait pas le cœur. Mais ensuite c'est arrivé … Je me souviens de la première fois que j'ai joué de l'orgue dans une église. Après avoir configuré l'interface (connue sous le nom d'arrêts sur un orgue), j'ai appuyé sur trois touches qui encodaient ma presse en un signal électrique qui était envoyé à l'autre bout de la cathédrale à certains actionneurs qui contrôlaient le flux d'air vers ces tuyaux géants et WOW.

Petit moi pourrait faire un gros son.

Pour moi, c'est la notion fondamentale d'une API géniale: contrôler de vastes ressources avec de simples commandes programmatiques:

  1. Regardez 1 000 images et sélectionnez celles avec des bébés? Il existe une API pour cela.
  2. Simulez 1000 scénarios boursiers et dites-moi si ma transaction a une chance de me permettre de prendre ma retraite? Il existe une API pour cela.
  3. Tout savoir, y compris la cote de crédit de mon professeur du secondaire en saisissant uniquement son adresse e-mail? Il existe une API pour cela.
  4. Envoyer de l'argent via cinq banques vers le compte de quelqu'un à l'autre bout du monde? Il existe une API pour cela.
  5. Faire de la propagande à tous les amis de mes adversaires? Malheureusement, il existe également une API pour cela.

Alors que les développeurs sont devenus les architectes de l'expérience humaine et de leur métier exposés aux masses, l'opportunité d'offrir à ces développeurs des commutateurs qui exploitent de vastes ressources sous la forme d'API s'est accrue. Tout le monde reçoit un clavier d'orgue et l'autre extrémité est connectée à des tuyaux élaborés et vastes à travers le monde.

Avant de rejoindre Shasta, j'étais le CTO d'API Economy chez IBM et c'était notre vision: donner aux entreprises les moyens d'exposer leurs fonctions en tant qu'API que d'autres peuvent mélanger, associer et exploiter – en installant toutes sortes de tuyaux dans le Wurlitzer mondial. Avant cela, chez StrongLoop, nous maintenions des frameworks très populaires que les développeurs utilisent pour créer ces API, notamment Node.js, Express et LoopBack.

Voici ce que j’ai appris: les entreprises d’API de démarrage ne méritent pas d’exister si elles ne se regroupent pas. Pensez-y comme un développeur: quel est l'intérêt d'ajouter une couche d'abstraction? Soit il doit cacher beaucoup de complexité (comme les fameuses API Stripe et Twilio qui cachent la complexité des télécommunications et des banques), soit il doit s'agréger. Pour les startups, elles n’ont généralement pas d’infrastructure complexe à résumer – c’est ce que peuvent faire les API des grandes entreprises. Les startups peuvent gagner un avantage en agrégeant de nombreuses fonctions, ou la même fonction à partir de nombreuses sources. Ou agréger des ensembles de données ou des utilisations de données. Mais attendez de vous dire, Twilio et Stripe étaient autrefois des startups! Oui, et je dirais que ce qu'ils ont fait, c'est un accès global à l'infrastructure (Twilio a facilité l'envoi de SMS sur de nombreux réseaux mobiles, il ne fait pas fonctionner les réseaux. Stripe a facilité le débit des cartes de crédit via de nombreuses banques, ils n'a pas exploité de banque.) Comme de nombreux entrepreneurs l'ont compris, les opportunités d'agrégation entre les grands acteurs sont très contestées. Mais il y a un nouveau domaine pour gagner en avantage: les données, et en particulier les données avec l'apprentissage automatique.

La formation et l'exécution de modèles ML coûtent cher. Il faut des milliers, voire des millions d'heures de GPU pour entraîner un excellent modèle, en mélangeant les données en continu. Il faut énormément d'annotations pour créer l'ensemble d'apprentissage. Si le modèle peut être utilisé dans toutes les entreprises, ou mieux encore, dans tous les secteurs, il est logique de le faire une fois, puis d'optimiser le temps d'exécution et d'offrir ce modèle (derrière une API) pour beaucoup moins qu'il n'en coûterait à quiconque de le créer lui-même, et répartir le coût entre les clients. En effet, ce type d’agrégation des dépenses et de répartition des coûts est l’idée fondamentale d’un éditeur de logiciels: créer un système trop coûteux pour qu’un utilisateur ait créé et réparti le coût entre de nombreuses personnes qui ont besoin des mêmes fonctionnalités.

Des API Easy ML ont déjà été créées – vous pouvez traiter du texte, classer des objets dans des photographies et traduire d'une langue à une autre. Cela devient vraiment intéressant lorsqu'un modèle formé à l'aide de données privées peut être agrégé par un fournisseur et distribué à tous ceux qui peuvent en bénéficier. Imaginez un modèle qui peut prédire combien de temps un bogue dans le code Python prendra pour corriger – il devrait être formé sur tous les rapports de bogues et toutes les modifications de code qui en résultent sur lesquelles nous pouvons mettre la main. Ce modèle s'améliorera avec le nombre de codes et de rapports de bogues qu'il verra, mais personne ne veut rendre son code et ses rapports de bogue publics (en dehors des projets open source, bien sûr.) Un fournisseur de confiance peut avoir accès à ces données, former un modèle , et permettre à ce modèle d'être utilisé par les clients. C'est le type d'avenir d'API que nous allons voir et ce sera génial.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *