Cómo implementar su proyecto de microservicios (parte 3)
En esta serie de seis partes sobre el desarrollo de aplicaciones de microservicios, proporcionamos un contexto para definir un proyecto piloto basado en la nube que se adapte mejor a las necesidades actuales y prepare para una decisión de adopción de la nube a más largo plazo.
En la parte 3, proporcionamos un método para implementar sus propios proyectos de microservicios.
Evolución de una aplicación existente
Ahora profundizaremos en cómo trazar un plan para el desarrollo de aplicaciones de microservicios específicas de diferente escala, con miras a una posible progresión desde transformaciones a pequeña escala hasta otras a mayor escala de las aplicaciones existentes.
Si bien la construcción de proyectos de microservicios sin una aplicación previa es relevante o importante, estamos de acuerdo en un enfoque de “monolito primero” al construir microservicios. En resumen, esto significa que debe crear su aplicación de cualquier forma posible para validar primero su idea. A continuación, aplique los principios de esta serie de blogs a escala y evolucione su monolito inicial hacia un proyecto de microservicios. No tiene ningún valor crear microservicios arquitectónicamente puros que no ofrezcan valor al negocio.
Hay tres áreas que debe comprender para implementar un proyecto de microservicios exitoso: su negocio, su cultura y conjunto de habilidades, y su tecnología.
Comprenda y defina las necesidades de su negocio
¿Por qué está pensando en pasar a los microservicios? Para muchas empresas, se requieren prácticas de desarrollo y operación de software más eficientes para aportar valor al negocio más rápido y ofrecer mejores experiencias de usuario.
Antes de que pueda comprender el impacto de un proyecto de microservicios en sus aplicaciones e infraestructura existentes, debe comprender qué partes de su negocio se están moviendo demasiado lento para producir resultados satisfactorios. En muchos casos, los sistemas de participación (SOE) de la organización son los que provocan la ralentización. Estos sistemas están disponibles a través de muchos canales: web, dispositivos móviles, API y similares. La falta de velocidad es la razón principal para mover a una arquitectura basada en microservicios.
Antes de adoptar un enfoque orientado a los microservicios, usted y los stakeholders de su empresa deben saber qué es lo que no está llegando al mercado con la suficiente rapidez. ¿Qué partes de la aplicación necesitan mejoras y modificaciones para que funcionen más rápido? Para responder a esa pregunta, hay que determinar qué partes del monolito existente deben ser objeto de la evolución hacia los microservicios.
Utilice flujos de experiencia del usuario o diagramas de arquitectura para ayudar al equipo a dividir rápidamente secciones del monolito existente a través de anotaciones de estilo de mapa de calor. Por ejemplo, utilizando la escala rojo-amarillo-verde para priorizar los puntos débiles, aquí hay un archivo de aplicación web para una tienda:
En este punto, sin ser exhaustivos y con una actitud abierta a la iteración, los objetivos clave de la evaluación son:
Identificar las funciones comerciales separadas que proporciona su monolito
Comprender la velocidad relativa y la complejidad necesarias para cambiar esas funciones empresariales.
Comprender el deseo del propietario de la empresa de ver ciclos de feedback más rápidos para esas funciones empresariales específicas.
Comprender su cultura y conjunto de habilidades
Aunque no es específico de las arquitecturas basadas en microservicios, comprender a fondo los equipos, la cultura y las habilidades de una organización es crítico para llevar a cabo con éxito una transformación digital.
Por lo general, en los monolitos de ingeniería, la mayoría de las organizaciones están integradas en silos, con equipos que participan según sea necesario a lo largo del ciclo de vida del desarrollo de software. Esto a menudo crea límites bien definidos, con roles y responsabilidades restrictivos a lo largo de esos límites.
Las arquitecturas de microservicios solo pueden tener éxito cuando los equipos tienen el poder para poseer todo el ciclo de vida del desarrollo y las operaciones de software. La creación de equipos multifuncionales que representen todas las funciones y responsabilidades es fundamental para implementar arquitecturas basadas en microservicios. Todos, desde el diseño hasta el desarrollo, las operaciones y el propietario del negocio, trabajan en estrecha colaboración y, a menudo, se encuentran en el mismo lugar.
Dado que cada stakeholder está representado en el equipo por diseño, desarrollo y operaciones, el trabajo puede moverse más rápidamente, de manera eficiente y con un claro enfoque en mejorar la experiencia del usuario para lograr los objetivos comerciales.
Un equipo multifuncional también favorece el rápido crecimiento de las habilidades individuales de todos los miembros del equipo. Cuando un equipo es responsable de todo lo que compete al microservicio, desde el diseño hasta las operaciones y los datos de tiempo de ejecución, ningún miembro del equipo realiza una sola tarea. A menudo, los ingenieros de frontend desarrollan habilidades de administración de bases de datos, mientras que los miembros del equipo orientados a las operaciones aprenden más sobre las diferencias en la infraestructura de interfaz de usuario. Ampliar el conjunto de habilidades de esta manera ayuda a toda la organización de TI a tener éxito con los microservicios, ya que es mucho más fácil crear nuevos miembros del equipo completos, en lugar de buscar constantemente especialistas para desempeñar roles muy específicos.
Comprender la tecnología
A menos que aborde el problema empresarial y la cultura y las habilidades de su equipo, no podrá implementar eficazmente la tecnología de microservicios y mantendrá los mismos procesos y estructuras.
El análisis adecuado de las pilas de tecnología existentes varía ampliamente de una organización a otra, pero el enfoque simplificado que describimos ayuda a garantizar el éxito inicial y sostenido de sus proyectos de microservicios. Comenzar poco a poco y definir éxitos iterativos y progresivos es un enfoque mucho más alcanzable y fructífero que un enfoque llamativo de transformar todo a la vez.
La primera fase para comprender su tecnología consiste en identificar los servicios generales que se encuentran en el monolito existente. La identificación de estos servicios generales le ayuda a comprender la complejidad de las estructuras de datos, el nivel de acoplamiento entre los componentes actuales, los equipos responsables de estos nuevos servicios generales, etc. Una revisión de servicios generales exitosa le brinda una comprensión clara de los límites de los datos, tanto dentro de un servicio determinado como entre servicios.
Una vez que identifique los servicios generales, debe crear un plan sobre cómo evolucionar estos servicios en microservicios específicos. Estos microservicios, basados en su trabajo anterior, deberían estar trabajando con datos similares, poseer sus “propios” datos y comprender qué datos necesitan leer desde dónde y escribir en otros servicios. A partir de aquí, puede identificar e implementar la resiliencia, la escalabilidad y la agilidad de los microservicios individuales de grano fino.
Las API y los microservicios son dos partes de un todo más grande. Una vez que tenga una mejor comprensión de sus microservicios detallados, también tendrá una mejor comprensión de sus interfaces, qué interfaces se encuentran en el camino crítico, qué interfaces son opcionales y qué interfaces ya no necesita. Si no puede asignar una interfaz o API existente a uno de sus microservicios generales o específicos, lo más probable es que pueda eliminarla.
Dimensionamiento del esfuerzo de microservicios
El trabajo pesado de comprender el negocio, comprender la estructura del equipo y comprender la tecnología garantiza que sus equipos y organizaciones más grandes estén preparados para comprender la totalidad de la evolución de los microservicios de cualquier monolito dado, ya sea en un alcance de prueba de concepto, alcance piloto o alcance de evolución a gran escala.
Una vez completado todo el trabajo de análisis y planificación, el siguiente paso es definir los plazos, las velocidades de entrega y los resultados esperados.
En la próxima publicación, analizaremos los patrones de desarrollo y operaciones que se pueden aplicar al llevar a cabo una transformación de microservicios.
Qué hacer a partir de aquí:
Para modernizar y refactorizar una aplicación monolítica, visite la progresión arquitectónica detallada.
Roland Barcia (ingeniero distinguido de IBM y director de tecnología) y Rick Osowski (miembro sénior del personal técnico) colaboraron con Kyle en esta publicación.