Herramientas DevOps para desarrolladores Java

Capítulo 1. DevOps para (o posiblemente contra) los desarrolladores

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Baruj Sadogursky

Mientras tú aquí yaces roncando,
Con los ojos abiertos conspira Su tiempo.
Si de la vida te preocupas
Sacúdete el sueño y ten cuidado:
¡Despierta, despierta!

William Shakespeare, La Tempestad

Algunos podrían preguntarse si el movimiento DevOps es simplemente un complot inspirado en las operaciones contra los desarrolladores.La mayoría (si no todos) de los que lo hicieran no esperarían una respuesta seria, entre otras cosas porque pretenden que la pregunta sea una broma irónica. También es porque -e independientemente de si tus orígenes están en el lado del desarrollo o de las operaciones de la ecuación- cuando alguien entabla una conversación sobre DevOps, pasarán aproximadamente 60 segundos antes de que alguien pregunte: "Pero, ¿qué es DevOps en realidad?".

Y cabría pensar que, 11 años después de que se acuñara el término (una década en la que los profesionales del sector han hablado, debatido y gritado sobre él), todos habríamos llegado a una definición estándar, sin tonterías y comúnmente entendida. Pero sencillamente no es así. De hecho, a pesar del aumento exponencial de la demanda corporativa de personal de DevOps, es muy dudoso que cinco empleados titulados en DevOps, elegidos al azar, pudieran decirte con precisión qué es DevOps.

Así que no te avergüences si sigues rascándote la cabeza cuando surge el tema. Conceptualmente, DevOps puede no ser fácil de entender, pero tampoco es imposible.

Pero independientemente de cómo discutamos el término o de la definición o definiciones que podamos acordar, hay una cosa, por encima de todo, que es fundamental tener en cuenta: DevOps es un concepto totalmente inventado, y los inventores procedían del lado de operaciones de la ecuación.

DevOps es un concepto inventado por el lado de operaciones

Puede que mi premisa sobre DevOps sea provocativa, pero también es demostrable. Empecemos por los hechos.

Prueba 1: El Proyecto Phoenix

El Proyecto Fénix de Gene Kim et al. (IT Revolution) se convirtió en un clásico desde que se publicó hace casi una década. No es un manual de instrucciones (al menos no en el sentido tradicional), sino una novela que cuenta la historia de una empresa muy problemática y de su director de informática, al que de repente se le asigna la tarea de poner en marcha una iniciativa corporativa decisiva que ya está muy por encima del presupuesto y lleva meses de retraso.

Si vives en el mundo del software, el resto de los personajes centrales del libro te resultarán familiares, pero de momento echemos un vistazo a sus títulos profesionales:

• Director de soporte de servicios informáticos

• Director de tecnología distribuida

• Director de ventas al por menor

• Administrador principal de sistemas

• Responsable de seguridad de la información

• Director Financiero

• Director General

¿Notas el tejido conectivo entre ellos? Son los protagonistas de uno de los libros más importantes sobre DevOps jamás escrito y ninguno de ellos es desarrollador. Incluso cuando los desarrolladores aparecen en la trama, bueno... digamos que no se habla de ellos en términos especialmente elogiosos.

Cuando llega la victoria, es el héroe de la historia (junto con un miembro de la junta que le apoya) quien inventa DevOps, saca las castañas del fuego, cambia la suerte de su empresa y es recompensado con un ascenso a director de información (CIO) de la empresa. Y todos viven felices, si no para siempre, al menos durante los dos o tres años que suelen durar esos éxitos en este negocio, antes de que llegue el momento de volver a demostrar tu valía.

Recuadro 2: El Manual DevOps

Es mejor leer El Proyecto Phoenix antes que El Manual DevOps de Gene Kim et al. (IT Revolution) porque el primero te sitúa en un escenario humano muy creíble. No es difícil sumergirse en los tipos de personalidad, los apuros profesionales y las relaciones interpersonales de los personajes. Los cómos y los porqués de DevOps se desarrollan como respuestas inevitables y racionales a una serie de circunstancias, que podrían haber conducido con la misma facilidad al colapso empresarial. Lo que está en juego, los personajes y las decisiones que toman parecen bastante verosímiles. Puede que no resulte demasiado difícil establecer paralelismos con tu propia experiencia.

El Manual DevOps te permite profundizar en los componentes conceptuales de los principios y prácticas DevOps. Como sugiere su subtítulo, el libro explica en gran medida Cómo crear agilidad, fiabilidad y seguridad de clase mundial en las organizaciones tecnológicas. Pero, ¿no debería tratarse de desarrollo? Si debería o no, puede ser objeto de debate. Lo que es incontrovertible es que los autores del libro son profesionales brillantes y supertalentosos que son, posiblemente, los padres de DevOps. Sin embargo, el Recuadro 2 no se incluye aquí para elogiarlos tanto como para examinar de cerca sus antecedentes.

Empecemos por Gene Kim.Fundó la empresa de seguridad de software e integridad de datos Tripwire, de la que fue director de tecnología (CTO) durante más de una década. Como investigador, ha dedicado su atención profesional a examinar y comprender las transformaciones tecnológicas que se han producido y se están produciendo en grandes y complejas empresas e instituciones. Además de ser coautor de El Proyecto Fénix, en 2019 fue coautor de El Proyecto Unicornio (del que hablaré más adelante). Todo en su carrera está impregnado de operaciones. Incluso cuando Unicornio dice que es "sobre Desarrolladores", ¡sigue siendo sobre desarrolladores visto a través de los ojos de un tipo de operaciones!

En cuanto a los otros tres autores del Manual:

• Jez Humble ha ocupado cargos en, como ingeniero de fiabilidad del sitio (SRE), director técnico, subdirector de Arquitectura de Entrega y Servicios de Infraestructura, y Relaciones con los Desarrolladores. Aunque el último de sus títulos hace referencia al desarrollo, el trabajo no consiste en eso, sino en las relaciones con los desarrolladores. Se trata de reducir la brecha entre desarrollo y operaciones, sobre lo que ha escrito, enseñado y dado muchas conferencias.

• Patrick Debois ha sido CTO, director de Estrategia de Mercado en y director de Relaciones Dev♥Ops (el corazón es su adición). Se describe a sí mismo como un profesional que "tiende puentes entre los proyectos y las operaciones utilizando técnicas ágiles en el desarrollo, la gestión de proyectos y la administración de sistemas". Eso sí que suena a tipo de operaciones.

• John Willis, en el momento de escribir estas líneas, ostenta el título de vicepresidente de DevOps y Prácticas Digitales en. Anteriormente, fue director de Desarrollo de Ecosistemas, vicepresidente de Soluciones y, sobre todo, vicepresidente de Formación y Servicios en Opscode (ahora conocida como Progress Chef). Y aunque la carrera de John ha estado un poco más relacionada con el desarrollo, la mayor parte de su trabajo se ha centrado en las operaciones, sobre todo en la medida en que ha centrado su atención en derribar los muros que antes mantenían a los desarrolladores y al personal de operaciones en campos distintos y separados.

Como puedes ver, todos los autores tienen formación en operaciones. ¿Coincidencia? Yo creo que no.

¿Aún no estás convencido de que DevOps está impulsado por las operaciones? ¿Qué tal si echamos un vistazo a los líderes que intentan vendernos DevOps hoy en día?

Búscalo en Google

En el momento de escribir esto, si escribes "¿Qué es DevOps?" en una búsqueda de Google en sólo para ver qué aparece, es probable que tu primera página de resultados incluya lo siguiente:

• Agile Admin, una empresa de administración de sistemas

• Atlassian, cuyos productos incluyen plataformas de seguimiento de proyectos y problemas, elaboración de listas y colaboración en equipo

• Amazon Web Services (AWS), Microsoft Azure y Rackspace Technology, que venden infraestructura de operaciones en la nube

• Logz.io, que vende servicios de gestión y análisis de registros

• New Relic, cuya especialidad es el monitoreo de aplicaciones

Todas ellas están muy centradas en las operaciones. Sí, esa primera página contenía una empresa que estaba un poco más en el lado del desarrollo y otra que realmente no estaba directamente relacionada con la búsqueda. La cuestión es que cuando intentas buscar DevOps, la mayoría de lo que encontrarás tiende a inclinarse hacia las operaciones.

¿Qué hace?

DevOps es algo, está muy solicitado.Y con esto, muchos querrán saber, concretamente, qué hace DevOps, qué produce sustancialmente. En lugar de seguir ese camino, veámoslo estructuralmente, conceptualizándolo como si fuera el símbolo del infinito en forma de ocho. Desde este punto de vista, vemos un bucle de procesos que va de la codificación a la construcción, a las pruebas, a la publicación, a la implementación, a las operaciones, al monitoreo, y luego de vuelta otra vez para empezar a planificar nuevas funciones, como se muestra en la Figura 1-1.

Figura 1-1. El bucle infinito de DevOps

Y si a algunos lectores les resulta familiar, debería, porque tiene una similitud conceptual con el ciclo de desarrollo Ágil(Figura 1-2).

Figura 1-2. Ciclo de desarrollo ágil

No hay ninguna diferencia profunda entre estas dos historias interminables, aparte del hecho de que la gente de operaciones se injertó en el viejo mundo del círculo Ágil, ampliándolo esencialmente en dos círculos e introduciendo con calzador sus preocupaciones y dolores en el dominio que antes se consideraba únicamente competencia de los desarrolladores.

Estado de la industria

Desde 2014, una prueba más de que DevOps es un fenómeno impulsado por ops ha llegado empaquetada en forma de un compendio anual fácil de leer de datos recopilados, analizados y resumidos de decenas de miles de profesionales del sector y organizaciones de todo el mundo. El informe "Accelerate: State of DevOps" fue principalmente el trabajo de DevOps Research and Assessment (DORA) y es el documento más importante de la industria del software para calibrar dónde está DevOps y hacia dónde se dirige probablemente. En la edición de 2018, por ejemplo, podemos ver un serio enfoque en cuestiones como éstas:

• ¿Con qué frecuencia implementan código las organizaciones?

• ¿Cuánto tiempo suele pasar desde que se confirma el código hasta que se ejecuta con éxito en producción?

• Cuando se producen averías o cortes, ¿cuánto tiempo suele tardar en restablecerse el servicio?

• ¿Qué porcentaje de los cambios implementados dan lugar a un servicio degradado o requieren reparación?

Fíjate en que todas ellas son preocupaciones muy centradas en las operaciones.

¿Qué constituye el trabajo?

Examinemos ahora cómo define el trabajo el informe "Accelerate: State of DevOps" y The Phoenix Project.Bueno, en primer lugar, el trabajo planificado se centra en proyectos empresariales y nuevas funciones, que abarcan tanto a ops como a dev. Los proyectos internos, incluidas las migraciones de servidores, las actualizaciones de software y los cambios impulsados por los comentarios sobre los proyectos implementados pueden tener una base amplia y pueden o no tener más peso para un lado de la ecuación DevOps que para el otro.

¿Pero qué pasa con las actividades no planificadas, como las escaladas de soporte y las interrupciones de emergencia? Éstas son actividades de operaciones, al igual que la codificación de nuevas funciones, la corrección de errores y la refactorización, que tratan de cómo se puede facilitar la vida de las operaciones incluyendo a los desarrolladores en la historia de DevOps.

Si no nos ocupamos de la Implementación y las Operaciones, ¿entonces cuál es nuestro trabajo?

Está claro que DevOps no es algo que los desarrolladores estuvieran (o estén) demandando.Es un invento de operaciones para hacer que todos los demás trabajen más. Y asumiendo esta verdad, reflexionemos sobre qué pasaría si los desarrolladores se alzaran como uno solo y dijeran: "Vuestras preocupaciones de operaciones son vuestras, no nuestras". Bien. Pero en ese caso, lo correcto sería preguntar a los desarrolladores rebeldes su definición de "hecho". ¿Qué estándares creen que deben alcanzar para decir: "Hemos hecho bien nuestro trabajo y nuestra parte ya está completa"?

No es una pregunta frívola, y hay fuentes a las que podemos acudir en busca de respuestas. Una, aunque imperfecta y no pocas veces criticada, es el Manifiesto por la Artesanía del Software, que plantea cuatro valores fundamentales que deberían motivar a los desarrolladores. Considerémoslos:

Software bien elaborado

Sí, efectivamente, la calidad es importante.

Valor añadido constante

No hay discusión al respecto. Por supuesto que queremos ofrecer servicios y funciones que la gente necesite, quiera o le gusten.

Comunidad de profesionales

A grandes rasgos, ¿quién podría oponerse a ello? La cordialidad entre compañeros del sector no es más que ser profesionalmente vecino.

Asociaciones productivas

La colaboración es, sin duda, el nombre del juego. Los desarrolladores no están en contra del control de calidad (QA), las operaciones o los propios productos. Así que, en contexto, se trata simplemente de ser amigable con todo el mundo (siempre y cuando otros equipos no empiecen a dictar lo que se supone que deben ser sus trabajos).

¿Qué es "Hecho"?

Con todo lo que hemos establecido hasta ahora, podemos decir sin temor a equivocarnos que tenemos que producir un código que sea sencillo, legible, comprensible y fácil de implementar. Debemos estar seguros de que se satisfacen los requisitos no funcionales (por ejemplo, el rendimiento, el rendimiento, la huella de memoria, la seguridad, la privacidad, etc.), rendimiento, rendimiento, huella de memoria, seguridad, privacidad, etc.) se satisfacen. Debemos trabajar con diligencia para evitar incurrir en cualquier carga técnica y, si tenemos suerte, desprendernos de alguna por el camino. Debemos asegurarnos de que todas las pruebas se superan. Y estamos obligados a mantener relaciones fructíferas con los equipos de control de calidad (cuando ellos están contentos, nosotros estamos contentos).

Con un código de buena calidad y revisiones positivas del líder del equipo y de los compañeros, todo debería ir bien desde el principio. Con un equipo de producto que defina normas de valor y valor añadido, pueden establecerse firmemente puntos de referencia. A través de sus comentarios, los propietarios del producto ayudan a determinar si esos puntos de referencia se están cumpliendo (o no) y en qué medida. Esa es una definición bastante buena de un buen desarrollador de software que ha "hecho" lo que tenía que hacer. También demuestra que "bien hecho" nunca puede medirse adecuadamente (ni siquiera saberse) sin la participación del personal de operaciones y una comunicación clara con él.

¿Rivalidad?

Así que sí, aunque puede demostrarse que DevOps no era realmente algo por lo que los desarrolladores estuvieran clamando, también puede demostrarse que su práctica infinita beneficia a todos. Y aún así hay resistentes; los que imaginan una rivalidad, incluso un antagonismo, entre los desarrolladores y, por ejemplo, los probadores de control de calidad. Los desarrolladores trabajan duro en sus creaciones y luego sienten que los equipos de control de calidad son casi como hackers, que quieren demostrar algo, que cavan y cavan hasta que encuentran un problema.

Aquí es donde entra en juego el asesoramiento DevOps. Todo desarrollador concienzudo quiere estar orgulloso de lo que produce. Encontrar fallos puede parecer una crítica, cuando en realidad no es más que un trabajo concienzudo que viene de otra dirección. Una comunicación buena, clara, abierta y continua entre los desarrolladores y el personal de control de calidad ayuda a reforzar las ventajas de DevOps, pero también deja claro que, en última instancia, todos trabajan por el mismo objetivo. Cuando el personal de control de calidad identifica errores, lo único que hace es ayudar a sus colegas desarrolladores a escribir mejor código, a ser mejores desarrolladores. Y este ejemplo de interacción entre los que están en el lado de las operaciones y los que están en el lado del desarrollo demuestra la útil difuminación de las distinciones y separaciones entre los dos mundos. Su relación es necesariamente simbiótica y, una vez más, funciona a lo largo de un continuo interminable de actividades, en el que una informa a la otra en beneficio mutuo de todos.

Más que nunca

La creciente demanda de DevOps procede tanto de fuerzas externas como de las propias empresas de software. Y esto se debe a que nuestras expectativas, todas nuestras expectativas, como personas que vivimos en un mundo del siglo XXI, siguen cambiando rápidamente. Cuanto más dependamos de soluciones de software cada vez mejores, menos tiempo tendremos que perder en lagunas de información y comunicación, y en retrasos entre los desarrolladores y el personal de operaciones.

Tomemos, por ejemplo, la banca. Hace una década, la mayoría de los grandes bancos tenían sitios web razonablemente adecuados. Podías conectarte para echar un vistazo a tus cuentas, tus extractos y tus transacciones recientes. Quizá incluso estabas empezando a hacer pagos electrónicamente a través de los servicios electrónicos que ofrecía tu banco. Y aunque esos servicios eran agradables y ofrecían cierta comodidad, probablemente seguías necesitando ir (o, al menos, te sentías más cómodo yendo) a tu sucursal local para gestionar tus asuntos bancarios.

Lo que no existía es la experiencia totalmente digital de hoy en día, con aplicaciones móviles, monitoreo automático de cuentas y alertas, y suficientes servicios para que sea cada vez más común que los titulares de cuentas promedio lo hagan todo por Internet. Puede que incluso estés entre aquellos a los que no sólo no les importa si alguna vez vuelven a ver el interior de su sucursal física, sino que ni siquiera saben dónde está esa sucursal. Es más, los bancos están reaccionando a estos rápidos cambios de hábitos bancarios consolidando y cerrando sucursales físicas, y ofreciendo incentivos a sus clientes para que trasladen sus operaciones bancarias a la esfera online. Esto se aceleró aún más durante la crisis COVID-19, cuando el acceso a las sucursales se restringió a servicios de sólo cita previa, acceso limitado sin cita previa y horarios más cortos.

Así que, hace 10 años, si el sitio web de tu banco se caía durante 12 horas de mantenimiento mientras el banco implementaba un sitio mejor y más seguro, probablemente te lo hubieras tomado con calma: ¿qué son una docena de horas si van a dar lugar a servicios de mayor calidad? No necesitabas una banca online 24 horas al día, 7 días a la semana y, además, la sucursal local estaba ahí para ti. Hoy en día, simplemente no es así. Medio día de inactividad es inaceptable. En esencia, esperas que tu banco esté siempre abierto y disponible. Esto se debe a que tu definición (y la del mundo) de calidad ha cambiado. Y ese cambio requiere DevOps más que nunca.

Volumen y velocidad

Otra presión que impulsa el crecimiento de DevOps en es la cantidad de datos que se almacenan y manejan. Y es lógico. Si cada vez más de nuestra vida diaria depende del software, obviamente se producirá un tremendo aumento de la cantidad de datos que genera. En 2020, toda la datasfera mundial ascendía a casi 10 zettabytes. Una década antes, era de 0,5 zettabytes. Para 2025, se estima razonablemente que se disparará exponencialmente a más de 50 zettabytes.

No se trata sólo de que gigantes como Google, Netflix, Facebook, Microsoft, Amazon, Twitter y otros sean cada vez más grandes y mejores, y por tanto necesiten procesar mayores cantidades de datos. Esta proyección afirma que cada vez más empresas se graduarán en el mundo de los grandes datos. Con ello vienen las demandas de cargas de datos enormemente mayores, así como el alejamiento de los entornos tradicionales de servidores de ensayo, que ofrecían réplicas exactas de determinados entornos de producción. Y este alejamiento se basa en el hecho de que mantener tales esquemas de par a par ya no es factible en términos de tamaño o velocidad.

Felices eran los días de antaño en que todo podía probarse antes de pasar a producción, pero esto ya no es posible.Cada vez se ponen y se pondrán más cosas en producción en las que las empresas de software no confían al 100%. ¿Debería cundir el pánico? No. La necesidad de lanzar rápido y seguir siendo competitivos debería inspirar la innovación y la creatividad en las formas necesarias para ejecutar mejor las renovaciones controladas, los procedimientos de prueba y más pruebas en producción, lo que ahora se denomina entrega progresiva. Esto viene acompañado de banderas de características y herramientas de observabilidad, como el rastreo distribuido.

Algunos equiparan la entrega progresiva con el radio de explosión de un artefacto explosivo. La idea es que, cuando realizamos una implementación en un entorno de producción, cabe esperar explosiones. Por tanto, para optimizar dichas implementaciones, lo mejor que podemos esperar es minimizar las bajas, mantener el tamaño del radio de explosión lo más pequeño posible. Esto se consigue sistemáticamente mejorando la calidad de los servidores, servicios y productos. Y si estamos de acuerdo en que la calidad es una preocupación de los desarrolladores y que su consecución forma parte de la definición de "hecho" de un desarrollador, entonces significa que no puede haber pausa ni desconexión entre ese momento de "hecho" del desarrollador y el siguiente, el momento de "producción" del departamento de operaciones. Porque tan pronto como esto ocurre, volvemos al desarrollo, a medida que se corrigen errores, se restablecen los servicios debido a interrupciones, etcétera.

Hecho y hecho

Puede que cada vez esté más claro que las expectativas y exigencias que se generaban y siguen generándose desde el entorno de operaciones, por necesidad, impulsaron el empuje hacia DevOps. Y como resultado, el aumento de las expectativas y exigencias sobre los desarrolladores no proceden de un odio enconado que la gente de operaciones siente por sus colegas desarrolladores, ni forma parte de un complot para privarles del sueño. Más bien, todo esto, todo lo que DevOps representa, es una respuesta empresarial de realpolitik a nuestro mundo cambiante y a los cambios que han forzado en la industria del software en general.

El hecho es que todo el mundo tiene nuevas responsabilidades, algunas de las cuales exigen que los profesionales (sin duda muchos departamentos) estén preparados para responder siempre que el deber lo requiera, porque el nuestro es un mundo que no para. He aquí otra forma de decirlo: ¡nuestras antiguas definiciones de "hecho" están acabadas!

Nuestra nueva definición es ingeniería de fiabilidad del sitio(SRE). Este término acuñado por Google une para siempre el desarrollo con las operaciones, salvando cualquier brecha persistente que se perciba entre ambos. Y aunque las áreas de interés de la SRE pueden ser asumidas por personal de uno o ambos lados de la ecuación DevOps, hoy en día las empresas suelen tener equipos de SRE dedicados que se encargan específicamente de examinar cuestiones relacionadas con el rendimiento, la eficiencia, la capacidad de respuesta ante emergencias, el monitoreo, la planificación de la capacidad y mucho más. Los profesionales de SRE piensan como ingenieros de software a la hora de idear estrategias y soluciones para los problemas de administración de sistemas. Son las personas que hacen funcionar cada vez más las Implementaciones automatizadas.

Cuando el personal de SRE está contento, significa que las compilaciones son cada vez más fiables, repetibles y rápidas, sobre todo porque el panorama es el de un código escalable, compatible hacia atrás y hacia delante, que opera en entornos sin estado, que dependen de un universo de servidores en explosión y que emiten flujos de eventos para permitir la observabilidad en tiempo real y las alertas cuando algo va mal. Cuando se producen nuevas compilaciones, deben lanzarse rápidamente (con la plena expectativa de que algunas morirán con la misma rapidez). Los servicios deben volver a funcionar plenamente lo antes posible. Cuando las funciones no funcionan, debemos tener la capacidad inmediata de desactivarlas mediante programación a través de una API. Cuando se lanza un nuevo software y los usuarios actualizan sus clientes, pero luego encuentran errores, debemos tener la capacidad de ejecutar reversiones rápidas y sin problemas. Los clientes antiguos y los servidores antiguos deben poder comunicarse con los clientes nuevos.

Y mientras la SRE evalúa y monitorea estas actividades y establece respuestas estratégicas, el trabajo en todas estas áreas corresponde por completo a los desarrolladores. Por tanto, mientras el personal de Desarrollo está haciendo, la SRE es la definición actual de hecho.

Flota como una mariposa...

Además de todas las consideraciones ya mencionadas, una característica fundamental debe definir el código en nuestra era moderna de DevOps (y SRE relacionada): lean. Y con esto nos referimos a ahorrar dinero. "Pero, ¿qué tiene que ver el código con ahorrar dinero?", te preguntarás.

Bien, un ejemplo podría ser el de los proveedores de servicios en la nube, que cobran a las empresas por una plétora de servicios discretos. Algunos de estos costes se ven directamente afectados por el código que producen esos suscriptores corporativos de servicios en la nube.Por tanto, la reducción de costes puede venir de la creación y el uso de herramientas innovadoras para desarrolladores, así como de la escritura e implementación de un código mejor.

La propia naturaleza de una sociedad global, nunca cerrada, impulsada por el software, con un deseo constante de nuevas y mejores funciones y servicios de software, significa que DevOps no puede preocuparse sólo de la producción y las implementaciones, sino que también debe estar atento a la cuenta de resultados de la propia empresa. Y aunque esto pueda parecer una carga más que se añade a la mezcla, piensa en ello la próxima vez que el jefe diga que hay que recortar gastos. En lugar de soluciones negativas e instintivas, como el despido de empleados o la reducción de salarios y prestaciones, el ahorro necesario puede encontrarse en medidas positivas que mejoren el perfil de la empresa, como pasar a trabajar sin servidor y a la nube. Entonces, ¡no se despide a nadie, y el café y los donuts de la sala de descanso siguen siendo gratis!

Ser lean no sólo ahorra dinero, sino que también da a las empresas la oportunidad de mejorar su impacto en el mercado. Cuando las empresas pueden lograr eficiencias sin reducciones de personal, pueden conservar niveles óptimos de fuerza de equipo. Cuando los equipos siguen estando bien compensados y cuidados, estarán más motivados para producir su mejor trabajo posible. Cuando ese trabajo tiene éxito, significa que los clientes sonríen. Mientras los clientes sigan obteniendo rápidamente nuevas funciones que funcionen bien como resultado de Implementaciones más rápidas, bueno... seguirán volviendo a por más y corriendo la voz a los demás. Y ése es un círculo virtuoso que significa dinero en el banco.

Integridad, autenticación y disponibilidad

De la mano y codo con codo con todas y cada una de las actividades de DevOps está la perpetua cuestión de la seguridad.Por supuesto, algunos optarán por abordar esta preocupación contratando a un jefe de seguridad de la información. Y eso está muy bien, porque siempre habrá una persona a la que culpar cuando algo vaya mal. Una opción mejor podría ser analizar realmente, dentro de un marco DevOps, cómo piensan los empleados individuales, los equipos de trabajo y las empresas en su conjunto sobre la seguridad y cómo puede reforzarse.

Hablamos mucho más de esto en el Capítulo 10, pero por ahora considera que: las brechas, los bugs, las inyecciones de Lenguaje de Consulta Estructurado (SQL), los desbordamientos de búfer, etc. no son nuevos. Lo que es diferente es la creciente velocidad de su aparición, su cantidad cada vez mayor y la astucia con la que son capaces de actuar las personas y entidades maliciosas. No es de extrañar. Con cada vez más código liberado, seguirán cada vez más problemas, y cada tipo exigirá soluciones diferentes.

Con Implementaciones más rápidas, cada vez es más crítico ser más reactivo ante los riesgos y amenazas. El descubrimiento en 2018 de las vulnerabilidades de seguridad Meltdown y Spectre dejó claro que algunas amenazas son imposibles de prevenir. Estamos en una carrera, y lo único que se puede hacer es implementar correcciones lo más rápidamente posible.

Urgencia feroz

Ya debería estar claro que DevOps es no un complot, sino una respuesta a las presiones evolutivas. Es un medio para un fin que hace lo siguiente

• Ofrece mejor calidad

• Produce ahorros

• Implementaciones más rápidas

• Refuerza la seguridad

Y no importa a quién le guste o no, ni a quién se le ocurrió la idea primero, ni siquiera su intención original. Lo que importa se trata en la siguiente sección.

La industria del software ha adoptado plenamente DevOps

Bу ahora, toda empresa es una empresa DevOps.Así que súbete a bordo... porque no tienes otra opción.

El DevOps de hoy, en lo que DevOps ha evolucionado, es, como se ha dicho antes, un bucle infinito. No significa que ya no existan grupos ni departamentos, ni que cada uno sea responsable de sus áreas de interés junto con las de todos los demás a lo largo de este continuo.

Significa que todos deben trabajar juntos. Significa que los profesionales del software de una empresa determinada deben ser conscientes y tener en cuenta de forma razonable el trabajo que hacen todos sus colegas. Deben preocuparse por los problemas a los que se enfrentan sus compañeros, por cómo esos problemas pueden afectar y afectan al trabajo que hacen, a los productos y servicios que ofrece su empresa, y por cómo todo ello afecta a la reputación de su empresa en el mercado.

Por eso, ingeniero Dev Ops es un término que no tiene sentido, porque implica la existencia de alguien que puede hacer de forma exhaustiva y competente (o que, al menos, está completamente versado en) todo lo que ocurre dentro del bucle infinito de DevOps. No existe tal persona. Nunca existirá. De hecho, incluso intentar ser ingeniero DevOps es un error, porque va totalmente en contra de lo que es DevOps, que es eliminar los silos en los que los desarrolladores de código están amurallados de los probadores de control de calidad, que están amurallados del personal de lanzamiento, etc.

DevOps es la unión de esfuerzos, intereses y retroalimentación en un esfuerzo continuo por crear, asegurar, implementar y perfeccionar el código. DevOps es colaboración. Y como las colaboraciones son esfuerzos orgánicos y comunicativos, bueno... igual que la ingeniería de la colaboración no existe, tampoco existe la ingeniería de DevOps (a pesar de lo que pueda prometer cualquier instituto o universidad).

Hacer que se manifieste

Saber qué es (y qué no es) DevOps sólo establece un concepto.La cuestión es, ¿cómo puede implantarse y mantenerse de forma sensata y eficaz en las empresas de software de todo el mundo? ¿El mejor consejo? Ahí va.

En primer lugar, puedes tener facilitadores de DevOps, evangelistas de DevOps, consultores y entrenadores de DevOps (y sé cómo Scrum nos estropeó a todos esos términos, pero no hay otros mejores).Eso está bien. Pero DevOps no es una disciplina de ingeniería. Queremos ingenieros de fiabilidad de sitios/servicios, ingenieros de producción, ingenieros de infraestructuras, ingenieros de control de calidad, etc. Pero una vez que una empresa tiene un ingeniero de DevOps, lo siguiente que casi seguro que tendrá es un departamento de DevOps, que no será más que otro silo que probablemente no sea más que un departamento existente al que se le ha cambiado el nombre, para que parezca que la empresa se ha subido al carro de DevOps.

Una oficina DevOps no es un signo de progreso. Más bien, es simplemente una vuelta al futuro. Entonces, lo siguiente que se necesitará es una forma de fomentar la colaboración entre Dev y DevOps, lo que hará necesario acuñar otro término más ¿Qué tal DevDevOps?

En segundo lugar, DevOps tiene que ver con matices y pequeñas cosas. Al igual que las culturas (especialmente las corporativas), tiene que ver con actitudes y relaciones. Puede que no seas capaz de definir claramente esas culturas, pero existen igualmente. DevOps tampoco tiene que ver con código, prácticas de ingeniería o proezas técnicas. Ninguna herramienta que puedas comprar, ningún manual paso a paso ni ningún juego de mesa de edición casera pueden ayudarte a crear DevOps en tu organización.

Se trata de los comportamientos que se fomentan y nutren dentro de las empresas, y gran parte de ello tiene que ver simplemente con la forma en que se trata al personal de base, la estructura de la empresa y los cargos que ocupan las personas. Se trata de la frecuencia con la que las personas tienen la oportunidad de reunirse (especialmente en entornos que no sean reuniones), donde se sientan y comen, hablan de compras y no compras, cuentan chistes, etc. Es en estos espacios, no dentro de los centros de datos, donde se forman, crecen y cambian las culturas.

Por último, las empresas deben buscar activamente e invertir en personas con forma de T (la forma de Ж es aún mejor, como podrían sugerir mis lectores de habla rusa). A diferencia de las personas con forma de I (que son expertos absolutos en un área) o de los generalistas (que saben bastante sobre mucho, pero no dominan ninguna disciplina concreta), una persona con forma de T tiene una pericia de talla mundial en al menos una cosa. Esta es la larga línea vertical de la "T" que enraíza firmemente su profundidad de conocimientos y experiencia. La "T" está atravesada por encima por una amplitud de capacidades acumuladas, conocimientos técnicos y sabiduría en otros ámbitos.

El paquete total es alguien que demuestra una clara y aguda propensión a adaptarse a las circunstancias, aprender nuevas habilidades y afrontar los retos de hoy. De hecho, ésta es una definición casi perfecta de un miembro ideal del personal DevOps. El personal con forma de T permite a las empresas trabajar eficazmente en cargas de trabajo priorizadas, en lugar de sólo en lo que las empresas creen que pueden soportar sus capacidades internas. Las personas con forma de T pueden ver y están intrigadas por el panorama general. Esto las convierte en excelentes colaboradoras, lo que, como resultado, conduce a la construcción de equipos empoderados.

Todos recibimos el mensaje

La buena noticia es que una década después de que el personal de operaciones inventara DevOps, ha comprendido completamente que no se trata sólo de ellos, sino de todos. Podemos ver el cambio con nuestros propios ojos. Por ejemplo, el informe 2019 "Accelerate: State of DevOps" consiguió que participaran en el estudio más desarrolladores que personal de operaciones o de SRE. Para encontrar una prueba más profunda de que las cosas han cambiado, volvamos a Gene Kim.También en 2019, el hombre que ayudó a novelar el extremo de operaciones de la ecuación con El Proyecto Fénix publicó El Proyecto Unicornio (IT Revolution). Si en el libro anterior se daba poca importancia a los desarrolladores, aquí nuestra heroína es Maxine, la desarrolladora principal de su empresa (y salvadora definitiva).

DevOps empezó con las operaciones, de eso no hay duda. Pero la motivación no era la subyugación de los desarrolladores, ni la supremacía de los profesionales de operaciones. Se basaba y se basa en que todo el mundo vea a los demás, aprecie su valor y sus contribuciones a la empresa, no simplemente por respeto o cortesía, sino por interés personal y por la supervivencia, la competitividad y el crecimiento de la empresa.

Y si tienes miedo de que DevOps vaya a abrumarte en un mar de conceptos de operaciones, en realidad lo más probable es que sea al revés. Basta con mirar la definición de SRE de Google (la empresa que inventó la disciplina):

SRE es lo que obtienes cuando tratas las operaciones como si fueran un problema de software.

¿Así que ahora los de operaciones quieren ser desarrolladores? Bienvenidos. Los problemas del software pertenecen a todos los profesionales del software , todo el tiempo. Estamos en el negocio de la resolución de problemas, lo que significa que todo el mundo es un poco SRE, un poco desarrollador, un poco de operaciones... porque todo es lo mismo. Son facetas entrelazadas que nos permiten idear soluciones para el software de hoy, así como para los problemas individuales y sociales del mañana.