Aunque las soluciones PaaS («Plataforma como Servicio») por sí solas no pueden cambiar la forma en que interactúan los individuos y los equipos, a menudo sirven como catalizadores de cambios organizacionales en respuesta a la creciente flexibilidad de las tecnologías de TI.
De hecho, el máximo rendimiento de la inversión en PaaS a menudo solo es posible si se modifican los roles organizacionales, las áreas de responsabilidad (tareas) y los esquemas de relaciones. Afortunadamente, soluciones PaaS como OpenShift Container Platform tienen la flexibilidad suficiente para que cada organización de TI pueda determinar por sí misma la velocidad y la escala de los cambios en relación con las personas involucradas y los procesos en curso.
En la primera etapa de la contenedorización de empresas, la prioridad principal es la implementación de una plataforma de contenedores como un nuevo sistema de despliegue de aplicaciones. En este momento, las organizaciones relacionan trabajos familiares con roles familiares para responder a las solicitudes estándar de los equipos de desarrollo en cuestiones como sistemas de almacenamiento, entornos de despliegue, etc. En las etapas posteriores de la contenedorización, se trata más bien de automatización o de ofrecer a los desarrolladores capacidades de autoservicio para reducir la carga sobre los administradores de sistemas y elevar la autonomía y agilidad de los desarrolladores a un nivel superior. Así es como la organización comienza a avanzar hacia DevOps. En la etapa final de la contenedorización, la empresa llega a un modelo DevOps más limpio y canónico, en el que muchas de las tareas y trabajos anteriores son asumidos por equipos multifuncionales que se agrupan no por plataforma o tecnología, sino desde la perspectiva de garantizar el funcionamiento de aplicaciones o servicios de aplicación.
En este post, presentaremos una guía sobre cómo realizar los cambios organizacionales necesarios y explicaremos cómo cambian los roles tradicionales de TI con la implementación de tecnologías de contenedores en la empresa.
La asignación de nuevos trabajos a roles antiguos
En su forma básica, el modelo organizativo de PaaS se forma para asignar de manera más flexible y rápida los recursos de TI a las aplicaciones como entorno de ejecución. Y aunque esto proporciona ciertas ventajas a los administradores de sistemas, los desarrolladores generalmente no obtienen beneficios significativos ni nuevas oportunidades, ya que en esta etapa la empresa puede funcionar sin necesidad de comenzar la automatización, implementar autoservicio o mejorar radicalmente el proceso de despliegue. Al afectar mínimamente los procesos de desarrollo en esta etapa, PaaS, sin embargo, aumenta la dinamismo del sistema de TI, lo que permite a los administradores atender mejor las solicitudes de los desarrolladores. Por ejemplo, si antes la creación de un entorno de desarrollo a partir de varios máquinas virtuales y volúmenes de almacenamiento podía llevar días o incluso semanas, requiriendo la participación de varios administradores diferentes, en PaaS todo se hace mucho más rápido y por solo un administrador. En otras palabras, los equipos de desarrollo presentan solicitudes como antes, pero el trabajo para implementar estas solicitudes ahora se realiza de una nueva manera.
En camino hacia una organización DevOps
Al lanzar PaaS y transferir a ella a los especialistas en operaciones de sistemas TI y a los desarrolladores de aplicaciones, la organización puede continuar implementando la metodología DevOps, que entre otras cosas incluye los siguientes principios fundamentales:
- Dividir el trabajo en pequeños pasos, para obtener retroalimentación en las primeras etapas, reducir riesgos y evitar el 'parálisis analítica';
- Automatizar las operaciones en suficiente medida, para no crear obstáculos o cuellos de botella en el proceso de despliegue de la aplicación;
- El intercambio de conocimientos es clave para construir confianza;
- Pagar regularmente la deuda técnica, reservando tiempo en cada ciclo de trabajo para mejoras sistemáticas.
En la segunda etapa de la implementación de tecnologías contenedorizadas, los equipos de desarrollo, naturalmente, comienzan a ver oportunidades de mejora, y la empresa se inclina hacia un modelo DevOps más canónico. El mecanismo tradicional de presentación y ejecución de solicitudes de servicio ahora se considera un cuello de botella, por lo que la organización busca automatizar acciones repetitivas y proporcionar a los desarrolladores capacidades de autoservicio. Además, estas capacidades de los desarrolladores en el marco de una solicitud determinada son definidas por el esfuerzo conjunto de los especialistas de TI encargados de la operación de plataformas y aquellos responsables de la entrega de aplicaciones. En otras palabras, los administradores de sistemas que realizaban acciones basadas en solicitudes de desarrolladores son reemplazados por estas dos categorías de empleados, quienes son responsables de describir y aplicar políticas que regulan lo que los desarrolladores pueden hacer por su cuenta. Los procedimientos automatizados ayudan a garantizar el cumplimiento de estos requisitos y a coordinar acciones en aquellos casos en que la situación se sale de las políticas vigentes.
La transición a un cronograma iterativo, en el que el entorno de TI y el modelo operativo experimentan cambios iterativos a lo largo del tiempo, es un hito crítico en el desarrollo de un sistema DevOps maduro en la empresa. El grado de adopción de la metodología DevOps depende de la tolerancia de cada organización específica a los cambios y de qué cambios traen el mayor beneficio. Por ejemplo, si la necesidad de crear nuevos entornos o aplicaciones surge de manera poco frecuente, entonces la optimización de las acciones correspondientes será menos importante que el fortalecimiento del control de los desarrolladores sobre el ciclo de vida de las aplicaciones.
Nuevas tareas que surgen en las organizaciones de TI al pasar a OpenShift
En esta sección, abordaremos los roles y tareas que las organizaciones que han adoptado OpenShift suelen aplicar para acelerar la automatización y el autoservicio utilizando tecnologías y PaaS.
En la tabla a continuación se enumeran las principales tareas de nivel superior que existen en cualquier organización que haya implementado OpenShift, con ejemplos de trabajos y habilidades correspondientes. Esta lista de tareas no debe confundirse con un esquema de desglose del trabajo o con la estructura organizativa del equipo; es solo un conjunto de tareas que deben ser atendidas por las personas responsables del apoyo a la infraestructura de TI para una implementación exitosa de la plataforma de contenedores. De hecho, más adelante mostraremos que la implementación de tecnologías de contenedores crea las condiciones para desarrollar una estrategia de DevOps más madura en la empresa, lo que a su vez aumenta el grado de multifuncionalidad de los equipos y reduce los riesgos de especialización estricta tanto a nivel de empleados individuales como de equipos.
Tabla 1. Definiciones de las tareas de OpenShift
Tareas
Habilidades requeridas
Automatización y aprovisionamiento de infraestructuras de TI
Trabajos:
- Diseño y construcción de soluciones de hardware
- Organización y soporte de la automatización de la configuración inicial
- Diseño y automatización del aprovisionamiento de máquinas virtuales y hosts
- Diseño e implementación de centros de datos
- Administración de sistemas Linux
- Scripts de automatización
- Conocimiento de sistemas de almacenamiento
- Conocimiento en diseño e implementación de redes
- Seguridad
Instalación y gestión de la plataforma OpenShift
Trabajos:
- Realización de la instalación del clúster
- Gestión de servicios de infraestructura
- Gestión de la escalabilidad de la plataforma
- Autenticación y autorización a nivel de plataforma
- Administración de sistemas Linux
- Conocimiento de tecnologías de red
- Scripts de automatización (Ansible)
- Conocimiento de sistemas de almacenamiento
- Conocimiento de tecnologías y arquitecturas de contenedores
- Conocimiento de las arquitecturas de Kubernetes y OpenShift
- Seguridad de las plataformas
- Integración de la monitorización
Gestión del aprovisionamiento de entornos de cliente (tenant provisioning), aislamiento con recursos de TI
Trabajos:
- Creación de usuarios y equipos dentro de la plataforma
- Diseño y gestión de cuotas
- Diseño e implementación de RBAC
- Conocimiento de las arquitecturas de Kubernetes y OpenShift
- Conocimiento de tecnologías y arquitecturas de contenedores
- Scripts de automatización
- Buenos conocimientos en proyectos, cuotas, asignación de roles y trabajo con planificadores
Compilación y gestión de imágenes base
Trabajos:
- Desarrollo de un flujo de trabajo para cambios en imágenes
- Desarrollo de imágenes basado en estándares
- Administración de sistemas Linux
- Scripts de automatización
- Configuración de componentes runtime de aplicaciones y middleware
- Conocimiento de arquitecturas de contenedores
- Frameworks de compilación de aplicaciones
- Buenos conocimientos en imágenes, imagestream y plantillas
Diseño y gestión de pipelines de implementación
Trabajos:
- Diseño y documentación de estándares de pipelines
- Desarrollo de guías breves y plantillas
- Capacitación de desarrolladores
- Gestión del código fuente
- Diseño e implementación de aplicaciones
- Scripts de automatización
- Pruebas automatizadas
- Pruebas de calidad del código
- Conocimiento de arquitecturas de contenedores
- Conocimiento de infraestructuras inmutables
- Seguridad: gestión de acceso a etapas del pipeline, aprobación de flujos de trabajo, etc.
- Buen conocimiento de plantillas de OpenShift, componentes buildconfigs, deploymentconfigs, services, routes, configmaps
Desarrollo de aplicaciones y pruebas
Trabajos:
- Codificación de aplicaciones
- Desarrollo de pruebas automatizadas
- Respuesta ante fallos de pruebas durante el pipeline de implementación
- Respuesta ante fallos de aplicaciones
- Pruebas de aceptación del usuario
- Diseño e implementación de aplicaciones
- Pruebas automatizadas
- Gestión del código fuente
- Monitoreo de aplicaciones
- Conocimiento de arquitecturas de aplicaciones nativas de la nube (cloud native)
Monitoreo operativo y gestión de aplicaciones
Trabajos:
- Diseño de aplicaciones en el contexto del rendimiento
- Monitoreo de aplicaciones en fase de ejecución
- Escalado de aplicaciones (o autoescalado)
- Gestión de la disponibilidad de aplicaciones
- Cuotas de solicitudes y límites para la gestión de recursos
- Pruebas de rendimiento y capacidades de TI
- Diseño e implementación del rendimiento de aplicaciones
- Monitoreo del rendimiento de aplicaciones
- Pruebas de rendimiento y pruebas de carga
Pruebas de aceptación del usuario
Trabajos:
- Pruebas de interfaz de usuario (diseño e interacciones del usuario)
- Desarrollo de pruebas automatizadas
- Diseño y verificación de interfaces de usuario
- Plantillas de pruebas automatizadas
- Marcos de pruebas
- Plantillas de diseño de aplicaciones
Nuevos roles que surgen en la organización de TI al adoptar OpenShift
A medida que se transita hacia un modelo organizacional orientado a DevOps, la especialización de los roles tiende a disminuir, mientras que el número de equipos y roles multifuncionales tiende a aumentar para maximizar la efectividad en la colaboración. Esta es, a nuestro entender, la lista de posiciones clave en una organización de TI que utiliza OpenShift:
- Ingeniero de operaciones de aplicaciones (Application Operations Engineer) O Ingeniero de fiabilidad del sitio (Site Reliability Engineer). Anteriormente, este cargo podría haberse llamado 'Administrador de servidor de aplicaciones'.
- Desarrollador de aplicaciones/desarrollador de software/ingeniero de programación.
- Administrador de clúster/plataforma de aplicaciones. Anteriormente, este rol podría haber sido llamado "Administrador de sistemas" o "Administrador de plataformas Linux".
- Gerente de lanzamiento de software (Release Manager)/Ingeniero de compilación (Build Engineer).
Matriz de roles y tareas RACI
Finalmente, pasamos a alinear las posiciones y tareas discutidas anteriormente para ofrecer una visión general de cómo debería estructurarse la organización que implemente DevOps en la plataforma OpenShift. Originalmente, los roles mencionados a continuación pueden ser desempeñados por diferentes ramas de la antigua estructura organizativa tradicional. Pero con el tiempo, se produce una consolidación y surgen nuevos equipos, organizados en torno a las aplicaciones, que asumen la mayoría o incluso todas las tareas mencionadas a continuación.
Tareas
Roles
Ingeniero de operaciones de aplicaciones / Ingeniero de confiabilidad del sitio
Desarrollador de aplicaciones / Desarrollador de software / Ingeniero de programación
Administrador de clúster/plataforma de aplicaciones
Gerente de lanzamiento de software / Ingeniero de compilación
Automatización y aprovisionamiento de infraestructuras de TI
I
I
R/A
C
Instalación y gestión de la plataforma OpenShift
C
I
R/A
C
Diseño y gestión de pipelines de implementación
C
C
I
R/A
Gestión de la preparación de entornos de clientes (tenant provisioning), aislamiento y capacidades de TI
C
I
R/A
I
Compilación y gestión de imágenes base
R
C
R/A
C
Desarrollo de aplicaciones y pruebas
C
R/A
I
I
Monitoreo operativo y gestión de aplicaciones
R/A
C
C
I
Pruebas de aceptación del usuario
C
R
I
I
Convenciones en la matriz RACI
Fuente:
- Responsible – Ejecutante – quien realiza lo necesario para completar la tarea.
- Accountable – Responsable – el empleado que, en última instancia, es responsable de la correcta y exhaustiva ejecución de la tarea o de alcanzar el resultado; también es el único que puede delegar el trabajo a los ejecutantes.
- Consulted – Consultores – por lo general, son expertos en el tema, cuyos consejos son solicitados; se mantiene una comunicación bidireccional con ellos.
- Informed – Informados – personas que están al tanto de los acontecimientos (a veces, solo al final de la tarea o al alcanzar el resultado); reciben información de manera unilateral.
Cómo funciona la colaboración entre equipos en una organización DevOps
El esquema tradicional para la obtención de recursos generalmente consiste en un ciclo de solicitudes para la asignación de recursos, que luego son ejecutadas por varios equipos. Finalmente, todos los recursos necesarios son asignados y confirmados por la parte solicitante. A menudo, estos procesos son parcialmente, o incluso totalmente, manuales y requieren frecuentes e innumerables interacciones entre equipos para el procesamiento exitoso de cada solicitud.
Figura 1. Organización de TI tradicional
El diagrama anterior ilustra las relaciones típicas entre los equipos en una organización de TI tradicional. En este esquema, algunos equipos solicitan a otros equipos la realización de trabajos necesarios, utilizando medios de comunicación más o menos formalizados, como sistemas de tickets o correos electrónicos. Luego, estas solicitudes entran en una cola y esperan su turno, y la larga espera a menudo lleva a un deterioro, e incluso a un agravamiento de las relaciones entre los equipos. La tensión se agrava aún más porque los miembros de diferentes equipos rara vez se encuentran en persona y, por lo general, solo comparten la información mínima necesaria.
Figura 2. Organización de TI DevOps
En este diagrama se muestra cómo se organiza la colaboración en una organización DevOps. Aquí, los mismos equipos del diagrama anterior han abandonado las comunicaciones ineficaces que aumentaban la desconexión y las han reemplazado por contactos personales, creando así canales permanentes de interacción entre los equipos. Estos canales fomentan la formación de un conjunto híbrido de habilidades que ayuda a los empleados a comprender mejor y representar las necesidades, problemas y oportunidades de los equipos que representan. Los equipos se permiten realizar los trabajos necesarios a través de portales de autoservicio automatizados en lugar de tener que gestionar manualmente las solicitudes de cambio de otros, como sucedía antes. Y gracias a la existencia de canales de interacción, estos sistemas de autoservicio pueden adaptarse rápidamente a las necesidades de los equipos para los que fueron creados. Para lograr una mayor comprensión mutua y un intercambio de conocimientos dentro de la organización, los miembros de los equipos realizan periódicamente rotaciones de roles para obtener experiencia en la interacción con diferentes equipos y comprender mejor el panorama general de los sistemas de TI que gestionan, aumentando así su nivel de capacidad transversal y utilidad.
Resumiendo
En este artículo, explicamos cómo la implementación de soluciones PaaS puede impulsar a una organización a adoptar la metodología DevOps, durante la cual se transforman los roles y tareas tradicionales. Por lo tanto, enumeramos las principales tareas de TI que surgen en la organización al migrar a OpenShift, así como las habilidades necesarias para llevarlas a cabo. También proporcionamos un conjunto básico de roles organizacionales que emergen al formar equipos multifuncionales de DevOps y una matriz RACI que vincula los nuevos roles con las nuevas tareas. Por último, describimos cómo la plataforma OpenShift y la metodología DevOps asociada pueden transformar la estructura organizativa de la organización al pasar de una jerarquía tradicional y sistemas de gestión de solicitudes a equipos multifuncionales con un mayor nivel de comunicación personal.
Fuente: habr.com
