Le 28 septembre à la conférence
RubyRussia Nikolai Sverchkov fera une présentation Serverless is Ruby Future.
Ivan Solovyov a expliqué dans une interview pourquoi cette tendance est intéressante et pourquoi les rubistes devraient y prêter attention.
Dites-moi comment vous êtes arrivée à Ruby?Il a commencé la programmation à l'université. Toute la pratique était en C ++, mais j'ai fait les derniers articles et la thèse en Ruby. Pourquoi j'ai choisi Ruby, je ne le dirai pas avec certitude, probablement parce que la langue à cette époque était dans le sillage du battage médiatique. Personne ne savait à l'Université Ruby, encore moins enseigné. Mais après avoir obtenu mon diplôme, je voulais écrire en Java. Ensuite, il m'a semblé que Java est spécial, les développeurs les plus cool, une sorte de caste supérieure de programmeurs, et je voulais être l'un d'eux. Mon premier entretien d'embauche a eu lieu en Java junior, et j'ai échoué avec succès. Mais il a pu entrer dans une entreprise où Ruby était nécessaire. C'est peut-être pour le mieux! Quelques années seulement se sont déplacées vers Elixir. Maintenant je travaille dans Evil Martians, je fais du backend.
Votre rapport sur sans serveur. Comment avez-vous commencé à travailler dans ce sens? L'entrée dans la technologie est-elle difficile?Il a commencé à étudier pendant son temps libre. J'avais un vrai, mais pas lié à la tâche principale du travail. Puis il a commencé à utiliser le serveur sans serveur dans les projets de l'entreprise. Le seuil d'entrée est assez bas, je pense qu'il n'est que légèrement supérieur à celui d'Heroku. Écrivez votre premier "Bonjour, monde!" ce sera très simple - il y a un tas d'articles, des tutoriels, une documentation extrêmement riche d'Amazon. Et puis, bien sûr, il y aura des difficultés. Il y a des écueils, j'en parlerai dans le rapport.
Les débutants devraient-ils plonger sans serveur et l'utiliser en production?Je pense que oui! Mais pas besoin de se précipiter pour tout implémenter sans serveur. Pour commencer, vous pouvez regarder votre application et y trouver un petit morceau de logique métier, que vous pouvez mettre dans un service séparé. Si ce nouveau microservice a une interface de communication simple, alors avec une probabilité de 99%, vous pourrez l'implémenter en utilisant le même AWS Lambda. Idéalement, s'il s'agit d'une logique métier sans état, vous n'avez pas à réfléchir à la façon de sauvegarder les résultats, pensez aux artefacts de l'exécution de votre fonction lambda. À titre d'exemple, l'envoi d'une lettre peut être une bonne première tâche. Dans mon rapport, je soulèverai séparément la question de savoir à quel spectre de tâches le modèle informatique sans serveur convient le mieux.
La principale recommandation est de séparer le code de logique métier des lambdas eux-mêmes. Il s'agit d'une variante de la règle douloureusement familière «contrôleurs minces, modèles épais». Tout d'abord, il sera plus facile de tester de cette façon. Deuxièmement, si dans le processus, vous réalisez que sans serveur ne convient pas à votre tâche, vous pouvez facilement migrer vers une solution éprouvée, par exemple, remplacer la couche d'entrée sans serveur par un serveur Web standard. À cet égard, de très bons
Jets . Il s'agit d'un framework Ruby Serverless qui vous permet d'écrire une application prête à l'emploi à la fois sur AWS Lambda et sur une instance Amazon EC2 standard.
Pour en savoir plus sur ce framework Ruby?Jets est unique en son genre. Malgré le fait qu'il existe d'autres frameworks sans serveur adaptés à certaines langues, Jets est le plus fonctionnel. Maintenant, il a plus de 2500 commits dans le maître. Le framework utilise beaucoup de conventions familières pour un développeur Ruby, c'est un tel "Ruby on Rails on Serverless". Mais cela a ses inconvénients. Étant donné qu'avec un modèle informatique sans serveur, vous payez le temps d'exécution du code, l'initialisation et le chargement d'un grand nombre de dépendances lourdes sont coûteux au sens littéral du terme. La divulgation de ce sujet sera également donnée dans mon rapport.
Quelles plates-formes sont les plus courantes pour les serveurs sans serveur maintenant, quelles sont leurs différences, laquelle est préférable de choisir? Si je comprends bien, vous vous noyez maintenant pour Amazon Web Services, car la plupart du temps vous en parlez.Vous demandez pourquoi j'utilise souvent le mot «lambda» dans notre conversation? Je pense que l'histoire est comme avec Karcher ou Xerox. Il existe des marques au nom desquelles il est d'usage d'appeler toute une niche de produits. En 2014, Amazon a été le premier à fournir un accès public à un modèle informatique sans serveur - AWS Lambda. Tout le monde: Microsoft avec Azure Functions, Google avec Cloud Function, IBM avec IBM Cloud Functions, est toujours mentalement dans le rôle de rattraper son retard. Bien que le marché sans serveur soit en plein essor, les prix des services AWS sont souvent plus élevés que leurs concurrents. Ainsi, les nouvelles versions, telles que
Google Cloud Run , peuvent transformer le jeu du jour au lendemain. Si nous effectuons une analyse plus détaillée des comparaisons de plates-formes, je recommanderais de regarder une
vidéo de Ruslan Serkin de DataArt de la conférence DUMP 2019 .
Que pensez-vous, dans quelle direction va se développer le serverless?Oh, c'est la partie la plus intéressante de mon rapport! Je peux me passer de spoilers - venez écouter! Au lieu de cela, je peux parler de servitude et de production. En avril de cette année, j'étais à la conférence RubyConfBy à Minsk, à laquelle l'auteur des mêmes Jets s'est exprimé. Lors de l'afterparty, nous avons discuté du développement sans serveur et pourquoi, s'il y a un soutien des principaux acteurs de l'industrie, nous ne voyons pas la distribution de masse des fonctions lambda. Les avantages du modèle sont évidents, l'écosystème est transparent, mais il n'y a pas de confiance généralisée de la part de la communauté informatique. En conséquence, nous sommes arrivés à la conclusion que maintenant sans serveur est une sorte de joueur fantôme et que la situation rappelle quelque peu celle qui était avec Docker à un moment donné. On pense depuis longtemps que Docker en production est un suicide. Nous voyons maintenant que la conteneurisation est le principal outil de distribution de logiciels. Je pense qu'à l'avenir, sans serveur attend la même chose. De plus en plus de gens lui feront confiance.
Les monolithes sans serveur vont-ils tuer?Cette question peut être reformulée comme "l'architecture du microservice va-t-elle tuer les monolithes?" Parce que sans serveur est un microserveur idéal - il est petit, il est sans état et possède une interface minimale pour communiquer avec le monde extérieur. Tout comme les microservices ne tuent pas les monolithes, les lambdas ne tuent pas les monolithes. Les trois architectures ont une gamme spécifique de tâches auxquelles elles sont parfaitement adaptées. Et vice versa - il y a des tâches où, par exemple, sans serveur n'est pas pratique à utiliser. Recherchez les détails dans mon rapport.
Que faire avec le verrouillage du fournisseur? Par exemple, vous avez développé un lambda pour Amazon, mais vous avez décidé de passer à Google.La migration entre les plates-formes est pénible si vous n'utilisez pas une sorte de cadre, par exemple,
sans serveur , qui fournit une API abstraite sur les fournisseurs de cloud et vous permet de déployer la même fonction dans Amazon et Google. Si vous, en gros, faites tout avec vos mains, alors oui, ce sera un peu douloureux.
Que faire des lambdas courants lors de l'utilisation de code? Par exemple, certains composants communs, certaines fonctions utilitaires, etc.Il n'y a toujours pas de meilleures pratiques à ce sujet. Et la question peut à nouveau être reformulée dans "Comment tâtonner un code commun entre microservices?", Parce que la signification est la même. Il existe une option lorsque vous tenez la logique réutilisée quelque part en partage et que la fonction elle-même la connecte. Cette approche fonctionnera bien, par exemple, avec Go, où la sortie que vous obtenez est un fichier exécutable. Une autre option consiste à se débarrasser de la connectivité des composants et à permettre la duplication. Cela vaut probablement la peine d'essayer et de voir ce qui fonctionne le mieux. La seule chose que je peux conseiller est de ne pas essayer de rendre les fonctions lambda universelles. À un moment donné, il pourrait vous sembler qu'une fonction uber serait la solution parfaite au problème de la duplication de code. Mais avec le temps, vous vous rendrez compte que c'est la route vers nulle part. Vous obtiendrez une certaine «version monolithique sans serveur» avec tous les problèmes de la première et de la seconde architecture.
Nous discuterons plus en détail après le rapport sur RubyRussia!Venez et vous, les
inscriptions sont encore ouvertes, la conférence se tiendra samedi 28 septembre prochain.
Il y aura non seulement des rapports, mais aussi des stands des meilleures entreprises:
Organisateur -
EvroneAssocié commandité -
ToptalPartenaire Gold -
GettPartenaires Silver -
Valarm ,
JetBrains ,
Bookmate et
CashwagonPartenaire Bronze -
InSales