Cuando hablamos de la arquitectura de microservicios, un conjunto de componentes autónomos, prácticamente independientes entre sí, aparece ante nuestros ojos. El aislamiento es la piedra angular de cualquier sistema de microservicio. Pero, incluso si confiamos en nuestra capacidad para crear microservicios, surge la pregunta: ¿cuánto está lista la estructura de la organización para tal tarea? ¿Somos capaces de capitalizar las oportunidades y limitaciones que traen los microservicios? ¿Cómo adaptar equipos para trabajar con éxito con esta arquitectura? En este artículo trataremos de discutir el aspecto organizacional del desarrollo de un sistema de microservicio.
Enfoque tradicional
Las grandes corporaciones empresariales se han organizado históricamente como un conjunto de unidades funcionales: financieras, de marketing, operativas, de recursos humanos, etc. La necesidad de la automatización digital de los procesos comerciales ha llevado a la compañía a formar otra unidad funcional: el departamento de TI. A su vez, el departamento de TI se dividió posteriormente en equipos funcionales de programadores, evaluadores y administradores de sistemas, por el principio de combinar grupos de especialistas con un cierto conjunto de conocimientos y funciones. El patrón del pensamiento organizacional se ve con bastante claridad. Y su estabilidad se asocia no tanto con la renuencia a hacer esfuerzos para analizar la efectividad de la gestión, sino con la gran inercia de los procesos y la ausencia de desafíos obvios que pondrían en peligro el éxito de la organización.
Sin embargo, la separación del personal de acuerdo con sus funciones inevitablemente crea una distancia entre los equipos. Cuando las pruebas de software las lleva a cabo un equipo separado de evaluadores, los desarrolladores se centran únicamente en escribir código y se preocupan poco por su capacidad de prueba. Como resultado, el producto de software tiene numerosas desviaciones en las especificaciones y, lo que es peor, los equipos se están convirtiendo gradualmente en otros.
Nota: Una mentalidad de silo es una renuencia a compartir.
información con empleados de otras unidades de la misma organización. Tal
el comportamiento a menudo conduce a una disminución en la efectividad organizacional y, en el peor de los casos
El caso lleva a la destrucción de la cultura corporativa.Además, en unidades estrictamente funcionales, el proceso de toma de decisiones inevitablemente se ralentiza. Los costos de coordinar los horarios de trabajo del equipo están aumentando. Las calificaciones y la experiencia de los mismos probadores, por ejemplo, necesitan un equilibrio constante teniendo en cuenta los detalles que requieren los equipos de desarrollo. Sí, y un alto umbral de entrada y la necesidad de transferencia de conocimiento retrasan el proceso: los expertos externos requieren un cambio constante del contexto de la tarea para atender las solicitudes de varios equipos.
Por lo tanto, cuando las empresas con una estructura organizativa tradicional se enfrentan a la necesidad de una respuesta casi instantánea a los desafíos que continuamente surgen del negocio, sus departamentos de TI no pueden garantizar la eficacia de las soluciones. La rápida evolución de la tecnología solo exacerbó este retraso y complicó la tarea de mantener el nivel requerido de motivación y profesionalismo en equipos dedicados al servicio del desarrollo. Y dado que el objetivo principal de TI era y es garantizar efectivamente el ciclo de vida completo de los productos independientes (incluidos los microservicios), se hizo evidente la necesidad de reorganizar los equipos de equipos funcionales orientados horizontalmente a equipos autónomos y orientados verticalmente.
Comandos funcionales cruzados
Según Wikipedia, un equipo multifuncional es un grupo de personas con diversas tareas funcionales y que trabajan hacia un objetivo común. En los negocios de hoy, la innovación es una ventaja competitiva líder. Los equipos interfuncionales fomentan la innovación a través de la colaboración creativa, tanto dentro del equipo como con otros equipos de la organización.
Figura 1. Equipos funcionales y multifuncionales.El equipo de desarrollo de microservicios multifuncional está formado por desarrolladores, ingenieros de bases de datos, probadores, ingenieros de infraestructura y otros especialistas. Dichos equipos realizan modificaciones más rápido que las funcionales, porque pueden tomar sus propias decisiones y trabajar independientemente de otros equipos. Al centrarse en mejorar el tiempo del ciclo de desarrollo e implementar la implementación continua, estos equipos pueden resolver problemas casi instantáneamente.
Shamim Mohammad, Director de TI de CarMax, dice: “En un mundo en rápida evolución, es importante crear equipos de productos flexibles y multifuncionales que puedan clasificar rápidamente las soluciones a un problema. Están dotados de todos los poderes necesarios y la gerencia nunca les dice cómo resolver el problema, sino solo en qué consiste y cuáles son los indicadores clave de rendimiento con los que trabajar. Este enfoque le permite mejorar la retroalimentación, acelerar significativamente el proceso de desarrollo, usar prueba y error para finalmente encontrar la mejor solución para clientes y socios. También descubrimos que los equipos tienen un riesgo más razonable y son creativos para lograr sus objetivos. Si no tiene equipos tan completamente integrados, eche un vistazo y piense, ¿está listo para una transformación digital exitosa? "
Según las encuestas del Massachusetts Institute of Technology y Deloitte Global Human Capital Trend, las empresas con un alto nivel de digitalización de procesos en el desarrollo de sus innovaciones dependen en gran medida de la presencia de equipos multifuncionales. El 83% de las empresas maduras admiten que utilizan equipos multifuncionales. A pesar de la mayor complejidad operativa (costos adicionales de hasta el 16%), las empresas recibieron mejoras significativas en los indicadores operativos (hasta el 53%), mejor acceso a recursos y activos (hasta el 37%), mayor flexibilidad (hasta el 12%) y una disminución en el nivel de burocracia excesiva debido a la reducción de la jerarquía de la estructura organizacional (hasta 11%).
Figura 2. Beneficios de adaptar equipos multifuncionales. EstadísticasUna transición suave y gradual de equipos funcionales a equipos multifuncionales es bastante posible. Los primeros equipos interfuncionales se forman en torno a las oportunidades comerciales más valiosas que requieren atención constante y respuesta rápida de TI. Los miembros de los equipos funcionales se trasladan a equipos interfuncionales, al tiempo que profundizan su experiencia y generalmente mejoran la autonomía del equipo y el proceso de toma de decisiones. En algún momento, los comandos funcionales se transforman completamente en un conjunto de comandos multifuncionales.
Figura 3. Transición a un equipo multifuncional.El surgimiento de equipos de plataforma
Sin embargo, la mera presencia de equipos interfuncionales no significa que hayamos proporcionado las mejores condiciones para la creación de microservicios y que cumplamos de manera más efectiva los requisitos del negocio. Todavía hay una serie de tareas relacionadas con el desarrollo, soporte y mantenimiento, las más importantes son:
- Sincronización (consistencia) de datos;
- Obsolescencia de datos
- Seguridad;
- Comunicación entre servicios;
- Servicio de descubrimiento;
- Registro distribuido y monitoreo;
- Dependencias cíclicas entre servicios y depuración;
- Prueba;
- Fiabilidad y tolerancia a fallos;
- Rendimiento
La mayoría de ellos no son tareas locales de ningún microservicio en particular. Estas son las tareas del nivel del sistema en su conjunto y más relacionadas con la infraestructura del sistema de microservicio. Muchas organizaciones llaman a esta infraestructura una "plataforma", la base sobre la cual se crean y desarrollan los microservicios.
De hecho, con el crecimiento de la organización, aumenta su dependencia de las tecnologías utilizadas. Múltiples áreas de inconsistencia surgen cada vez más a menudo, lo que lleva a la organización a perder su capacidad de avanzar rápidamente en el mercado, evaluar oportunidades emergentes e innovar. Una posible salida de esta situación es la transición al uso de una "plataforma digital" que consiste en "bloques de oportunidades" en las áreas más importantes de la actividad de la organización (como la infraestructura para entregar soluciones o interactuar con el cliente). Las plataformas digitales minimizan la brecha entre conceptos e inversiones; mejorar la estabilidad del sistema y, lo que es más importante, mejorar el microclima dentro de la organización.
Muchas organizaciones de TI se preguntan: ¿cuánto personal debe asignarse para trabajar directamente en el "producto" y cuál trabajar en la "plataforma"? Uno de los argumentos más importantes para el beneficio de dicha separación de personal es el siguiente: una plataforma digital necesita propietarios que estén dedicados a garantizar el cumplimiento de los principios declarados por la plataforma, que tengan una amplia experiencia y un alto nivel de experiencia en el desarrollo, implementación y mantenimiento de plataformas.
Para ilustrar la necesidad de la introducción de plataformas digitales como un producto independiente, recurrimos a uno de los principios fundamentales de los microservicios: el uso de filtros inteligentes y canales simples.
No importa cuán simple sea el canal, todavía requiere un propietario. Y si hay muchos equipos, cada uno de los cuales "posee su propio microservicio", ¿quién es responsable de su interacción? ¿Para el descubrimiento de servicios, por seguridad, monitoreo a nivel de todo el sistema (o incluso a nivel de organización, si se trata del nivel entre sistemas)? ¿Quién será responsable de las pruebas integrales? Si comenzamos a asignar estas responsabilidades a equipos particulares de desarrollo de microservicios, ¿cuál será nuestra estrategia y criterios de selección? Y finalmente, ¿esos equipos (desarrollo, les recuerdo) seguirán siendo flexibles y autónomos en sus productos? ¡Parece que ha llegado el momento en que el equipo de desarrollo de la plataforma debería aparecer en el escenario!
El equipo de desarrollo de la plataforma (abreviado como equipo de plataforma) es un equipo multifuncional especializado que gestiona la plataforma digital, la base para la formación de API, herramientas y servicios, cuyo conocimiento y soporte están organizados en un producto interno independiente.
La estrategia de la plataforma digital se centra en proporcionar valor comercial. Para eliminar inconsistencias en la construcción de un ecosistema de microservicios, la estrategia se enfoca en cinco áreas principales de entrega de soluciones tecnológicas:
- Infraestructura de entrega;
- Arquitectura API y arreglo;
- Datos de autoservicio;
- Infraestructura experimental y telemetría;
- Interacción con el cliente.
Figura 4: Estrategia de plataforma digitalLos equipos de microservicios independientes tienen la oportunidad de usar la plataforma para acelerar el soporte para las funciones de sus productos y al mismo tiempo reducir el grado de coordinación necesaria entre equipos.
Sin lugar a dudas, el concepto de equipos de plataforma especializados dedicados tiene ventajas y desventajas:
Los beneficios incluyen:
- unificación y secuencia de canales de comunicación;
- proporcionando control mientras se mantiene la flexibilidad de los equipos de desarrollo individuales.
Las desventajas incluyen:
- costos de tiempo para adaptar la estrategia en la organización;
- la necesidad de recursos adicionales: el equipo de la plataforma necesita estudiar los detalles de los diversos equipos de microservicios, así como los requisitos de formulario para crear una plataforma unificada;
- Si la plataforma no se implementa correctamente, se convertirá en un cuello de botella en los procesos de la organización.
Por lo tanto, debemos tener en cuenta los posibles problemas y riesgos al planificar las actividades del equipo y entre equipos dentro de la organización.
Sinergia de interacción
Entonces, ¿cómo puede ocurrir la interacción con el equipo de la plataforma? Existen varios enfoques posibles, entre los cuales se pueden distinguir dos:
- Usando la plataforma como producto. El equipo de la plataforma actualiza regularmente las versiones de la plataforma y la proporciona a los equipos de microservicios como una API de producto. Esto puede ser una imagen de una máquina virtual, o un contenedor con capacidades mejoradas (en comparación con la versión anterior), o un marco extensible.
- Penetración en los equipos de microservicios cuando un representante del equipo de la plataforma está presente en el equipo de microservicios (o uno de los miembros del equipo de microservicios está asignado para la comunicación con el equipo de la plataforma). Al utilizar este enfoque, los equipos de microservicios tienen la oportunidad de recibir comentarios más rápidos con el equipo de la plataforma y pueden iniciar el proceso de introducir cambios en la plataforma.
Figura 5: Interacción con el equipo de desarrollo de la plataforma: a la izquierda está la plataforma como producto, a la derecha está la penetración en los equipos.Conclusión
En conclusión, me gustaría enfatizar una vez más que la estructura organizativa debería permitir el uso efectivo de las ventajas de la elección arquitectónica y tecnológica. La ley de Conway establece que una organización busca crear proyectos que sean copias de la estructura organizacional. Pero también me inclino a creer que lo contrario es cierto: la estructura del sistema le dice a la organización cuál es la estructura más adecuada para su implementación.
Para garantizar la calidad de respuesta necesaria a las solicitudes comerciales, la industria moderna de TI debe tener el más alto nivel de flexibilidad organizacional. Y, para no perder la efectividad del sistema que estamos tratando de crear, debemos considerar la necesidad y la posibilidad de transformaciones organizacionales.