El fundador y director de «Otomato Software», uno de los iniciadores e instructores de la primera certificación DevOps en Israel, Anton Weiss, habló el año pasado sobre la teoría del caos y los principios fundamentales de la ingeniería del caos, así como explicó cómo debería ser la organización DevOps ideal del futuro.
Hemos preparado una versión escrita de la charla.
¡Buenos días!
DevOpsDays en Moscú por segundo año consecutivo, estoy de nuevo en este escenario, muchos de ustedes están por segunda vez en esta sala. ¿Y qué significa esto? Significa que el movimiento DevOps en Rusia está creciendo, multiplicándose, y lo más importante, significa que ha llegado el momento de hablar sobre qué es DevOps en 2018.
Levante la mano quienes piensan que en 2018 DevOps ya es una profesión. ¿Hay algunos? ¿Hay en la sala ingenieros DevOps que tengan «ingeniero DevOps» en su descripción del puesto? ¿Hay en la sala gerentes DevOps? No hay. ¿Arquitectos DevOps? Tampoco. Muy pocos. ¿De verdad nadie tiene escrito que es ingeniero DevOps?
Entonces, la mayoría de ustedes piensa que esto es un antipatrón. ¿Que esta profesión no debería existir? Podemos pensar lo que queramos, pero mientras pensamos, la industria avanza triunfalmente al son de la trompeta DevOps.
¿Quién ha oído hablar de un nuevo tema llamado DevDevOps? Es una nueva metodología que permite garantizar una colaboración efectiva entre desarrolladores y DevOps. Y no tan nueva. Si se juzga por Twitter, hace 4 años ya se había comenzado a hablar de esto. Y el interés sigue creciendo, lo que indica que existe un problema. Hay que resolver el problema.
Somos personas creativas, no nos conformamos tan fácilmente. Decimos: DevOps es una palabra poco abarcadora, hay muchas cosas interesantes que faltan. Vamos a nuestros laboratorios secretos y comenzamos a crear curiosas mutaciones: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La lógica es contundente, ¿no? Nuestro sistema de entrega no es funcional, nuestros sistemas son inestables y los usuarios están descontentos, no logramos lanzar el software a tiempo, no nos ajustamos al presupuesto. ¿Cómo resolveremos todo esto? ¡Inventaremos una nueva palabra! ¡Terminará en «Ops» y el problema estará resuelto!
Así es como llamo a este enfoque: «Ops, y el problema está resuelto».
Todo esto queda en segundo plano si nos recordamos por qué inventamos todo esto. Inventamos toda esta metodología DevOps para que la entrega de software y nuestro trabajo en este proceso sean lo más fluido, indoloro, eficiente y, sobre todo, placentero posible.
DevOps surgió del dolor. Y nos cansamos de sufrir. Para que esto suceda, nos basamos en prácticas atemporales: cooperación efectiva, prácticas de flujo y, lo más importante, pensamiento sistémico, porque sin él, no hay DevOps que funcione.
¿Qué es un sistema?
Y dado que estamos hablando de pensamiento sistémico, recordemos qué es un sistema.
Si eres un hacker revolucionario, para ti un sistema es un mal absoluto. Es una nube que se cierne sobre ti y te obliga a hacer cosas que no quieres hacer.
Desde la perspectiva del pensamiento sistémico, un sistema es un todo compuesto de partes. En este sentido, cada uno de nosotros es un sistema. Las organizaciones en las que trabajamos son sistemas. Y lo que construimos juntos se llama sistema.
Todo esto es parte de un gran sistema sociotecnológico. Y solo si entendemos cómo funciona este sistema sociotecnológico en conjunto, podremos optimizar realmente algo en este asunto.
Desde la perspectiva del pensamiento sistémico, un sistema tiene diferentes propiedades interesantes. En primer lugar, está compuesto de partes, lo que significa que su comportamiento depende del comportamiento de las partes. Además, todas sus partes son interdependientes. Por lo tanto, cuanto más partes tenga un sistema, más difícil será entender o predecir su comportamiento.
Desde la perspectiva del comportamiento, hay otro hecho interesante. Un sistema puede hacer algo que ninguna de sus partes individuales puede hacer.
Como decía el Dr. Russell Ackoff (uno de los fundadores del pensamiento sistémico), esto es bastante fácil de probar mediante un experimento mental. Por ejemplo, ¿quién en la sala sabe escribir código? Muchas manos, y eso es normal, porque es uno de los requisitos fundamentales de nuestra profesión. Tú puedes escribir, pero ¿tus manos, por separado de ti, pueden escribir código? Hay quienes dirán: 'No son mis manos las que escriben código, es mi cerebro el que escribe código'. ¿Y puede el cerebro, por separado de ti, escribir código? Bueno, probablemente no.
El cerebro es una máquina increíble; ni siquiera conocemos el 10% de cómo funciona, pero no puede operar de manera independiente del sistema que es nuestro organismo. Y esto se puede demostrar fácilmente: ábrete el cráneo, saca el cerebro y ponlo frente a una computadora para que intente escribir algo simple. "Hola, mundo" en Python, por ejemplo.
Si un sistema puede hacer algo que ninguna de sus partes por separado puede hacer, significa que su comportamiento no está determinado por el comportamiento de sus partes. ¿Entonces, por qué está determinado? Se determina por las interacciones entre estas partes. Por lo tanto, cuanto más partes hay, más complejas son las interacciones, y más difícil es comprender y prever el comportamiento del sistema. Esto hace que dicho sistema sea caótico, porque cualquier cambio, por insignificante que sea y a simple vista imperceptible, en cualquiera de las partes del sistema puede llevar a resultados completamente impredecibles.
Esta sensibilidad a las condiciones iniciales fue descubierta e investigada por primera vez por el meteorólogo estadounidense Ed Lorenz. Posteriormente, recibió el nombre de "efecto mariposa" y condujo al desarrollo de una corriente de pensamiento científico que se llama "teoría del caos". Esta teoría se convirtió en uno de los principales cambios de paradigma en la ciencia del siglo XX.
Teoría del caos
Las personas que estudian el caos se llaman a sí mismas caulogos.
La verdadera razón de esta charla es que, al trabajar con sistemas distribuidos complejos y grandes organizaciones internacionales, en algún momento me di cuenta de que esto es lo que siento ser. Soy un caulogo. En general, es una forma ingeniosa de decir: "No entiendo qué está sucediendo aquí y no sé qué hacer con ello".
Creo que muchos de ustedes también se sienten así a menudo, así que también son caulogos. Los sistemas que nosotros, queridos colegas caulogos, vamos a estudiar se llaman "sistemas adaptativos complejos".
¿Qué es la adaptabilidad? La adaptabilidad significa que el comportamiento individual y colectivo de las partes en un sistema adaptativo cambia y se autoorganiza, reaccionando a eventos o cadenas de microeventos en el sistema. Es decir, el sistema se adapta a los cambios a través de la autoorganización. Y esta capacidad de autoorganización se basa en la cooperación voluntaria y completamente descentralizada de agentes autónomos libres.
Otra propiedad interesante de tales sistemas es que son escalables de forma flexible. Esto debería interesarnos indudablemente como ingenieros del caos. Así que, si hemos dicho que el comportamiento de un sistema complejo está determinado por la interacción de sus partes, ¿qué debe interesarnos? La interacción.
Hay otras dos conclusiones interesantes.
Primero, entendemos que no se puede simplificar un sistema complejo simplificando sus partes. En segundo lugar, la única forma de simplificar un sistema complejo es a través de la simplificación de las interacciones entre sus partes.
¿Cómo interactuamos? Todos nosotros somos partes de un gran sistema de información llamado sociedad humana. Interactuamos a través de un lenguaje común, si lo tenemos, si lo encontramos.
Pero el lenguaje por sí mismo es un sistema adaptativo complejo. Por lo tanto, para interactuar de manera más efectiva y sencilla, necesitamos crear ciertos protocolos. Es decir, alguna secuencia de símbolos y acciones que haga el intercambio de información entre nosotros más simple, más predecible, más claro.
Quiero decir que las tendencias hacia la complejidad, la adaptabilidad, la descentralización y el caos se observan en todo. Tanto en los sistemas que construimos como en aquellos de los que somos parte.
Y para no quedarme en palabras, veamos cómo cambian los sistemas que creamos.
Sabía que esperaban esta palabra. Estamos en la conferencia de DevOps, hoy esta palabra será pronunciada unas cien mil veces y luego soñaremos con ella por la noche.
Microservicios: la primera arquitectura de software que surgió como respuesta a las prácticas de DevOps, destinada a hacer nuestros sistemas más flexibles, más escalables y a asegurar una entrega continua. ¿Cómo lo logra? Mediante la reducción de la cantidad de servicios, la simplificación de los límites de los problemas que estos servicios manejan y la disminución del tiempo de entrega. Es decir, disminuimos y simplificamos partes del sistema, aumentando su cantidad, lo que, a su vez, incrementa la complejidad de las interacciones entre estas partes, lo que genera nuevos problemas que debemos resolver.
Los microservicios no son el final; son, en realidad, un vestigio del pasado, porque llega Serverless. Todos los servidores se han quemado, no hay servidores, no hay sistemas operativos, solo código ejecutable puro. Las configuraciones son separadas, los estados son separados, todo se gestiona mediante eventos. Belleza, limpieza, silencio; no hay eventos, nada sucede, todo en orden.
¿Dónde está la complejidad? La complejidad, por supuesto, reside en las interacciones. ¿Cuánto puede hacer una función por sí sola? ¿Cómo interactúa con otras funciones? Colas de mensajes, bases de datos, balanceadores. ¿Cómo recrear un evento cuando ocurre una falla? Muchas preguntas y pocas respuestas.
Los microservicios y Serverless son todo lo que nosotros, los hipsters de la computación, llamamos Cloud Native. Todo se trata de la nube. Pero la nube, en esencia, también es limitada en cuanto a escalabilidad. Estamos acostumbrados a verla como un sistema distribuido. Sin embargo, ¿dónde viven los servidores de los proveedores de nube? En los centros de datos. Es decir, aquí tenemos un modelo distribuido, pero muy centralizado y limitado.
Hoy entendemos que el Internet de las cosas ya no son solo palabras grandilocuentes, porque según pronósticos modestos, en los próximos cinco a diez años habrá miles de millones de dispositivos conectados a Internet. Un enorme volumen de datos útiles e inútiles que se volcarán en la nube y se descargarán de la nube.
La nube no podrá soportarlo, por lo que hablamos cada vez más de lo que se llama 'computación perimetral'. O también me gusta la maravillosa definición de 'fog computing'. Está envuelto en la mística del romanticismo y el misterio.
Computación nebulosa. Se trata de que las nubes son agrupaciones centralizadas de agua, vapor, hielo y piedras. Y la niebla son gotas de agua dispersas a nuestro alrededor en la atmósfera.
En la paradoja de la niebla, la mayor parte del trabajo es realizado por estas gotas de manera completamente autónoma o en colaboración con otras gotas. Y solo se dirigen a la nube cuando realmente es necesario.
Es decir, de nuevo descentralización, autonomía, y, por supuesto, muchos de ustedes ya comprenden hacia dónde va todo esto, porque no se puede hablar de descentralización sin mencionar la blockchain.
Hay quienes creen, esos son los que invirtieron en criptomonedas. Hay quienes creen, pero tienen miedo, como yo, por ejemplo. Y hay quienes no creen. Se puede tener diversas opiniones al respecto. Hay una tecnología, un nuevo asunto incomprensible, hay problemas. Como cualquier nueva tecnología, plantea más preguntas de las que ofrece respuestas.
El hype alrededor de la blockchain es comprensible. Incluso dejando de lado la fiebre del oro, la propia tecnología promete un futuro brillante: más libertad, más autonomía, confianza global distribuida. ¿Qué es lo que no se puede querer?
Así, cada vez más ingenieros en todo el mundo comienzan a desarrollar aplicaciones descentralizadas. Y esta es una fuerza de la que no se puede desentender simplemente diciendo: "Ahh, la blockchain es solo una base de datos distribuida mal implementada". O como les gusta decir a los escépticos: "No hay aplicaciones reales para la blockchain". Si lo piensas, hace 150 años decían lo mismo sobre la electricidad. E incluso en cierto modo tenían razón, porque lo que la electricidad hace posible hoy en día, era completamente irreal en el siglo XIX.
Por cierto, ¿quién sabe qué logo está en la pantalla? Es Hyperledger. Es un proyecto que se desarrolla bajo la égida de The Linux Foundation, que incluye un conjunto de tecnologías blockchain. Esta es verdaderamente la fuerza de nuestra comunidad de código abierto.
Ingeniería caótica
Así que, el sistema que estamos desarrollando se vuelve cada vez más complejo, más caótico, más adaptable. Netflix es pionera en sistemas de microservicios. Fueron uno de los primeros en entenderlo, desarrollaron un conjunto de herramientas que llamaron Simian Army, de las cuales la más famosa es . Definió lo que se conoció como .
Por cierto, mientras trabajábamos en la presentación, incluso tradujimos este texto al español, así que puedes entrar por , lee, comenta, critica.
En resumen, los principios de la ingeniería del caos afirman lo siguiente. Los sistemas distribuidos complejos son, por su naturaleza, impredecibles, y fundamentalmente contienen errores. Los errores son inevitables, lo que significa que debemos aceptar estos errores y trabajar con estos sistemas de una manera completamente diferente.
Debemos intentar introducir estos errores en nuestros sistemas de producción, para probar nuestra capacidad de adaptación, nuestra capacidad de autoorganización y de supervivencia.
Y esto lo cambia todo. No solo la forma en que lanzamos el sistema en producción, sino también cómo los desarrollamos y los probamos. No hay ningún proceso de estabilización, de congelamiento del código; por el contrario, hay un proceso constante de desestabilización. Intentamos destruir el sistema y ver que sigue sobreviviendo.
Protocolos de Integración de Sistemas Distribuidos
Por lo tanto, esto requiere que nuestros sistemas también cambien de alguna manera. Para volverse más resilientes, necesitan nuevos protocolos de interacción entre sus partes. Para que estas partes puedan comunicarse y alcanzar cierta autoorganización. Surgen diversas herramientas nuevas, nuevos protocolos que llamo «protocolos de interacción de sistemas distribuidos».
¿De qué hablo? Primero, el proyecto . Un intento de crear un protocolo común de seguimiento distribuido, que es una herramienta absolutamente indispensable para depurar sistemas distribuidos complejos.
A continuación — . Decimos que no podemos predecir lo que sucederá con el sistema, es decir, necesitamos aumentar su observabilidad. Opentracing pertenece a la familia de herramientas que brindan observabilidad a nuestros sistemas. Pero necesitamos observabilidad para determinar si el sistema se comporta como esperamos o no. ¿Cómo podemos determinar el comportamiento esperado? A través de definir en él alguna política, un conjunto de reglas. El proyecto Open Policy Agent se ocupa de definir este conjunto de reglas en una amplia gama: desde el acceso hasta la ubicación de recursos.
Como hemos mencionado, nuestros sistemas están cada vez más orientados a eventos. Serverless es un excelente ejemplo de sistemas basados en eventos. Para poder transmitir eventos entre sistemas y rastrearlos, necesitamos un lenguaje común, un protocolo común sobre cómo hablamos de los eventos y cómo nos los transmitimos. Esto es lo que aborda el proyecto llamado .
Un flujo continuo de cambios que inunda nuestros sistemas, desestabilizándolos constantemente, es un flujo constante de artefactos de software. Para poder mantener este flujo constante de cambios, necesitamos un protocolo común que nos permita hablar sobre qué es un artefacto de software, cómo ha sido verificado, qué verificación ha pasado. Esto es lo que aborda el proyecto llamado . Es decir, un protocolo común de metadatos de artefactos de software.
Y, por último, si queremos que nuestros sistemas sean completamente autónomos, adaptativos y se autorregulen, debemos darles derecho a la autoidentificación. El proyecto llamado es precisamente de lo que se encarga. Este también es un proyecto bajo la égida de la Cloud Native Computing Foundation.
Todos estos proyectos son jóvenes, necesitan nuestro apoyo, nuestra revisión. Todo es código abierto, nuestras pruebas, nuestra implementación. Nos muestran hacia dónde se dirige la tecnología.
Pero DevOps nunca ha sido principalmente sobre tecnología, siempre ha sido sobre la colaboración entre las personas. Y, por tanto, si queremos que los sistemas que estamos desarrollando cambien, debemos cambiar nosotros mismos. En realidad, ya estamos cambiando, no tenemos mucha opción.
Hay una maravillosa autora británica, Rachel Botsman, que escribe sobre la evolución de la confianza a lo largo de la historia humana. Ella dice que originalmente, en sociedades primitivas, la confianza era local, es decir, confiábamos solo en aquellos que conocíamos personalmente.
Luego hubo un largo período —un tiempo oscuro— cuando la confianza se volvió centralizada, cuando comenzamos a confiar en personas que no conocíamos basándonos en el hecho de que pertenecíamos a la misma institución social o estatal.
Y esto es lo que vemos en nuestro mundo moderno: la confianza se está volviendo cada vez más distribuida y descentralizada, y se basa en la libertad de los flujos de información y en la accesibilidad de la información.
Si lo piensas, esta misma accesibilidad, que hace posible esta confianza, es algo que estamos implementando. Esto significa que debe cambiar la forma en que colaboramos y cómo lo hacemos, porque las organizaciones de TI jerárquicas y centralizadas del viejo estilo están dejando de funcionar. Comienzan a desvanecerse.
Fundamentos de una organización DevOps
La organización DevOps perfecta del futuro es un sistema descentralizado y adaptativo, compuesto por equipos autónomos, cada uno formado por individuos autónomos. Estos equipos están esparcidos por todo el mundo, colaborando de manera efectiva entre sí a través de comunicación asincrónica y protocolos de intercambio de información muy transparentes. Muy bonito, ¿verdad? Un futuro muy hermoso.
Por supuesto, todo esto es imposible sin cambios culturales. Necesitamos liderazgo transformacional, responsabilidad personal y motivación interna.
Esta es la base de las organizaciones DevOps: transparencia de la información, comunicación asincrónica, liderazgo transformacional, descentralización.
Burnout
Los sistemas de los que formamos parte, y aquellos que construimos, son cada vez más caóticos, y nos resulta difícil aceptar esta realidad, difícil renunciar a la ilusión de control. Intentamos seguir controlándolos, y esto a menudo conduce al burnout. Hablo desde mi propia experiencia; yo también me he quemado, también soy una víctima de fallos inesperados en producción.
El burnout ocurre cuando intentamos controlar lo que, por su propia naturaleza, no es controlable. Cuando nos quemamos, todo pierde sentido, porque perdemos el deseo de crear algo nuevo, nos posicionamos a la defensiva y comenzamos a proteger lo que tenemos.
La profesión de ingeniero, como me gusta recordarme a menudo, es, ante todo, una profesión creativa. Si perdemos el deseo de crear algo, nos convertimos en cenizas, en polvo. Las personas se queman, las organizaciones enteras se queman.
En mi opinión, solo aceptar el poder creativo del caos, solo construir la colaboración sobre sus principios, es lo que nos ayudará a no perder lo bueno que hay en nuestra profesión.
Eso es lo que les deseo: amar su trabajo, amar lo que hacemos. Este mundo se alimenta de información, y tenemos el honor de alimentarlo. Así que vamos a estudiar el caos, seamos caologistas, aportemos valor, creemos algo nuevo, y cuando aparezcan los problemas, como ya hemos descubierto, serán inevitables. Cuando lleguen, simplemente diremos '¡Ops!', y el problema estará resuelto.
¿Qué hay más allá de Chaos Monkey?
En realidad, todas estas herramientas son muy nuevas. Los mismos Netflix construyeron herramientas para ellos mismos. Construyan herramientas para ustedes mismos. Lean los principios de la ingeniería del caos y adhieran a esos principios, en lugar de buscar otras herramientas que alguien más ya ha construido.
Traten de entender cómo fallan sus sistemas y empiecen a romperlos para observar cómo resisten los golpes. Esto es lo primero. Las herramientas se pueden buscar. Hay muchos proyectos disponibles.
No entendí del todo el momento en que mencionaste que no se puede simplificar un sistema simplificando sus componentes, y de inmediato pasaste a los microservicios, que justo simplifican el sistema al simplificar los componentes y complicar las interacciones. Es, esencialmente, dos partes que se contradicen entre sí.
Es cierto, los microservicios son un tema muy controvertido en general. De hecho, simplificar partes aumenta la flexibilidad. ¿Qué nos brindan los microservicios? Nos ofrecen flexibilidad y velocidad, pero para nada nos brindan simplicidad. Aumentan la complejidad.
Entonces, ¿en la filosofía DevOps, los microservicios no son una bendición?
Cualquier bendición tiene su reverso. Hay una bendición: aumenta la flexibilidad, nos permite hacer cambios más rápido, pero también aumenta la complejidad y, por ende, la fragilidad de todo el sistema.
¿En qué se pone más énfasis: en simplificar la interacción o en simplificar las partes?
El enfoque está, sin duda, en simplificar la interacción, porque si lo miramos desde la perspectiva de cómo trabajamos juntos, primero debemos prestar atención a simplificar las interacciones, no a simplificar el trabajo de cada uno de nosotros por separado. Porque simplificar el trabajo significa convertirnos en robots. Eso funciona bien en McDonald's, donde tienes instrucciones: aquí pones la hamburguesa, aquí le echas la salsa. Eso no funciona en nuestro trabajo creativo en absoluto.
¿Es cierto que todo lo que has mencionado vive en un mundo sin competencia, donde el caos es amable y no hay contradicciones dentro de ese caos, nadie quiere devorar o matar a nadie? ¿Cómo deberían coexistir la competencia y DevOps?
Bueno, depende de qué tipo de competencia estamos hablando. ¿De la competencia en el lugar de trabajo o de la competencia entre empresas?
De la competencia de los servicios que existen, porque los servicios no son solo unas pocas empresas. Creamos un nuevo tipo de entorno informativo, y cualquier entorno no puede existir sin competencia. La competencia está en todas partes.
Tomemos a Netflix como modelo de referencia. ¿Por qué lo hicieron? Porque necesitaban ser competitivos. Esa flexibilidad y rapidez en el movimiento son precisamente ese requisito competitivo que introduce caos en nuestros sistemas. Así que el caos no es algo que hagamos conscientemente porque lo deseamos, es algo que ocurre porque el mundo lo exige. Simplemente tenemos que adaptarnos. Y el caos, en realidad, es el resultado de la competencia.
¿Significa esto que el caos es la ausencia de objetivos, o son esos objetivos que no queremos ver? Estamos en nuestra casa sin entender los objetivos de los demás. La competencia, de hecho, se basa en el hecho de que tenemos objetivos claros y sabemos a dónde llegaremos en cada momento del tiempo. Desde mi point de vista, esa es la esencia de DevOps.
También es una perspectiva sobre la cuestión. Creo que todos tenemos un mismo objetivo: sobrevivir y hacerlo con
el mayor placer posible. Y el objetivo competitivo de cualquier organización es el mismo. La supervivencia a menudo ocurre en la lucha competitiva, no hay nada que hacer al respecto.
Este año la conferencia se llevará a cabo el 7 de diciembre en 'Technopolis'. Aceptamos propuestas para conferencias hasta el 11 de noviembre. si desea dar una charla.
La inscripción para los participantes está abierta, el boleto cuesta 7000 rublos. ¡Únete!
Fuente: habr.com
