Avant vous, avec la permission de l'auteur, ma relecture plutôt lâche d'un
article de l' ingénieur DevOps
Paul Hammant , dans lequel il décrit très simplement les avantages peu évidents de Serverless en termes de DevOps, ainsi que la sécurité de travailler avec le backend de l'application.
Pour commencer, Paul donne un diagramme de la façon dont les processus se déroulent dans Serverless et quelle est la différence fondamentale entre cette approche et l'architecture traditionnelle des applications frontales avec des backends. Dans le diagramme, l'auteur fait allusion à la façon dont la réponse bien connue à la «Question principale de la vie, l'univers et tout cela» du Guide Douglas Adams pour faire de l'auto-stop sur la galaxie a été reçue.
Ports, processus et tout cela
Le fait essentiel pour l'auteur est que les fonctions sans serveur n'ont aucun nom de domaine, aucune adresse TCP / IP et n'écoutent même aucun port. Cela est vrai, au moins pour les utilisateurs du cloud sans serveur, ceux qui créent des backends basés sur ces fonctionnalités. À l'intérieur de la plate-forme sans serveur, tout cela est certainement présent, mais les utilisateurs du système ne sont pas visibles.
Tout le routage se fait uniquement sur la base de certains noms logiques. Il s'avère que pour exécuter ma fonction sans serveur zipCodeService, qui décode l'adresse en un index, j'ai besoin de connaître, en fait, uniquement l'adresse et un lien vers son API, que la plate-forme sans serveur elle-même me génère gentiment et automatiquement. Une si belle conception vous permet d'avoir des fonctions complètement indépendantes pour exécuter l'une ou l'autre logique d'application, qui ne se croisent pas et n'interfèrent pas entre elles, et le coût de chaque fonctionnalité, chaque demande, chaque écran peut être calculé séparément. Ces fonctions peuvent même utiliser différents langages de programmation. Et le tout dans une seule application!
De plus, si nous parlons de la même fonction, Serverless nous permet de créer de nombreuses fonctions de ce type pour chaque développeur, processus CI individuels, tests, staging, production. Dans le même temps, nous savons clairement qui, quand et dans quelle mesure a utilisé sa fonction et pouvons clairement répartir nos coûts de mise en œuvre entre les consommateurs individuels. Des disciplines, non?
Avantages clés pour DevOps
En plus de tous les autres avantages sans serveur, l'abandon du schéma nom: port est l'un des principaux avantages de DevOps. Bien que deux processus sur le même serveur ne puissent toujours pas écouter sur le même port, cela n'est plus important pour nous, car nous séparons ces processus en utilisant la méthode la plus simple - par nom. Et nous pouvons nommer les fonctions comme vous le souhaitez, limitées uniquement par notre propre imagination, contrairement aux ports où il y a des restrictions strictes.
De plus, dans Serverless, nous ne gérons pas les choses comme les sockets, du moins lors de l'accès aux fonctions Serverless et de l'échange de données entre elles.
Comme pour l'utilisation des conteneurs dockers, nous ne pensons pas aux processus, pourquoi ils sont tombés et comment les récupérer. Mais, contrairement au docker, nous n'avons pas besoin de penser aux processus de docker eux-mêmes et aux processus d'orchestration des conteneurs. Pas besoin de penser à la configuration et à la prise en charge de Kubernetes.
À suivre
D'une part, il est évident que tout ne devient pas aussi rose avec la transition vers Serverless, et la transition elle-même ne sera pas toujours simple. D'un autre côté, pourquoi perdre votre temps et utiliser des options intermédiaires sous la forme d'un docker, si vous pouvez passer immédiatement au niveau suivant?
Comment en pratique pour passer au niveau suivant, nous avons décrit précédemment:
Application todo sans serveur avec autorisation et photosBot sans serveur pour TelegramPlus seront plus de guides!
Donnez vie à vos idées sur notre plateforme Swifty sans serveur