Microservicios
7
min de lectura
4 de julio de 2017

Lo que deben saber los CIOs sobre Microservicios

Lucas Tempestini
Global Marketing Manager
Desarrollar estrategias de marketing y comunicación en una estrategia global muy compleja.
Más sobre el autor
SENSEDIA - O que os CIOs precisam saber sobre Microservicos

En los últimos anos el «hype» de los Microservices ganó mucha fuerza, y no es para menos. Con modelos de propaganda como Amazon y Netflix queda difícil argumentar contra. Pero, ¿que necesitan saber los CIOs sobre Microservicios?

Estas gigantes destruidoras de modelos de negocios «tradicionales» son los mayores casos de Arquitecturas Microservices, y convengamos, ellas fueron exitosas, pero al fin de cuentas, ¿qué significa todo eso?

La Arquitectura de Microservicios (o Microservices Architecture) es otro diseño pattern para arquitectura de software. Ella consiste en diversos servicios independientes que ejecutan funciones de negocios específicas, y el acoplamiento de esos servicios debe ser hecho por medio de un protocolo simple y liviano, por eso RESTful APIs son normalmente el «go to» al momento de hacer estas integraciones.

La ventaja de una arquitectura así es la posibilidad de separar cada «bloque» por valor entregado al usuario. Eso lleva a servicios muy específicos y menores, facilitando el mantenimiento del software y agregando flexibilidad, especialmente si se comparado a sistemas monolíticos más enyesados.

Pero entonces, ¿que necesita saber sobre Arquitectura Microservices antes de tirarse de cabeza?

Fuera del estante

Como todas las prácticas y modelos arquitecturales, Microservices tampoco es algo «comprable», usted no decide comprar en una tienda una solución preparada para su negocio y listo, su empresa ya está rodando en este modelo.

Es necesario entender el escenario y todos los detalles del modelo para implementar algo así, ya que cada monolítico presenta desafíos diferentes y específicos, y eso ocurre incluso en escenarios en que una aplicación será creada de cero.

¿On-Premise o en la nube? ¡Esa es la pregunta!

Una de las principales variables consideradas es la forma de deploy, la opción por Cloud o On-Premise es crucial, ya que uno de los beneficios esperados en este modelo es exactamente la velocidad de Deploy, para aplicaciones Cloud queda muy claro este aumento, ya en situaciones On-Premise pueden demandar una infraestructura diferente de la actual y algunos esfuerzos de coordinación de esos Deploys.

Lo que me lleva al siguiente tema:

¡DevOps!

Si estás hablando de velocidad de Deploy, estás hablando de DevOps y punto.

Uno de los principales drivers de Microservices es la posibilidad de tener las funciones de aquel «Microservicio» orientadas por las demandas de negocio, y posibilitar que ese Microservicio sea experimentado, modificado e innovador en la velocidad necesaria para atender a esas demandas. Y la mejor forma de garantizar eso es por medio de DevOps y releases continuos.

Nueva organización: Nueva organización

¡El título anterior no está equivocado!

Adoptar una arquitectura de Microservicios impacta la arquitectura de la Organización, pero también puede tener un impacto en la organización de los Equipos de TI, no aumentando ni reduciendo, sino especializando.

Un buen ejemplo de una «reorganización» es la metodología de «Squads» implementadas en el Spotify, donde cada «Squad» posee personas de diferentes skills técnicos enfocadas en una «Misión», y esa misión normalmente es un servicio específico y ellos son los expertos que desarrollarán ese servicio resolviendo cualquier problema. La Cultura de la Ingeniería del Spotify ganó adeptos en diversos departamentos de I&D e TI.

Un buen ejemplo de "reorganización" es la metodología de las "Escuadras", desplegada en Spotify, en la que cada "Escuadra" cuenta con personas de diferentes habilidades técnicas centradas en una "Misión": normalmente se trata de un servicio específico, y las personas son los expertos que desarrollarán este servicio y resolverán cualquier problema. La cultura de ingeniería de Spotify ha ganado adeptos en múltiples departamentos de I+D y de TI. Ellos cuentan un poco cómo lo desplegaron en este enlace.

En 2015, tuvimos a Jamie Kirkpatrick, de Spotify, hablando en APIX, un contenido espectacular sobre su equipo de desarrollo, que puedes ver aquí.

Los microservicios deben ser administrados

Una de las maneras más eficiente de asistir a una Arquitectura de Microservicios es utilizar una plataforma de Gestión de APIs, como la API Management Platform para las comunicaciones Norte-Sur combinada con una Service Mesh a las comunicaciones Este-Oeste.

Una plataforma como estas ofrecerá las funciones necesarias para que las integraciones entre sus microservicios e incluso su Backend sean gestionadas y monitoreadas. Además de ofrecer seguridad no solo contra ataques dirigidos a su API sino también contra integraciones que puedan generar una sobrecarga en su API. Otra feature importante para considerar en una plataforma como estas es la posibilidad de generar métricas e indicadores de sus APIs, no solo de «salud» sino de Negocios también.

Si quiere hablar con un especialista, rellene el siguiente formulario.

¡Gracias por leer!