{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps y Caos: entrega de software en un mundo descentralizado","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El fundador y director de \u00abOtomato Software\u00bb, uno de los iniciadores e instructores de la primera certificaci\u00f3n DevOps en Israel, Anton Weiss, habl\u00f3 el a\u00f1o pasado DevOpsDays Mosc\u00fa<\/a><\/noindex> sobre la teor\u00eda del caos y los principios fundamentales de la ingenier\u00eda del caos, as\u00ed como explic\u00f3 c\u00f3mo deber\u00eda ser la organizaci\u00f3n DevOps ideal del futuro.<\/p>\n

Hemos preparado una versi\u00f3n escrita de la charla. <\/p>\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\n\u00a1Buenos d\u00edas! <\/p>\n

DevOpsDays en Mosc\u00fa por segundo a\u00f1o consecutivo, estoy de nuevo en este escenario, muchos de ustedes est\u00e1n por segunda vez en esta sala. \u00bfY qu\u00e9 significa esto? Significa que el movimiento DevOps en Rusia est\u00e1 creciendo, multiplic\u00e1ndose, y lo m\u00e1s importante, significa que ha llegado el momento de hablar sobre qu\u00e9 es DevOps en 2018. <\/p>\n

Levante la mano quienes piensan que en 2018 DevOps ya es una profesi\u00f3n. \u00bfHay algunos? \u00bfHay en la sala ingenieros DevOps que tengan \u00abingeniero DevOps\u00bb en su descripci\u00f3n del puesto? \u00bfHay en la sala gerentes DevOps? No hay. \u00bfArquitectos DevOps? Tampoco. Muy pocos. \u00bfDe verdad nadie tiene escrito que es ingeniero DevOps?<\/p>\n

Entonces, la mayor\u00eda de ustedes piensa que esto es un antipatr\u00f3n. \u00bfQue esta profesi\u00f3n no deber\u00eda existir? Podemos pensar lo que queramos, pero mientras pensamos, la industria avanza triunfalmente al son de la trompeta DevOps.<\/p>\n

\u00bfQui\u00e9n ha o\u00eddo hablar de un nuevo tema llamado DevDevOps? Es una nueva metodolog\u00eda que permite garantizar una colaboraci\u00f3n efectiva entre desarrolladores y DevOps. Y no tan nueva. Si se juzga por Twitter, hace 4 a\u00f1os ya se hab\u00eda comenzado a hablar de esto. Y el inter\u00e9s sigue creciendo, lo que indica que existe un problema. Hay que resolver el problema.<\/p>\n

\"DevOps
\n
\nSomos personas creativas, no nos conformamos tan f\u00e1cilmente. 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.<\/p>\n

\"DevOps
\n
\nLa l\u00f3gica es contundente, \u00bfno? Nuestro sistema de entrega no es funcional, nuestros sistemas son inestables y los usuarios est\u00e1n descontentos, no logramos lanzar el software a tiempo, no nos ajustamos al presupuesto. \u00bfC\u00f3mo resolveremos todo esto? \u00a1Inventaremos una nueva palabra! \u00a1Terminar\u00e1 en \u00abOps\u00bb y el problema estar\u00e1 resuelto!<\/p>\n

As\u00ed es como llamo a este enfoque: \u00abOps, y el problema est\u00e1 resuelto\u00bb.<\/p>\n

Todo esto queda en segundo plano si nos recordamos por qu\u00e9 inventamos todo esto. Inventamos toda esta metodolog\u00eda DevOps para que la entrega de software y nuestro trabajo en este proceso sean lo m\u00e1s fluido, indoloro, eficiente y, sobre todo, placentero posible. <\/p>\n

DevOps surgi\u00f3 del dolor. Y nos cansamos de sufrir. Para que esto suceda, nos basamos en pr\u00e1cticas atemporales: cooperaci\u00f3n efectiva, pr\u00e1cticas de flujo y, lo m\u00e1s importante, pensamiento sist\u00e9mico, porque sin \u00e9l, no hay DevOps que funcione.<\/p>\n

\u00bfQu\u00e9 es un sistema?<\/b><\/h3>\n

\nY dado que estamos hablando de pensamiento sist\u00e9mico, recordemos qu\u00e9 es un sistema.<\/p>\n

\"DevOps
\n
\nSi 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. <\/p>\n

\"DevOps
\n
\nDesde la perspectiva del pensamiento sist\u00e9mico, 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.<\/p>\n

Todo esto es parte de un gran sistema sociotecnol\u00f3gico. Y solo si entendemos c\u00f3mo funciona este sistema sociotecnol\u00f3gico en conjunto, podremos optimizar realmente algo en este asunto. <\/p>\n

Desde la perspectiva del pensamiento sist\u00e9mico, un sistema tiene diferentes propiedades interesantes. En primer lugar, est\u00e1 compuesto de partes, lo que significa que su comportamiento depende del comportamiento de las partes. Adem\u00e1s, todas sus partes son interdependientes. Por lo tanto, cuanto m\u00e1s partes tenga un sistema, m\u00e1s dif\u00edcil ser\u00e1 entender o predecir su comportamiento. <\/p>\n

Desde la perspectiva del comportamiento, hay otro hecho interesante. Un sistema puede hacer algo que ninguna de sus partes individuales puede hacer. <\/p>\n

Como dec\u00eda el Dr. Russell Ackoff (uno de los fundadores del pensamiento sist\u00e9mico), esto es bastante f\u00e1cil de probar mediante un experimento mental. Por ejemplo, \u00bfqui\u00e9n en la sala sabe escribir c\u00f3digo? Muchas manos, y eso es normal, porque es uno de los requisitos fundamentales de nuestra profesi\u00f3n. T\u00fa puedes escribir, pero \u00bftus manos, por separado de ti, pueden escribir c\u00f3digo? Hay quienes dir\u00e1n: 'No son mis manos las que escriben c\u00f3digo, es mi cerebro el que escribe c\u00f3digo'. \u00bfY puede el cerebro, por separado de ti, escribir c\u00f3digo? Bueno, probablemente no. <\/p>\n

El cerebro es una m\u00e1quina incre\u00edble; ni siquiera conocemos el 10% de c\u00f3mo funciona, pero no puede operar de manera independiente del sistema que es nuestro organismo. Y esto se puede demostrar f\u00e1cilmente: \u00e1brete el cr\u00e1neo, saca el cerebro y ponlo frente a una computadora para que intente escribir algo simple. \"Hola, mundo\" en Python, por ejemplo.<\/p>\n

Si un sistema puede hacer algo que ninguna de sus partes por separado puede hacer, significa que su comportamiento no est\u00e1 determinado por el comportamiento de sus partes. \u00bfEntonces, por qu\u00e9 est\u00e1 determinado? Se determina por las interacciones entre estas partes. Por lo tanto, cuanto m\u00e1s partes hay, m\u00e1s complejas son las interacciones, y m\u00e1s dif\u00edcil es comprender y prever el comportamiento del sistema. Esto hace que dicho sistema sea ca\u00f3tico, 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. <\/p>\n

Esta sensibilidad a las condiciones iniciales fue descubierta e investigada por primera vez por el meteor\u00f3logo estadounidense Ed Lorenz. Posteriormente, recibi\u00f3 el nombre de \"efecto mariposa\" y condujo al desarrollo de una corriente de pensamiento cient\u00edfico que se llama \"teor\u00eda del caos\". Esta teor\u00eda se convirti\u00f3 en uno de los principales cambios de paradigma en la ciencia del siglo XX.<\/p>\n

Teor\u00eda del caos<\/b><\/h3>\n

\nLas personas que estudian el caos se llaman a s\u00ed mismas caulogos.<\/p>\n

\"DevOps
\n
\nLa verdadera raz\u00f3n de esta charla es que, al trabajar con sistemas distribuidos complejos y grandes organizaciones internacionales, en alg\u00fan 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\u00e9 est\u00e1 sucediendo aqu\u00ed y no s\u00e9 qu\u00e9 hacer con ello\". <\/p>\n

Creo que muchos de ustedes tambi\u00e9n se sienten as\u00ed a menudo, as\u00ed que tambi\u00e9n son caulogos. Los sistemas que nosotros, queridos colegas caulogos, vamos a estudiar se llaman \"sistemas adaptativos complejos\". <\/p>\n

\u00bfQu\u00e9 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\u00e9s de la autoorganizaci\u00f3n. Y esta capacidad de autoorganizaci\u00f3n se basa en la cooperaci\u00f3n voluntaria y completamente descentralizada de agentes aut\u00f3nomos libres.<\/p>\n

Otra propiedad interesante de tales sistemas es que son escalables de forma flexible. Esto deber\u00eda interesarnos indudablemente como ingenieros del caos. As\u00ed que, si hemos dicho que el comportamiento de un sistema complejo est\u00e1 determinado por la interacci\u00f3n de sus partes, \u00bfqu\u00e9 debe interesarnos? La interacci\u00f3n. <\/p>\n

Hay otras dos conclusiones interesantes.
\n \"DevOps
\n
\nPrimero, entendemos que no se puede simplificar un sistema complejo simplificando sus partes. En segundo lugar, la \u00fanica forma de simplificar un sistema complejo es a trav\u00e9s de la simplificaci\u00f3n de las interacciones entre sus partes. <\/p>\n

\u00bfC\u00f3mo interactuamos? Todos nosotros somos partes de un gran sistema de informaci\u00f3n llamado sociedad humana. Interactuamos a trav\u00e9s de un lenguaje com\u00fan, si lo tenemos, si lo encontramos.<\/p>\n

\"DevOps
\n
\nPero el lenguaje por s\u00ed mismo es un sistema adaptativo complejo. Por lo tanto, para interactuar de manera m\u00e1s efectiva y sencilla, necesitamos crear ciertos protocolos. Es decir, alguna secuencia de s\u00edmbolos y acciones que haga el intercambio de informaci\u00f3n entre nosotros m\u00e1s simple, m\u00e1s predecible, m\u00e1s claro.<\/p>\n

Quiero decir que las tendencias hacia la complejidad, la adaptabilidad, la descentralizaci\u00f3n y el caos se observan en todo. Tanto en los sistemas que construimos como en aquellos de los que somos parte.<\/p>\n

Y para no quedarme en palabras, veamos c\u00f3mo cambian los sistemas que creamos.<\/p>\n

\"DevOps
\n
\nSab\u00eda que esperaban esta palabra. Estamos en la conferencia de DevOps, hoy esta palabra ser\u00e1 pronunciada unas cien mil veces y luego so\u00f1aremos con ella por la noche.<\/p>\n

Microservicios: la primera arquitectura de software que surgi\u00f3 como respuesta a las pr\u00e1cticas de DevOps, destinada a hacer nuestros sistemas m\u00e1s flexibles, m\u00e1s escalables y a asegurar una entrega continua. \u00bfC\u00f3mo lo logra? Mediante la reducci\u00f3n de la cantidad de servicios, la simplificaci\u00f3n de los l\u00edmites de los problemas que estos servicios manejan y la disminuci\u00f3n 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.<\/p>\n

\"DevOps
\n
\nLos 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\u00f3digo 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. <\/p>\n

\u00bfD\u00f3nde est\u00e1 la complejidad? La complejidad, por supuesto, reside en las interacciones. \u00bfCu\u00e1nto puede hacer una funci\u00f3n por s\u00ed sola? \u00bfC\u00f3mo interact\u00faa con otras funciones? Colas de mensajes, bases de datos, balanceadores. \u00bfC\u00f3mo recrear un evento cuando ocurre una falla? Muchas preguntas y pocas respuestas.<\/p>\n

Los microservicios y Serverless son todo lo que nosotros, los hipsters de la computaci\u00f3n, llamamos Cloud Native. Todo se trata de la nube. Pero la nube, en esencia, tambi\u00e9n es limitada en cuanto a escalabilidad. Estamos acostumbrados a verla como un sistema distribuido. Sin embargo, \u00bfd\u00f3nde viven los servidores de los proveedores de nube? En los centros de datos. Es decir, aqu\u00ed tenemos un modelo distribuido, pero muy centralizado y limitado.<\/p>\n

Hoy entendemos que el Internet de las cosas ya no son solo palabras grandilocuentes, porque seg\u00fan pron\u00f3sticos modestos, en los pr\u00f3ximos cinco a diez a\u00f1os habr\u00e1 miles de millones de dispositivos conectados a Internet. Un enorme volumen de datos \u00fatiles e in\u00fatiles que se volcar\u00e1n en la nube y se descargar\u00e1n de la nube. <\/p>\n

La nube no podr\u00e1 soportarlo, por lo que hablamos cada vez m\u00e1s de lo que se llama 'computaci\u00f3n perimetral'. O tambi\u00e9n me gusta la maravillosa definici\u00f3n de 'fog computing'. Est\u00e1 envuelto en la m\u00edstica del romanticismo y el misterio.<\/p>\n

\"DevOps
\n
\nComputaci\u00f3n 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\u00f3sfera. <\/p>\n

En la paradoja de la niebla, la mayor parte del trabajo es realizado por estas gotas de manera completamente aut\u00f3noma o en colaboraci\u00f3n con otras gotas. Y solo se dirigen a la nube cuando realmente es necesario. <\/p>\n

Es decir, de nuevo descentralizaci\u00f3n, autonom\u00eda, y, por supuesto, muchos de ustedes ya comprenden hacia d\u00f3nde va todo esto, porque no se puede hablar de descentralizaci\u00f3n sin mencionar la blockchain. <\/p>\n

\"DevOps
\n
\nHay 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\u00eda, un nuevo asunto incomprensible, hay problemas. Como cualquier nueva tecnolog\u00eda, plantea m\u00e1s preguntas de las que ofrece respuestas. <\/p>\n

El hype alrededor de la blockchain es comprensible. Incluso dejando de lado la fiebre del oro, la propia tecnolog\u00eda promete un futuro brillante: m\u00e1s libertad, m\u00e1s autonom\u00eda, confianza global distribuida. \u00bfQu\u00e9 es lo que no se puede querer? <\/p>\n

As\u00ed, cada vez m\u00e1s 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\u00e9pticos: \"No hay aplicaciones reales para la blockchain\". Si lo piensas, hace 150 a\u00f1os dec\u00edan lo mismo sobre la electricidad. E incluso en cierto modo ten\u00edan raz\u00f3n, porque lo que la electricidad hace posible hoy en d\u00eda, era completamente irreal en el siglo XIX.<\/p>\n

Por cierto, \u00bfqui\u00e9n sabe qu\u00e9 logo est\u00e1 en la pantalla? Es Hyperledger. Es un proyecto que se desarrolla bajo la \u00e9gida de The Linux Foundation, que incluye un conjunto de tecnolog\u00edas blockchain. Esta es verdaderamente la fuerza de nuestra comunidad de c\u00f3digo abierto.<\/p>\n

Ingenier\u00eda ca\u00f3tica<\/b><\/h3>\n

\n\"DevOps
\n
\nAs\u00ed que, el sistema que estamos desarrollando se vuelve cada vez m\u00e1s complejo, m\u00e1s ca\u00f3tico, m\u00e1s 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\u00e1s famosa es Chaos Monkey<\/a><\/noindex>. Defini\u00f3 lo que se conoci\u00f3 como \u00abprincipios de la ingenier\u00eda del caos\u00bb<\/a><\/noindex>.<\/p>\n

Por cierto, mientras trabaj\u00e1bamos en la presentaci\u00f3n, incluso tradujimos este texto al espa\u00f1ol, as\u00ed que puedes entrar por el enlace<\/a><\/noindex>, lee, comenta, critica.<\/p>\n

En resumen, los principios de la ingenier\u00eda 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. <\/p>\n

Debemos intentar introducir estos errores en nuestros sistemas de producci\u00f3n, para probar nuestra capacidad de adaptaci\u00f3n, nuestra capacidad de autoorganizaci\u00f3n y de supervivencia. <\/p>\n

Y esto lo cambia todo. No solo la forma en que lanzamos el sistema en producci\u00f3n, sino tambi\u00e9n c\u00f3mo los desarrollamos y los probamos. No hay ning\u00fan proceso de estabilizaci\u00f3n, de congelamiento del c\u00f3digo; por el contrario, hay un proceso constante de desestabilizaci\u00f3n. Intentamos destruir el sistema y ver que sigue sobreviviendo.<\/p>\n

Protocolos de Integraci\u00f3n de Sistemas Distribuidos<\/b><\/h3>\n

\n\"DevOps
\n
\nPor lo tanto, esto requiere que nuestros sistemas tambi\u00e9n cambien de alguna manera. Para volverse m\u00e1s resilientes, necesitan nuevos protocolos de interacci\u00f3n entre sus partes. Para que estas partes puedan comunicarse y alcanzar cierta autoorganizaci\u00f3n. Surgen diversas herramientas nuevas, nuevos protocolos que llamo \u00abprotocolos de interacci\u00f3n de sistemas distribuidos\u00bb.<\/p>\n

\"DevOps
\n
\n\u00bfDe qu\u00e9 hablo? Primero, el proyecto Opentracing<\/a><\/noindex>. Un intento de crear un protocolo com\u00fan de seguimiento distribuido, que es una herramienta absolutamente indispensable para depurar sistemas distribuidos complejos.<\/p>\n

\"DevOps
\n
\nA continuaci\u00f3n \u2014 Open Policy Agent<\/a><\/noindex>. Decimos que no podemos predecir lo que suceder\u00e1 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. \u00bfC\u00f3mo podemos determinar el comportamiento esperado? A trav\u00e9s de definir en \u00e9l alguna pol\u00edtica, 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\u00f3n de recursos.<\/p>\n

\"DevOps
\n
\nComo hemos mencionado, nuestros sistemas est\u00e1n cada vez m\u00e1s 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\u00fan, un protocolo com\u00fan sobre c\u00f3mo hablamos de los eventos y c\u00f3mo nos los transmitimos. Esto es lo que aborda el proyecto llamado Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nUn flujo continuo de cambios que inunda nuestros sistemas, desestabiliz\u00e1ndolos constantemente, es un flujo constante de artefactos de software. Para poder mantener este flujo constante de cambios, necesitamos un protocolo com\u00fan que nos permita hablar sobre qu\u00e9 es un artefacto de software, c\u00f3mo ha sido verificado, qu\u00e9 verificaci\u00f3n ha pasado. Esto es lo que aborda el proyecto llamado Grafeas<\/a><\/noindex>. Es decir, un protocolo com\u00fan de metadatos de artefactos de software.<\/p>\n

\"DevOps
\n
\nY, por \u00faltimo, si queremos que nuestros sistemas sean completamente aut\u00f3nomos, adaptativos y se autorregulen, debemos darles derecho a la autoidentificaci\u00f3n. El proyecto llamado spiffe<\/a><\/noindex> es precisamente de lo que se encarga. Este tambi\u00e9n es un proyecto bajo la \u00e9gida de la Cloud Native Computing Foundation.<\/p>\n

Todos estos proyectos son j\u00f3venes, necesitan nuestro apoyo, nuestra revisi\u00f3n. Todo es c\u00f3digo abierto, nuestras pruebas, nuestra implementaci\u00f3n. Nos muestran hacia d\u00f3nde se dirige la tecnolog\u00eda. <\/p>\n

Pero DevOps nunca ha sido principalmente sobre tecnolog\u00eda, siempre ha sido sobre la colaboraci\u00f3n 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\u00f3n. <\/p>\n

\"DevOps
\n
\nHay una maravillosa sobre patrones de Kubernetes. Todo comenz\u00f3 con \"<\/a><\/noindex> autora brit\u00e1nica, Rachel Botsman, que escribe sobre la evoluci\u00f3n de la confianza a lo largo de la historia humana. Ella dice que originalmente, en sociedades primitivas, la confianza era local, es decir, confi\u00e1bamos solo en aquellos que conoc\u00edamos personalmente. <\/p>\n

Luego hubo un largo per\u00edodo \u2014un tiempo oscuro\u2014 cuando la confianza se volvi\u00f3 centralizada, cuando comenzamos a confiar en personas que no conoc\u00edamos bas\u00e1ndonos en el hecho de que pertenec\u00edamos a la misma instituci\u00f3n social o estatal.<\/p>\n

Y esto es lo que vemos en nuestro mundo moderno: la confianza se est\u00e1 volviendo cada vez m\u00e1s distribuida y descentralizada, y se basa en la libertad de los flujos de informaci\u00f3n y en la accesibilidad de la informaci\u00f3n. <\/p>\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\u00f3mo lo hacemos, porque las organizaciones de TI jer\u00e1rquicas y centralizadas del viejo estilo est\u00e1n dejando de funcionar. Comienzan a desvanecerse. <\/p>\n

Fundamentos de una organizaci\u00f3n DevOps<\/b><\/h3>\n

\nLa organizaci\u00f3n DevOps perfecta del futuro es un sistema descentralizado y adaptativo, compuesto por equipos aut\u00f3nomos, cada uno formado por individuos aut\u00f3nomos. Estos equipos est\u00e1n esparcidos por todo el mundo, colaborando de manera efectiva entre s\u00ed a trav\u00e9s de comunicaci\u00f3n asincr\u00f3nica y protocolos de intercambio de informaci\u00f3n muy transparentes. Muy bonito, \u00bfverdad? Un futuro muy hermoso.<\/p>\n

Por supuesto, todo esto es imposible sin cambios culturales. Necesitamos liderazgo transformacional, responsabilidad personal y motivaci\u00f3n interna.<\/p>\n

\"DevOps
\n
\nEsta es la base de las organizaciones DevOps: transparencia de la informaci\u00f3n, comunicaci\u00f3n asincr\u00f3nica, liderazgo transformacional, descentralizaci\u00f3n. <\/p>\n

Burnout<\/b><\/h3>\n

\nLos sistemas de los que formamos parte, y aquellos que construimos, son cada vez m\u00e1s ca\u00f3ticos, y nos resulta dif\u00edcil aceptar esta realidad, dif\u00edcil renunciar a la ilusi\u00f3n de control. Intentamos seguir control\u00e1ndolos, y esto a menudo conduce al burnout. Hablo desde mi propia experiencia; yo tambi\u00e9n me he quemado, tambi\u00e9n soy una v\u00edctima de fallos inesperados en producci\u00f3n.<\/p>\n

\"DevOps
\n
\nEl 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. <\/p>\n

La profesi\u00f3n de ingeniero, como me gusta recordarme a menudo, es, ante todo, una profesi\u00f3n creativa. Si perdemos el deseo de crear algo, nos convertimos en cenizas, en polvo. Las personas se queman, las organizaciones enteras se queman.<\/p>\n

En mi opini\u00f3n, solo aceptar el poder creativo del caos, solo construir la colaboraci\u00f3n sobre sus principios, es lo que nos ayudar\u00e1 a no perder lo bueno que hay en nuestra profesi\u00f3n. <\/p>\n

Eso es lo que les deseo: amar su trabajo, amar lo que hacemos. Este mundo se alimenta de informaci\u00f3n, y tenemos el honor de alimentarlo. As\u00ed que vamos a estudiar el caos, seamos caologistas, aportemos valor, creemos algo nuevo, y cuando aparezcan los problemas, como ya hemos descubierto, ser\u00e1n inevitables. Cuando lleguen, simplemente diremos '\u00a1Ops!', y el problema estar\u00e1 resuelto. <\/p>\n

\u00bfQu\u00e9 hay m\u00e1s all\u00e1 de Chaos Monkey?<\/b><\/p>\n

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\u00eda del caos y adhieran a esos principios, en lugar de buscar otras herramientas que alguien m\u00e1s ya ha construido. <\/p>\n

Traten de entender c\u00f3mo fallan sus sistemas y empiecen a romperlos para observar c\u00f3mo resisten los golpes. Esto es lo primero. Las herramientas se pueden buscar. Hay muchos proyectos disponibles. <\/p>\n

No entend\u00ed 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\u00ed. <\/b><\/p>\n

Es cierto, los microservicios son un tema muy controvertido en general. De hecho, simplificar partes aumenta la flexibilidad. \u00bfQu\u00e9 nos brindan los microservicios? Nos ofrecen flexibilidad y velocidad, pero para nada nos brindan simplicidad. Aumentan la complejidad.<\/p>\n

Entonces, \u00bfen la filosof\u00eda DevOps, los microservicios no son una bendici\u00f3n?<\/b><\/p>\n

Cualquier bendici\u00f3n tiene su reverso. Hay una bendici\u00f3n: aumenta la flexibilidad, nos permite hacer cambios m\u00e1s r\u00e1pido, pero tambi\u00e9n aumenta la complejidad y, por ende, la fragilidad de todo el sistema. <\/p>\n

\u00bfEn qu\u00e9 se pone m\u00e1s \u00e9nfasis: en simplificar la interacci\u00f3n o en simplificar las partes?<\/b> <\/p>\n

El enfoque est\u00e1, sin duda, en simplificar la interacci\u00f3n, porque si lo miramos desde la perspectiva de c\u00f3mo trabajamos juntos, primero debemos prestar atenci\u00f3n 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\u00ed pones la hamburguesa, aqu\u00ed le echas la salsa. Eso no funciona en nuestro trabajo creativo en absoluto.<\/p>\n

\u00bfEs 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? \u00bfC\u00f3mo deber\u00edan coexistir la competencia y DevOps?<\/b><\/p>\n

Bueno, depende de qu\u00e9 tipo de competencia estamos hablando. \u00bfDe la competencia en el lugar de trabajo o de la competencia entre empresas? <\/p>\n

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\u00e1 en todas partes.<\/b><\/p>\n

Tomemos a Netflix como modelo de referencia. \u00bfPor qu\u00e9 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\u00ed 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.<\/p>\n

\u00bfSignifica 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\u00e1s. La competencia, de hecho, se basa en el hecho de que tenemos objetivos claros y sabemos a d\u00f3nde llegaremos en cada momento del tiempo. Desde mi point de vista, esa es la esencia de DevOps.<\/b><\/p>\n

Tambi\u00e9n es una perspectiva sobre la cuesti\u00f3n. Creo que todos tenemos un mismo objetivo: sobrevivir y hacerlo con
\nel mayor placer posible. Y el objetivo competitivo de cualquier organizaci\u00f3n es el mismo. La supervivencia a menudo ocurre en la lucha competitiva, no hay nada que hacer al respecto.<\/p>\n

Este a\u00f1o la conferencia DevOpsDays Mosc\u00fa<\/a><\/noindex> se llevar\u00e1 a cabo el 7 de diciembre en 'Technopolis'. Aceptamos propuestas para conferencias hasta el 11 de noviembre. Escr\u00edbanos<\/a><\/noindex> si desea dar una charla.<\/p>\n

La inscripci\u00f3n para los participantes est\u00e1 abierta, el boleto cuesta 7000 rublos. \u00a1\u00danete! \n<\/p><\/blockquote>\n

Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps y Caos: entrega de software en un mundo descentralizado | ProHoster","description":"El fundador y director de \u00abOtomato Software\u00bb, uno de los iniciadores e instructores de la primera certificaci\u00f3n DevOps en Israel, Anton Weiss, habl\u00f3 el a\u00f1o pasado","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}