Les développeurs d'applications Android ont remarqué une grave lacune dans Chrome 79, entraînant.

Transcription :
Azat Khadiyev : Bonjour. Je m'appelle Azat Khadiyev. Je suis développeur dans le secteur PaaS de Mail.ru Cloud Solutions. Avec moi ici, Pavel Selivanov de la société Southbridge. Nous sommes à la conférence DevOpsDays. Il va y parler de comment construire DevOps avec Kubernetes, mais il est probable que vous n'y arriverez pas. Pourquoi un sujet aussi sombre ?

Pavel Selivanov : En réalité, ce n'est pas sombre. Il s'agit de nombreuses problématiques que notre communauté essaie de résoudre par le biais des technologies. De plus, nous avons tendance à les aborder de manière unidimensionnelle. Kubernetes, c'est un outil géré, on peut dire, par Ops. Mais nous avons ce magnifique concept d'ingénieur DevOps. C'est l'ingénieur DevOps qui est responsable de Kubernetes. Cependant... En gros, vous devez mettre en place Kubernetes, alors que les développeurs ne sont pas du tout au courant de tout ce que Kubernetes permet — et pour eux, tout fonctionne exactement de la même façon. Et cela, malgré le fait que Kubernetes offre des solutions prêtes à l'emploi, des outils pour étendre cette approche DevOps, pour faciliter la communication entre Dev et Ops. Nous exploitons très peu cette opportunité. Le fait que nous transitions même les structures existantes vers tous ces outils DevOps — Docker, Kubernetes, cloud, etc. — aggrave encore la situation. Et nous commençons à utiliser les outils d'une manière pour laquelle ils n'étaient pas conçus. Entouré de toutes ces technologies, on construit simplement des béquilles terribles.

Azat Khadiyev : Je vois. On sent que le sujet est vaste. Que penses-tu, quelle est la problématique la plus répandue chez les entreprises actuellement ? Avec Kubernetes.

Pavel Selivanov : Avec Kubernetes, le problème le plus répandu est le manque de compétences. C'est un problème courant dans l'IT. Il y a toujours un manque de spécialistes. Toujours un manque de compétences. Et maintenant, avec Kubernetes, il y a un manque de compétences. De plus, il y a encore très peu de solutions prêtes à l'emploi sur le marché qui permettent d'adopter Kubernetes sans les compétences nécessaires. Et celles qui existent soulèvent toutes des questions. Nous sommes constamment à la recherche de personnes qui s'y connaissent en Kubernetes. Nous essayons d'adapter le développement en conséquence.

Azat Khadiev : Et compte tenu de la pénurie actuelle de talents dans le secteur IT, qui a toujours existé et existe encore, que penses-tu, comment peut-on survivre dans ces conditions ? Quels sont les astuces ?

Pavel Selivanov : Les astuces. D'abord, de la perspective des clouds, l'astuce est la suivante : pourquoi ne pas nous confier une partie de vos compétences ? Nous les prendrons et nous nous occuperons de ça en interne. Tout cela est très bien, sauf qu'il est important de comprendre pour ceux qui l'utilisent... En fait, c'est un moment formidable... Mais il faut comprendre qu'en confiant une partie de ses compétences à un cloud ou à un fournisseur, nous recevons en retour une solution généralisée. En gros, nous avons une base de données qui effectue des tâches très spécifiques et qui était configurée de manière très spécifique. En confiant cette base de données au cloud, nous pouvons certes licencier l'administrateur qui s'occupait des clusters de bases de données - Amazon ou Google le fera pour nous. Mais en même temps, Amazon ou Google ne nous permettront pas de configurer notre base de données de manière précise. Les grands projets et les grandes entreprises finissent toujours par utiliser des solutions cloud à un moment donné de leur parcours, puis retournent inévitablement à la récupération de leurs compétences parce qu'une approche plus spécifique est nécessaire.

Azat Khadiev : Les solutions universelles, est-ce que c'est mauvais ou peut-on y bâtir plus ?

Pavel Selivanov : Non, les solutions universelles ne sont pas mauvaises. Les solutions universelles sont bonnes. Les solutions universelles... sont universelles. Il est important de comprendre cela. C'est comme prendre un script générique... Si tu peux construire toute, toute la logique de fonctionnement de l'entreprise autour de ce script générique, c'est super. Et si la logique de fonctionnement est différente, mais que tu prends cette solution universelle, ce script universel - et que tu essaies de l'adapter de façon inappropriée, c'est mauvais. Mais dans le fait d'universaliser, il n'y a rien de mal.

Azat Khadiev : Si cet administrateur est déjà là, ce n'est pas l'affaire de son licenciement. Il pourra simplement faire plus.

Pavel Selivanov : Oui, déléguer sa routine à quelqu'un d'autre pour qu'elle soit gérée quelque part. C'est sans aucun doute une bonne approche. La question clé ici est de savoir si cette solution standard convient au cas spécifique.

Azat Khadiev : D'après mon expérience, je constate que de nombreuses entreprises font la même chose. Elles configurent un cluster Kubernetes et réfléchissent à son évolutivité. Toutes ces opérations sont très répétitives.

Pavel Selivanov : Oui, absolument. Surtout si l'on prend Kubernetes spécifiquement, il y a un point à considérer, il y a vraiment peu de bonnes connaissances approfondies sur Kubernetes sur le marché en ce moment. Kubernetes est un constructeur gigantesque, donc si vous l'apportez dans une entreprise, soyez prêt à engager un ingénieur qui s'en occupera à plein temps. Et c'est coûteux. De plus, trouver un tel ingénieur n'est pas évident. Pour ma part, je n'aime pas vraiment les solutions cloud, car je comprends assez bien et profondément comment fonctionne Kubernetes. Dans les clouds, il me manque souvent une fonctionnalité que je demande — et on me dit "Non, ça ne se fait pas". Dans ce cas, désolé, mais je peux mieux faire qu'un cloud. Cependant, si vous n'avez pas d'ingénieur à plein temps, si vous ne voulez pas payer pour cet ingénieur qui gère Kubernetes, et que vous lui versez constamment beaucoup d'argent pour qu'il expérimente, alors le cloud est simplement une excellente solution. Parce qu'au moins, il y a des gens que le fournisseur a déjà recrutés. Ils savent ce qu'ils font. Et les éléments de base dont vous avez besoin au quotidien sont présents là-bas.

Azat Khadiev : Que penses-tu de l'état actuel de Kubernetes ? Que se passera-t-il dans cinq ou dix ans ?

Pavel Selivanov : Bonne question. Je sais juste ce qui se passe dans notre communauté à ce sujet. Certaines personnes croient que, à part Kubernetes, il ne restera rien. La situation qui est survenue depuis longtemps avec Linux. En dehors de Linux, il y a des gens qui vivent sur BSD, et ils ont probablement des tâches très spécifiques. Il y a des gens qui travaillent sous Windows — serveurs Windows — probablement ils ont aussi des tâches spécifiques, ou ils ont simplement des compétences dans ce domaine et ne sont pas prêts à partir. Dans tous les cas, la norme dans notre domaine est Linux. Il y a cette opinion selon laquelle Kubernetes deviendra une norme de facto, et qu’il n’y aura rien d’autre à part Kubernetes. Kubernetes gérera non seulement les applications, leur déploiement, leur mise à l'échelle, mais absolument tout. On demande déjà : « Peut-on mettre une base de données dans Kubernetes ? ». Je parle généralement de cela, que la question n’est pas dans Kubernetes, mais dans Docker. Si vous êtes prêt à ce que votre base de données fonctionne dans des conteneurs, alors comment elle fonctionnera. On me répond : « Non, non, non, attendez. Il ne faut pas dans des conteneurs. Il faut dans Kubernetes. Nous l'associerons au nœud. C'est-à-dire que tout sera comme maintenant, sauf que tout cela sera géré par Kubernetes. » Et c'est une bonne idée. Donc, Kubernetes est ce genre de chose, où l'on peut entrer dans une entreprise, si l'entreprise a Kubernetes et des processus construits dessus, alors la personne qui s'y connaît suffit de regarder quelques jours pour dire : « Je suis prêt à vous soutenir. Complètement. Entièrement. J'ai compris comment cela fonctionne chez vous. » Contrairement aux approches sans Kubernetes — ici un contrainte ici, une autre contrainte là. Ici Ansible, ici Terraform. Tout cela est écrit par quelqu'un, et il faut six mois pour comprendre. Donc, M. Kubernetes deviendra-t-il une norme de facto, je ne sais pas. À ce jour, il semble beaucoup plus ambitieux et sûr que les solutions qui l'entourent.

Azat Khadiyev : Eh bien, la comparaison avec Linux est assez audacieuse. Cela fonctionne sur une seule machine — et c'est tout. Mais Kubernetes fonctionne sur plusieurs machines. Cela soulève immédiatement un million de variations, de raisons. Oui, c'est audacieux. Il faut juste prendre en compte qu'il y a des concurrents à cette paradigme. Par exemple, Serverless. Kubernetes est en danger face à de tels concurrents ?

Pavel Selivanov : De Serverless… (rires) Serverless — nous devons comprendre que de serveurs il y a quand même des serveurs. J'ai entendu récemment une présentation à ce sujet. La personne a dit qu'il y avait en effet des serveurs — et c'est le cloud. Mais nous devons toujours comprendre que dans le cloud, il y a aussi des serveurs. Il y a de véritables serveurs physiques, des racks, qui sont installés quelque part. C'est ça le cloud. Au-dessus de cela, il existe le Serverless, où serveurs il n'y a « rien ». La question est : le Serverless l'emportera-t-il sur Kubernetes ? Je pense que le Serverless s'en ira vers Kubernetes. Pour les fournisseurs qui offrent des solutions Serverless, Kubernetes est une plateforme très pratique pour cela. Oui, il se peut qu'à un moment donné, nous cessions de parler de Kubernetes en tant que tel, comme d'un développement standard d'applications professionnelles. Mais au fond, chez les fournisseurs et les ingénieurs, il y aura Kubernetes, où tout cela sera mis en œuvre.

Azat Kadiyev : Un sujet légèrement différent. Il existe un concept d'ingénieur fullstack. Que penses-tu de cela ? Existent-ils vraiment ?

Pavel Selivanov : Euh... Ingénieur fullstack... Eh bien, je pense qu'il est important de faire la distinction entre ces choses... Tu sais, il y a ce concept de T-shaped people. Ont-ils besoin de telles personnes dans l'industrie actuelle? Oui, absolument. Nous avons besoin de personnes qui ont une visiön large, mais qui sont également spécialisées dans un domaine précis. Et ici, l'ingénieur fullstack c'est la même chose — une personne qui fait tout. Commence par le développement frontend, le test, le backend, les serveurs et tout le reste. Je ne crois pas qu'une seule personne puisse gérer cela dans une grande entreprise sans avoir des spécialisations étroites sur chacun des aspects. Mais en même temps, avoir une spécialisation étroite, en disant que je ne sais rien de ce qui se passe autour, cela ne fonctionne pas non plus dans le monde moderne. Donc, je dirais… le mot fullstack, je l'écarterais. Nous avons vraiment besoin d'ingénieurs. Nous avons besoin de DevOps. Je sens que nous allons bientôt reconsidérer ce point. Et ils ne seront pas nécessaires.

Azat Kadiyev : Peux-tu expliquer ?

Pavel Selivanov : Je pense que notre industrie va évoluer vers un point où les rôles Dev et Ops vont disparaître. Si nous avons besoin de spécialistes et que nous sommes à la recherche… Nous avons besoin d'un type de développeur, d'administrateurs particuliers, d'ingénieurs DevOps — ils sont maintenant parmi nous, et bientôt nous verrons de nouveaux ingénieurs de production, des ingénieurs SRE. Pourtant, en réalité, ce dont nous avons besoin ce sont des ingénieurs que nous souhaitons embaucher. La formation académique n'a fondamentalement pas d'importance. Parce que… Par exemple, un SRE dit que les problèmes d'infrastructure sont toujours des problèmes logiciels. Alors… Prendre des développeurs — en considérant qu'un développeur est un ingénieur — les placer dans le département de support et ils résoudront ces problèmes de la même manière qu'ils résolvent les problèmes commerciaux à l'aide de code, avec l'ingénierie en tant que telle.

Azat Khadiyev : Alors, dans cette perspective… Comment interviewer de tels ingénieurs ?

Pavel Selivanov : Oh, bonne question. Il se situe probablement au-delà de ce que je comprends dans cette vie. Mais je donnerais juste un exemple. Ce n'est pas lié à l'entretien. C'est à propos de notre système éducatif en Russie. Dans le domaine de l'informatique, nous savons que notre système éducatif en Russie est très obsolète pour le monde IT, il n'est pas ce qu'il devrait être. Je parle ici de la Russie immense — et de ce qui s'y passe. Les diplômés qui sortent sont absolument pas prêts à entrer immédiatement dans le développement web, dans une entreprise technologique. Et c'est un problème. Nous les formons à des choses étranges, alors que nous devrions les enseigner à développer pour Android, pour iOS, comment utiliser Git et tout ça. En réalité, il semble que ce ne soit pas le cas. L'institut — c'est cette période où, pour la plupart, tes parents paient pour toi. Pour toute ta vie. Et tu peux consacrer cinq années de ta vie à étudier en profondeur. À étudier tous ces aspects T-shaped. Pendant que tu peux étudier à l'institut ce qu'est un système de contrôle de version, quels types de modèles de développement existent, comment tout cela se teste, quels types de bases de données, des répartiteurs de charge. Et quand tu commences à travailler, tu commences à te spécialiser dans un domaine particulier. Et ainsi nous formons des ingénieurs. Et notre système éducatif en Russie est beaucoup plus proche de cette réalité qu'il ne nous semble. Nous avons une bonne formation mathématique, une bonne formation algorithmique, nous avons une certaine connaissance des langages de programmation. Et en ce qui concerne les entretiens, je pense que c'est quelque chose de similaire. Nous devons interviewer des ingénieurs. Nous avons besoin de la partie supérieure de la lettre T de T-shaped. Parce que la barre verticale de T, ils l'acquerront.

Azat Khadiev : Oui, intéressant. Pendant cinq ans après l'institut, je pensais que ma formation était un peu étrange et inappropriée. Puis, au fur et à mesure que je travaillais, lorsque les tâches sont devenues plus profondes et les projets plus importants, j'ai réalisé que non, on m'avait appris des choses très importantes. Pavel, merci à toi. C'était très intéressant d'écouter tes réponses. Écoutons ta présentation.

Pavel Selivanov : Merci à vous.

Source : habr.com