En la víspera de Vitaliy Khabarov realizó una entrevista con Dmitry Stolyarov (), director técnico y cofundador de la empresa «Flant». Vitaliy preguntó a Dmitry sobre lo que hace «Flant», sobre Kubernetes, el desarrollo del ecosistema, el soporte. Discutieron por qué es necesario Kubernetes y si realmente es necesario. También hablaron sobre microservicios, Amazon AWS, el enfoque de ‘Me siento afortunado’ en DevOps, el futuro de Kubernetes, por qué, cuándo y cómo dominará el mundo, las perspectivas de DevOps y a qué deben prepararse los ingenieros en un futuro brillante y cercano con la simplificación y las redes neuronales.
en forma de pódcast en DevOps Deflop, un pódcast en ruso sobre DevOps, y abajo la versión escrita.
Aquí y adelante, las preguntas las hace un ingeniero de Express42.
Sobre «Flant»
— Dima, hola. Tú eres el director técnico de «» y también su fundador. Cuéntame, por favor, qué hace la empresa y qué haces tú en ella.
Dmitry: Desde fuera parece que somos esos chicos que van por ahí, instalando Kubernetes a todos y haciendo algo con él. Pero no es así. Comenzamos como una empresa que se ocupa de Linux, pero desde hace mucho tiempo nuestra actividad principal es el mantenimiento de proyectos de producción y de alta carga llave en mano. Generalmente, construimos toda la infraestructura desde cero y luego nos hacemos responsables de ella durante mucho tiempo. Por lo tanto, el trabajo principal que realiza «Flant», por lo que recibe dinero, es asumir la responsabilidad y llevar a cabo la producción llave en mano.
Yo, como director técnico y uno de los fundadores de la empresa, estoy todo el día pensando en cómo aumentar la disponibilidad de la producción, simplificar su operación, hacer la vida más fácil a los administradores y mejorar la experiencia de los desarrolladores.
Sobre Kubernetes
— Últimamente he visto muchas conferencias de «Flant» y sobre Kubernetes. ¿Cómo llegaron a él?
Dmitry: Ya he contado esto muchas veces, pero no me importa repetirlo en absoluto. Creo que es correcto volver a hablar de este tema, porque hay confusión entre la causa y el efecto.
Realmente necesitábamos una herramienta. Nos enfrentamos a un montón de problemas, luchamos, los superamos con diferentes parches y experimentamos la necesidad de una herramienta. Probamos muchas opciones diferentes, construimos nuestros propios sistemas y acumulamos experiencia. Poco a poco, llegamos al punto en que comenzamos a usar 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 algo similar a "Docker" — algunos parches propios en Python. Con la llegada de Docker, tuvimos la oportunidad de deshacernos de esos parches y usar una solución confiable y respaldada por la comunidad.
La historia con Kubernetes es similar. Para el momento en que comenzó a ganar tracción — para nosotros fue la versión 1.2 — ya teníamos un montón de parches tanto en Shell como en Chef, que intentábamos orquestar con Docker. Mirábamos seriamente hacia Rancher y otras soluciones, pero ahí apareció Kubernetes, que está implementado exactamente como lo haríamos nosotros o incluso mejor. No tenemos nada de qué quejarnos.
Sí, aquí hay alguna imperfección, allí hay otra imperfección — muchas cosas por hacer, y la 1.2 es un desastre en general, pero... Kubernetes es como un edificio en construcción: miras el proyecto y entiendes que será increíble. Si el edificio tiene ahora un cimiento y dos pisos, entiendes que es mejor no mudarse todavía, pero con el software no hay tales problemas — ya se puede usar.
No hubo un momento en el que pensáramos si debíamos usar Kubernetes o no. Lo esperábamos mucho antes de que apareciera y tratamos de construir nuestras propias alternativas.
Alrededor de Kubernetes
— ¿Participan directamente en el desarrollo de Kubernetes?
Dmitry: De manera indirecta. Más bien participamos en el desarrollo del ecosistema. Enviamos una cierta cantidad de pull requests: en Prometheus, en varios operadores, en Helm — al ecosistema. Desafortunadamente, no puedo seguir todo lo que hacemos y puedo estar equivocado, pero desde nuestra parte no hay ningún pull request en el núcleo.
— A pesar de esto, ¿desarrollan muchas de sus propias herramientas alrededor de Kubernetes?
Dmitry: La estrategia es esta: vamos y hacemos pull requests en todo lo que ya existe. Si no aceptan pull requests, simplemente los forkeamos para nosotros y seguimos viviendo hasta que sean aceptados con nuestras versiones. Luego, cuando llegue a upstream, regresamos a la versión upstream.
Por ejemplo, tenemos el operador de Prometheus, con el que hemos estado alternando en el upstream de nuestra compilación unas 5 veces, probablemente. Necesitamos alguna función, enviamos un pull request, necesitamos implementarla mañana y no queremos esperar a que la liberen en el upstream. Por lo tanto, estamos construyendo nuestra propia versión con la función que necesitamos en todos nuestros clústeres. Luego, esto, por ejemplo, en el upstream lo llevan con las palabras: "Chicos, hagamos esto para un caso más general", nosotros, o alguien más, lo completamos y eventualmente se fusiona nuevamente.
Todo lo que existe, nos esforzamos por desarrollarlo.Muchos elementos que aún no existen, o que se han pensado pero no se han implementado, los hacemos. Y no porque nos guste el proceso en sí o la construcción de bicicletas como industria, sino simplemente porque necesitamos esta herramienta. A menudo nos preguntan por qué hicimos tal o cual cosa. La respuesta es simple: porque necesitábamos avanzar, resolver algún problema práctico, y lo hicimos con esta herramienta.
El camino siempre es este: buscamos detenidamente y, si no encontramos ninguna solución, como hacer un trolebús a partir de un pan, hacemos nuestro propio pan y nuestro propio trolebús.
Herramientas de Flant
Sé que en Flant ahora hay operadores addon, operadores shell, herramientas dapp/werf. Como entiendo, es la misma herramienta en diferentes encarnaciones. También entiendo que dentro de Flant hay muchas otras herramientas diferentes. ¿Es así?
DmitryEn nuestro GitHub hay muchas más cosas. De lo que puedo recordar ahora, tenemos statusmap, un panel para Grafana que ha sido muy bien recibido. Se menciona en prácticamente cada segundo artículo sobre monitoreo de Kubernetes en Medium. Es imposible resumir qué es statusmap; se necesita un artículo aparte, pero es una herramienta muy útil para monitorear el estado en el tiempo, ya que a menudo necesitamos mostrar el estado en el tiempo en Kubernetes. También tenemos LogHouse, que es una herramienta basada en ClickHouse y un poco de magia negra para recopilar logs en Kubernetes.
¡Muchas utilidades! Y habrá más, porque una serie de soluciones internas se lanzarán este año. De las grandes, hay un montón de addons para Kubernetes, como cómo instalar correctamente el sert manager—una herramienta para gestionar certificados, cómo instalar Prometheus con un montón de complementos—son alrededor de veinte binaries diferentes que exportan datos y recopilan algo, además Prometheus tiene una gráfica espectacular y alertas. Todo esto es simplemente un montón de addons para Kubernetes que se instalan en el clúster, y se transforma de uno simple en uno impresionante, sofisticado, automático, en el que muchas cuestiones ya están resueltas. Sí, hacemos muchas cosas.
Desarrollo del ecosistema
— Creo que es una gran contribución al desarrollo de esta herramienta y sus métodos de uso. ¿Puedes estimar quién más podría hacer una contribución similar al desarrollo del ecosistema?
Dmitry: En Rusia, de las empresas que operan en nuestro mercado, no hay nadie ni cerca. Por supuesto, es una declaración audaz, porque hay grandes jugadores como Mail y Yandex—they también están haciendo algo con Kubernetes, pero incluso ellos no se acercan a la contribución de empresas en todo el mundo, que hacen mucho más de lo que hacemos nosotros. Es difícil comparar a 'Flant' con un equipo de 80 personas y a Red Hat, que tiene 300 ingenieros solo para Kubernetes, si no me equivoco. Es complicado comparar. En nuestro departamento de I+D somos 6 personas, incluyéndome, que crean todas nuestras herramientas. 6 personas contra 300 ingenieros de Red Hat—es un poco raro comparar.
— Sin embargo, cuando incluso estas 6 personas pueden hacer algo realmente útil y transferible, cuando se enfrentan a un problema práctico y entregan la solución a la comunidad—es un caso interesante. Entiendo que en grandes empresas tecnológicas, donde hay su propio desarrollo y un equipo de soporte para Kubernetes, también pueden desarrollarse herramientas similares. Es un ejemplo para ellos de lo que se puede desarrollar y entregar a la comunidad, dando un impulso a toda la comunidad que usa Kubernetes.
Dmitry: Probablemente, esto es una característica del integrador, su particularidad. Tenemos muchos proyectos y vemos muchas situaciones diferentes. Para nosotros, la principal forma de crear valor agregado es analizar estos casos, encontrar lo común y maximizar su reducción de costos para nosotros. Esto es algo en lo que trabajamos activamente. Me resulta difícil hablar sobre Rusia y el mundo, pero tenemos alrededor de 40 ingenieros DevOps en la empresa, que se dedican a Kubernetes. No creo que haya muchas empresas en Rusia con una cantidad comparable de especialistas que realmente entiendan Kubernetes, si es que existen.
Entiendo todo sobre el título de DevOps Engineer, todos lo comprenden y están acostumbrados a llamar a los ingenieros DevOps ingenieros DevOps, no lo discutiremos. Todos estos 40 maravillosos ingenieros DevOps enfrentan problemas todos los días y los resuelven; simplemente analizamos esta experiencia y tratamos de generalizar. Entendemos que si se queda con nosotros internamente, en un año o dos la herramienta será inútil, porque en algún lugar de la comunidad aparecerá un tool listo. No tiene sentido acumular esta experiencia internamente: es solo el despilfarro de recursos y tiempo en dev/null. Así que no nos importa en absoluto. Publicamos todo con gran placer y entendemos que es necesario publicar, desarrollar, promocionar y difundir para que las personas usen y añadan su experiencia; entonces todo crece y vive. Así, después de dos años, la herramienta no termina en la basura. No nos importa seguir invirtiendo recursos, porque es evidente que alguien está utilizando tu herramienta, y después de dos años, ya la están usando todos.
Es parte de nuestra gran estrategia con dapp/werf. No recuerdo cuándo comenzamos a hacerlo, parece que hace 3 años. Originalmente estaba en shell. Fue un gran proof of concept, resolvimos algunos de nuestros problemas específicos, ¡y funcionó! Pero con shell hay problemas, es imposible escalar más allá, programar en shell es una tarea complicada. Teníamos la costumbre de programar en Ruby, por lo que rehicimos algo en Ruby, desarrollamos, desarrollamos, desarrollamos, y llegamos al punto de que la comunidad, la multitud que no dice 'queremos o no queremos', se aleja de Ruby, por muy divertido que parezca. Nos dimos cuenta de que debíamos escribir todo esto en Go, para cumplir con el primer punto de la lista de verificación: La herramienta DevOps debe ser un binario estático. En Go o no en Go no es tan importante, pero es mejor un binario estático escrito en Go.
Hemos invertido esfuerzo, reescribimos la dapp en Go y la llamamos werf. La dapp ya no se mantiene, no se desarrolla, funciona en alguna versión final, pero hay una ruta de actualización absoluta hacia arriba, y se puede seguir.
Por qué se creó la dapp
— ¿Puedes contar brevemente por qué se creó la dapp, qué problemas resuelve?
Dmitry: La primera razón es la compilación. Al principio teníamos serios problemas con la compilación, cuando Docker no sabía hacer multi-stage, y lo hicimos por nuestra cuenta. Luego tuvimos un montón más de preguntas sobre la limpieza de imágenes. Todos los que realizan CI/CD, más temprano que tarde, se enfrentan al problema de que hay un montón de imágenes compiladas, necesitas limpiar lo que no se necesita y dejar lo que sí.
La segunda razón es el despliegue. Sí, existe Helm, pero solo resuelve una parte de las tareas. Como es irónico, está escrito que "Helm es el gestor de paquetes para Kubernetes". Precisamente eso, "el". También hay palabras "Gestor de Paquetes" — ¿qué expectativas hay normalmente de un Gestor de Paquetes? Decimos: "Gestor de Paquetes, ¡instala el paquete!" y esperamos que nos diga: "El paquete ha sido instalado".
Es curioso que digamos: "Helm, instala el paquete", y cuando responde que lo ha instalado, resulta que solo ha comenzado la instalación — le indicó a Kubernetes: "¡Inicia esta cosa!", pero si se inició o no, si funciona o no, Helm no resuelve esa cuestión en absoluto.
Así que resulta que Helm es simplemente un preprocesador de texto que carga datos en Kubernetes.
Pero dentro de cualquier despliegue queremos saber — ¿la aplicación se ha implementado en producción o no? Implementarse en producción significa que la aplicación ha sido desplegada, se ha lanzado una nueva versión y no se cae y responde correctamente. Helm no resuelve esta tarea. Para resolverla, hay que invertir mucho esfuerzo porque es necesario dar la orden a Kubernetes para que implemente y seguir lo que sucede — si se ha desplegado o no.
Planes
Este año comenzaremos con el desarrollo local. Queremos llegar a un estado como el que teníamos anteriormente con Vagrant: ingresamos 'vagrant up' y nuestras máquinas virtuales se desplegaban. Queremos llegar a un estado en el que tengamos un proyecto en Git, escribimos 'werf up' y se levanta una copia local de ese proyecto, desplegada en un mini-Kub local, con todos los directorios conectados y listos para el desarrollo. Dependiendo del lenguaje de programación, esto se ejecuta de diferentes maneras, pero, en cualquier caso, queremos facilitar el desarrollo local con archivos montados.
El siguiente paso para nosotros es invertir fuertemente en la comodidad para los desarrolladores. Para poder desplegar rápidamente un proyecto localmente con una sola herramienta, desarrollarlo, subirlo a Git, y que se despliegue exactamente igual en stage o en pruebas, dependiendo de los pipelines, y luego usar la misma herramienta para ir a producción. Esta unidad, unificación y reproducibilidad de la infraestructura desde el entorno local hasta producción es un aspecto muy importante para nosotros. Pero esto aún no está presente en werf; solo planeamos hacerlo.
Sin embargo, el camino hacia dapp/werf siempre ha sido similar al de Kubernetes al principio. Enfrentamos problemas, los solucionamos de manera indirecta, creando algunas soluciones en shell o lo que fuera. Luego intentamos simplificar, generalizar y consolidar esos soluciones en binarios que, en este caso, simplemente compartimos.
Hay otra perspectiva sobre toda esta historia, con analogías.
Kubernetes es el chasis de un automóvil con su motor. No hay puertas, cristales, receptor de radio, nada, solo el marco y el motor. Y Helm es el volante. Es genial tener el volante, pero también se necesitan el pasador de dirección, la cremallera, la transmisión y las ruedas; sin ellos, no sirve de nada.
En el caso de werf, es otro componente para Kubernetes. Actualmente, en nuestra versión alfa de werf, por ejemplo, Helm se compila completamente dentro de werf, porque ya estábamos cansados de hacerlo nosotros mismos. Hay muchas razones para hacerlo de esta manera; explicaré en detalle por qué hemos incorporado helm junto con tiller completamente dentro de werf .
Ahora, werf es un componente más integrado. Nos proporciona un volante listo, un vástago de dirección; no tengo mucho conocimiento sobre automóviles, pero es un gran bloque que resuelve una amplia gama de tareas. No necesitamos buscar en el catálogo, seleccionar una pieza para otra, pensar en cómo atornillarlas entre sí. Obtenemos una cosechadora lista que resuelve un montón de tareas de entrada. Pero en su interior, está construido con los mismos componentes de código abierto, también utiliza Docker para la construcción, Helm para parte de la funcionalidad y hay varias otras bibliotecas. Es una herramienta integrada para obtener rápida y cómodamente un CI/CD impresionante desde la caja.
¿Es difícil mantener Kubernetes?
— Estás hablando sobre la experiencia de haber comenzado a usar Kubernetes, este es su marco, su motor, y se puede agregar mucho más: chasis, volante, atornillar pedales, asientos. Surge la pregunta: ¿cuán difícil es para ustedes mantener Kubernetes? Tienen una rica experiencia, ¿cuánto tiempo y recursos les lleva específicamente mantener Kubernetes independientemente de todo lo demás?
Dmitry: Es una pregunta muy complicada y para responderla, necesitamos entender qué significa mantenimiento y qué queremos de Kubernetes. ¿Podrías explicarlo?
— Hasta donde sé y como veo, actualmente muchos equipos quieren probar Kubernetes. Todos están involucrándose, instalándolo en sus laptops. Tengo la sensación de que las personas no siempre comprenden la complejidad de este sistema.
Dmitry: Así es.
— ¿Qué tan difícil es instalar Kubernetes de cero para que esté listo para producción?
Dmitry: ¿Qué piensas, cuán difícil es realizar un trasplante de corazón? Entiendo que es una pregunta comprometida. Manejar un escalpelo y no cometer errores no es tan complicado. Si te dicen dónde cortar y dónde coser, el procedimiento en sí no es difícil. Lo complicado es garantizar que todo salga bien cada vez.
Instalar Kubernetes y lograr que funcione es simple: ¡clic! — se instala, hay montones de formas de hacerlo. Pero, ¿qué pasará cuando surjan problemas?
Siempre surgen preguntas: ¿qué más no hemos considerado? ¿Qué más no hemos hecho? ¿Qué parámetros del núcleo de Linux configuramos incorrectamente? Dios mío, ¿acaso los configuramos en absoluto? ¿Qué componentes de Kubernetes instalamos y cuáles no? Aparecen miles de preguntas, y para responderlas, se necesita hervir en esta industria durante 15-20 años.
Tengo un ejemplo reciente sobre este tema que puede revelar el sentido del problema "¿Es difícil mantener Kubernetes?". Hace un tiempo, consideramos seriamente implementar Cilium como red en Kubernetes.
Voy a explicar qué es Cilium. En Kubernetes hay muchas implementaciones diferentes del subsistema de red, y una de ellas es muy interesante: Cilium. ¿Cuál es su propósito? Hace algún tiempo, se introdujo la capacidad de escribir ganchos para el núcleo que interaccionan de alguna manera con el subsistema de red y otros subsistemas, permitiendo eludir grandes partes del núcleo.
Históricamente, en el núcleo de Linux existen ip rout, netfilter, puentes y muchos componentes antiguos que tienen 15, 20 o 30 años. En general, funcionan, todo está bien, pero actualmente hemos llenado de contenedores, y se ve como una torre de 15 ladrillos uno sobre otro, y tú te mantienes en ella sobre una pierna: una sensación extraña. Este sistema se ha desarrollado históricamente con muchos matices, como un apéndice en el organismo. En algunas situaciones hay problemas de rendimiento, por ejemplo.
Hay un maravilloso BPF y la posibilidad de escribir ganchos para el núcleo: los chicos han escrito sus ganchos para el núcleo. El paquete llega al núcleo de Linux, lo extraen justo en la entrada, lo procesan como necesitan sin puentes, sin TCP, sin pila IP: en resumen, eludiendo todo lo escrito en el núcleo de Linux, y lo escupen directamente en el contenedor.
¿Qué se obtuvo? Un rendimiento muy bueno, características geniales: ¡simplemente increíble! Pero miramos esto y vemos que en cada máquina hay un programa que se conecta a la API de Kubernetes y, basándose en los datos que obtiene de esa API, genera código en C y compila binarios que carga en el núcleo, para que esos ganchos funcionen en el espacio del kernel.
¿Qué pasará si algo no sale bien? No lo sabemos. Para entenderlo, es necesario leer todo este código y comprender toda la lógica, y eso es increíblemente complicado. Pero, por otro lado, existen estos puentes, filtros de red, ip rout: yo no he leído sus fuentes, y 40 ingenieros que trabajan en nuestra empresa tampoco. Tal vez, algunas partes solo sean entendidas por unos pocos.
¿Y cuál es la diferencia? Resulta que hay ip rout, núcleo de Linux, y hay una nueva herramienta — ¿cuál es la diferencia?, ninguna de las dos las entendemos. Pero tememos usar lo nuevo — ¿por qué? Porque si la herramienta tiene 30 años, durante estos 30 años se han encontrado todos los errores, se han caído en todas las trampas y no es necesario saber todo — funciona como una caja negra y siempre opera. Todos saben dónde insertar el destornillador de diagnóstico, qué tcpdump ejecutar en qué momento. Todos conocen bien las utilidades de diagnóstico y comprenden cómo funciona este conjunto de componentes en el núcleo de Linux — no cómo está construido, sino cómo usarlo.
Pero el increíble Cilium no tiene 30 años, aún no ha madurado. Hay el mismo problema con Kubernetes, es una copia. Tanto Cilium como Kubernetes se instalan perfectamente, pero cuando algo falla en producción, ¿serán capaces de entender rápidamente, en una situación crítica, qué salió mal?
Cuando decimos que es difícil mantener Kubernetes — no, es muy fácil, y sí, es increíblemente complicado. Kubernetes funciona maravillosamente por sí mismo, pero con un billón de matices.
Sobre el enfoque "Me va a ir bien"
— ¿Y hay empresas donde estos matices aparecerán casi garantizadamente? Supongamos que Yandex de repente traslade todos sus servicios a Kubernetes, habrá una carga enorme.
Dmitry: No, esta conversación no trata sobre la carga, sino sobre cosas sencillas. Por ejemplo, tenemos Kubernetes, hemos desplegado una aplicación allí. ¿Cómo entender que está funcionando? No hay una herramienta lista para saber que la aplicación no falla. No hay un sistema preparado que envíe alertas — se deben configurar estas alertas y cada gráfico. Ah, y estamos actualizando Kubernetes.
Tenemos Ubuntu 16.04. Se podría decir que es una versión antigua, pero seguimos utilizándola porque es LTS. Ahí está systemd, cuyo detalle es que no limpia los grupos C. Kubernetes inicia pods, crea grupos C, luego elimina los pods, y de alguna manera, no recuerdo los detalles, disculpen, quedan residuos de systemd. Esto lleva a que, con el tiempo, cualquier máquina comience a ralentizarse considerablemente. No se trata ni siquiera de una cuestión de alta carga. Si se están ejecutando pods de forma continua, por ejemplo, si hay un trabajo cron que genera pods constantemente, la máquina con Ubuntu 16.04 comenzará a ralentizarse después de una semana. Habrá una carga promedio alta debido a que se han creado muchos grupos C. Este es un problema con el que se enfrenta cualquier persona que simplemente instale Ubuntu 16 y encima Kubernetes.
Supongamos que de alguna manera actualiza systemd o algo más, pero en el núcleo de Linux hasta la versión 4.16 es incluso más curioso: al eliminar grupos C, estos gotean en el núcleo y efectivamente no se eliminan. Por eso, después de un mes de uso de esta máquina, no se podrá ver la estadística de memoria por pods. Sacamos un archivo, lo contamos en el programa, y un archivo tarda 15 segundos en procesarse porque el núcleo tarda mucho en calcular internamente un millón de grupos C que supuestamente han sido eliminados, pero no, siguen goteando.
Todavía hay muchos de estos detalles por todos lados. No es un asunto con el que las grandes empresas puedan tropezar de vez en cuando bajo cargas muy altas; no, se trata de cuestiones cotidianas. La gente puede vivir así durante meses: instalar Kubernetes, desplegar una aplicación, y parece que funciona. A muchos les parece bien. No se darán cuenta de que en algún momento esa aplicación fallará por alguna razón; no recibirán alertas, pero para ellos eso es normal. Antes vivían en máquinas virtuales sin monitorización, ahora se han trasladado a Kubernetes también sin monitorización, ¿cuál es la diferencia?
La cuestión es que cuando caminamos sobre el hielo, nunca sabemos su grosor si no lo hemos medido previamente. Muchos caminan sin preocupaciones porque lo han hecho antes.
Desde mi punto de vista, la complejidad y el matiz del funcionamiento de cualquier sistema radica en garantizar que el grosor del hielo es suficiente para cumplir nuestras tareas. De eso se trata.
En TI, parece que hay demasiados enfoques de «tendré suerte». Muchos instalan software, utilizan bibliotecas en la esperanza de que tendrán suerte. En general, a muchos les va bien. Tal vez por eso funciona.
— Desde mi evaluación pesimista, esto se presenta así: cuando los riesgos son altos y la aplicación debe funcionar, se necesita apoyo de «Flant», posiblemente de Red Hat, o se requiere un equipo interno dedicado específicamente a Kubernetes, que esté preparado para gestionarlo.
Dmitry: Objetivamente, es así. Involucrarse por sí mismo con Kubernetes es arriesgado para un equipo pequeño.
¿Necesitamos contenedores?
— ¿Puedes contarme cuán extendido está Kubernetes en Rusia?
Dmitry: No tengo esos datos, y no estoy seguro de que nadie los tenga. Decimos: «Kubernetes, Kubernetes», pero hay otra perspectiva sobre el tema. No sé cuán extendidos están los contenedores, pero tengo una cifra de informes en internet que dice que el 70% de los contenedores son orquestados por Kubernetes. Esta fue una fuente confiable con una muestra bastante grande a nivel mundial.
A continuación, otra pregunta: ¿necesitamos contenedores? Tengo la sensación personal y también la posición de la empresa «Flant» de que Kubernetes es el estándar de facto.
No habrá nada más que Kubernetes.
Es un cambio absoluto en el campo de la gestión de infraestructura. Simplemente absoluto: no más Ansible, Chef, máquinas virtuales, Terraform. Y ni hablar de los métodos antiguos y obsoletos. Kubernetes es un cambio absoluto, y así será siempre.
Es claro que a algunos les llevará un par de años, y a otros, un par de décadas, darse cuenta de esto. No tengo dudas de que no habrá nada más que Kubernetes y esta nueva perspectiva: ya no dañamos la operación del sistema, sino que utilizamos infrastructure as code, solo que no con código, sino con yml: infraestructura descrita de manera declarativa. Tengo la sensación de que así será siempre.
— Entonces, ¿las empresas que aún no han migrado a Kubernetes necesariamente lo harán o quedarán en el olvido? ¿Te he entendido correctamente?
Dmitry: Esto tampoco es del todo correcto. Por ejemplo, si nuestra tarea es poner en marcha un servidor DNS, se puede hacer en FreeBSD 4.10 y puede funcionar perfectamente durante 20 años. Simplemente funciona y ya está. Puede que durante esos 20 años se necesite actualizar algo una vez. Si hablamos de software en un formato en el que lo hemos lanzado y realmente funciona durante muchos años sin actualizaciones ni cambios, entonces, por supuesto, no habrá Kubernetes. No es necesario allí.
Todo lo relacionado con CI/CD: en todos los lugares donde se requiere Continuous Delivery, donde es necesario actualizar versiones y realizar cambios activos, donde se necesita construir resiliencia, solo Kubernetes.
Sobre microservicios
— Aquí me surge un pequeño disonancia. Para trabajar con Kubernetes, se necesita soporte externo o interno, ese es el primer punto. El segundo es que cuando recién comenzamos el desarrollo, somos una pequeña startup, no tenemos nada todavía, desarrollar para Kubernetes o incluso para una arquitectura de microservicios puede ser difícil y no siempre justificado económicamente. Me interesa tu opinión: ¿deben las startups comenzar de cero escribiendo para Kubernetes o se puede escribir un monolito primero y luego pasar a Kubernetes?
Dmitry: Gran pregunta. Tengo una charla sobre microservicios Me he encontrado muchas veces con que las personas intentan usar un microscopio para clavar clavos. La aproximación en sí es correcta, nosotros también diseñamos nuestro software interno de esta manera. Pero cuando lo haces, debes comprender claramente lo que estás haciendo. Lo que más odio en los microservicios es la palabra «micro». Históricamente se forjó este término y, por alguna razón, la gente piensa que 'micro' significa muy pequeño, menos de un milímetro, como un micrómetro. No es así.
Por ejemplo, hay un monolito que es escrito por 300 personas, y todos los que participaron en el desarrollo saben que hay problemas y que debe dividirse en micropedazos — alrededor de 10, cada uno de los cuales es escrito por un mínimo de 30 personas. Eso es importante, necesario y genial. Pero cuando llega a nosotros una startup donde 3 chicos muy geniales y talentosos han escrito 60 microservicios de manera improvisada, cada vez busco un calmante.
Me parece que ya se ha hablado de esto miles de veces: hemos recibido un monolito distribuido en una u otra forma. Esto no es económicamente justificable, es muy complicado en general. Simplemente he visto esto tantas veces que me duele, por eso continúo hablando de ello.
Volviendo a la pregunta inicial, hay un conflicto entre, por un lado, que Kubernetes es terrible de usar porque no está claro qué puede romperse o no funcionar, y por otro lado, es evidente que todo se dirige hacia allí y que nada, excepto Kubernetes, será relevante. La respuesta es evaluar el volumen de beneficios que se obtienen y el volumen de tareas que se pueden resolver.. Esto es un lado de la balanza. Por el otro lado están los riesgos asociados con el tiempo de inactividad o la disminución del tiempo de respuesta, los niveles de disponibilidad, y la disminución de los indicadores operativos.
Aquí es así: debemos avanzar rápidamente, y Kubernetes permite realizar muchas cosas mucho más rápido y mejor, o utilizar soluciones confiables y probadas, pero avanzar mucho más lentamente. Cada empresa debe tomar esta decisión. Se puede ver esto como un sendero en la jungla: la primera vez que caminas, puedes encontrarte con una serpiente, un tigre o un tejón furioso, pero después de haberlo hecho 10 veces, has abierto el camino, quitado ramas y es más fácil de transitar. Cada vez el sendero se hace más ancho. Luego se convierte en una carretera asfaltada, y más tarde en un bonito bulevar.
Kubernetes no se detiene. Nuevamente surge la pregunta: Kubernetes, por un lado, son 4-5 binarios; por el otro lado, es todo un ecosistema. Es un sistema operativo que tenemos en nuestras máquinas. ¿Qué es esto? ¿Ubuntu o Curios? Es el núcleo de Linux, un montón de componentes adicionales. Todas estas cosas: aquí han quitado una serpiente venenosa del camino, allí han puesto una valla. Kubernetes se desarrolla de manera muy rápida y dinámica, y el volumen de riesgos y lo desconocido disminuye cada mes y, por lo tanto, estas balanzas se reequilibran.
Al responder a la pregunta sobre qué hacer un startup, diría: ven a "Flant", paga 150 mil rublos y obtén un servicio DevOps fácil llave en mano. Si eres una pequeña startup con unos pocos desarrolladores, esto funciona. En lugar de contratar tu propio DevOps, que necesitará aprender a resolver tus problemas y durante ese tiempo pagarle un salario, obtendrás una solución integral a todas tus inquietudes. Sí, hay algunos inconvenientes. Como outsourcing, no podemos estar tan involucrados y reaccionar rápidamente a los cambios. Pero tenemos mucha experiencia y prácticas listas. Garantizamos que en cualquier situación, con certeza resolveremos rápidamente y levantaremos cualquier Kubernetes desde el más allá.
Recomiendo categóricamente el outsourcing a startups y negocios establecidos hasta el tamaño en que puedes destinar un equipo de 10 personas para operaciones, porque de lo contrario no tiene sentido. Categóricamente tiene sentido externalizar.
Sobre Amazon y Google
¿Se puede considerar como outsourcing un hosting de soluciones de Amazon o Google?
Dmitry: Sí, claro, esto resuelve algunos problemas. Pero nuevamente hay matices. Aún hay que entender cómo utilizarlo. Por ejemplo, hay mil detalles en el funcionamiento de Amazon AWS: el Load Balancer necesita ser precalentado o hay que solicitar previamente que "compañeros, nos llegará tráfico, calienten nuestro Load Balancer!" Estos matices deben ser conocidos.
Cuando te diriges a personas que se especializan en esto, obtienes casi todas las cosas estándar cubiertas. Actualmente tenemos 40 ingenieros, para finales de año probablemente serán 60; claramente nos hemos encontrado con todas estas cuestiones. Incluso si en algún proyecto nos encontramos nuevamente con este problema, ya preguntamos rápidamente entre nosotros y sabemos cómo resolverlo.
Probablemente, la respuesta es así: por supuesto, la historia de hosting facilita una parte. La pregunta es si estás dispuesto a confiar en estos hosts y si resolverán tus problemas. Amazon y Google se han ganado una buena reputación. Para todos nuestros casos, definitivamente. No tenemos más experiencias positivas. Todos los demás nubes con las que hemos intentado trabajar crean muchos problemas: Ager, y todo lo que existe en Rusia, y varios OpenStack en diferentes implementaciones: Headster, Overage, lo que desees. Todos crean problemas que no queremos resolver.
Por lo tanto, la respuesta es sí, pero, en realidad, no hay muchas soluciones de hosting maduras.
¿Quién necesita Kubernetes?
— Sin embargo, ¿quién necesita Kubernetes? ¿Quién debería cambiarse a Kubernetes, quién es el cliente típico de "Flant" que llega específicamente por Kubernetes?
Dmitry: La pregunta es interesante, porque ahora mismo, en la ola de Kubernetes, muchos se acercan a nosotros: «Chicos, sabemos que ustedes hacen Kubernetes, ¡háganlo para nosotros!». Les respondemos: «Señores, no hacemos Kubernetes, hacemos producción y todo lo que se relaciona con ello». Porque hacer producción sin haber implementado todo el CI/CD y toda esa historia es prácticamente imposible en la actualidad. Todos se han alejado de la separación, donde el desarrollo es desarrollo y la operación es operación.
Nuestros clientes esperan diferentes cosas, pero todos esperan algún tipo de milagro, que tienen ciertas dificultades y ahora, ¡zas! — Kubernetes las resolverá. La gente cree en los milagros. Comprenden racionalmente que no habrá milagro, pero espiritualmente esperan — ¿y si este Kubernetes nos resuelve todo ahora, se habla tanto de él? ¿Y si ahora es un ¡achís! — y la bala de plata, un ¡achís! — y tenemos 100% de tiempo de actividad, todos los desarrolladores pueden lanzar lo que sea a producción 50 veces y no se cae? En resumen, ¡un milagro!
Cuando estas personas vienen a nosotros, decimos: «Lo siento, pero no hay milagros». Para estar sano, uno necesita comer bien y hacer ejercicio. Para tener una producción confiable, debe hacerse de manera confiable. Para tener un CI/CD conveniente, debe hacerse así. Es un gran trabajo que debe realizarse.
Al responder a la pregunta de quién necesita Kubernetes, Kubernetes no es necesario para nadie.
Algunas personas tienen la errónea sensación de que necesitan Kubernetes. La gente necesita, tiene una profunda necesidad de dejar de pensar, hacer y preocuparse por todos los problemas de infraestructura y de implementar sus aplicaciones. Quieren que las aplicaciones simplemente funcionen y se desplieguen. Para ellos, Kubernetes es la esperanza de que dejarán de escuchar historias como «estuvimos atascados» o «no podemos desplegar», o cualquier otra cosa.
Normalmente nos visita el director técnico. Se le preguntan dos cosas: por un lado, danos funciones, y por el otro, estabilidad. Proponemos que asumamos esto y lo hagamos. La bala de plata, o mejor dicho, la bala plateada, es que dejarás de pensar en estos problemas y de perder tiempo. Tendrás personas especializadas que se encargarán de este asunto.
La afirmación de que necesitamos Kubernetes, o que alguien lo necesita, es incorrecta.
Kubernetes es muy necesario para los administradores, porque es una herramienta realmente interesante con la que se puede jugar, experimentar. Seamos honestos: a todos nos gustan los juguetes. Todos seguimos siendo un poco niños, y cuando vemos algo nuevo, queremos jugar con ello. Algunas personas pueden haber perdido ese interés, como en la administración, porque ya han jugado lo suficiente y les ha aburrido hasta el punto de no quererlo más. Pero eso no significa que nadie lo haya perdido por completo. Por ejemplo, aunque me haya cansado de jugar con herramientas en el ámbito de la administración de sistemas y DevOps, sigo disfrutando de nuevos juguetes y sigo comprando algunos.
No se debe jugar con producción. Lo que recomiendo encarecidamente no hacer y lo que veo que sucede masivamente es: "Ah, un juguete nuevo!" – corren a comprarlo, lo adquieren y luego dicen: "Vamos a llevarlo a la escuela y mostrarlo a todos nuestros amigos". No hagan eso. Disculpen, mis hijos están creciendo, y constantemente veo cosas en ellos y las reconozco en mí mismo, y luego generalizo sobre los demás.
La respuesta definitiva: no necesitas Kubernetes. Necesitas resolver tus problemas.
Se puede lograr que:
- la producción no se caiga;
- incluso si intenta caerse, lo sabemos de antemano y podemos hacer algo al respecto;
- podemos cambiarlo a la velocidad que requerimos para el negocio y hacerlo de manera conveniente, sin que esto nos cause problemas.
Las verdaderas necesidades son dos: fiabilidad y dinamismo / flexibilidad en la implementación. Todos los que están haciendo proyectos de TI en este momento, sin importar en qué negocio – software para mejorar el mundo – y que lo entienden, deben resolver estas necesidades. Kubernetes, con el enfoque correcto, la comprensión adecuada y suficiente experiencia, permite resolverlas.
Sobre serverless
Si miramos un poco más adelante en el futuro, tratando de resolver la problemática de no tener dolores de cabeza con la infraestructura, la velocidad de implementación y el ritmo de cambio de la aplicación, surgen nuevas soluciones, como serverless. ¿Sientes algún potencial en esta dirección y, digamos, un peligro para Kubernetes y soluciones similares?
Dmitry: Aquí hay que hacer un apunte de nuevo, que no soy un vidente que mira hacia el futuro y dice: ¡será así! Aunque acabo de hacer lo mismo. Miro hacia abajo y veo un montón de problemas, por ejemplo, cómo funcionan los transistores en una computadora. Es casi cómico, ¿no? Nos enfrentamos a algunos errores en el CPU.
Hacer serverless es suficientemente fiable, barato, eficiente y cómodo, resolviendo todos los problemas del ecosistema. Aquí estoy de acuerdo con Elon Musk en que se necesita un segundo planeta para lograr la resiliencia para la humanidad. Aunque no sé lo que dice, entiendo que no estoy listo para volar a Marte y que eso no sucederá mañana.
Con serverless está claramente claro que es una cosa ideológicamente correcta, así como la resiliencia para la humanidad: tener dos planetas es mejor que uno. Pero, ¿cómo lograrlo ahora? Enviar una expedición no es un problema si se concentran los esfuerzos en ello. Enviar varias expediciones y colonizar allí a varios miles de personas, creo que también es realista. Pero lograr resiliencia total, de modo que la mitad de la humanidad viva allí, me parece actualmente imposible, algo que no se contempla.
Con serverless es lo mismo: es algo genial, pero está lejos de los problemas de 2019. Más cerca de 2030, vamos a vivir hasta entonces. No dudo que lleguemos, seguro que llegaremos (repítelo antes de dormir), pero ahora hay que resolver otros problemas. Es como creer en un poni mágico llamado Arcoíris. Sí, un par de casos se resuelven, y se resuelven muy bien, pero subjetivamente, serverless es un arcoíris... Para mí, este tema está demasiado lejos y demasiado confuso. No estoy listo para hablar. En 2019 no se puede escribir ninguna aplicación con serverless.
Cómo se desarrollará Kubernetes
— Mientras avanzamos hacia este potencialmente hermoso futuro lejano, ¿cómo crees que se desarrollará Kubernetes y el ecosistema que lo rodea?
Dmitry: He estado pensando mucho en esto y tengo una respuesta clara. Primero, para hacer algo statefull, realmente es más fácil hacerlo stateless. Kubernetes, desde el principio, ha invertido más en esto, fue de donde todo comenzó. Stateless funciona prácticamente a la perfección en Kubernetes, simplemente no hay nada de qué quejarse. En cuanto a statefull, todavía hay muchos problemas, es decir, matices. Todo ya funciona bien allí, pero eso somos nosotros. Para que esto funcione para todos, necesitará al menos un par de años más. Esto no es una estimación calculada, sino una intuición mía.
En resumen, statefull debe desarrollarse muy intensamente, y lo hará, porque todas nuestras aplicaciones almacenan estado, no existen aplicaciones stateless. Es una ilusión, siempre se necesita algún tipo de base de datos y algo más. Statefull es la optimización de todo lo que se puede, solucionando todos los errores, mejorando todos los problemas con los que nos enfrentamos actualmente, llamémoslo adopción.
El nivel de lo desconocido, el nivel de problemas no resueltos, el nivel de probabilidad de encontrarse con algo, caerá drásticamente. Esta es una historia importante. Y los operadores, todo lo relacionado con la codificación de la lógica de administración, la lógica de gestión, para obtener un servicio fácil: servicio fácil de MySQL, servicio fácil de RabbitMQ, servicio fácil de Memcache, en general, todos estos componentes que necesitamos para garantizar que funcionen directamente desde la caja. Esto realmente aborda esos problemas que queremos una base de datos, pero no queremos administrarla, o queremos Kubernetes, pero no queremos administrarlo.
Esta historia sobre el desarrollo de operadores en alguna medida será importante en los próximos años.
Creo que la simplicidad de explotación debería aumentar considerablemente: la caja se volverá cada vez más negra, cada vez más fiable, con controles cada vez más fáciles.
Una vez escuché una vieja entrevista a Isaac Asimov de los años 80 en YouTube en un programa llamado Saturday Night Live, un programa similar al de Urgant, pero mucho más interesante. Allí le preguntaban sobre el futuro de las computadoras. Dijo que el futuro residía en la simplicidad, tal como sucedió con el receptor de radio. El receptor de radio al principio era algo complejo. Para captar la señal, tenías que girar los controles durante 15 minutos, mover las perillas y, en general, saber cómo funcionaba todo, entender la física de la transmisión de ondas de radio. Al final, en la radio, solo quedó un control.
¿Qué radio hay ahora en 2019? En el coche, el receptor de radio encuentra todas las frecuencias, los nombres de las estaciones. La física del proceso no ha cambiado en 100 años, pero la facilidad de uso ha mejorado. En la actualidad, y no solo ahora, ya en 1980, cuando hubo una entrevista con Asimov, todos usaban la radio y nadie se preguntaba cómo funcionaba. Siempre funcionó, esa es la realidad.
Asimov decía entonces que con las computadoras será lo mismo— la facilidad de uso aumentará. Si en 1980 era necesario obtener una educación especializada para presionar botones en una computadora, en el futuro eso no será así.
Tengo la sensación de que con Kubernetes y la infraestructura también aumentará significativamente la facilidad de uso. Eso, en mi opinión, es obvio, está a la vista.
¿Qué pasará con los ingenieros?
— ¿Y qué sucederá con los ingenieros, los administradores de sistemas que mantienen Kubernetes?
Dmitry: ¿Qué pasó con los contadores después de la llegada de 1C? Algo similar. Antes se calculaba en papel; ahora, en un programa. La productividad del trabajo ha aumentado drásticamente, pero el trabajo en sí no ha desaparecido. Si antes se necesitaban 10 ingenieros para cambiar una bombilla, ahora con uno es suficiente.
La cantidad de software y de tareas, me parece, está creciendo a un ritmo mayor que la aparición de nuevos DevOps y el aumento de la eficiencia. Actualmente, hay una escasez concreta en el mercado que durará mucho tiempo. Más adelante, todo se normalizará, donde la eficiencia del trabajo aumentará, habrá más opciones sin servidor, se integrará una red neuronal con Kubernetes que ajustará todos los recursos exactamente como se necesita, y todo funcionará por sí mismo, como debe ser; el ser humano debe apartarse y no interferir.
Pero aún habrá decisiones que alguien deberá tomar. Está claro que el nivel de calificación y especialización de esa persona será más alto. Actualmente, en el departamento de contabilidad no necesitas 10 empleados que lleven libros de contabilidad para que sus brazos no se cansen. Simplemente no es necesario. Muchos documentos se escanean automáticamente y son reconocidos por el sistema de gestión documental electrónica. Solo se necesita un contador jefe inteligente, ya con habilidades mucho más avanzadas y un buen entendimiento.
En general, este camino es común en todas las industrias. Con los automóviles sucede lo mismo: antes se requería un mecánico y tres conductores. Ahora, conducir un automóvil es un proceso sencillo en el que todos participamos a diario. Nadie piensa en que un automóvil es algo complejo.
DevOps o la ingeniería de sistemas no van a desaparecer; la alta capacidad y la eficiencia del trabajo seguirán aumentando.
— He oído una idea interesante, que en realidad también aumentará el trabajo.
Dmitry: ¡Por supuesto, un cien por ciento! Porque la cantidad de software que escribimos está en constante crecimiento. La cantidad de problemas que resolvemos con software sigue creciendo. La cantidad de trabajo está aumentando. Ahora, el mercado de DevOps está extremadamente sobrecalentado. Esto se refleja en las expectativas salariales. En términos generales, sin entrar en detalles, debe haber junior que quieran X, intermedios que quieran 1.5X, y seniors que quieran 2X. Y ahora, si miramos el mercado salarial de DevOps en Moscú, un junior quiere entre X y 3X y un senior quiere entre X y 3X.
Nadie sabe cuánto cuesta. El nivel salarial está determinado por tu confianza: es un completo caos, para ser honesto, el mercado está muy sobrecalentado.
Por supuesto, esta situación cambiará muy pronto; debería haber cierta saturación. Con el desarrollo de software no es así: a pesar de que todos necesitan desarrolladores y necesitan buenos desarrolladores, el mercado entiende cuánto vale cada uno, la industria se ha estabilizado. Con DevOps, no es así ahora.
— De lo que he escuchado, llegué a la conclusión de que el actual administrador de sistemas no debería preocuparse demasiado, pero es hora de mejorar las habilidades y prepararse para que mañana habrá más trabajo, pero será más especializado.
Dmitry: Absolutamente. En general, estamos viviendo en 2019 y la regla de vida es: el aprendizaje continuo — aprendemos toda la vida. Creo que ahora ya todos lo saben y lo sienten, pero saber poco no es suficiente, hay que actuar. Cada día debemos cambiar. Si no lo hacemos, tarde o temprano seremos descartados en la orilla de la profesión.
Prepárate para giros bruscos de 180 grados. No descarto situaciones donde algo cambie radicalmente, se invente algo nuevo — eso sucede. ¡Hop! — y ahora actuamos de manera diferente. Es importante estar preparado para esto y no preocuparse demasiado. Puede suceder que mañana todo lo que haga se vuelva innecesario — no hay problema, he estado aprendiendo toda mi vida y estoy listo para aprender algo nuevo. No hay que tener miedo a la seguridad laboral, pero hay que estar dispuesto a aprender constantemente algo nuevo.
Deseos y un momento de publicidad
— ¿Tienes algún deseo?
Dmitry: Sí, tengo varios deseos.
El primero, y materialista, es que te suscribas a . Estimados lectores, ingresen a YouTube y suscríbanse a nuestro canal. En aproximadamente un mes comenzaremos una activa expansión en el servicio de video, tendrá un montón de contenido educativo sobre Kubernetes, abierto y variado: desde cosas prácticas, hasta laboratorios, hasta principios teóricos profundos y cómo aplicar Kubernetes a nivel de principios y patrones.
El segundo deseo materialista es que entren a y nos den estrellas, porque nos alimentamos de ellas. Si no nos dan estrellas, no tendremos qué comer. Es como el maná en un videojuego. Hacemos algo, intentamos, algunos dicen que son bicicletas horribles, otros que todo está mal, y nosotros seguimos actuando de manera completamente honesta. Vemos un problema, lo resolvemos y compartimos la experiencia. Por lo tanto, denos una estrella, no les costará nada, y a nosotros nos beneficiará, porque de eso nos alimentamos.
El tercero, importante y ya no materialista, es dejen de creer en cuentos. Ustedes son profesionales. DevOps es una profesión muy seria y responsable. Dejen de jugar en el lugar de trabajo. Que se ilumine su entendimiento y lo comprendan. Imaginen que llegan a un hospital, y allí un doctor experimenta con ustedes. Entiendo que esto puede ofender a algunos, pero probablemente no se refiera a ustedes, sino a otra persona. Digan a los demás que también dejen de hacerlo. Realmente esto arruina la vida de todos nosotros — muchos comienzan a ver a los operadores, a los administradores y a los DevOps como chicos que nuevamente rompieron algo. Este
Eso no significa que no se deban hacer experimentos. Hay que experimentar, nosotros mismos lo hacemos. Siendo sinceros, a veces también jugamos, lo cual es, por supuesto, muy malo, pero nada humano nos es ajeno. Declaremos el año 2019 como el año de experimentos serios y reflexivos, y no de juegos en producción. Probablemente, así sea.
¡Muchas gracias!
Dmitry: Gracias a ti, Vitaliy, tanto por tu tiempo como por la entrevista. Queridos lectores, muchas gracias a ustedes si han llegado hasta este momento. Espero que al menos les hayamos traído un par de ideas.
En la entrevista, Dmitry tocó el tema de werf. Actualmente, es un cuchillo suizo universal que resuelve casi todas las tareas. Pero no siempre fue así. En el festival Dmitry Stolyarov hablará de esta herramienta en detalle. En su presentación, habrá todo: problemas y matices ocultos de Kubernetes, opciones para resolver estas dificultades y la implementación actual de werf en detalle. Únanse el 27 y 28 de mayo, estaremos creando herramientas ideales.
Fuente: habr.com
