Descifrado:
Azat KhaDiev: Hola. Me llamo Azat KhaDiev. Soy desarrollador en la dirección PaaS de Mail.ru Cloud Solutions. Aquí conmigo está Pavel Selivanov de la empresa Southbridge. Estamos en la conferencia DevOpsDays. Él hará una presentación sobre cómo se puede construir DevOps con Kubernetes, pero probablemente no tendrán éxito. ¿Por qué un tema tan sombrío?
Pavel Selivanov: En realidad, no es sombrío. Se trata de que muchos problemas en nuestra comunidad intentamos resolver con la ayuda de tecnologías. Y de hecho, tratamos de resolverlos de manera bastante unidimensional. Kubernetes es exactamente eso: es algo de lo que, se puede decir, son responsables los Ops. Pero tenemos un concepto maravilloso llamado ingeniero DevOps. Así que el ingeniero DevOps es quien se encarga de Kubernetes. Así que... Tipo, ustedes hacen Kubernetes, y los chicos de Dev están completamente desinformados sobre todo este asunto de Kubernetes, no saben lo que permite hacer, y todo sigue igual para ellos. Y esto a pesar de que Kubernetes contiene soluciones listas, herramientas preparadas para que, a través de esta tecnología, se expanda este enfoque de DevOps y la comunicación entre Dev y Ops. Usamos muy poco esa oportunidad. Debido a que incluso las estructuras actuales las estamos trasladando a todas estas herramientas de DevOps — Docker, Kubernetes, nubes, etc. — estamos empeorando aún más esa situación. Y comenzamos a usar las herramientas de manera diferente a como fueron pensadas. Y en torno a todas estas tecnologías se construyen simplemente horribles soluciones improvisadas.
Azat KhaDiev: Entiendo. Se siente que el tema es extenso. ¿Cuál crees que es el problema más común que enfrentan las empresas ahora? Con Kubernetes.
Pavel Selivanov: Con Kubernetes, el problema más común es la falta de competencias. En TI es un problema común. Siempre faltan especialistas. Siempre faltan competencias. Y ahora con Kubernetes hay una escasez de competencias. Y a esto se suma que hay muy pocas soluciones completamente listas en el mercado que permitan tener Kubernetes sin poseer las competencias necesarias, y las que existen, todas plantean cuestionamientos. Constantemente estamos en busca de personas que entiendan esto. Estamos tratando de adaptar el desarrollo a esto.
Azat Khadieev: Y considerando la actual escasez de personal en TI, que siempre ha existido y sigue existiendo. ¿Qué piensas, cómo es vivir en estas condiciones? ¿Cuáles son algunos consejos útiles?
Pavel Selivanov: Consejos útiles. En primer lugar, desde la perspectiva de la nube, un consejo sería: ¿por qué no nos entregan parte de sus competencias? Y nosotros las tomaremos. Y lo manejaremos internamente. Y todo está bien. A excepción de que es importante entender para quienes lo utilizan... En realidad, es un momento excelente... Pero es crucial entender que al entregar una parte de tus competencias a la nube o a un proveedor, a cambio obtenemos una solución universalizada. En otras palabras, tenemos una base de datos que realiza tareas muy específicas y ha sido configurada de manera muy específica. Al trasladar esta base de datos a la nube, podemos, por supuesto, despedir al administrador que antes manejaba los clústeres de bases de datos; el mismo Amazon o Google lo hará por nosotros. Pero, al mismo tiempo, Amazon o Google no nos permitirán ajustar nuestra base de datos de manera precisa. Los grandes proyectos y empresas eventualmente terminan utilizando soluciones en la nube, pero en algún momento regresan a recuperar sus competencias porque necesitan algo más específico.
Azat Khadieev: ¿Las soluciones universales son malas o se puede construir más sobre ellas?
Pavel Selivanov: No, las soluciones universales no son malas en absoluto. Las soluciones universales son buenas. Simplemente son... universales. Aquí es importante entenderlo. Es como tomar un script general... Si puedes construir toda la lógica de la operación de la empresa alrededor de ese script general, es genial. Pero si la lógica de operación es diferente y tomas esa solución universal, ese script universal, y comienzas a adaptarlo de forma inadecuada, eso es malo. Pero en el concepto de universalidad no hay nada malo.
Azat Khadieev: Si ese administrador ya está trabajando para ti, el problema no es su despido. Simplemente podrá hacer más.
Pavel Selivanov: Sí, quitarle la rutina y entregársela a alguien más para que lo haga en otro lugar. Sin duda, este es un buen enfoque. Un punto importante aquí es si esta solución estándar se adapta al caso específico.
Azat Khadiev: Simplemente, basándome en mi experiencia, veo que muchas empresas hacen lo mismo. Configuran un clúster de Kubernetes y piensan en su escalabilidad. Y todas estas operaciones son muy repetitivas.
Pavel Selivanov: Sí, sin duda. Además, si tomamos específicamente Kubernetes, hay un punto que es que actualmente hay realmente pocos conocimientos profundos y buenos sobre Kubernetes en el mercado. Kubernetes es un constructor gigantesco, así que si lo implementas en tu empresa, prepárate para contratar a un ingeniero que se dedique a tiempo completo a gestionarlo. Y eso es caro. Además, encontrar a un ingeniero así es un desafío. Hablando de mí mismo, no me gustan mucho las soluciones en la nube, porque tengo un buen y profundo entendimiento de cómo funciona Kubernetes. A menudo, en la nube, me falta alguna funcionalidad que solicito y me dicen 'No, no se puede'. Bueno, en ese caso, lo siento, pero puedo hacerlo mejor que la nube. Pero, al mismo tiempo, si no tienes un ingeniero a tiempo completo, si no deseas pagar por ese ingeniero que maneja Kubernetes y le estás pagando constantemente mucho dinero solo para que experimente, entonces, la nube es realmente una buena solución. Porque al menos allí hay chicos que el proveedor ya ha contratado. Y saben lo que hacen. Y las necesidades básicas que requieres a diario están allí.
Azat Khadiev: ¿Qué piensas sobre el estado actual de Kubernetes? ¿Qué pasará con él en cinco y diez años?
Pavel Selivanov: Buena pregunta. Simplemente sé lo que está sucediendo en nuestra comunidad al respecto. Algunas personas creen que, aparte de Kubernetes, no quedará nada. Es la misma situación que ocurrió hace tiempo con Linux. Fuera de Linux hay personas que viven en BSD, y probablemente tienen tareas muy específicas. Hay personas que trabajan en Windows — servidores Windows — y es probable que también tengan tareas específicas, o simplemente tienen competencia en este asunto y no están dispuestos a moverse de allí. En cualquier caso, el estándar en nuestro campo es Linux. Hay opiniones de que Kubernetes se convertirá en un estándar de facto, y que no habrá nada más que Kubernetes. Kubernetes gestionará no solo aplicaciones, sino también su implementación, despliegue y escalado. De hecho, ya se pregunta: "¿Se puede meter una base de datos en Kubernetes?" Generalmente digo que la pregunta no está en Kubernetes, sino en Docker. Si estás dispuesto a que tu base de datos funcione en contenedores, entonces así funcionará. Me responden: "No, no, no, espera. No se necesita en contenedores. Necesitamos en Kubernetes. La conectaremos a un nodo. Es decir, todo funcionará como tenemos ahora, solo que todo eso será gestionado por Kubernetes." Y en realidad, es una buena idea. Es decir, Kubernetes es algo que permite llegar a una empresa; si en la empresa hay Kubernetes y procesos construidos sobre él, una persona que entiende de esto solo necesita mirar un par de días para decir: "Estoy listo para apoyarlos. Completamente. Totalmente. Entendí cómo funciona todo aquí." A diferencia de los enfoques sin Kubernetes, donde aquí metieron un montón de parches, aquí otros parches. Aquí está Ansible, aquí está Terraform. Todo esto fue escrito por alguien y se necesita medio año para entenderlo. Entonces, no sé si Kubernetes se convertirá en un estándar de facto. A día de hoy, se ve mucho más ambicioso y seguro que las soluciones que lo rodean.
Azat Khadiev: Bueno, la comparación con Linux es bastante audaz. Funciona en una sola máquina, y eso es todo. Pero Kubernetes funciona en muchas máquinas. Inmediatamente surgen un millón de variaciones y razones. Sí, es audaz. Simplemente, si se tiene en cuenta que hay competidores para este paradigma. Por ejemplo, Serverless. ¿Está Kubernetes en peligro con tales competidores?
Pavel Selivanov: De Serverless... (risa) Serverless — debemos recordar que servidores existe. Recientemente escuché una presentación sobre esto. La persona dijo que los servidores realmente existen — y eso es la nube. Pero siempre debemos entender que en la nube, también hay servidores. Hay servidores físicos reales, racks, y están instalados en algún lugar. Eso es la nube. Sobre esto existe Serverless, donde servidores «no». Así que, ¿la pregunta es si Serverless superará a Kubernetes? Me parece que Serverless se trasladará a Kubernetes. Para los proveedores que ofrecen Serverless, Kubernetes es una plataforma muy conveniente para proporcionar esto. Sí, es posible que en algún momento dejemos de hablar de Kubernetes, en general, como desarrollo de aplicaciones empresariales comunes. Pero en el fondo, para los proveedores e ingenieros, Kubernetes estará allí, donde todo esto será implementado.
Azat Kadiyev: Un tema ligeramente diferente. Existe el concepto de ingeniero fullstack. ¿Qué opinas de ellos? ¿Realmente existen?
Pavel Selivanov: Eh... Ingeniero fullstack... Bueno, creo que es importante diferenciar estas cosas. Sabes, hay algo llamado personas T-shaped. ¿Se necesitan este tipo de personas en la industria actual? Sí, sin duda. Necesitamos personas que tengan una visión amplia, pero que además sean especialistas en un área específica. Y aquí el ingeniero fullstack es lo mismo — una persona que hace todo. Desde el desarrollo de frontend, pruebas, backend, servidores y todo lo demás. No creo que en una gran empresa una sola persona pueda abarcar todo esto sin tener especializaciones en cada uno de los aspectos. Pero al mismo tiempo, simplemente tener una especialización estrecha, tipo 'no sé nada sobre lo que sucede alrededor de esto' — eso tampoco funciona en el mundo moderno. Así que diría que… descartaría la palabra Fullstack. Necesitamos ingenieros realmente. Necesitamos DevOps. Siento que pronto reconsideraremos este punto. Y quizás no sean necesarios.
Azat Kadiyev: ¿Puedes profundizar?
Pavel Selivanov: Me parece que en la industria llegaremos al punto en que estos roles de Dev y Ops desaparecerán pronto. Si necesitamos especialistas y estamos cazando... Necesitamos un desarrollador específico, necesitamos administradores de ciertos tipos, necesitamos ingenieros DevOps — ahora ya los tenemos, y pronto aparecerán ingenieros de producción, ingenieros SRE. Aunque, en realidad, lo que necesitamos son ingenieros que queremos contratar. La experiencia, en gran medida, no es importante. Porque... Por ejemplo, un SRE dice que los problemas de infraestructura siempre son problemas de software. Y qué... Vayamos por desarrolladores — desde la perspectiva de que un desarrollador es un ingeniero — coloquémoslos en el departamento de soporte y ellos resolverán estos problemas de la misma manera en que abordan los problemas de negocio mediante código, utilizando ingeniería como tal.
Azat Khadiyev: Y desde esta perspectiva... ¿Cómo entrevistar a tales ingenieros?
Pavel Selivanov: Oh, buena pregunta. Probablemente está más allá de lo que entiendo en esta vida. Pero simplemente daría un ejemplo. No tiene relación con la entrevista. Se trata de nuestro sistema educativo en Rusia. En TI sabemos que nuestro sistema educativo en Rusia está muy desactualizado para el mundo de TI, no es como debería ser. Hablo en promedio sobre la vasta Rusia, y lo que está ocurriendo allí. Se gradúan personas que no están en absoluto preparadas para ir mañana mismo a la programación web, a una empresa tecnológica. Y eso es algo malo. Los estamos enseñando cosas extrañas, aunque deberíamos enseñarles a desarrollar para Android, para iOS, cómo usar Git y todas esas cosas. En realidad, parece que no. La universidad es un período en el que, en su mayor parte, tus padres te pagan. Por toda tu vida. Y puedes dedicar cinco años de tu vida a estudiar en profundidad. Y aprender todo este enfoque T-shaped. Cuando puedes estudiar en la universidad qué es un sistema de control de versiones, qué patrones de desarrollo existen, cómo probar todo esto, qué bases de datos hay, balanceadores. Y cuando ya empiezas a trabajar, comienzas a profundizar en un área específica. Y de esta manera obtenemos ingenieros. Y nuestro sistema educativo en Rusia está mucho más cerca de esta realidad de lo que pensamos. Nos dan una buena preparación matemática, una buena preparación en algoritmos, nos dan alguna noción sobre lenguajes de programación. Y en cuanto a la entrevista, creo que hay algo cercano a esto. Necesitamos entrevistar a ingenieros. Necesitamos la parte superior de la letra T en el enfoque T-shaped. Porque la barra vertical de la T la adquirirá.
Azat Khadiev: Sí, interesante. Durante cinco años después de la universidad, pensé que mi educación era extraña y no adecuada. Pero luego, a medida que avanzaba en mi trabajo, cuando las tareas se volvieron más profundas y los proyectos más grandes, me di cuenta de que no, me enseñaron cosas muy importantes. Pavel, gracias. Fue muy interesante escuchar tus respuestas. Escuchemos tu presentación.
Pavel Selivanov: Gracias a ustedes.
Fuente: habr.com
