El paso a los microservicios representa un cambio radical en el desarrollo de aplicaciones. Aquí le mostramos cómo desentrañar la complejidad de un cambio tan grande.

El desarrollo de nuevas aplicaciones hoy en día tiene que ver con la velocidad de entrega. El amplio movimiento hacia el entorno ágil que ha estado en marcha durante varios años ha fomentado una sensación de implementación de software fácil y rápida.

Una de las tendencias tecnológicas que está ayudando a acelerar el desarrollo de aplicaciones es el auge de los microservicios, y es posible que los líderes de TI de una variedad de empresas deseen considerar esta técnica de desarrollo de software para sus organizaciones, si aún no lo han hecho.

Los microservicios son una variante de la arquitectura orientada a servicios (SOA) que estructura las aplicaciones como colecciones de servicios débilmente acoplados. Entre los beneficios de dividir las aplicaciones en servicios más pequeños está que mejora la modularidad, lo que facilita el desarrollo y la prueba de las aplicaciones.

“Los microservicios aumentan el empoderamiento del equipo y reducen el acoplamiento, lo que permite que los equipos individuales innoven más rápido, reduzcan la comunicación entre equipos y se sientan capacitados para tomar sus propias decisiones con respecto a la arquitectura, el lenguaje y los marcos”, externa EJ Campbell, vicepresidente de ingeniería, deportes y ingeniería de producción de medios en Verizon Media Group, una subsidiaria de la compañía de comunicaciones compuesta por 50 marcas en línea.

“Hemos visto que el tiempo del ciclo desde el compromiso hasta la producción se reduce drásticamente a medida que los equipos adoptan microservicios”, añade Campbell. “Muchos equipos implementan microservicios varias veces al día sin intervención humana, confiando en pruebas, revisiones de código y canalizaciones sofisticadas de CI/CD [integración continua/entrega continua] para garantizar la entrega segura de los cambios”.

El producto Yahoo Daily Fantasy de la compañía comprende varios microservicios, incluido un servicio de juego central, un servicio de datos deportivos, un servicio de billetera y varios servicios internos de apoyo. “Cada uno de estos servicios tiene sus propias canalizaciones de implementación continua, almacenes de datos aislados y equipos individuales responsables de su desarrollo y operación”, señala Campbell.

Las organizaciones pueden encontrar una serie de desafíos al usar microservicios. Estos incluyen determinar los límites correctos entre los servicios, superar la dificultad de compartir código entre equipos en un entorno de microservicios y la complejidad de la gestión de cambios porque los equipos publican el código de forma independiente.

El paso a los microservicios representa un cambio radical y las organizaciones deben estar preparadas para un cambio tan grande.

“Evolucionar a los microservicios es como pasar del caballo a la bicicleta, o de la bicicleta al automóvil”, asevera Jay Bercher, subgerente de programas de Solutions By Design II (SBD), una empresa de servicios tecnológicos y de consultoría de gestión que trabaja con agencias federales. agencias en su transición a un enfoque de TI basado en microservicios.

“A medida que avanzamos por las etapas de la evolución, encontramos aún más piezas en movimiento”, dice Bercher. “Cada pieza móvil requiere su propio nivel de mantenimiento, y el soporte y supervisión de tantos elementos no solo complica la solución, sino que incrementa los costos asociados. En consecuencia, tenemos que analizar nuestras decisiones para asegurarnos de que no solo sean la mejor decisión tecnológica, sino también rentables”.

Otro desafío es la seguridad. “Tenemos que determinar si queremos implementar una única solución de verificación en toda la aplicación o si queremos que cada microservicio tenga su propio proceso de verificación”, asevera Bercher. “Esta es una decisión que debe tomarse caso por caso y que cada equipo de proyecto debe tomar por su cuenta”.

Estas son algunas de las mejores prácticas sugeridas para abordar los desafíos y prosperar en un entorno de microservicios.

Emplee un diseño basado en el dominio

La creación de microservicios se trata de hacer que los servicios estén poco acoplados y aplicar el principio de responsabilidad única, señala Bercher.

“Si bien existen varios métodos y metodologías para el desarrollo, el diseño basado en dominios y los microservicios parecen ser una combinación perfecta”, dice Bercher. Los equipos de SBD utilizan el diseño basado en dominios, un enfoque temático para crear una aplicación que crea un patrón de desarrollo eficiente que elimina la mayoría de las interdependencias del equipo.

“En nuestro trabajo, la correlación del dominio con los microservicios es esencialmente uno a uno”, agrega Bercher. “Entonces, cada equipo de desarrollo es responsable de un dominio y también responsable de desarrollar el microservicio correspondiente. Esto crea una clara delimitación de responsabilidades, lo que a su vez limita los despidos que pueden ocurrir en los esfuerzos de desarrollo paralelos”.

Establecer pautas para las bibliotecas de códigos.

Es mucho más difícil compartir código entre equipos en un mundo de microservicios, apunta Campbell.

“A diferencia de un monolito, donde el código común está a solo una llamada de método, con una arquitectura de microservicios, los elementos comunes deben tenerse en cuenta en un servicio independiente o el código debe empaquetarse en una biblioteca compartida”.

La adopción de estas bibliotecas suele ser lenta y hacer cambios requiere coordinación entre el propietario de la biblioteca y múltiples servicios. “Por lo tanto, es importante que las organizaciones adopten un conjunto sólido de pautas para bibliotecas comunes y expectativas sobre los lanzamientos”, asegura Campbell.

No comparta bases de datos entre microservicios

“Al construir nuestros servicios desacoplados, estamos permitiendo que nuestros equipos de desarrollo construyan su propia base de datos que alimenta nuestros [sistemas de back-end], lo que limita las dependencias de otros equipos de desarrollo”, señala Bercher.

“Nuestros equipos de desarrollo envían sus escrituras al backend para que todos los demás las absorban, y luego nuestro equipo de datos administra esta información”, asevera Bercher. “Esto continúa con el concepto plug-and-play. Si necesita reemplazar un servicio, simplemente sáquelo y conecte el nuevo. Es como cambiar una luz, solo que un poco más complejo”.

Debido a que los microservicios son modulares por diseño, el proceso de desarrollo es predominantemente plug-and-play, lo que hace que sea extremadamente fácil solucionar cualquier problema que pueda surgir.

“Debido a que el código no se propaga a través de toda la plataforma, podemos aislar rápidamente los problemas en una fuente específica y luego rastrearlos dentro de los microservicios”, declara Bercher. “Esto facilita la actualización de aplicaciones al permitir actualizaciones por microservicio. ¿Se imagina actualizar un sistema pieza a pieza en lugar de un reemplazo completo? Este concepto por sí solo revoluciona el desarrollo de sistemas”.

SBD tiene equipos de desarrollo en diferentes lugares de los Estados Unidos que mejoran los beneficios de los microservicios. Los miembros del equipo en Charleston, SC, tienen un mayor nivel de independencia de desarrollo porque están desarrollando su propio microservicio que se conecta a una solución.

Abordar las preocupaciones de seguridad

Como todo lo relacionado con TI, los microservicios tienen sus propios problemas de seguridad.

Las empresas deben buscar vulnerabilidades conocidas al principio y con frecuencia en el ciclo de vida del desarrollo de software, apunta Ryan Douglas, CIO de Digital River, un proveedor de servicios de comercio electrónico, pagos y marketing. 

“Un mantra importante para cualquier equipo de TI que opere en nuestro mundo acelerado es identificar y reparar las vulnerabilidades de las soluciones locales, así como también del software de terceros”, dice Douglas. “Es esencial para mantener la seguridad. Es fundamental adoptar un enfoque general del ecosistema de software para comprender cómo funciona en conjunto y dónde residen las áreas problemáticas potenciales”.

La implementación de parches de software es mucho más fácil de probar cuando se usan microservicios, añade Douglas. “Y no es sólo para el código de cosecha propia”, dice. “Los ingenieros de TI pueden probar el software de terceros en busca de vulnerabilidades junto con su propio desarrollo de software. En caso de que se encuentre una vulnerabilidad, se puede implementar una solución más rápidamente que con las estructuras de código monolítico anteriores”.

Evita enredos

Los enredos pueden ocurrir con demasiada facilidad en grandes implementaciones de microservicios, advierte JP Morgenthal, CTO de servicios de aplicaciones en DXC Technology, un proveedor de servicios de TI que se formó tras la fusión de CSC y la división empresarial de HP.

“Incluso puede haber rutas de datos recursivas si las organizaciones no tienen cuidado de garantizar que haya una arquitectura de sistema” que impulse el uso de microservicios, aclara Morgenthal. “Entre el uso de equipos interfuncionales independientes y repositorios de servicios, es posible que aparezcan dependencias que harían que el sistema invalidara los principios de los microservicios”.

Un solo microservicio debe poder cambiarse o eliminarse sin un impacto significativo en el sistema en su conjunto. Una mejor práctica es involucrar la arquitectura empresarial para validar los diseños de microservicios, refiere Morgenthal.

Considere crear aplicaciones desde cero

Vylla.com, una plataforma hipotecaria directa al consumidor lanzada por el proveedor de servicios inmobiliarios Carrington Mortgage Holdings, trasladó recientemente su arquitectura tecnológica a microservicios.

“Uno de los desafíos que encontramos cuando decidimos migrar a los microservicios fue dividir la aplicación pieza por pieza o realizar una reescritura completa”, declara John Nicholas, CTO de Carrington Mortgage.

“Debido a algunos requisitos comerciales preestablecidos, necesitábamos ofrecer una nueva funcionalidad en un período de tiempo muy corto”, recuerda Nicholas. “Al principio, intentamos integrarnos a la arquitectura monolítica con resultados exitosos. Sin embargo, también sabíamos que dividirlo resultaría más difícil que reescribir la mayoría de nuestras características actuales”.

Con esto en mente, el equipo de desarrollo decidió que el mejor camino a seguir era construir una nueva aplicación desde cero. “Fue una tarea enorme y requirió esfuerzos masivos de todos los miembros de nuestro equipo, pero ya ha demostrado su valor en el corto período de tiempo transcurrido desde la transición”, subraya Nicholas.

Debido a que se necesita una importante inversión en tecnología para implementar microservicios con éxito, es importante tener un caso de negocios claramente definido que describa cómo la nueva tecnología mejorará el rendimiento o la eficiencia operativa.

“El componente crítico aquí es encontrar el talento adecuado”, dice Nicholas. “No es fácil encontrar arquitectos ingenieros que tengan la experiencia para hacer el trabajo. Hemos podido crear un sólido equipo de ingeniería que comprende la arquitectura adecuada y un sólido equipo de control de calidad para crear pruebas de automatización en torno a la aplicación”.

Medir el rendimiento al escalar

Las aplicaciones monolíticas se pueden escalar en su totalidad para satisfacer un aumento en la demanda agregando servidores, dice Praveen Kanyadi, cofundador de SpotCues, una empresa que proporciona software de productividad utilizando Inteligencia Artificial.

“En el caso de los microservicios, la arquitectura modular permite escalar sólo partes del sistema”, manifiesta Kanyadi. “Sin embargo, los microservicios requieren un enfoque de escalabilidad muy diferente porque una implementación de arquitectura de microservicio típica puede consistir en múltiples componentes que se ejecutan en diferentes servidores y virtualizaciones que trabajan juntas”.

Esto agrega el desafío de identificar qué componentes individuales mejorar. “Aquí es donde la medición del desempeño se vuelve fundamental, y herramientas como un controlador de entrega de aplicaciones pueden ayudar a medir y detectar problemas de desempeño”, asegura Kanyadi.

Las empresas también deberían considerar la definición de acuerdos de nivel de servicio (SLA) para cada microservicio para el rendimiento y la confiabilidad, en función de las prioridades comerciales, dice Kanyadi.

Centrarse en la gestión del cambio

Las empresas necesitan actualizar los procesos de gestión y control de cambios, junto con la documentación de respaldo, para beneficiarse del cambio de una arquitectura monolítica a una de microservicios.

“Un proceso de desarrollo más rápido es excelente, pero no pierda los beneficios de los microservicios al dejar de lado el control de cambios y otros procesos de gobierno importantes”, argumenta Ron Hayman, director de nube en Avant Communications, un proveedor de servicios en la nube para el canal de ventas de TI.

“Asegúrese de alinear el control de cambios y el proceso de aprobación para que coincida con su ciclo de vida de desarrollo ágil”, concluye Hayman.

Bob Violino, CIO.com