¿Están convergiendo los desarrolladores y DevOps?

¿Están convergiendo los desarrolladores y DevOps?

¿Están sus desarrolladores en PagerDuty? Ésta es la pregunta clave y para la mayoría de los equipos la respuesta es un rotundo «sí». Este es un gran cambio con respecto a hace unos años cuando, a menos que tuvieras equipos de DevOps o SRE, la respuesta era un rotundo «no». Entonces, ¿qué ha cambiado? Se está produciendo una tendencia a largo plazo en empresas grandes y pequeñas: la convergencia entre los desarrolladores, quienes codifican aplicaciones, y DevOps, quienes mantienen los sistemas en los que se ejecutan las aplicaciones y los desarrolladores codifican. Hay tres razones principales para este cambio: (1) la transformación a la nube, (2) el paso a un único almacén de datos de observabilidad y (3) el enfoque de los esfuerzos del trabajo técnico en los KPI empresariales. El impacto inminente en DevOps en términos de rol, flujo de trabajo y alineación empresarial será profundo. Antes de profundizar brevemente en las tres razones, en primer lugar, ¿por qué debería importarles a los líderes empresariales? El papel de DevOps y la dinámica de equipo: las líneas entre equipos tradicionalmente separados se están desdibujando a medida que los desarrolladores, DevOps y SRE chocan cada vez más. Las mejores organizaciones adaptarán los roles y habilidades de los equipos y cambiarán los flujos de trabajo hacia enfoques más cohesivos. Una forma clave es comunicarse en torno a conjuntos de datos combinados en lugar de proveedores distintos y separados creados y aislados en función de roles. Si bien todos los roles técnicos se verán afectados, DevOps sentirá el mayor cambio a medida que las empresas redefinan su rol y la mentalidad que se requerirá de los miembros de su equipo en el futuro. Rentabilidad: a medida que las organizaciones se adaptan al nuevo paradigma, la composición del equipo también debe adaptarse en consecuencia. Se necesitarán diferentes habilidades, se utilizarán diferentes proveedores y se consolidarán los costos. Adaptado a la cultura y las expectativas: ¿quién estará de guardia con PagerDuty? ¿Cómo cambiarán las funciones de DevOps y SRE cuando los desarrolladores puedan monitorear, alertar y resolver directamente sus propios problemas? ¿Cuáles serán las expectativas de clasificación a medida que los equipos trabajen más estrechamente y se centren en los resultados comerciales en lugar del tiempo de actividad? DevOps no se limitará a crear proveedores, mantener herramientas de desarrollo y monitorear los costos de la nube. Transformación de la nube Este es un tema muy popular, por lo que la historia es corta… A los proveedores les encantaría eliminar por completo los roles en sus equipos, especialmente DevOps y SRE. El paso a la nube significa que todo es virtual. Si bien se puede decir que la nube es más inmensa en términos de complejidad, los equipos ya no tienen que lidiar con equipos físicos que literalmente requieren que haya alguien en el sitio o en la oficina. Con entornos virtuales, los proveedores de la nube y relacionados con la nube administran la infraestructura, la configuración de los proveedores, las herramientas de desarrollo y las medidas de costos… todo con el objetivo de reducir la configuración y eliminar el mantenimiento continuo. El rol de DevOps no va a desaparecer… al menos no en el corto plazo, pero debe ser flexible y estar alineado. Debido a que los proveedores de la nube facilitan a los desarrolladores la ejecución y el mantenimiento de aplicaciones, DevOps en su encarnación actual es innecesario. Los propios proveedores y desarrolladores pueden respaldar la infraestructura y las aplicaciones, respectivamente. En cambio, DevOps necesitará justificar sus esfuerzos de trabajo en función de los KPI comerciales, como los ingresos y la deserción. Un pequeño subconjunto del equipo actual de DevOps tendrá KPI relacionados con la eficiencia de los desarrolladores, convirtiéndose en el guardián interno para hacer cumplir la estandarización entre los desarrolladores y todo el ciclo de vida del software, incluida la forma en que se crean, prueban, distribuyen y monitorean las aplicaciones. Luego, los desarrolladores pueden ser responsables de la eficacia y eficiencia de sus aplicaciones (y de la infraestructura subyacente) de principio a fin. Esto significa que los desarrolladores, no los DevOps, utilizan PagerDuty, monitorean los problemas en toda la pila y responden a los incidentes. Un único almacén de datos de observabilidad Los proveedores y las herramientas están convergiendo en un único conjunto de tipos de datos. Al observar las acciones de los diferentes equipos de ingeniería, los esfuerzos se pueden dividir fácilmente en análisis (por ejemplo, producto, experiencia, ingeniería), monitoreo (por ejemplo, usuario, aplicación, infraestructura) y seguridad. Lo interesante es que estos depósitos actualmente utilizan diferentes proveedores creados para roles específicos, pero los conjuntos de datos subyacentes se están volviendo rápidamente los mismos. Esto no era cierto hace apenas unos años. La definición de datos de observabilidad es recopilar *todos* los datos no estructurados creados dentro de las aplicaciones (tanto del lado del servidor como del lado del cliente) y la infraestructura circundante. Si bien la estructura de estos datos varía según la disciplina, siempre se transforma en cuatro formas: métricas, registros, seguimientos y, más recientemente, eventos. Los proveedores actuales generalmente piensan en estos cuatro tipos por separado: uno se utiliza para registros, otro para seguimientos, un tercero para métricas y otro más para análisis. Sin embargo, al combinar estos cuatro tipos, se crea la base de un almacén de datos común. Los casos de uso para estos tipos de datos comunes se vuelven inmensos porque el análisis, el monitoreo y la seguridad utilizan los mismos tipos de datos subyacentes y, por lo tanto, deben aprovechar el mismo repositorio. Por lo tanto, la pregunta no es tanto cómo recopilar y almacenar los datos (que a menudo es la fuente de dependencia del proveedor), sino cómo utilizar los datos combinados para crear análisis que informen y protejan mejor el negocio. La convergencia entre los desarrolladores y los equipos de DevOps (y en este caso posiblemente también el producto) es que necesitan los mismos datos para todos sus casos de uso. Con los mismos datos, los equipos pueden hablar cada vez más el mismo idioma. Los flujos de trabajo que antes eran dolorosos ahora se vuelven posibles. (Ya no hay acusaciones entre DevOps y desarrolladores). Los esfuerzos de trabajo se alinean más en lo que impulsa a la empresa y menos en lo que cada proveedor individual cree que es más importante. Los roles entonces se vuelven borrosos en lugar de tener líneas de demarcación claras. Centrar los esfuerzos laborales en los KPI comerciales Los equipos están cada vez más impulsados ​​por los objetivos y las ganancias comerciales. Para DevOps, el enfoque está cambiando del bajo nivel actual de tiempo de actividad y SLA a aquellos KPI relacionados con ingresos, abandono y experiencia del usuario. Además, con la alineación empresarial, se pide a los desarrolladores y DevOps que informen de manera diferente y justifiquen sus esfuerzos y prioridades de trabajo. Por ejemplo, un gran minorista de Fortune 500 celebra reuniones mensuales entre sus grupos técnicos (esto no incluye a los gerentes de producto). Analizan los KPI en los que se centran los líderes empresariales, especialmente la pérdida de ingresos. Los desarrolladores (no DevOps) seleccionan métricas y errores específicos como indicadores principales de pérdida de ingresos y los desglosan por tipo (por ejemplo, fallas, registros de errores, ANR), impacto en el usuario (por ejemplo, tasa de abandono) y área de aplicación de aplicaciones afectadas. (por ejemplo, inicio, flujo de compras). Tenga en cuenta que no se menciona la métrica de DevOps. El grupo no analiza las métricas utilizadas históricamente en torno al tiempo de actividad y los SLA porque son suposiciones… y no se pueden utilizar para priorizar el trabajo y hacer crecer mejor el negocio. El objetivo es priorizar los esfuerzos de los desarrolladores y DevOps para lograr los objetivos comerciales. Esto significa que los equipos de ingeniería ahora deben justificar el trabajo, lo que requiere una inversión total por parte del equipo en este nuevo enfoque. En muchos sentidos, esto es más simple que la metodología anterior basada en KPI técnicos de conducción separados. DevOps debe ser flexible y estar alineado DevOps no está desapareciendo por completo, pero debe evolucionar junto con los cambiantes panoramas tecnológicos y comerciales del mundo actual impulsado por KPI. Quienes están en DevOps se han adaptado a la rápida adopción de la nube y deben adaptarse nuevamente al hecho de que los avances tecnológicos y la consolidación de fuentes de datos los afectarán. A medida que las infraestructuras de la nube se vuelvan más modulares y más fáciles de mantener, los proveedores forzarán más cambios en las funciones y responsabilidades de DevOps. Y a medida que se establezcan la observabilidad, el análisis y la seguridad de los datos, surgirá una gran cantidad de proveedores (como Databricks, Confluent y Snowflake) para gestionar esta complejidad. Por lo tanto, los datos serán más accesibles y fáciles de aprovechar, lo que permitirá a los desarrolladores y líderes empresariales conectar los datos con un valor real, alineando los esfuerzos laborales con el impacto empresarial. DevOps debe hacer lo mismo, alineando sus esfuerzos con los objetivos que tienen el mayor impacto empresarial.

About Francisco

Check Also

¿El secreto para mejores productos?  Deje que los ingenieros impulsen la visión

¿El secreto para mejores productos? Deje que los ingenieros impulsen la visión

A mitad de mis cinco años y medio en SpaceX, la gerencia decidió cambiar la …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *