Entrevista con Alexander Titov, uno de los miembros del comité del programa de nuestra
conferencia de junio HighLoad ++ , una sección separada de la cual estará dedicada a DevOps.
Bajo el corte sobre qué dirección sopla el "viento" de DevOps, y qué aspectos exactos de este concepto se discutirán en el foro.
Alexander es bastante familiar para nuestra comunidad, es el organizador de DevOps Moscow y la conferencia DevOpsDays Moscow, ha estado hablando en nuestros eventos durante varios años y ayuda en la formación de sus programas. Actualmente es socio gerente en Express 42, que desarrolla DevOps en empresas de tecnología. Anteriormente, de 2010 a 2012, Alexander atravesó una fascinante ruta de adquisición con Qik, desde operar una startup de rápido crecimiento hasta operar en una gran empresa internacional Microsoft. Antes de eso, en 2009-2010, fue director técnico del primer alojamiento en la nube en Rusia, Skalaxi.- Comencemos desde lejos: ¿está evolucionando la cultura DevOps? ¿Qué cambios se han observado en esta área en los últimos años? ¿Y cómo se ve DevOps en Rusia?Por supuesto, en un mundo donde la tecnología se cambia entre sí cada tres años, todo cambia constantemente y mucho. Inicialmente, el problema básico era la producción y el funcionamiento del propio software en la era digital. En torno a este problema, el movimiento DevOps se ha reunido. Ahora, el problema básico se ha dividido en muchas subcategorías: administración de infraestructura, monitoreo, integración continua, entrega continua, trabajo con personas (en particular, el problema del agotamiento de las personas que se dedican tanto a la explotación como al desarrollo), algunas cosas tecnológicas (por ejemplo, la aparición de Kubernetes, como dicho estándar de facto para toda la plataforma de infraestructura en las empresas). Es decir, en muchos aspectos, aparecieron detalles específicos: pasamos por la etapa de comprender lo que se debe hacer de manera diferente que antes, probamos muchos enfoques nuevos y llegamos a la formación de algunos procesos estandarizados para resolver problemas comunes (típicos). Pero al mismo tiempo, las herramientas y los procesos en muchas empresas de todo el mundo siguen siendo de baja calidad o muy poco formalizados.
En el contexto ruso, un problema adicional es que no entendemos por qué todo esto es necesario. Esto desorienta a muchos. Tenemos desarrollo, pruebas y operación por separado, y luego algunos Kubernetes entran para resolver algunos problemas, pero intentan implementarlo sin cambiar los procesos, enfoques y competencias de las personas. Todo se rompe. Y por qué estas nuevas tecnologías no son claras.
- ¿Y cuál es la razón de una transformación tan radical?Como ya mencioné, comenzamos a resolver otro problema. Inicialmente, la TI clásica resolvió el problema de automatizar los procesos comerciales dentro de una corporación. Toda la infraestructura se ajustó a esto: bases de datos, autobuses, etc. Desde 2000, después de la crisis de las puntocom, TI ha cambiado a la creación de productos digitales que pueden proporcionar servicios personalizados de forma masiva, entregando algo de valor. Si antes la compañía producía cierto modelo de automóvil, ahora se ha cambiado a la personalización para cada cliente. Esta es una solución a otro problema, para el cual se necesitan enfoques y tecnologías fundamentalmente diferentes: un proceso de producción de software diferente. Aquí ya no es posible realizar el desarrollo, las pruebas y la operación de forma secuencial. Ahora estos procesos comienzan simultáneamente.
Por cierto, a pesar de esto, hay una idea errónea de que DevOps se trata de la operación. Los administradores de sistemas clásicos que realizan trabajo operativo simplemente se renombran ingenieros de DevOps, desacreditando el término en principio. De hecho, el concepto es mucho más amplio. Este es un conjunto separado de prácticas, un marco separado que le permite resolver problemas específicos en ciertas condiciones y con personas de cierta competencia, ni más ni menos. Pocas personas entienden por qué esto es necesario. Y este es uno de los problemas que estamos tratando de resolver mediante conferencias.
-
¿Qué informes están planeados para enfocarse en las secciones dentro de Siberian HighLoad?Si antes había principalmente informes operativos, entonces este año queremos agregar más información sobre la conexión con el desarrollo, por ejemplo, sobre procesos de entrega continua, integración continua, pruebas. Un buen ejemplo es un informe de Maxim Lapshin en RIT ++ (como parte de Spring RootConf 2018) sobre cómo usar DevOps en el desarrollo de cajas. Dicha empresa básicamente no tiene explotación: fabrica una caja que vende a un cliente. Al mismo tiempo, ella tiene DevOps adentro. Este enfoque rompe el patrón, pero al mismo tiempo ayuda a desacreditar el mito mencionado de que DevOps solo se trata de la operación. Este es nuestro primer enfoque básico.
El segundo foco son las nuevas tecnologías. Ahora está de moda hablar de Kubernetes, Prometeo y otros. Y estamos buscando personas que hayan podido sentir estas tecnologías en la práctica. Es decir, no solo configurado y hecho funcionar, sino que también lo incluyó en su proceso de desarrollo. En general, tratamos de considerar todas las tecnologías bajo el prisma de cómo se incluyen en el proceso de producción de software: qué problema resuelven, qué objetivos se establecen, etc. Si no habla de esto, la gente comenzará a trabajar con la tecnología como un culto a la carga: "Vamos a poner Kubernetes y podemos hacer Google". No funcionará de esa manera.
- El concepto de integración continua ya está bien aceptado por el mercado. Además de herramientas específicas, ¿hay algo de qué hablar?Por supuesto El concepto básico, incluso se puede decir, crucial es que, en el contexto de DevOps, no se prueba la calidad de los productos dentro del proceso de integración continua. Es decir, no importa cuán funcionalmente maduro sea el producto. Es importante verificar qué tan bien comienza y si está listo para integrarse con otros componentes.
Este es un cambio importante, porque hay una integración continua en el desarrollo, operación y pruebas consistentes. Pero allí, en este nivel, se verifica la calidad del producto de acuerdo con los requisitos del usuario, y en el marco de DevOps, se verifican las cualidades funcionales. Es esta etapa la que permite la integración más rápida posible de servicios individuales dentro del marco de la infraestructura de microservicios (y DevOps en su conjunto no existe sin una arquitectura de microservicios).
- ¿Qué herramientas están en foco este año?En primer lugar, los ya mencionados Kubernetes. Apareció hace algún tiempo, pero solo recientemente llegó a la etapa en que se puede usar. Ahora puede ser utilizado por cualquier empresa que desarrolle un servicio digital actualizado, por ejemplo, que brinde servicios a través de sitios web o aplicaciones móviles.
A menudo denominado Prometheus, un sistema de monitoreo, GitLab, como un sistema de integración continua. Y también toda la pila de HashiCorp: Vault, Terraform (ambas desarrolladas por HashiCorp). Bueno, por supuesto, Docker, como formato de entrega.
- ¿Hay cambios recientes en el marco del concepto de "todo como un código"?La práctica de "todo como un código" en sí es obviamente útil. Este es uno de los principios fundamentales en los que se basa el proceso DevOps. Kubernetes simplemente continúa con esta ideología.
En DevOps, la historia principal es "infraestructura como código". Y este no es solo un concepto, sino también un proceso en el que todos los componentes se presentan en forma de código que permite que "piezas" individuales de infraestructura interactúen entre sí. No hay cambios drásticos aquí, pero, como práctica, ahora se está desarrollando dentro de Kubernetes. Por ejemplo, se desarrollan herramientas de gestión de dependencias como Helm, herramientas para crear módulos separados, descripciones de infraestructura, por ejemplo, operadores (y aparecen marcos para escribir declaraciones en Kubernetes), etc. En otras palabras, hay un desarrollo saludable del instrumento y la penetración de la práctica dentro de él.
- ¿Vale la pena hablar de la práctica de "todo como un código" separada del instrumento?Todavía no hemos formado completamente un programa, por lo que no puedo decir si vamos a plantear dichos temas específicamente en HighLoad ++. Pero esto en sí mismo es posible.
Existen muchos enfoques para organizar la infraestructura, administrar la dependencia dentro del código de infraestructura y probarlo. Por supuesto, hablaremos sobre conceptos para trabajar con la práctica; por ejemplo, ese código de infraestructura debe dividirse en módulos. Me parece que refinado, aislado de la práctica, tales temas no encajan muy bien. Pero, tal vez, elegiremos un informe donde se recopilarán todos los enfoques posibles dentro del marco de una única descripción del sistema. Sin embargo, es mucho más valioso cuando las personas cuentan y muestran cómo estos conceptos teóricos se realizan en la realidad. Sobre la teoría que subyace a las prácticas, puede hablar con las mismas personas al margen.
- Existe la opinión de que la popularidad de la arquitectura basada en eventos está creciendo con el tiempo. ¿Estás de acuerdo con esta afirmación?La infraestructura impulsada por eventos siempre ha sido parte del enfoque de las computadoras de escritorio: por evento, tomamos una decisión en el chat sobre lo que debería sucederle a una pieza de infraestructura. Esta historia es muy necesaria para las grandes empresas grandes, pero para el resto de la audiencia todavía no es del todo madura. Para tomar decisiones sobre lo que debería suceder (lo que deberíamos hacer), es necesario desarrollar un marco para las reglas dentro de los equipos sobre cómo tomamos estas decisiones, para que todos lo hagan más o menos de la misma manera: mire desde un lado. Y con esto, todo es complicado. El formato para desarrollar dicho marco es de lo que todos están hablando ahora: cómo se puede automatizar, llevar a una herramienta, cómo se debe hacer a nivel de creación de equipos y cómo coordinarse con diferentes equipos.
- ¿Se refleja esto de alguna manera en los informes de la conferencia?No, HighLoad ++ trata más sobre sistemas y herramientas altamente cargados, por lo que aquí podemos hablar sobre herramientas, pero no sobre el desarrollo de dicho marco. Pero en el otoño tendremos una conferencia RootConf separada, que se llevará a cabo del 1 al 2 de octubre. Hasta 2011, se dedicó a cuestiones operativas (es decir, solo un componente de todo el proceso "desarrollo-prueba-operación"). En 2015, lo reencarnamos en el contexto de todo DevOps, por lo que ampliamos gradualmente el tema. En RootConf discutimos cómo garantizar la interacción de los desarrolladores y los ingenieros de mantenimiento, hablamos sobre nuevos procesos y tecnologías, sobre plataformas de infraestructura y gestión de infraestructura, que en el paradigma DevOps no solo está involucrado en la operación, sino también en el desarrollo (simplemente realizan diferentes tareas).
- ¿Ha habido tecnologías interesantes para mejorar la resiliencia de los proyectos en los últimos años? ¿Serán discutidos en la conferencia?Hoy nos encontramos con una paradoja relacionada con el hecho de que "tolerancia a fallas" no significa "confiabilidad". La tolerancia a fallas ahora es reemplazada por la confiabilidad.
La tolerancia a fallas es un concepto del paradigma de los sistemas monolíticos, donde el problema de confiabilidad se resolvió mediante la duplicación, el aumento de recursos, etc. Ahora tales enfoques ya no funcionan. La fiabilidad se basa en enfoques fundamentalmente diferentes: implica la "antifragilidad" del sistema. Es decir, el sistema se vuelve "blando": si actuamos sobre él, cambia, no colapsa. En otras palabras, si va a construir algún tipo de servicio nuevo, debe proporcionar tales variantes de su comportamiento en las que si el usuario o el entorno en el que trabaja intentan destruirlo, entonces el servicio simplemente cambia sus propiedades, mientras que el servicio aún se proporciona , se da algún resultado.
Un buen marcador de la tendencia es la aparición de la ingeniería de confiabilidad del sitio como práctica y especialistas individuales: el ingeniero de confiabilidad del sitio (SRE) como reemplazo de la competencia pasada del administrador del sistema. Como ilustración de este proceso, mencionaré que Google lanzó su práctica de implementación de DevOps en forma de un libro sobre ingeniería de confiabilidad del sitio y está promoviendo activamente esta idea entre las masas.
También hablaremos de esto en RootConf. Ahora, este tema es exagerado en Occidente, y nosotros (por la comunidad DevOps de Moscú) estamos tratando de acercarnos gradualmente.