En previsión Vitaly Khabarov entrevistado Dmitri Stoliarov (), director técnico y cofundador de la empresa Flant. Vitaly le preguntó a Dmitry sobre lo que hace Flant, sobre Kubernetes, el desarrollo del ecosistema y el soporte. Discutimos por qué se necesita Kubernetes y si es necesario. Y también sobre los microservicios, Amazon AWS, el enfoque "Tendré suerte" para DevOps, el futuro de Kubernetes, por qué, cuándo y cómo se apoderará del mundo, las perspectivas de DevOps y para qué deben prepararse los ingenieros en el futuro. Un futuro brillante y cercano con simplificación y redes neuronales.
Escúchelo como un podcast en DevOps Deflop, un podcast en ruso sobre DevOps, y a continuación se muestra la versión de texto.
Aquí y abajo hace preguntas. ingeniero de Express42.
Acerca de "Flanto"
- Hola Dima. Eres el director técnico "" y también su fundador. ¿Cuéntanos qué hace la empresa y en qué participas?
Dmitry: Desde fuera parece que somos los que instalamos Kubernetes para todos y hacemos algo con él. Pero eso no es cierto. Comenzamos como una empresa que se ocupa de Linux, pero durante mucho tiempo nuestra actividad principal ha sido dar servicio a proyectos llave en mano de producción y de alta carga. Normalmente construimos toda la infraestructura desde cero y luego somos responsables de ella durante mucho, mucho tiempo. Por tanto, el principal trabajo que realiza “Flant”, por el que recibe dinero, es asumir la responsabilidad e implementar la producción llave en mano.
Yo, como director técnico y uno de los fundadores de la empresa, paso todo el día y la noche tratando de descubrir cómo aumentar la accesibilidad de la producción, simplificar su funcionamiento, hacer la vida de los administradores más fácil y la vida de los desarrolladores más placentera. .
Acerca de Kubernetes
— Últimamente he visto muchos informes de Flant y sobre Kubernetes. ¿Cómo llegaste a ello?
Dmitry: Ya he hablado de esto muchas veces, pero no me importa en absoluto repetirlo. Creo que es correcto repetir este tema porque hay confusión entre causa y efecto.
Realmente necesitábamos una herramienta. Nos enfrentamos a muchos problemas, luchamos, los superamos con varias muletas y sentimos la necesidad de una herramienta. Pasamos por muchas opciones diferentes, construimos nuestras propias bicicletas y adquirimos experiencia. Poco a poco llegamos al punto en el que empezamos a utilizar Docker casi tan pronto como apareció, alrededor de 2013. En el momento de su aparición, ya teníamos mucha experiencia con contenedores, ya habíamos escrito un análogo de "Docker", unas de nuestras propias muletas en Python. Con la llegada de Docker, fue posible dejar de lado las muletas y utilizar una solución confiable y respaldada por la comunidad.
Con Kubernetes la historia es similar. Cuando comenzó a ganar impulso (para nosotros esta es la versión 1.2), ya teníamos un montón de muletas tanto en Shell como en Chef, que de alguna manera intentamos orquestar con Docker. Estábamos pensando seriamente en Rancher y otras soluciones, pero luego apareció Kubernetes, en el que todo se implementa exactamente como lo habríamos hecho nosotros o incluso mejor. No hay nada de qué quejarse.
Sí, hay algún tipo de imperfección aquí, hay algún tipo de imperfección allí; hay muchas imperfecciones y 1.2 es generalmente terrible, pero... Kubernetes es como un edificio en construcción: miras el proyecto y comprendes que será genial. Si el edificio ahora tiene cimientos y dos pisos, entonces comprende que es mejor no mudarse todavía, pero no hay tales problemas con el software; ya puede usarlo.
No tuvimos un momento en el que pensáramos en usar Kubernetes o no. Lo estuvimos esperando mucho antes de que apareciera e intentamos crear análogos nosotros mismos.
Acerca de Kubernetes
— ¿Está directamente involucrado en el desarrollo del propio Kubernetes?
Dmitry: Mediocre. Más bien, participamos en el desarrollo del ecosistema. Enviamos una cierta cantidad de solicitudes de extracción: a Prometheus, a varios operadores, a Helm, al ecosistema. Desafortunadamente, no puedo realizar un seguimiento de todo lo que hacemos y podría estar equivocado, pero no hay ni un solo grupo desde nosotros hasta el núcleo.
— Al mismo tiempo, ¿desarrolláis muchas de vuestras herramientas en torno a Kubernetes?
Dmitry: La estrategia es la siguiente: vamos y solicitamos todo lo que ya existe. Si las solicitudes de extracción no se aceptan allí, simplemente las bifurcamos nosotros mismos y vivimos hasta que sean aceptadas con nuestras compilaciones. Luego, cuando llega al upstream, volvemos a la versión upstream.
Por ejemplo, tenemos un operador Prometheus, con el que probablemente ya hemos conmutado 5 veces hacia adelante y hacia atrás en nuestro ensamblaje. Necesitamos algún tipo de característica, enviamos una solicitud de extracción, necesitamos implementarla mañana, pero no queremos esperar a que se lance en sentido ascendente. En consecuencia, nos ensamblamos nosotros mismos, implementamos nuestro ensamblaje con nuestra característica, que necesitamos por alguna razón, en todos nuestros grupos. Luego, por ejemplo, nos lo entregan en el sentido ascendente con las palabras: "Chicos, hagámoslo para un caso más general", nosotros, o alguien más, lo terminamos y, con el tiempo, se fusiona nuevamente.
Intentamos desarrollar todo lo que existe.. Muchos elementos que aún no existen, aún no se han inventado o se han inventado, pero no han tenido tiempo de implementarse: lo estamos haciendo. Y no porque nos guste el proceso o la construcción de bicicletas como industria, sino simplemente porque necesitamos esta herramienta. A menudo se hace la pregunta: ¿por qué hicimos esto o aquello? La respuesta es simple: sí, porque teníamos que ir más allá, resolver algún problema práctico y lo resolvimos con esta tula.
El camino siempre es así: buscamos con mucho cuidado y, si no encontramos ninguna solución sobre cómo hacer un trolebús con una barra de pan, entonces hacemos nuestra propia barra y nuestro propio trolebús.
herramientas de flanta
— Sé que Flant ahora tiene operadores de complementos, operadores de shell y herramientas dapp/werf. Según tengo entendido, este es el mismo instrumento en diferentes encarnaciones. También entiendo que hay muchas más herramientas diferentes dentro de Flaunt. ¿Esto es cierto?
Dmitry: Tenemos mucho más en GitHub. Por lo que recuerdo ahora, tenemos un mapa de estado: un panel para Grafana que a todos les gustó. Se menciona en casi uno de cada dos artículos sobre el monitoreo de Kubernetes en Medium. Es imposible explicar brevemente qué es un mapa de estado; necesita un artículo aparte, pero es muy útil para monitorear el estado a lo largo del tiempo, ya que en Kubernetes a menudo necesitamos mostrar el estado a lo largo del tiempo. También tenemos LogHouse: esto es algo basado en ClickHouse y magia negra para recopilar registros en Kubernetes.
¡Muchas utilidades! Y habrá aún más, porque este año se lanzarán varias soluciones internas. De los muy grandes basados en el operador de complementos, hay un montón de complementos para Kubernetes, por ejemplo, cómo instalar correctamente Sert Manager, una herramienta para administrar certificados, cómo instalar correctamente Prometheus con un montón de accesorios, estos son alrededor de veinte diferentes. binarios que exportan datos y recopilan algo, para esto Prometheus tiene los gráficos y alertas más sorprendentes. Todo esto es solo un montón de complementos para Kubernetes, que se instalan en un clúster, y pasa de ser simple a ser genial, sofisticado y automático, en el que ya se han resuelto muchos problemas. Sí, hacemos mucho.
Desarrollo de ecosistemas
"Me parece que esta es una contribución muy grande al desarrollo de este instrumento y sus métodos de uso". ¿Puedes estimar aproximadamente quién más haría la misma contribución al desarrollo del ecosistema?
Dmitry: En Rusia, de las empresas que operan en nuestro mercado, ninguna se le acerca. Por supuesto, esta es una afirmación fuerte, porque hay actores importantes como Mail y Yandex, que también están haciendo algo con Kubernetes, pero ni siquiera ellos se acercan a la contribución de empresas de todo el mundo que hacen mucho más que nosotros. Es difícil comparar Flant, que tiene una plantilla de 80 personas, y Red Hat, que tiene 300 ingenieros sólo por Kubernetes, si no me equivoco. Es difícil comparar. Contamos con 6 personas en el departamento de I+D, incluyéndome a mí, que cortan todas nuestras herramientas. 6 personas frente a 300 ingenieros de Red Hat: de alguna manera es difícil comparar.
- Sin embargo, cuando incluso estas 6 personas pueden hacer algo realmente útil y alienante, cuando se enfrentan a un problema práctico y dan la solución a la comunidad, es un caso interesante. Entiendo que en las grandes empresas tecnológicas, donde tienen su propio equipo de desarrollo y soporte de Kubernetes, en principio se pueden desarrollar las mismas herramientas. Este es un ejemplo para ellos de lo que se puede desarrollar y dar a la comunidad, dando impulso a toda la comunidad que utiliza Kubernetes.
Dmitry: Esta es probablemente una característica del integrador, su peculiaridad. Tenemos muchos proyectos y vemos muchas situaciones diferentes. Para nosotros, la principal forma de crear valor añadido es analizar estos casos, encontrar puntos en común y hacerlos lo más baratos posible para nosotros. Estamos trabajando activamente en esto. Me resulta difícil hablar de Rusia y del mundo, pero tenemos unos 40 ingenieros de DevOps en la empresa que trabajan en Kubernetes. No creo que haya muchas empresas en Rusia con un número comparable de especialistas que entiendan Kubernetes, si es que hay alguno.
Entiendo todo sobre el puesto de trabajo ingeniero de DevOps, todos entienden todo y están acostumbrados a llamar ingenieros de DevOps a los ingenieros de DevOps, no discutiremos esto. Todos estos 40 increíbles ingenieros de DevOps enfrentan y resuelven problemas todos los días, simplemente analizamos esta experiencia e intentamos generalizar. Entendemos que si permanece dentro de nosotros, en uno o dos años la herramienta será inútil, porque en algún lugar de la comunidad aparecerá una Tula ya preparada. No tiene sentido acumular esta experiencia internamente: simplemente está drenando energía y tiempo en dev/null. Y no lo sentimos en absoluto. Publicamos todo con gran placer y entendemos que es necesario publicarlo, desarrollarlo, promocionarlo, promocionarlo para que la gente lo use y agregue su experiencia; entonces todo crece y vive. Luego, después de dos años, el instrumento no va a la basura. No es una lástima seguir echando fuerzas, porque está claro que alguien está usando tu herramienta, y después de dos años todos la están usando.
Esto es parte de nuestra gran estrategia con dapp/werf.. No recuerdo cuando empezamos a hacerlo, parece que hace 3 años. Inicialmente, generalmente estaba en el caparazón. Fue una súper prueba de concepto, resolvimos algunos de nuestros problemas particulares: ¡funcionó! Pero hay problemas con el shell, es imposible expandirlo más, programar en el shell es otra tarea. Teníamos la costumbre de escribir en Ruby, en consecuencia, rehicimos algo en Ruby, lo desarrollamos, lo desarrollamos, lo desarrollamos y nos topamos con el hecho de que la comunidad, la multitud que no dice "lo queremos o no lo queremos, ” le vuelve la nariz a Ruby, ¿qué tan gracioso es eso? Nos dimos cuenta de que deberíamos escribir todo esto en Go solo para cumplir con el primer punto de la lista de verificación: La herramienta DevOps debe ser un binario estático. Ser Go o no no es tan importante, pero un binario estático escrito en Go es mejor.
Gastamos nuestra energía, reescribimos el dapp en Go y lo llamamos werf. La Dapp ya no es compatible, no está desarrollada y se ejecuta en alguna de las últimas versiones, pero existe una ruta de actualización absoluta hacia la parte superior y puede seguirla.
¿Por qué se creó la dapp?
— ¿Puedes contarnos brevemente por qué se creó la dapp y qué problemas resuelve?
Dmitry: La primera razón está en la asamblea. Inicialmente, tuvimos serios problemas con la compilación cuando Docker no tenía capacidades de múltiples etapas, por lo que las hicimos nosotros mismos. Luego tuvimos muchos más problemas con la limpieza de la imagen. Todos los que hacen CI/CD, más temprano que tarde, se enfrentan al problema de que hay un montón de imágenes recopiladas, es necesario limpiar de alguna manera lo que no se necesita y dejar lo que se necesita.
La segunda razón es el despliegue. Sí, existe Helm, pero solo resuelve algunos de los problemas. Curiosamente, está escrito que "Helm es el administrador de paquetes para Kubernetes". Exactamente qué es “el”. También están las palabras "Administrador de paquetes": ¿cuál es la expectativa habitual de un Administrador de paquetes? Decimos: "Administrador de paquetes: ¡instale el paquete!" y esperamos que nos diga: “El paquete ha sido entregado”.
Es interesante que digamos: "Helm, instala el paquete", y cuando él responde que lo instaló, resulta que acaba de iniciar la instalación; le indicó a Kubernetes: "¡Inicia esto!", y si se inició o no. , funcione o no, Helm no resuelve este problema en absoluto.
Resulta que Helm es solo un preprocesador de texto que carga datos en Kubernetes.
Pero como parte de cualquier implementación, queremos saber si la aplicación se lanzó para producción o no. Implementado para producir significa que la aplicación se movió allí, se implementó la nueva versión y al menos no falla allí y responde correctamente. Helm no resuelve este problema de ninguna manera. Para resolverlo, es necesario dedicar mucho esfuerzo, porque es necesario darle a Kubernetes el comando para implementar y monitorear lo que sucede allí, ya sea que se implemente o se implemente. Y también hay muchas tareas relacionadas con el despliegue, la limpieza y el montaje.
Planes
Este año iniciaremos el desarrollo local. Queremos lograr lo que había anteriormente en Vagrant: escribimos "vagrant up" e implementamos máquinas virtuales. Queremos llegar al punto donde hay un proyecto en Git, escribimos "werf up" allí y aparece una copia local de este proyecto, implementada en un mini-Kub local, con todos los directorios convenientes para el desarrollo conectados. . Dependiendo del lenguaje de desarrollo, esto se hace de manera diferente, pero de todos modos, de modo que el desarrollo local se pueda realizar cómodamente en archivos montados.
El siguiente paso para nosotros es invertir en comodidad para los desarrolladores. Para implementar rápidamente un proyecto localmente con una herramienta, desarrollarlo, insertarlo en Git y también se implementará en etapa o pruebas, según las canalizaciones, y luego usará la misma herramienta para pasar a producción. Esta unidad, unificación, reproducibilidad de la infraestructura desde el entorno local hasta las ventas es un punto muy importante para nosotros. Pero esto aún no está listo, simplemente estamos planeando hacerlo.
Pero el camino hacia dapp/werf siempre ha sido el mismo que con Kubernetes al principio. Encontramos problemas, los resolvimos con soluciones alternativas; se nos ocurrieron algunas soluciones nosotros mismos en el shell, en cualquier cosa. Luego intentaron de alguna manera corregir estas soluciones, generalizarlas y consolidarlas en binarios en este caso, que simplemente compartimos.
Hay otra manera de ver toda esta historia, con analogías.
Kubernetes es la estructura de un automóvil con motor. No hay puertas, ni cristales, ni radio, ni árbol de Navidad... nada de nada. Solo el chasis y el motor. Y ahí está Helm: este es el volante. Genial: hay un volante, pero también necesitas un pasador de dirección, una cremallera de dirección, una caja de cambios y ruedas, y no puedes prescindir de ellos.
En el caso de werf, este es otro componente de Kubernetes. Solo que ahora en la versión alfa de werf, por ejemplo, Helm se compila dentro de werf, porque estamos cansados de hacerlo nosotros mismos. Hay muchas razones para hacer esto, te contaré en detalle por qué compilamos el timón completo junto con el timón dentro del werf. .
Ahora werf es un componente más integrado. Obtenemos un volante terminado, un pasador de dirección; no soy muy bueno con los autos, pero este es un bloque grande que ya resuelve una gama bastante amplia de problemas. No necesitamos revisar el catálogo nosotros mismos, seleccionar una pieza por otra, pensar en cómo atornillarlas. Obtenemos una cosechadora lista para usar que resuelve una gran cantidad de problemas a la vez. Pero por dentro está construido a partir de los mismos componentes de código abierto, todavía usa Docker para el ensamblaje, Helm para algunas de las funciones y hay varias otras bibliotecas. Esta es una herramienta integrada para obtener CI/CD geniales listos para usar de manera rápida y conveniente.
¿Es difícil mantener Kubernetes?
— Hablas de la experiencia de que empezaste a usar Kubernetes, este es un marco para ti, un motor, y en él puedes colgar muchas cosas diferentes: una carrocería, un volante, pedales atornillados, asientos. Surge la pregunta: ¿qué tan difícil es para usted el soporte de Kubernetes? Tienes mucha experiencia, ¿cuánto tiempo y recursos dedicas a respaldar a Kubernetes de forma aislada de todo lo demás?
Dmitry: Esta es una pregunta muy difícil y, para responderla, debemos comprender qué es el soporte y qué queremos de Kubernetes. ¿Quizás puedas revelarlo?
— Hasta donde yo sé y veo, ahora muchos equipos quieren probar Kubernetes. Todos se enganchan a él y lo ponen de rodillas. Tengo la sensación de que la gente no siempre comprende la complejidad de este sistema.
Dmitry: Es así.
— ¿Qué tan difícil es tomar e instalar Kubernetes desde cero para que esté listo para producción?
Dmitry: ¿Qué tan difícil crees que es trasplantar un corazón? Entiendo que esta es una pregunta comprometedora. Usar un bisturí y no equivocarse no es tan difícil. Si te dicen dónde cortar y dónde coser, entonces el procedimiento en sí no es complicado. Es difícil garantizar una y otra vez que todo saldrá bien.
Instalar Kubernetes y hacerlo funcionar es fácil: ¡chico! — instalado, existen muchos métodos de instalación. Pero ¿qué pasa cuando surgen problemas?
Siempre surgen preguntas: ¿qué no hemos tenido en cuenta todavía? ¿Qué no hemos hecho todavía? ¿Qué parámetros del kernel de Linux se especificaron incorrectamente? Señor, ¿los mencionamos siquiera? ¿Qué componentes de Kubernetes hemos entregado y cuáles no? Surgen miles de preguntas y para responderlas es necesario pasar entre 15 y 20 años en esta industria.
Tengo un ejemplo reciente sobre este tema que puede revelar el significado del problema "¿Es difícil mantener Kubernetes?" Hace algún tiempo nos planteamos seriamente si deberíamos intentar implementar Cilium como red en Kubernetes.
Déjame explicarte qué es Cilium. Kubernetes tiene muchas implementaciones diferentes del subsistema de red, y una de ellas es genial: Cilium. ¿Cuál es su significado? En el kernel, hace algún tiempo fue posible escribir ganchos para el kernel, que de una forma u otra invaden el subsistema de red y varios otros subsistemas, y permiten eludir grandes fragmentos del kernel.
Históricamente, el kernel de Linux tiene una ruta IP, un sobrefiltro, puentes y muchos componentes antiguos diferentes que tienen 15, 20, 30 años. En general, funcionan, todo está genial, pero ahora han amontonado contenedores y parece una torre de 15 ladrillos uno encima del otro, y te paras sobre ella sobre una pierna, una sensación extraña. Este sistema se ha desarrollado históricamente con muchos matices, al igual que el apéndice en el cuerpo. En algunas situaciones, por ejemplo, hay problemas de rendimiento.
Hay un BPF maravilloso y la capacidad de escribir ganchos para el kernel: los chicos escribieron sus propios ganchos para el kernel. El paquete ingresa al kernel de Linux, lo sacan directamente en la entrada, lo procesan ellos mismos como debería sin puentes, sin TCP, sin pila de IP; en resumen, evitando todo lo que está escrito en el kernel de Linux y luego escupen sáquelo al contenedor.
¿Qué pasó? Rendimiento excelente, funciones interesantes: ¡simplemente genial! Pero miramos esto y vemos que en cada máquina hay un programa que se conecta a la API de Kubernetes y, en base a los datos que recibe de esta API, genera código C y compila binarios que carga en el kernel para que estos ganchos funcionen. en el espacio del núcleo.
¿Qué ocurre si algo va mal? No sabemos. Para comprender esto, es necesario leer todo este código, comprender toda la lógica y es sorprendente lo difícil que es. Pero, por otro lado, están estos puentes, filtros de red, rutas IP; no he leído su código fuente, ni tampoco los 40 ingenieros que trabajan en nuestra empresa. Quizás sólo unos pocos entiendan algunas partes.
¿Y cuál es la diferencia? Resulta que hay ip rout, el kernel de Linux y hay una nueva herramienta: qué diferencia hay, no entendemos lo uno ni lo otro. Pero tenemos miedo de utilizar algo nuevo, ¿por qué? Porque si la herramienta tiene 30 años, entonces en 30 años se han encontrado todos los errores, se han solucionado todos los errores y no es necesario saberlo todo: funciona como una caja negra y siempre funciona. Todo el mundo sabe qué destornillador de diagnóstico colocar en qué lugar, qué tcpdump ejecutar en qué momento. Todo el mundo conoce bien las utilidades de diagnóstico y comprende cómo funciona este conjunto de componentes en el kernel de Linux; no cómo funciona, sino cómo utilizarlo.
Y el increíblemente genial Cilium no tiene 30 años, aún no ha envejecido. Kubernetes tiene el mismo problema, copia. Que Cilium está instalado perfectamente, que Kubernetes está instalado perfectamente, pero cuando algo sale mal en producción, ¿eres capaz de comprender rápidamente en una situación crítica qué salió mal?
Cuando decimos si es difícil mantener Kubernetes, no, es muy fácil y sí, es increíblemente difícil. Kubernetes funciona muy bien por sí solo, pero con mil millones de matices.
Sobre el enfoque "tendré suerte"
— ¿Hay empresas en las que es casi seguro que aparecerán estos matices? Supongamos que Yandex transfiere repentinamente todos los servicios a Kubernetes, habrá una carga enorme allí.
Dmitry: No, esta no es una conversación sobre la carga, sino sobre las cosas más simples. Por ejemplo, tenemos Kubernetes, implementamos la aplicación allí. ¿Cómo sabes que está funcionando? Simplemente no existe una herramienta preparada para comprender que la aplicación no falla. No existe un sistema listo para usar que envíe alertas; es necesario configurar estas alertas y cada programación. Y estamos actualizando Kubernetes.
Tengo Ubuntu 16.04. Se puede decir que esta es una versión antigua, pero todavía estamos en ella porque es LTS. Existe systemd, cuyo matiz es que no limpia los grupos C. Kubernetes lanza pods, crea grupos C, luego elimina pods y de alguna manera resulta (no recuerdo los detalles, lo siento) que quedan segmentos de systemd. Esto lleva al hecho de que, con el tiempo, cualquier automóvil comienza a frenar con fuerza. Ni siquiera se trata de una cuestión de alta carga. Si se inician pods permanentes, por ejemplo, si hay un trabajo cron que genera pods constantemente, entonces la máquina con Ubuntu 16.04 comenzará a ralentizarse después de una semana. Habrá un promedio de carga constantemente alto debido al hecho de que se han creado muchos grupos C. Este es el problema al que se enfrentará cualquier persona que simplemente instale Ubuntu 16 y Kubernetes encima.
Digamos que de alguna manera actualiza systemd o algo más, pero en el kernel de Linux hasta 4.16 es aún más divertido: cuando eliminas los grupos C, se filtran en el kernel y en realidad no se eliminan. Por lo tanto, después de un mes de trabajo en esta máquina, será imposible consultar las estadísticas de memoria de los hogares. Sacamos un archivo, lo introducimos en el programa y un archivo se publica durante 15 segundos, porque el núcleo tarda mucho en contar un millón de grupos C dentro de sí mismo, que parecen eliminados, pero no, están goteando. .
Todavía hay muchas pequeñas cosas aquí y allá. Este no es un problema al que las empresas gigantes puedan enfrentarse a veces bajo cargas muy pesadas; no, es una cuestión de cosas cotidianas. La gente puede vivir así durante meses: instalaron Kubernetes, implementaron la aplicación, parece funcionar. Para muchas personas esto es normal. Ni siquiera sabrán que esta aplicación fallará por algún motivo, no recibirán una alerta, pero para ellos esto es la norma. Anteriormente vivíamos en máquinas virtuales sin monitoreo, ahora nos mudamos a Kubernetes, también sin monitoreo, ¿cuál es la diferencia?
La cuestión es que cuando caminamos sobre hielo, nunca sabemos su espesor a menos que lo midamos de antemano. Mucha gente camina y no se preocupa, porque ya ha caminado antes.
Desde mi punto de vista, el matiz y la complejidad de operar cualquier sistema es garantizar que el espesor del hielo sea exactamente suficiente para resolver nuestros problemas. Esto es de lo que estamos hablando.
En TI, me parece, hay demasiados enfoques de "tendré suerte". Mucha gente instala software y utiliza bibliotecas de software con la esperanza de tener suerte. En general, mucha gente tiene suerte. Probablemente por eso funciona.
— Según mi evaluación pesimista, se ve así: cuando los riesgos son altos y la aplicación debe funcionar, entonces se necesita el soporte de Flaunt, tal vez de Red Hat, o necesita su propio equipo interno dedicado específicamente a Kubernetes, que está listo para lograrlo.
Dmitry: Objetivamente, esto es así. Entrar en la historia de Kubernetes para un equipo pequeño por su cuenta implica una serie de riesgos.
¿Necesitamos contenedores?
— ¿Puede decirnos qué tan extendido está Kubernetes en Rusia?
Dmitry: No tengo estos datos y no estoy seguro de que alguien más los tenga. Decimos: “Kubernetes, Kubernetes”, pero hay otra forma de ver este tema. Tampoco sé qué tan extendidos están los contenedores, pero conozco una cifra por informes en Internet de que el 70% de los contenedores están orquestados por Kubernetes. Era una fuente confiable para una muestra bastante grande en todo el mundo.
Luego otra pregunta: ¿necesitamos contenedores? Mi sentimiento personal y la posición general de la empresa Flant es que Kubernetes es un estándar de facto.
No habrá nada más que Kubernetes.
Se trata de un punto de inflexión absoluto en el campo de la gestión de infraestructuras. Simplemente absoluto: eso es todo, no más Ansible, Chef, máquinas virtuales, Terraform. No me refiero a los viejos métodos agrícolas colectivos. Kubernetes es un cambiador absoluto, y ahora solo será así.
Está claro que a algunos les lleva un par de años, y a otros, un par de décadas, darse cuenta de ello. No tengo ninguna duda de que no habrá más que Kubernetes y esta nueva apariencia: ya no dañamos el sistema operativo, sino que usamos infraestructura como código, solo que no con código, sino con yml, una infraestructura descrita de forma declarativa. Tengo la sensación de que siempre será así.
— Es decir, aquellas empresas que aún no se han pasado a Kubernetes definitivamente lo harán o quedarán en el olvido. ¿Te entendí correctamente?
Dmitry: Esto tampoco es del todo cierto. Por ejemplo, si tenemos la tarea de ejecutar un servidor DNS, entonces se puede ejecutar en FreeBSD 4.10 y puede funcionar perfectamente durante 20 años. Solo trabaja y listo. Quizás dentro de 20 años sea necesario actualizar algo una vez. Si hablamos de software en el formato que lanzamos y realmente funciona durante muchos años sin actualizaciones, sin realizar cambios, entonces, por supuesto, no habrá Kubernetes. No es necesario allí.
Todo lo relacionado con CI/CD, donde sea que se necesite entrega continua, donde necesite actualizar versiones, realizar cambios activos, donde necesite desarrollar tolerancia a fallas, solo Kubernetes.
Acerca de los microservicios
- Aquí tengo una ligera disonancia. Para trabajar con Kubernetes, necesita soporte externo o interno; este es el primer punto. En segundo lugar, cuando recién estamos comenzando el desarrollo, somos una pequeña startup, todavía no tenemos nada, el desarrollo para Kubernetes o la arquitectura de microservicios en general puede ser complejo y no siempre justificado económicamente. Me interesa su opinión: ¿las startups deben comenzar a escribir inmediatamente para Kubernetes desde cero, o aún pueden escribir un monolito y luego solo llegar a Kubernetes?
Dmitry: Genial pregunta. Tengo una charla sobre microservicios. Muchas veces me he encontrado con personas que intentaban clavar clavos con un microscopio. El enfoque en sí es correcto; nosotros mismos diseñamos nuestro software interno de esta manera. Pero cuando haces esto, necesitas entender claramente lo que estás haciendo. La palabra que más odio de los microservicios es "micro". Históricamente, esta palabra se originó allí y, por alguna razón, la gente piensa que micro es muy pequeño, menos de un milímetro, como un micrómetro. Esto está mal.
Por ejemplo, hay un monolito escrito por 300 personas, y todos los que participaron en el desarrollo entienden que hay problemas allí y que deben dividirse en micropiezas, unas 10 piezas, cada una de las cuales está escrita por 30 personas. en una versión mínima. Esto es importante, necesario y genial. Pero cuando nos llega una startup, donde 3 tipos geniales y talentosos escribieron 60 microservicios de rodillas, cada vez que busco Corvalol.
Me parece que ya se ha hablado de esto miles de veces: obtuvimos un monolito distribuido de una forma u otra. Esto no está justificado económicamente, es muy difícil en general en todo. He visto esto tantas veces que realmente me duele, así que sigo hablando de ello.
A la pregunta inicial, hay un conflicto entre el hecho de que, por un lado, Kubernetes da miedo de usar, porque no está claro qué podría fallar allí o no funcionar, y por otro lado, está claro que todo va allí. y no existirá nada más que Kubernetes. Respuesta - sopesa la cantidad de beneficio que viene, la cantidad de tareas que puedes resolver. Esto está en un lado de la balanza. Por otro lado, existen riesgos asociados con el tiempo de inactividad o con una disminución en el tiempo de respuesta, el nivel de disponibilidad, con una disminución en los indicadores de desempeño.
Aquí está: o nos movemos rápidamente y Kubernetes nos permite hacer muchas cosas mucho más rápido y mejor, o utilizamos soluciones confiables y probadas en el tiempo, pero nos movemos mucho más lentamente. Ésta es una elección que toda empresa debe tomar. Puedes pensar en ello como un camino en la jungla: cuando caminas por primera vez, puedes encontrarte con una serpiente, un tigre o un tejón loco, y cuando hayas caminado 10 veces, habrás pisado el camino, eliminado. las ramas y caminar más fácilmente. Cada vez el camino se hace más ancho. Luego es una carretera asfaltada y luego un hermoso bulevar.
Kubernetes no se queda quieto. Pregunta nuevamente: Kubernetes, por un lado, son 4 o 5 binarios, por otro lado, es el ecosistema completo. Este es el sistema operativo que tenemos en nuestras máquinas. ¿Qué es esto? ¿Ubuntu o Curiosidades? Este es el kernel de Linux, un montón de componentes adicionales. Todas estas cosas aquí, una serpiente venenosa fue arrojada fuera del camino, allí se erigió una cerca. Kubernetes se está desarrollando de manera muy rápida y dinámica, y el volumen de riesgos, el volumen de lo desconocido disminuye cada mes y, en consecuencia, estas escalas se están reequilibrando.
Respondiendo a la pregunta de qué debería hacer una startup, diría: venga a Flaunt, pague 150 mil rublos y obtenga un servicio sencillo de DevOps llave en mano. Si eres una pequeña startup con algunos desarrolladores, esto funciona. En lugar de contratar a sus propios DevOps, que necesitarán aprender cómo resolver sus problemas y pagar un salario en este momento, obtendrá una solución llave en mano para todos los problemas. Sí, hay algunas desventajas. Nosotros, como subcontratistas, no podemos involucrarnos tanto y responder rápidamente a los cambios. Pero tenemos mucha experiencia y prácticas ya preparadas. Garantizamos que en cualquier situación definitivamente lo resolveremos rápidamente y resucitaremos a cualquier Kubernetes de entre los muertos.
Recomiendo encarecidamente la subcontratación a empresas emergentes y establecidas hasta un tamaño en el que se pueda dedicar un equipo de 10 personas a las operaciones, porque de lo contrario no tiene sentido. Definitivamente tiene sentido subcontratar esto.
Acerca de Amazon y Google
— ¿Se puede considerar subcontratado un host de una solución de Amazon o Google?
Dmitry: Sí, por supuesto, esto resuelve una serie de cuestiones. Pero nuevamente hay matices. Aún necesitas entender cómo usarlo. Por ejemplo, hay mil pequeñas cosas en el trabajo de Amazon AWS: es necesario calentar el Load Balancer o escribir una solicitud con anticipación que diga "muchachos, recibiremos tráfico, ¡calienten el Load Balancer por nosotros!" Necesitas conocer estos matices.
Cuando recurres a personas especializadas en esto, consigues cerrar casi todas las cosas típicas. Ahora tenemos 40 ingenieros, a finales de año probablemente seremos 60; definitivamente nos hemos encontrado con todas estas cosas. Incluso si volvemos a encontrar este problema en algún proyecto, rápidamente nos preguntamos y sabemos cómo solucionarlo.
Probablemente la respuesta sea: por supuesto, una historia alojada facilita algunas cosas. La pregunta es si está dispuesto a confiar en estos proveedores de alojamiento y si solucionarán sus problemas. A Amazon y Google les ha ido bien. Para todos nuestros casos, exactamente. No tenemos más experiencias positivas. Todas las demás nubes con las que intentamos trabajar crean muchos problemas: Ager y todo lo que hay en Rusia y todo tipo de OpenStack en diferentes implementaciones: Headster, Overage, lo que quieras. Todos crean problemas que no quieres resolver.
Por lo tanto, la respuesta es sí, pero, de hecho, no hay muchas soluciones alojadas maduras.
¿Quién necesita Kubernetes?
— Y, sin embargo, ¿quién necesita Kubernetes? ¿Quién debería cambiarse ya a Kubernetes, quién es el típico cliente de Flaunt que viene específicamente para Kubernetes?
Dmitry: Esta es una pregunta interesante, porque ahora mismo, a raíz de Kubernetes, mucha gente viene a nosotros: "Chicos, sabemos que están haciendo Kubernetes, ¡haganlo por nosotros!" Les respondemos: "Caballeros, no hacemos Kubernetes, hacemos pinchazos y todo lo relacionado con él". Porque actualmente es simplemente imposible crear un producto sin realizar todo el CI/CD y toda esta historia. Todo el mundo se ha alejado de la división de que tenemos desarrollo tras desarrollo y luego explotación tras explotación.
Nuestros clientes esperan cosas diferentes, pero todos esperan algún buen milagro para tener ciertos problemas, y ahora, ¡salte! — Kubernetes los resolverá. La gente cree en los milagros. En sus mentes entienden que no habrá ningún milagro, pero en sus almas esperan: ¿y si este Kubernetes ahora nos resuelva todo? ¡Hablan tanto de eso! De repente él ahora - ¡estornuda! - y una bala de plata, ¡estornuda! – y tenemos un 100 % de tiempo de actividad, todos los desarrolladores pueden publicar lo que entre en producción 50 veces y no falla. En general, ¡un milagro!
Cuando esas personas acuden a nosotros, decimos: "Lo siento, pero los milagros no existen". Para estar sano es necesario comer bien y hacer ejercicio. Para tener un producto confiable, es necesario fabricarlo de manera confiable. Para tener un CI/CD conveniente, debe hacerlo así. Es mucho trabajo por hacer.
Respondiendo a la pregunta de quién necesita Kubernetes: nadie necesita Kubernetes.
Algunas personas tienen la idea errónea de que necesitan Kubernetes. La gente necesita, tiene una profunda necesidad, de dejar de pensar, estudiar y interesarse por todos los problemas de infraestructura y los problemas de ejecución de sus aplicaciones. Quieren que las aplicaciones simplemente funcionen y se implementen. Para ellos, Kubernetes es la esperanza de que dejen de escuchar la historia de que “estábamos ahí tirados” o “no podemos implementar” o algo más.
Normalmente viene a nosotros el director técnico. Le piden dos cosas: por un lado, que nos dé prestaciones, por otro, estabilidad. Le sugerimos que lo asuma usted mismo y lo haga. La solución milagrosa, o más bien plateada, es que dejarás de pensar en estos problemas y de perder el tiempo. Contarás con personas especiales que cerrarán este tema.
La redacción de que nosotros o cualquier otra persona necesitamos Kubernetes es incorrecta.
Los administradores realmente necesitan Kubernetes, porque es un juguete muy interesante con el que puedes jugar y jugar. Seamos honestos: a todo el mundo le encantan los juguetes. Todos somos niños en alguna parte, y cuando vemos uno nuevo, queremos jugar con él. Para algunos, esto se ha desalentado, por ejemplo, en la administración, porque ya han jugado lo suficiente y ya están cansados hasta el punto de que simplemente no quieren hacerlo. Pero esto no está completamente perdido para nadie. Por ejemplo, si he estado cansado de los juguetes en el campo de la administración de sistemas y DevOps durante mucho tiempo, todavía me encantan los juguetes y todavía compro algunos nuevos. Todas las personas, de una forma u otra, todavía quieren algún tipo de juguete.
No es necesario jugar con la producción. Lo que recomiendo categóricamente no hacer y lo que veo ahora en masa: “¡Oh, un juguete nuevo!” — corrieron a comprarlo, lo compraron y: “Vamos a llevarlo ahora a la escuela y mostrárselo a todos nuestros amigos”. No hagas esto. Pido disculpas, mis hijos apenas están creciendo, constantemente veo algo en los niños, lo noto en mí y luego lo generalizo a los demás.
La respuesta final es: no necesitas Kubernetes. Necesitas resolver tus problemas.
Lo que puedes lograr es:
- la picana no cae;
- incluso si intenta caerse, lo sabemos de antemano y podemos ponerle algo;
- podemos cambiarlo a la velocidad que nuestro negocio lo requiera, y podemos hacerlo cómodamente, no nos causa ningún problema.
Hay dos necesidades reales: confiabilidad y dinamismo/flexibilidad de implementación. Todos los que actualmente están realizando algún tipo de proyecto de TI, sin importar en qué tipo de negocio - suave para facilitar el mundo, y que entienden esto, deben resolver estas necesidades. Kubernetes con el enfoque correcto, con la comprensión adecuada y con suficiente experiencia te permite resolverlos.
Acerca de sin servidor
— Si miramos un poco más hacia el futuro, al tratar de resolver el problema de la ausencia de dolores de cabeza con la infraestructura, con la velocidad de implementación y la velocidad de los cambios de aplicaciones, aparecen nuevas soluciones, por ejemplo, sin servidor. ¿Siente algún potencial en esta dirección y, digamos, un peligro para Kubernetes y soluciones similares?
Dmitry: Aquí debemos hacer una observación nuevamente: no soy un vidente que mira hacia adelante y dice: ¡será así! Aunque acabo de hacer lo mismo. Me miro los pies y veo un montón de problemas allí, por ejemplo, cómo funcionan los transistores en una computadora. Es gracioso, ¿verdad? Nos encontramos con algunos errores en la CPU.
Haga que la tecnología sin servidor sea bastante confiable, económica, eficiente y conveniente, resolviendo todos los problemas del ecosistema. En este punto estoy de acuerdo con Elon Musk en que se necesita un segundo planeta para crear tolerancia a las fallas en la humanidad. Aunque no sé lo que está diciendo, entiendo que yo no estoy listo para volar a Marte y que eso no sucederá mañana.
Con la tecnología sin servidor, queda claramente claro que esto es algo ideológicamente correcto, como la tolerancia a fallos de la humanidad: tener dos planetas es mejor que uno. ¿Pero cómo hacerlo ahora? Enviar una expedición no es un problema si concentras tus esfuerzos en ello. Creo que también es realista enviar varias expediciones y asentar allí a varios miles de personas. Pero hacerlo completamente tolerante a fallos para que la mitad de la humanidad viva allí, ahora me parece imposible, sin considerarlo.
Con el uno a uno sin servidor: la cosa está bien, pero está lejos de los problemas de 2019. Más cerca de 2030: vivamos para verlo. No tengo ninguna duda de que viviremos, definitivamente viviremos (repito antes de acostarnos), pero ahora necesitamos solucionar otros problemas. Es como creer en el pony de cuento de hadas Rainbow. Sí, un par de por ciento de los casos se resuelven, y se resuelven perfectamente, pero subjetivamente, serverless es un arcoíris... Para mí, este tema es demasiado lejano y demasiado incomprensible. No estoy listo para hablar. En 2019, no se puede escribir una sola aplicación sin servidor.
Cómo evolucionará Kubernetes
— A medida que avanzamos hacia este futuro lejano potencialmente maravilloso, ¿cómo cree que se desarrollarán Kubernetes y el ecosistema que lo rodea?
Dmitry: He pensado mucho en esto y tengo una respuesta clara. El primero es con estado; después de todo, sin estado es más fácil de hacer. Kubernetes inicialmente invirtió más en esto, todo empezó con ello. Stateless funciona casi a la perfección en Kubernetes, simplemente no hay nada de qué quejarse. Todavía hay muchos problemas, o mejor dicho, matices. Todo allí ya funciona muy bien para nosotros, pero somos nosotros. Se necesitarán al menos un par de años más para que esto funcione para todos. Este no es un indicador calculado, sino un sentimiento de mi cabeza.
En resumen, statefull debería (y lo hará) desarrollarse con mucha fuerza, porque todas nuestras aplicaciones almacenan el estado; no hay aplicaciones sin estado. Esto es una ilusión; siempre necesitas algún tipo de base de datos y algo más. Statefull se trata de corregir todo lo posible, corregir todos los errores, mejorar todos los problemas que se enfrentan actualmente; llamémoslo adopción.
El nivel de lo desconocido, el nivel de problemas no resueltos, el nivel de probabilidad de encontrar algo disminuirá significativamente. Esta es una historia importante. Y los operadores, todo lo relacionado con la codificación de la lógica de administración y la lógica de control para obtener un servicio sencillo: servicio sencillo MySQL, servicio sencillo RabbitMQ, servicio sencillo Memcache, en general, todos estos componentes con los que debemos tener la garantía de funcionar. la caja. Esto simplemente resuelve el problema de que queremos una base de datos, pero no queremos administrarla, o queremos Kubernetes, pero no queremos administrarlo.
Esta historia de desarrollo de operadores de una forma u otra será importante en los próximos años.
Creo que la facilidad de uso debería aumentar considerablemente: la caja será cada vez más negra, cada vez más fiable y con perillas cada vez más simples.
Una vez escuché una vieja entrevista con Isaac Asimov de los años 80 en YouTube en el programa Saturday Night Live, un programa como Urgant, solo que interesante. Le preguntaron sobre el futuro de las computadoras. Dijo que el futuro está en la simplicidad, como la radio. El receptor de radio era originalmente un objeto complejo. Para atrapar una ola, había que girar las perillas durante 15 minutos, girar las brochetas y, en general, saber cómo funciona todo, comprender la física de la transmisión de ondas de radio. Como resultado, solo quedó una perilla en la radio.
Ahora en 2019 ¿qué radio? En el coche, el receptor de radio encuentra todas las ondas y los nombres de las emisoras. La física del proceso no ha cambiado en 100 años, pero sí la facilidad de uso. Ahora, y no sólo ahora, ya en 1980, cuando hubo una entrevista con Azimov, todos usaban la radio y nadie pensaba en cómo funcionaba. Siempre funcionó, eso es un hecho.
Azimov luego dijo que con las computadoras pasaría lo mismo: la facilidad de uso aumentará. Mientras que en 1980 había que aprender a pulsar botones en un ordenador, ese no será el caso en el futuro.
Tengo la sensación de que con Kubernetes y la infraestructura también habrá un enorme aumento en la facilidad de uso. Esto, en mi opinión, es obvio: se encuentra en la superficie.
¿Qué hacer con los ingenieros?
— ¿Qué pasará entonces con los ingenieros y administradores de sistemas que apoyan a Kubernetes?
Dmitry: ¿Qué pasó con el contador después de la llegada de 1C? Sobre lo mismo. Antes contaban en papel, ahora en el programa. La productividad laboral ha aumentado en órdenes de magnitud, pero el trabajo en sí no ha desaparecido. Si antes eran necesarios 10 ingenieros para enroscar una bombilla, ahora bastará con uno.
Me parece que la cantidad de software y la cantidad de tareas están creciendo ahora a un ritmo más rápido que la aparición de nuevos DevOps y la eficiencia está aumentando. Hay una escasez específica en el mercado ahora mismo y durará mucho tiempo. Más tarde, todo volverá a algún tipo de normalidad, en la que la eficiencia del trabajo aumentará, habrá cada vez más servidores, se conectará una neurona a Kubernetes, que seleccionará todos los recursos exactamente según sea necesario y, en general, hacer todo por sí mismo, como debería; la persona simplemente se aleja y no interfiere.
Pero todavía habrá alguien que tendrá que tomar decisiones. Está claro que el nivel de cualificación y especialización de esta persona es mayor. Hoy en día, en el departamento de contabilidad no hacen falta 10 empleados llevando libros para que no se les cansen las manos. Simplemente no es necesario. Muchos documentos son escaneados y reconocidos automáticamente por el sistema de gestión de documentos electrónicos. Un jefe de contabilidad inteligente es suficiente, ya con habilidades mucho mayores y con buenos conocimientos.
En general, este es el camino a seguir en todas las industrias. Lo mismo ocurre con los coches: antes, un coche venía con un mecánico y tres conductores. Hoy en día conducir un coche es un proceso sencillo en el que todos participamos cada día. Nadie piensa que un coche sea algo complicado.
DevOps o la ingeniería de sistemas no desaparecerán: aumentarán el trabajo de alto nivel y la eficiencia.
— También escuché una idea interesante de que el trabajo aumentará.
Dmitry: ¡Por supuesto, cien por ciento! Porque la cantidad de software que escribimos crece constantemente. La cantidad de problemas que solucionamos con software crece constantemente. La cantidad de trabajo está creciendo. Ahora el mercado de DevOps está terriblemente sobrecalentado. Esto se puede ver en las expectativas salariales. En el buen sentido, sin entrar en detalles, debería haber jóvenes que quieran X, medianos que quieran 1,5X y seniors que quieran 2X. Y ahora, si nos fijamos en el mercado salarial de DevOps de Moscú, un junior quiere de X a 3X y un senior quiere de X a 3X.
Nadie sabe cuánto cuesta. El nivel salarial se mide por su confianza: un completo manicomio, para ser honesto, un mercado terriblemente sobrecalentado.
Por supuesto, esta situación cambiará muy pronto: debería producirse cierta saturación. Este no es el caso del desarrollo de software: a pesar de que todo el mundo necesita desarrolladores y todo el mundo necesita buenos desarrolladores, el mercado entiende quién vale qué: la industria se ha asentado. Ese no es el caso de DevOps hoy en día.
— Por lo que escuché, llegué a la conclusión de que el actual administrador del sistema no debería preocuparse demasiado, pero es hora de mejorar sus habilidades y prepararse para el hecho de que mañana habrá más trabajo, pero estará más calificado.
Dmitry: Cien por ciento. En general vivimos en 2019 y la regla de vida es esta: Aprendizaje de por vida: aprendemos a lo largo de nuestra vida.. Me parece que ahora todo el mundo ya lo sabe y lo siente, pero no basta con saberlo, hay que hacerlo. Cada día debemos cambiar. Si no lo hacemos, tarde o temprano quedaremos marginados de la profesión.
Esté preparado para giros bruscos de 180 grados. No descarto una situación en la que algo cambie radicalmente, se invente algo nuevo: sucede. ¡Brincar! - y ahora actuamos de manera diferente. Es importante estar preparado para esto y no preocuparse. Puede suceder que mañana todo lo que haga resulte innecesario, nada, he estudiado toda mi vida y estoy dispuesto a aprender algo más. No es un problema. No hay por qué temer la seguridad laboral, pero sí hay que estar preparado para aprender constantemente algo nuevo.
Deseos y un minuto de publicidad.
- ¿Tiene algún deseo?
Dmitry: Sí, tengo varios deseos.
Primera y mercantil - suscríbete a . Estimados lectores, vayan a YouTube y suscríbanse a nuestro canal. En aproximadamente un mes comenzaremos la expansión activa del servicio de video. Tendremos una gran cantidad de contenido educativo sobre Kubernetes, abierto y variado: desde cosas prácticas, hasta laboratorios, hasta conceptos teóricos fundamentales profundos y cómo usar Kubernetes en el nivel de principios y patrones.
El segundo deseo mercantil: vaya a y poner estrellas porque de ellas nos alimentamos. Si no nos das estrellas, no tendremos nada que comer. Es como maná en un juego de computadora. Hacemos algo, lo hacemos, lo intentamos, alguien dice que son bicicletas terribles, alguien que todo está completamente mal, pero continuamos y actuamos con absoluta honestidad. Vemos un problema, lo solucionamos y compartimos nuestra experiencia. Por tanto, danos una estrella, no se irá de ti, sino que vendrá a nosotros, porque de ella nos alimentamos.
Tercer deseo importante y ya no mercantil: deja de creer en los cuentos de hadas. Sois profesionales. DevOps es una profesión muy seria y responsable. Deja de jugar en el lugar de trabajo. Deja que haga clic por ti y lo entenderás. Imagina que llegas al hospital y allí el médico está experimentando contigo. Entiendo que esto puede resultar ofensivo para alguien, pero lo más probable es que no se trate de usted, sino de otra persona. Diles a los demás que también se detengan. Esto realmente nos arruina la vida a todos: muchos comienzan a tratar a las operaciones, administradores y DevOps como tipos que han vuelto a romper algo. Esto se "rompió" la mayoría de las veces debido al hecho de que íbamos a jugar y no mirábamos con la fría conciencia de que así es y así es.
Esto no significa que no debas experimentar. Necesitamos experimentar, lo hacemos nosotros mismos. Para ser honesto, nosotros mismos a veces jugamos; esto, por supuesto, es muy malo, pero nada humano nos es ajeno. Declaremos 2019 como un año de experimentos serios y bien pensados, y no de juegos en producción. Probablemente.
- ¡Muchas gracias!
Dmitry: Gracias Vitaly, tanto por el tiempo como por la entrevista. Queridos lectores, muchas gracias si de repente habéis llegado a este punto. Espero haberte traído al menos un par de pensamientos.
En la entrevista, Dmitry abordó el tema del werf. Ahora bien, esta es una navaja suiza universal que resuelve casi todos los problemas. Pero no siempre fue así. En en el festival Dmitry Stolyarov le contará en detalle sobre esta herramienta. en el informe Habrá de todo: problemas y matices ocultos de Kubernetes, opciones para resolver estas dificultades y la implementación actual de werf en detalle. Únase a nosotros el 27 y 28 de mayo, crearemos las herramientas perfectas.
Fuente: habr.com