Cette année, nous
traduisions un article solide sur le concept Serverless: l'auteur a montré au doigt ce que c'est et pourquoi. Nous savons également que nos partenaires européens ont depuis longtemps baptisé notre plateforme
CPaaS sans serveur - afin de le confirmer explicitement, notre PDG Alexei Aylarov a pris la parole lors de la conférence des
API Days à Amsterdam le 16 octobre. Alexey a expliqué pourquoi le CPaaS sans serveur sera bientôt omniprésent et comment il s'est avéré que Voximplant - soudainement - dès le début a personnifié cette approche. Sous la coupe, vous trouverez une adaptation du texte du discours, des extraits de la présentation sont joints. Bienvenue!
C'était mieux (c)
Avant CPaaS, l'entreprise était obligée de faire beaucoup de travail préparatoire: pour commencer, nous devions choisir un opérateur télécom. Ensuite, vous devez choisir un backend et créer une infrastructure pour tout cela (par exemple, prenez le PBX et le fichier du logiciel Asterisk / FreeSWITCH). Pour aider ce PBX, augmentez également le backend sur le node.js conditionnel ... Et seulement après cela, décidez où et comment la logique métier sera implémentée, puis déployez-la, configurez la surveillance et assurez-vous qu'elle ne se bloque pas pendant le travail. Le lancement d'une solution clé en main peut prendre un an ou plus.
Le CPaaS a permis de sauter les étapes de bas niveau et de démarrer immédiatement la logique métier: pour cela, le client devait étudier la plateforme de communication, puis ... l'infrastructure, le déploiement, la surveillance. D'une part, vous n'avez pas à penser à ce que sera le backend et à chercher un opérateur télécom. De ce fait, le temps de démarrage est réduit sans perte de qualité. En revanche, il reste beaucoup à faire de son côté.
Bienvenue sans serveur
Et puis Serverless est arrivé. Et ici, nous devons nous concentrer sur le point clé - pourquoi moins? Les calculs doivent être effectués quelque part.
Sans serveur ne signifie pas du tout l'absence de serveurs, mais leur absence côté client.
Le concept implique un tas de fournisseur de calcul + devops côté client. Le client n'a pas besoin de maintenir sa propre infrastructure, il lui suffit de payer le fournisseur de calcul pour ... l'informatique :) C'est-à-dire qu'il n'y a des coûts que lorsqu'il y a un besoin d'informatique - c'est beaucoup plus rentable que, par exemple, payer le loyer du serveur 24/7 quand il n'y a pas de réel besoin utilisez ces serveurs 24/7. Le manque d'infrastructure conduit au deuxième avantage important de l'approche: vous ne pouvez pas penser à l'évolutivité, car le fournisseur fournit une mise à l'échelle automatique.
Pour les développeurs, ils prennent le plus souvent un framework sans serveur (par exemple,
Fn Project ou
serverless - oh, ironie), ce qui simplifie le développement et l'assemblage d'applications. En outre, le cadre peut fournir des poignées pour les événements; cela est pratique car sans serveur n'est qu'un concept basé sur des événements (exemples de la téléphonie: un appel est arrivé - c'est un événement, a répondu à un appel - c'est un événement, etc.).
Ajoutez des fonctionnalités sans serveur à CPaaS et obtenez Voximplant conditionnel. En conséquence, l'étape «infrastructure» disparaît - une entreprise étudie un CPaaS sans serveur spécifique, y met en œuvre une logique métier et surveille silencieusement son fonctionnement sans se soucier d'acheter des racks, des serveurs, de trouver une salle pour une salle de serveurs, etc. Bien sûr, c'est un cas idéal et chaque solution est unique: il est possible que le client ait besoin d'une sorte de matériel de son côté, mais Serverless fait tout son possible pour s'assurer que les clients n'ont pas de tels besoins.
Améliorer l'expérience utilisateur
Parfois, les plates-formes sans serveur font ce qu'on appelle Les fonctions sont des intermédiaires entre le client et d'autres services (concept
FaaS ). Par exemple, les fonctions peuvent être chargées d'accepter les requêtes HTTP et de donner une réponse, ou d'interagir via HTTP avec des services tiers. Les webhooks et les interactions spécifiques aux télécommunications peuvent également être traités ici.
Cependant, cette couche a ses limites:
- délai d'exécution limité;
- contexte immuable (apatride);
- le traitement des appels est dissocié de l'exécution de la plate-forme car la communication se fait via HTTP.
Dès le début, l'architecture Voximplant a rendu le runtime accessible aux clients, donc le contrôle des appels se fait à l'aide de scripts JS, plutôt que de HTTP sec. Le runtime intégré offre plusieurs avantages:
- Les scripts Cloud JS prennent en charge la dernière norme linguistique - ECMA2018;
- les scripts utilisent l' API native de la plateforme ;
- contrôle en temps réel: le traitement des événements et l'exécution des fonctions se produisent instantanément;
- il est possible d'utiliser un débogueur avec un break et des états;
- Vous pouvez tout attacher à la gestion des erreurs, y compris les alertes vocales pour une personne. Un exemple de gestion des erreurs basée sur les événements:
function onHttpRequestFailed() { call.say(“Unfortunately, we couldn't process your request, please try again later”, Language.US_ENGLISH_FEMALE) call.addEventListener(CallEvents.PlaybackFinished,(e) => { if (destroy) VoxEngine.terminate() else tryAgain() }) }
L'événementiel est particulièrement important car a) il s'agit d'une approche unifiée b) ajoute de la flexibilité. Toute action peut être interprétée comme un événement et traitée dans un script JS basé sur le cloud: répondre à l'appel entrant avec synthèse vocale, reconnaître la messagerie vocale et raccrocher, transférer l'appel vers SIP, couper la notification push, etc.
En conséquence, notre plate-forme sans serveur réduit la latence, améliore l'expérience utilisateur et, finalement, réduit le temps de lancement du produit fini autant que possible: si dans «l'ère pré-CPaa'n'nu», cela pourrait être de six mois, alors avec Voximplant vous pouvez
rencontrer 1 mois ( y compris toutes les approbations et réunions, le temps de développement immédiat est encore plus court).
Le futur
Les plates-formes de communication sans serveur seront de plus en plus demandées car la demande pour ces services est en augmentation, ainsi que la fonctionnalité des plates-formes elles-mêmes. Le CPaaS sans serveur sera bientôt en mesure d'offrir le stockage de données, une intégration profonde avec les systèmes externes (notre
connecteur Dialogflow en est un bon exemple), la fonctionnalité de serveur Web, enfin :) Les perspectives sont brillantes, il vous suffit de suivre la mise en œuvre et de profiter des progrès du concept Serverless.