Non classé

WTF est sans serveur? – WTF est mon ingénieur parle – Bien installer son serveur

Le 9 juin 2019 - 14 minutes de lecture

Les architectures sans serveur évoluent depuis quelques années et beaucoup les voient comme l'avenir de l'infrastructure. Parlons des ressources sans serveur WTF et des raisons pour lesquelles les ingénieurs peuvent en parler. (Psst … Je recommande de lire mon article sur les piles de technologie avant de continuer avec cet article.)

Un peu d'histoire

Pour comprendre sans serveur, vous devez d'abord comprendre les alternatives. Alors que le sans-serveur représente un changement important dans la gestion de notre infrastructure, à certains égards, le nombre de personnes non techniques qui pensent que le réseau fonctionne est plus proche. Voici un très bref historique de la gestion des serveurs depuis le début d’Internet jusqu’à ce jour.

Des batteries de serveurs sur site

Vous ne devriez pas être surpris d'apprendre que, pour tous les sites Web que vous visitez et toutes les applications que vous utilisez qui se connectent à Internet, il existe au moins un ordinateur à l'autre extrémité qui interagit avec celui-ci (à partir de là, je ne ferai référence qu'à des applications comprenant des sites Web, applications mobiles et tout ce qui fonctionne sur Internet). Au début, c'était tout simplement parfait. Tout le monde peut exécuter un serveur à partir de son domicile et le configurer pour exécuter une application Web. Cependant, les batteries de serveurs sont plus courantes: les racks d’hébergement de grands magasins sur des racks de serveurs capables d’exécuter les applications des utilisateurs. Les petites applications utiliseraient un serveur partagé qui exécutait également d'autres applications. Les applications de taille moyenne utiliseront un ou plusieurs serveurs dédiés. Les grandes applications conduisent généralement leurs propres maisons de serveurs pour des raisons financières ou ont davantage de contrôle sur l'infrastructure. Les indicateurs de taille ici se réfèrent généralement au trafic Web; si l'application est utilisée par une poignée d'utilisateurs par jour ou par des milliers d'utilisateurs par seconde.

Ça sonne bien, faisons-le

Alors que sur site (par exemple, auto-traité par la société qui les utilise) et les serveurs partagés semblent très bien – et est en fait encore populaire aujourd'hui – ils ont certaines limitations. Tout d’abord, c’est un long délai en termes de nouveau matériel. Au fur et à mesure que l'application gagne en popularité ou en complexité, l'application a besoin de plusieurs serveurs pour gérer la charge. Une entreprise qui exécute sa propre batterie de serveurs doit commander et configurer le matériel, ce qui prend des jours, voire des semaines. Une entreprise qui engage des serveurs tiers partagés ou dédiés peut accélérer le nouveau matériel à condition que les tiers aient quelque chose à portée de main, mais ils doivent tout de même le configurer, ce qui prend encore des heures, voire des jours. Cela est particulièrement problématique en cas d'éclats de trafic imprévus, tels qu'un renforcement des relations publiques; Si vous ne pouvez pas planifier à l'avance, votre demande peut être lente ou jusqu'à un moment triomphant.

Deuxièmement, vous devez remplacer le matériel pour prendre en compte les fluctuations du trafic. Outre les augmentations ponctuelles des relations publiques, la plupart des applications ont des flux et reflux naturels dans le trafic, le plus souvent en fonction du moment de la journée ou de la semaine. Avec les batteries de serveurs, vous devez toujours disposer de suffisamment de matériel pour la mémoire supérieure. Une grande partie de la journée, vous payez pour des serveurs qui ne font rien.

Enfin, considérons la maintenance. Les batteries de serveurs ont besoin d’Internet haut débit, d’électricité, de systèmes de refroidissement et de techniciens pour configurer de nouveaux serveurs et réparer ceux qui sont corrompus. Il y a beaucoup de travail lorsque vous avez des dizaines, des centaines ou des milliers de serveurs. Ensuite, considérons la vitesse à laquelle l’informatique a évolué depuis ses débuts. Les serveurs sont en ruines en quelques années et les services Internet doivent souvent être mis à niveau pour rester compétitifs. Enfin, vous devez gérer la maintenance du logiciel. Pour des raisons de performances et de sécurité, vous souhaitez que ces serveurs exécutent la dernière version du système d'exploitation et des autres logiciels. C'est beaucoup de travail. Avec un serveur partagé, quelqu'un d'autre fait beaucoup de ce travail pour vous, mais vous payez un supplément pour le faire, et vous êtes encore principalement seul dans le logiciel.

Cloud Computing / Infrastructure en tant que service (IaaS)

Viennent ensuite Amazon Web Services (AWS), Google Cloud, Azure et de nombreux autres services qui ont popularisé le cloud computing. Les serveurs cloud sont des batteries de serveurs qui passent au niveau supérieur. Les grandes entreprises technologiques comme Amazon, Google et Microsoft étaient très douées pour faire fonctionner des centaines de milliers de serveurs afin de prendre en charge leur propre entreprise et ont décidé de vendre leurs compétences à d'autres. Ils ont commencé à utiliser encore plus de serveurs et à les louer à tous ceux qui le souhaitaient.

La principale différence entre ces services et les utilisateurs du serveur précédents est que vous pouvez les démarrer et les arrêter par programmation, et que vous comptez pour chaque heure ou minute. En d’autres termes, vous n’avez pas à appeler ni envoyer de courrier électronique à qui que ce soit pour lui demander de configurer un serveur, vous pouvez le faire en un clic ou encore moins en écrivant un logiciel qui se lance automatiquement et arrête les instances.

Bien que cela ne semble pas être un grand fossé, c’était un échange de jeu. Au lieu de planifier des semaines ou des mois à l'avance pour prendre en compte les pointes de trafic attendues, vous pouvez écrire un logiciel permettant de détecter ou de prédire un trafic important, puis de démarrer et de configurer les serveurs automatiquement (ceci s'appelle la mise à l'échelle automatique, et tous les principaux fournisseurs de curseurs ont commencé à l'offrir en sortie). service-ou-la-boîte), puis les baissez et arrêtez de payer pour eux quand le trafic est mort. Vous pouvez configurer automatiquement vos serveurs pour qu'ils exécutent le programme et tous les logiciels de support au lieu de les configurer manuellement. Étant donné que vous êtes facturé à la minute ou à l’heure, vous n’auriez pas à payer tout votre matériel en pleine nuit, lorsque personne n’utilisait votre application.

conteneurs

Dernier arrêt avant le serveur, les services de conteneur tels que Docker ont été mis en avant ces dernières années. Les conteneurs ont été principalement créés pour moderniser les serveurs partagés. Il s’agit d’un mécanisme normalisé qui englobe toute la configuration de l’application et la distribue automatiquement à de nouveaux serveurs. Les services de conteneur ont simplifié la configuration, le déploiement et la mise à l'échelle de l'infrastructure d'une application. Les conteneurs n’ont augmenté que de manière bien visible il ya quelques années et sont toujours très populaires; Il reste à voir si l’histoire les considère comme une étape sur la voie de l’installation sans serveur ou un outil à long terme dans diverses options d’infrastructure.

Allez-vous enfin me dire que le WTF sans serveur est?

Vous avez peut-être remarqué que le mot "serveur" était utilisé à plusieurs reprises dans chaque solution précédente. Vous voyez probablement où je veux en venir avec ceci: sans serveur élimine la nécessité pour les ingénieurs de penser aux serveurs. Notez que je n'ai pas dit que nous avons retiré les serveurs de l'équation; ils sont toujours à l'arrière-plan, mais ils font partie de l'équipe d'infrastructure à laquelle les ingénieurs n'ont pas besoin de réfléchir. Comme nous nous appuyons sur des fournisseurs de services Internet et des sociétés du secteur de l’énergie pour faire fonctionner nos applications, mais n’avons pas à y penser beaucoup, sans serveur nous permet de traiter les serveurs de la même manière. Les serveurs sont absolument nécessaires, mais quelqu'un d'autre fait tout le travail pour les maintenir pour nous.

Quel est le problème avec les serveurs?

La raison principale pour laquelle abandonner l’idée de serveurs séduit les ingénieurs, c’est qu’il faut une compétence spécialisée pour les manipuler. Les jeunes entreprises en démarrage doivent soit engager un ingénieur d'infrastructure (ou un titre similaire, Ingénieur système ou Ingénieur DevOps), ou faire quelque chose avec quelqu'un, généralement un ingénieur backend, qui ne se spécialise pas dans la gestion de serveur. La première approche est coûteuse (les ingénieurs d’infrastructure sont parmi les mieux payés du secteur) et la seconde prendra beaucoup de temps aux autres ingénieurs et risque de conduire à des systèmes de sous-production plus lents et moins fréquents. Serverless n'annule pas totalement le besoin d'ingénieurs de ce type, mais peut vous permettre de faire plus avec moins.

Une autre raison qui pousse les ingénieurs à se débarrasser des serveurs est qu’ils sont assez lourds. Alors que les serveurs de garde sont certainement moins encombrants que les entreprises de serveurs, chaque serveur ou conteneur peut généralement traiter des milliers de demandes à la minute, ce dont vous n’avez probablement pas besoin au début ni pendant les heures de pointe. Vous pouvez automatiquement redimensionner les serveurs, mais la granularité est excellente: vous ne pouvez pas faire tourner un demi-conteneur. Et, alors que les serveurs cloud se mettent en place dans quelques minutes, il reste encore beaucoup de temps pour que le trafic prenne de l'ampleur.

Fonctionnalités en tant que service (FaaS)

Enfin, je vais enfin vous dire ce que signifie sans serveur. Serverless vous permet d'exécuter beaucoup ou tout votre backend … attendez-le … sans serveurs. Oui, il y avait beaucoup d'accumulation pour quelque chose que vous auriez pu tirer du nom.

La façon dont cela fonctionne est que les grands fournisseurs de cloud ont introduit ce que l'on appelle "Fonctions en tant que service" (FaaS), comme AWS Lambda et Google Cloud Functions. Amazon et Google exploitent les serveurs, qui permettent aux développeurs de télécharger leur code sans se soucier du système d'exploitation sous-jacent et de tout ce qui est nécessaire à sa maintenance. Amazon et Google sont inquiets à ce sujet. Les ingénieurs sont préoccupés par le codage de l'application de la société.

Le meilleur de tous, il évolue sans fin. Il y a quelques avertissements, mais dans la plupart des cas, les ingénieurs n'ont pas à s'inquiéter de la mise à l'échelle (ce qui nous préoccupe trop). Il est vrai que vous pouvez affiner les serveurs cloud à l'infini, mais cela nécessite un peu de configuration pour le faire fonctionner correctement. De plus, les serveurs sont lourds; L'exploitation d'un serveur pendant une heure coûte quelques dollars, tandis que le prix d'une seule invocation AWS Lambda est de 0,0000002 USD.

Serverless supprime une grande partie du travail de gestion du système nécessaire à la maintenance des serveurs. Bien que vous ayez probablement encore besoin d’embaucher des ingénieurs d’infrastructure, vos ingénieurs back-end devraient être capables de gérer eux-mêmes les tâches pendant longtemps, et vous aurez besoin de moins d’ingénieurs d’infrastructure pour gérer la même charge de travail. Vous confiez en grande partie la complexité opérationnelle, en particulier les composants qui empêchent les ingénieurs de travailler la nuit, à des experts de Google et Amazon.

Framework sans serveur

Un peu déroutant, "serverless" décrit cette solution d'accès étendue sans serveurs, tandis que le "capitalless Framework" S-majuscule est un framework spécifique qui facilite le travail d'infrastructure sans serveur. Personnellement, je suis un fan du cadre (mis à part le nom, qui rend impossible la recherche sur Google), car il résout bon nombre des limitations des solutions sans serveur proposées par les principaux fournisseurs: elle permet le développement de code localement, simplifie le test des périphériques, et réduit le verrouillage des fournisseurs. Il existe d'autres cadres sans serveur, mais j'appelle cela parce que c'est le plus populaire de ces écrits et parce que son nom introduit de la confusion dans les conversations sur les architectures sans serveur.

Mon équipe doit-elle utiliser Serverless?

Même si je suis un grand fan des architectures sans serveur (je l’utilise pour construire mon démarrage actuel), il a certaines limitations qui l’empêchent de devenir le Saint Graal dans toutes les situations.

Tout d’abord, utiliser sans serveur signifie céder le contrôle. Bien que j'aie longtemps parlé de la difficulté de maintenir des serveurs, des équipes qualifiées peuvent en tirer parti. Ils peuvent optimiser les performances mieux que les fonctionnalités de ski ou utiliser les serveurs pour quelque chose que le cloud ne prend pas en charge. Les fonctionnalités cloud ont été conçues pour une utilisation commune, mais elles peuvent ne pas fonctionner correctement ou pas du tout pour des utilisations inhabituelles. Avec serverless, vous contrôlez Amazon ou Google; S'ils ne prennent pas en charge votre cas d'utilisation ou si leurs performances ne vous suffisent pas, vous n'êtes pas satisfait. De même, chaque service FaaS est différent et en choisir un signifie que vous vous engagez auprès de ce vendeur. Les personnes qui s’inquiètent des verrous des vendeurs réfléchissent à deux fois avant d’utiliser un serveur sans serveur.

Une autre grande considération est le coût. À faible volume, le serveur sans fil sera sans doute moins cher que les solutions de rechange. En effet, sans serveur, vous avez besoin d'au moins un serveur à tout moment, même lorsque personne ne l'utilise. Vous payez pour la capacité de traiter des milliers, voire des millions de demandes par heure, même si vous ne recevez pas autant de trafic. Avec serverless, vous ne payez pas les serveurs en temps d'arrêt, vous devez simplement payer une fraction de centime lorsque votre service est requis. Mais si vous est Traitant des millions de demandes par heure, les serveurs peuvent vous donner des économies d’échelle que les serveurs sans serveur ne peuvent pas. Ce qui est moins cher dépend de nombreux facteurs, mais les serveurs vous offrent beaucoup plus d'options.

Third Go Serverless est une décision importante qui nécessite de classer l’application différemment. Ce n'est pas un problème si vous développez un programme à partir de rien, mais la migration d'un programme existant de serveurs vers des serveurs sans serveur est une grosse affaire. Certaines équipes choisissent de déplacer une partie de la charge de travail sur une machine sans serveur et d’en conserver une partie sur des serveurs, en tant que plan de transfert ou division à long terme.

Enfin, le serveur est nouveau et change rapidement. Travailler avec de nouvelles technologies encourage de nombreux développeurs, mais cela présente certains risques. Des ingénieurs comme moi, épicés (c'est-à-dire fatigués) ont été mordus plus d'une fois en sautant sur la nouvelle technologie la plus en demande juste pour la laisser à bon prix plus tard. Il est possible que le serveur sans serveur soit un bâton éphémère et que vous deviez le prendre en charge pendant quelques années pour suivre l'évolution des temps. Si le problème persiste, une itération plus rapide des systèmes sous-jacents peut signifier que les développeurs doivent déployer davantage d'efforts pour les mettre à niveau.

Une architecture sans serveur n'est pas une solution miracle pour toutes les couches et son utilisation dépend de nombreux facteurs. J'espère que cet article vous a fourni suffisamment de raisons pour avoir une conversation honnête avec vos ingénieurs si c'est la bonne solution pour votre entreprise.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.