Sans serveur dans le cloud: AWS vs Google Cloud vs Microsoft Azure

Si vous vous êtes déjà réveillé à 3 heures du matin parce qu'un serveur s'est détraqué, vous comprendrez l'attrait d'un mot à la mode comme «sans serveur». La configuration des machines peut prendre des heures, des jours, voire des semaines, puis elles doivent être constamment mises à jour pour corriger les bogues et les failles de sécurité. Ces mises à jour apportent généralement des tracas qui leur sont propres, car les nouvelles mises à jour provoquent des incompatibilités forçant d'autres mises à jour ou alors cela semble à l'infini.

La chaîne interminable de maux de tête liés à l'exécution d'un serveur est l'une des raisons pour lesquelles les grandes sociétés de cloud ont adopté l'architecture «sans serveur». Ils savent que le patron a entendu les excuses - le serveur ceci, le serveur cela - depuis trop longtemps. Si nous pouvions seulement nous débarrasser de ces serveurs, le patron doit réfléchir.

C'est un terme de vente merveilleux avec le seul problème étant que ce n'est pas strictement vrai. Ces applications sont sans serveur de la même manière que les restaurants sont sans cuisine. Si ce que vous voulez est au menu et que vous aimez la façon dont le cuisinier le prépare, vous asseoir dans un restaurant est super. Mais si vous voulez un plat différent, si vous voulez des épices différentes, eh bien, vous feriez mieux d'avoir votre propre cuisine.

Amazon, Google et Microsoft sont trois des plus grandes entreprises qui se battent pour héberger les applications du futur, celles qui, espèrent-elles, seront écrites sur leur API sans serveur et gérées via leur couche d'automatisation. Si les plates-formes font ce que vous voulez et que les nouveaux modèles sont assez généraux, elles peuvent être le moyen le plus simple et le plus rapide de créer votre propre application Web licorne de plusieurs milliards de dollars. Vous n'écrivez que les bits cruciaux de la logique et la plate-forme gère tous les détails.

Les fonctions sans serveur deviennent la colle ou le langage de script qui relie toutes les fonctionnalités du cloud. Les outils de cartographie ou d'IA qui étaient autrefois assez indépendants sont désormais liés via les fonctions sans serveur basées sur les événements. Désormais, une plus grande partie de votre travail peut être résolue par des requêtes qui ondulent et rebondissent dans les différents coins de chaque nuage, se déclenchant et étant déclenchées par un flux d'événements. Si vous souhaitez explorer l'apprentissage automatique et l'utiliser pour analyser vos données, l'un des moyens les plus rapides de le faire est de créer une application sans serveur et de commencer à envoyer des événements au coin de l'apprentissage automatique du cloud.

La promesse implicite est que tout découper plus fin facilite le partage des ressources dans le cloud. Dans le passé, tout le monde créait frénétiquement de nouvelles instances avec, par exemple, Ubuntu Server fonctionnant dans sa propre machine virtuelle. Tout le monde a utilisé le même système d'exploitation et il a été dupliqué des millions de fois sur la même boîte réelle qui prétendait être une douzaine de boîtes Ubuntu virtuelles ou plus. Les opérations sans serveur évitent toute cette duplication, ce qui rend le cloud computing considérablement moins cher, en particulier pour les travaux qui s'exécutent de manière sporadique et ne bloquent jamais vraiment l'ancien boîtier installé dans votre salle de serveurs climatisée.

Bien sûr, toute cette commodité a un coût caché. Si vous souhaitez quitter ou déplacer votre code vers un autre site, vous serez probablement bloqué en réécrivant la majeure partie de la pile. Les API sont différentes, et bien qu'il y ait une certaine normalisation autour des langages populaires comme JavaScript, elles sont assez proches du propriétaire. Il y a de nombreuses possibilités de verrouillage.

Pour comprendre l'attrait des options sans serveur, j'ai passé du temps à créer quelques fonctions et à fouiller dans les piles. Je n'ai pas écrit beaucoup de code, mais c'était le but. J'ai passé plus de temps à cliquer sur des boutons et à taper dans des formulaires Web pour tout configurer. Vous souvenez-vous quand nous avons tout configuré avec XML puis JSON? Maintenant, nous remplissons un formulaire Web et le cloud le fait pour nous. Cependant, vous devez toujours penser comme un programmeur pour comprendre ce qui se passe dans les coulisses et hors de votre contrôle.

AWS Lambda

AWS Lambda est en train de devenir la couche de script shell pour l'ensemble du cloud d'Amazon. C'est un système de base qui vous permet d'intégrer des fonctions qui répondent aux événements qui pourraient être générés par presque n'importe quelle partie de la vaste infrastructure cloud d'Amazon. Si un nouveau fichier est téléchargé sur S3, vous pouvez le faire déclencher une fonction qui en fait quelque chose d'intéressant. Si une vidéo est transcodée par Amazon Elastic Transcoder, vous pouvez avoir une fonction Lambda en attente de déclenchement à la fin. Ces fonctions, à leur tour, peuvent déclencher d'autres opérations Lambda ou peut-être simplement envoyer une mise à jour à quelqu'un.

Vous pouvez écrire des fonctions Lambda en JavaScript (Node.js), Python, Java, C # et Go. Étant donné que ces langages peuvent intégrer de nombreux autres langages, il est tout à fait possible d'exécuter d'autres codes comme Haskell, Lisp ou même C ++. (Consultez cette histoire sur la compilation du C ++ hérité dans une bibliothèque à utiliser avec AWS Lambda.)

L'écriture de fonctions Lambda semble souvent beaucoup plus complexe que prévu, car Amazon propose de nombreuses options de configuration et d'optimisation. Bien qu'il soit techniquement vrai que vous ne pouvez écrire que quelques lignes de code et accomplir de grandes choses, j'ai eu le sentiment que je devais ensuite allouer plus de temps à la configuration du fonctionnement du code. Une grande partie de cela est accompli en remplissant des formulaires dans le navigateur au lieu de taper dans des fichiers texte. Parfois, on a l'impression que nous venons d'échanger un éditeur de texte contre un formulaire de navigateur, mais c'est le prix à payer pour conserver toute la flexibilité qu'Amazon offre à l'utilisateur Lambda.

Certaines des étapes supplémentaires sont dues au fait qu'Amazon expose plus d'options à l'utilisateur et attend plus du créateur de fonctions pour la première fois. Une fois que j'avais fini d'écrire une fonction chez Google ou Microsoft, je pouvais pointer mon navigateur vers la bonne URL et la tester immédiatement. Amazon m'a fait cliquer pour configurer la passerelle API et ouvrir le bon trou dans le pare-feu.

En fin de compte, tout ce clic ajoute une couche de prise en main qui rend le travail un peu plus facile que de commencer avec un fichier texte. Lorsque je créais une fonction, le navigateur avait un avertissement, "Cette fonction contient des bibliothèques externes." À l'époque de Node pur, c'était quelque chose que je devais simplement savoir, ou je l'apprendrais en recherchant le message d'erreur sur Google en croisant les doigts et en espérant que la réponse était là. Maintenant, le cloud se précipite pour aider.

Amazon propose un certain nombre d'autres options qui sont à peu près aussi «sans serveur» qu'AWS Lambda, si sans serveur signifie vous soulager des tâches de gestion de serveur. Il dispose d'outils élastiques tels qu'Amazon EC2 Auto Scaling et AWS Fargate qui mettent en marche et arrêtent les serveurs, et AWS Elastic Beanstalk, qui prend votre code téléchargé, le déploie sur les serveurs Web et gère l'équilibrage de charge et la mise à l'échelle. Bien sûr, avec beaucoup de ces outils d'automatisation, vous êtes toujours responsable de la création de l'image du serveur.

L'une des offres les plus utiles est AWS Step Functions, une sorte d'outil de diagramme de flux sans code permettant de créer des machines d'état pour modéliser ce que les architectes logiciels appellent le flux de travail. Une partie du problème est que toutes les fonctions sans serveur sont censées être entièrement exemptes d'état, ce qui fonctionne lorsque vous appliquez une logique métier assez basique, mais cela peut être un peu un cauchemar lorsque vous guidez un client à travers un liste de contrôle ou un organigramme. Vous allez constamment dans la base de données pour recharger les informations sur le client. Les fonctions d'étape collent les fonctions Lambda avec l'état.

Google Cloud Functions et Firebase

Si votre objectif est de vous débarrasser des tracas liés à la configuration des serveurs, Google Cloud propose un certain nombre de services qui offrent une grande liberté, comme le besoin d'un mot de passe root ou même l'utilisation d'une ligne de commande.

À partir de Google App Engine en 2008, Google a progressivement ajouté différentes options «sans serveur» avec diverses combinaisons de messagerie et de transparence des données. Celui appelé Google Cloud Pub / Sub vous cache la file d'attente de messagerie. Il vous suffit donc d'écrire le code pour le producteur et le consommateur de données. Google Cloud Functions propose des calculs basés sur les événements pour de nombreux produits majeurs, y compris certains des outils et API de renom. Et puis il y a Google Firebase, une base de données sur les stéroïdes qui vous permet de mélanger du code JavaScript dans une couche de stockage de données qui fournit les données à votre client.

Parmi ceux-ci, Firebase est le plus intriguant pour moi. Certains suggèrent que les bases de données étaient l'application sans serveur d'origine, éliminant les structures de données et les tâches de stockage sur disque pour fournir toutes les informations via un port TCP / IP. Firebase pousse cette abstraction à l'extrême en ajoutant également du code JavaScript et de la messagerie pour faire presque tout ce que vous voudrez peut-être faire avec l'infrastructure côté serveur, y compris l'authentification. Techniquement, ce n'est qu'une base de données, mais c'est celle qui peut gérer une grande partie de la logique métier et de la messagerie de votre pile. Vous pouvez vraiment vous en sortir avec un peu de HTML client, CSS, JavaScript et Firebase.

Vous pourriez être tenté d'appeler les couches JavaScript de Firebase «procédures stockées», tout comme Oracle l'a fait, mais cela manquerait la vue d'ensemble. Le code Firebase est écrit en JavaScript et s'exécutera donc dans une version locale de Node.js. Vous pouvez intégrer une grande partie de la logique métier dans cette couche car le monde de Node est déjà rempli de bibliothèques pour gérer ce flux de travail. De plus, vous profiterez des plaisirs du code isomorphe qui s'exécute sur le client, le serveur et maintenant la base de données.

La partie qui a attiré mon attention était la couche de synchronisation intégrée à Firebase. Il synchronisera les copies des objets de la base de données sur tout le réseau. L'astuce est que vous pouvez configurer votre application client comme un simple autre nœud de base de données qui souscrit à toutes les modifications pour les données pertinentes (et uniquement les données pertinentes). Si les données changent au même endroit, elles changent partout. Vous pouvez éviter tous les tracas de la messagerie et vous concentrer uniquement sur l'écriture des informations dans Firebase, car Firebase les répliquera là où elles doivent être.

Vous n'avez pas besoin de vous concentrer uniquement sur Firebase. Les fonctions Google Cloud plus basiques sont une approche plus simple pour intégrer du code personnalisé dans le cloud Google. Pour le moment, Cloud Functions n'est en grande partie qu'une option pour écrire du code Node.js qui s'exécutera dans un environnement Node préconfiguré. Alors que le reste de Google Cloud Platform prend en charge une grande variété de langages, de Java et C # à Go, Python et PHP, Cloud Functions est strictement limité à JavaScript et Node. Il y a eu des indices que d'autres options linguistiques sont à venir et je ne serais pas surpris qu'elles apparaissent bientôt.

Google Cloud Functions n'atteint pas aussi profondément le Google Cloud qu'AWS Lambda atteint AWS, du moins à ce stade. Lorsque j'ai cherché à créer une fonction pour interagir avec Google Docs, j'ai trouvé que je devrais probablement utiliser l'API REST et écrire le code dans quelque chose appelé Apps Script. En d'autres termes, le monde de Google Docs possède sa propre API REST qui était sans serveur bien avant que le mot à la mode ne soit inventé.

Il convient de noter que Google App Engine continue de fonctionner. Au début, il proposait simplement de lancer des applications Python pour répondre à la demande de quiconque accédait au site Web, mais il a été étendu au fil des ans pour gérer de nombreux environnements d'exécution de langage différents. Une fois que vous avez regroupé votre code dans un exécutable, App Engine gère le processus de démarrage de suffisamment de nœuds pour gérer votre trafic, en augmentant ou en diminuant à mesure que vos utilisateurs envoient des demandes.

Il y a encore quelques obstacles à garder à l'esprit. Comme avec Cloud Functions, votre code doit être écrit de manière relativement sans état et il doit terminer chaque requête dans un laps de temps limité. Mais App Engine ne supprime pas tout l'échafaudage ni n'oublie tout entre les demandes. App Engine a joué un rôle important dans la révolution sans serveur et reste le plus accessible à ceux qui gardent un pied en arrière dans la méthode à l'ancienne de créer leur propre pile en Python, PHP, Java, C # ou Go.

Fonctions Microsoft Azure

Microsoft, bien sûr, travaille aussi dur que les autres pour s'assurer que les gens peuvent également faire toutes ces choses intelligentes sans serveur avec le cloud Azure. La société a créé ses propres fonctions de base pour jongler avec les événements - les fonctions Azure - et construit des outils sophistiqués qui sont encore plus accessibles aux semi-programmeurs.

Le plus grand avantage de Microsoft peut être sa collection d'applications Office, les anciens exécutables de bureau qui migrent lentement mais sûrement vers le cloud. En effet, une comptabilité des revenus du cloud a placé Microsoft devant Amazon, en partie en regroupant une partie de ses revenus Office dans la rubrique éphémère du «cloud».

L'un des meilleurs exemples de la documentation Azure Functions montre comment une fonction cloud peut être déclenchée lorsque quelqu'un enregistre une feuille de calcul sur OneDrive. Soudain, les petits elfes dans le nuage prennent vie et font des choses sur la feuille de calcul. C'est forcément une aubaine pour les boutiques informatiques qui soutiennent les équipes qui aiment leurs feuilles de calcul Excel (ou d'autres documents Office). Ils peuvent écrire des fonctions Azure pour faire pratiquement n'importe quoi. Nous pensons souvent que HTML et le Web sont la seule interface avec le cloud, mais il n'y a aucune raison pour que cela ne puisse pas passer par des formats de documents tels que Microsoft Word ou Excel.