Cómo implementar su proyecto de microservicios (parte 3)
En esta serie de 6 partes sobre el desarrollo de aplicaciones de microservicios, proporcionamos un contexto para definir un proyecto piloto basado en la nube que mejor se adapte a las necesidades actuales y se prepare para una decisión de adopción de la nube a largo plazo.
Aquí, en la parte 3: proporcionamos un método para implementar sus propios proyectos de microservicios.
Evolución de una aplicación existente
Ahora profundizamos en cómo trazar un curso para un recorrido específico de desarrollo de aplicaciones de microservicios de diferente escala y con vistas a una posible progresión de transformaciones de menor a mayor escala de las aplicaciones existentes.
Si bien la creación de proyectos de microservicios sin una aplicación previa es relevante o importante, estamos de acuerdo en un enfoque de “monolito primero” al crear microservicios. En resumen, esto significa que primero debe crear su aplicación de cualquier manera que pueda para validar su idea. A continuación, aplique los principios de esta serie de blogs para escalar y evolucionar su monolito inicial hasta convertirlo en un proyecto de microservicios. No tiene ningún valor crear microservicios arquitectónicamente puros que no ofrezcan valor a la empresa.
Hay tres áreas que debe comprender para implementar un proyecto de microservicios de éxito: su negocio, su cultura y conjunto de habilidades, y su tecnología.
Comprenda y defina las necesidades de su empresa
¿Por qué está pensando en pasarse 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 poder comprender el impacto de un proyecto de microservicios en sus aplicaciones y su infraestructura existentes, debe comprender qué partes de su negocio se mueven demasiado lentamente para producir resultados satisfactorios. En muchos casos, los sistemas de compromiso (SOE) de la organización están causando la ralentización. Estos sistemas están disponibles a través de muchos canales: web, móvil, API y similares. La falta de velocidad es la razón principal para pasar a una arquitectura basada en microservicios.
Antes de adoptar un enfoque orientado a los microservicios, usted y las partes interesadas de su empresa deben saber qué es lo que no llega al mercado con la suficiente rapidez. ¿Qué partes de la aplicación necesitan mejoras y modificaciones para hacerlas más rápidas? Responder a esa pregunta implica qué partes del monolito existente deben ser objeto de la evolución del microservicio.
Utilice flujos de experiencia de usuario o diagramas de arquitectura para ayudar al equipo a crear rápidamente secciones del monolito existente a través de anotaciones de estilo de mapa de calor. Por ejemplo, si utiliza una escala rojo-amarillo-verde para priorizar los puntos débiles, he aquí un archivo de aplicaciones web para un escaparate:
En este punto, sin ser exhaustivos y con una apertura a ser iterativa, los objetivos clave de la evaluación son:
Identificar las funciones empresariales independientes 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, una comprensión profunda de los equipos, la cultura y el conjunto de habilidades de una organización es crítico para una transformación digital exitosa.
Por lo general, en los monolitos de ingeniería, la mayoría de las organizaciones se construyen en silos, y los equipos participan según sea necesario a lo largo del ciclo de vida del desarrollo del software. Esto suele crear límites bien definidos, con funciones y responsabilidades restrictivas a lo largo de esos límites.
Las arquitecturas de microservicios solo pueden tener éxito cuando los equipos tienen el poder de poseer el ciclo de vida completo del desarrollo de software y las operaciones. Crear equipos interfuncionales que representen todas las funciones y responsabilidades es fundamental para la implementación de 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, están ubicados en el mismo lugar.
Dado que cada parte interesada está representada en el equipo por diseño, desarrollo y operaciones, el trabajo puede avanzar de forma más rápida, eficiente y con un claro enfoque en mejorar la experiencia del usuario para alcanzar los objetivos empresariales.
Un equipo multifuncional también apoya el rápido crecimiento de las habilidades individuales en todo el equipo. Cuando un equipo es propietario de todo lo que el microservicio es responsable, desde el diseño hasta las operaciones y los datos de tiempo de ejecución, ningún miembro del equipo realiza ni una sola tarea. A menudo, los ingenieros front-end 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 los marcos 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 equipos de miembros completos, en lugar de buscar constantemente especialistas para desempeñar funciones muy específicas.
Comprenda la tecnología
A menos que aborde el problema empresarial y la cultura y el conjunto de 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 tecnológicas existentes varía mucho de una organización a otra, pero el enfoque simplificado que describimos ayuda a garantizar tanto el éxito inicial como el 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 transformarlo todo a la vez.
La primera fase para comprender su tecnología es identificar los servicios de granularidad gruesa que se encuentran en el monolito existente. Identificar estos servicios específicos 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 satisfactoria le proporciona 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 de granularidad gruesa, debe crear un plan sobre cómo evolucionar estos servicios de granularidad gruesa en microservicios de granularidad fina. Estos microservicios, basados en su trabajo anterior, deberían trabajar con datos similares, ser dueños de sus “propios” datos y comprender qué datos necesitan leer de dónde y escribir en otros servicios. Desde aquí, puede identificar e implementar la resiliencia, la escalabilidad y la agilidad de los microservicios individuales finos.
Las API y los microservicios son dos partes de un todo más grande. Una vez que comprenda mejor sus microservicios, también comprenderá mejor sus interfaces, qué interfaces están 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 de grano grueso o fino, lo más probable es que pueda prescindir de él.
Dimensionar del esfuerzo de microservicio
El trabajo pesado de comprender el negocio, comprender la estructura del equipo y comprender la tecnología garantiza que sus equipos y la organización en general 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, los próximos pasos son definir los plazos, las velocidades de entrega y los resultados.
En la próxima publicación, consideraremos los patrones de desarrollo y operaciones que puede aplicar para emprender una transformación de microservicios.
Qué hacer a partir de aquí:
Para modernizar y refactorizar una aplicación monolítica, visite una progresión arquitectónica detallada.
Roland Barcia (ingeniero distinguido de IBM/CTO) y Rick Osowski (miembro sénior del personal técnico) colaboraron con Kyle en esta publicación.