¿Son los Microservicios el siguiente gran paso en PLM?

PLM Microservices

Con las redes sociales y las tecnologías móviles y cloud como punto de referencia en cuestiones de velocidad, agilidad y facilidad de uso, no es de extrañar que los usuarios esperen un rendimiento y una flexibilidad similares de las plataformas PLM.

Sin embargo, si bien el argumento comercial para adoptar una tecnología más intuitiva y flexible está ampliamente respaldado, la realidad es que con el tiempo los proveedores de software se han ido alejando de este discurso. Este hecho no es otra cosa que la consecuencia derivada de los grandes cambios que las principales arquitecturas de las empresas y los modelos de negocio requieren. Y es que ya se sabe: optar por un cambio radical en plataformas bien establecidas y probadas, comenzando desde cero, es un camino arriesgado.

El riesgo es una parte ineludible de cada estrategia de negocio, y el escenario protagonizado por empleo de cloud y APIs abiertas, ha cambiado radicalmente el juego para la industria PLM. Por eso, aunque los proveedores de software tradicionales no desean que sus aplicaciones sean menos monolíticas, la tecnología y los clientes los están obligando a ello.

MICROSERVICIOS PLM: RECONFIGURAR LA ARQUITECTURA DE SISTEMAS DE LAS EMPRESAS

En los últimos años el cambio en las tecnologías de la arquitectura empresarial ha sido rápido y extenso. Por ejemplo, la gama actual de tecnologías en la nube es más potente y menos costosa que las referidas a la generación anterior. Esto permite a las empresas almacenar, analizar y utilizar datos activamente para tomar decisiones y generar nuevas oportunidades de negocio. Sin embargo, estas nuevas herramientas también son más complejas y, en muchos casos, representan un desafío para los sistemas y plataformas empresariales bien establecidas.

Los microservicios son la gran tendencia en arquitectura y desarrollo de software. Intentan resolver los problemas derivados del aumento en la velocidad y la flexibilidad, y parece que también están apareciendo en el entorno PLM: los gurús de PLM Jos Voskuil y Oleg Shilovitsky discuten en sus entradas de blog “Microservices, Apis, Platforms and PLM services” y  “Will PLM microservices eat PLM dinosaurs”, cómo los microservicios están impulsando el escenario PLM hacia arquitecturas más ágiles y flexibles.

Los microservicios representan un cambio fundamental en la forma en la que las empresas abordan la arquitectura de sistemas y el desarrollo de software. En pocas palabras, los microservicios eliminan la lógica empresarial de las aplicaciones y la sustituyen por módulos de código reutilizables que son completamente independientes de todas las demás partes de las aplicaciones.

Ahora exploremos con mayor detalle qué son los microservicios y cómo pueden afectar a los grandes proveedores de plataformas PLM.

BREVE HISTORIA DE LA ARQUITECTURA DE SISTEMAS

Orígenes de la arquitectura de sistemas de empresa: Aplicaciones monolíticas

Antes de los años 90, las arquitecturas de sistemas eran estrictamente monolíticas. Cuando hablamos de arquitecturas monolíticas, nos referimos a aquellas que consisten en una sola aplicación. Tal y como hemos revisado en «Sistemas de información en PLM«, hay tres componentes principales en las aplicaciones monolíticas: una base de datos, una aplicación del lado del servidor y una interfaz de usuario del lado del cliente. La aplicación del lado del servidor maneja las peticiones HTTP, ejecuta la lógica de negocio, recupera y actualiza los datos de la base de datos y los rellena en el navegador.

En arquitecturas monolíticas, cualquier cambio en el sistema significa que toda la aplicación debe ser chequeada desde el sistema de control de versiones.La versión debe ser actualizada y toda la aplicación implementada de nuevo.

El software en aplicaciones monolíticas no es fácil de reemplazar pieza por pieza. Los componentes de estas aplicaciones están estrechamente vinculados: si cambia algo en una parte del programa, su acción probablemente afectará a otras partes de la aplicación. Así que si no quieres «romper nada», es necesario que tus desarrolladores tengan un buen modelo mental de toda la aplicación a la hora de hacer cualquier cambio.

La mayoría de las plataformas PLM disponibles hoy en día se basan principalmente en arquitecturas monolíticas. Por lo general, apoyan a las empresas de manera propietaria, es decir, se adaptan a las necesidades de cada organización. Estos diseños hacen que sea difícil y costoso para las empresas compartir, consolidar y adaptarse a las cambiantes realidades empresariales.

Desacoplamiento de aplicaciones monolíticas con Arquitectura Orientada a Servicios (Service-Oriented Architecture - SOA)

Alrededor del año 2000, se produjo un cambio en la arquitectura de sistemas de las empresas. Esencialmente, varios pioneros llegaron a la idea de ensamblar aplicaciones utilizando un conjunto de elementos fundamentales conocidos como componentes, algunos de los cuales están disponibles “al alcance de la mano”, mientras que otros deben ser construidos desde cero.

De esta forma, fragmentaron sistemas grandes e inflexibles en un conjunto de piezas más pequeñas llamadas servicios. Estos servicios intercambiaban datos a través de la red. La comunicación entre los componentes se realizaba normalmente a través de XML.

En SOA, el servidor define a qué funcionalidad se puede acceder y cómo deben ser las peticiones y respuestas. Las interacciones son verbos-cosas que se pueden hacer con las peticiones al sistema, en lugar de estar asociadas a recursos específicos del mismo.

Principales componentes de SOA

Servicios web

Los «Servicios Web» son programas que permiten que una aplicación hable con otra a través de Internet. Ahora imagina que estás en un restaurante a punto de pedir. El camarero anota la comanda, la traslada a la cocina, y en algún momento, tú recibes tu comida. En este ejemplo, el camarero está actuando como un servicio web.

Los servicios web no están vinculados a ningún lenguaje de programación. Volviendo al ejemplo de antes, si tú solo hablas español y el personal de cocina solo habla alemán, el camarero debería ser capaz de traducir el pedido para obtengas la comida que habías pedido.

Bus de servicios empresariales (Enterprise Service Bus – EBS)

En las arquitecturas orientadas a servicios, los diferentes componentes de software se comunican entre sí mediante el envío de mensajes. Para transportar los mensajes entre componentes de software, las SOA suelen utilizar un Bus de Servicio Empresarial (Enterprice Service Bus o ESB).

El Registro SOA

El registro SOA es una biblioteca donde se almacena la información que describe lo que hace cada componente. Los desarrolladores y las aplicaciones consultan a través del registro qué servicios existen y cómo deben utilizarse.

Desafíos en la implementación

El gran desafío en las implementaciones de SOA fue que, aunque se había obtenido un mayor modularidad de software, las piezas de la aplicación seguían siendo bastante grandes. Además, al definir estrictamente cómo se podía acceder a los datos, de alguna forma se volvió a introducir la rigidez. Algunos proveedores desarrollaron formas exclusivas de llamar a los métodos a través de la red, lo que de nuevo llevó a un estrecho acoplamiento.

MICROSERVICIOS PARA ACELERAR EL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

No fue hasta el año 2010 cuando se acuñó el término «microservicios». En una arquitectura de microservicios, las aplicaciones se construyen como un conjunto de pequeños servicios, cada uno de los cuales ejecuta su propio proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP.

Las APIs son interfaces simples que se proporcionan a través de HTTP. Normalmente se construyen en base a interfaces REST, que hacen que los datos sean accesibles utilizando la Notación de Objetos JavaScript (JSON) y los verbos HTTP (en inglés: PUT, GET, POST y DELETE) para crear, leer, actualizar y eliminar recursos. Estos protocolos y formatos de datos son más fáciles de usar que los estándares de servicios web utilizados en los primeros SOA.

Los microservicios pueden ser vistos como una evolución de SOA. Mientras que SOA se centraba en compartir la funcionalidad de las aplicaciones, los microservicios se centran más en hacer que los propios datos estén disponibles, sin restringir su uso.

De igual forma, los microservicios son muy buenos para consumir datos de diferentes fuentes y transformarlos para otras aplicaciones.

PRINCIPIOS BÁSICOS PARA LA CONSTRUCCIÓN DE MICROSERVICIOS

1. Un microservicio, una tarea

El principio fundamental de los microservicios es que cada uno sólo debe realizar una tarea. En el siguiente ejemplo, se representa una aplicación para gestionar órdenes. Como vemos, en la arquitectura de microservicios hay un servicio dedicado para cada tarea en el proceso de gestión de pedidos.

2. Desarrollar e implementar servicios de forma independiente

Debería ser posible desarrollar y desplegar un microservicio independientemente de todas las demás partes de una aplicación. Como ya hemos visto en las arquitecturas monolíticas tradicionales, un cambio en cualquier parte de la aplicación requiere que esta se vuelva a implementar por completo. Con los microservicios, la aplicación se descompone en múltiples servicios que se pueden volver a implementar de forma independiente, lo que facilita mucho el proceso.

3. Productos, no proyectos

Tradicionalmente, el desarrollo de aplicaciones empresariales sigue siempre el modelo de proyecto: el objetivo es entregar una pieza de software en funcionamiento que luego se considera completa. Con los microservicios, la idea es que los componentes de software se conviertan en productos reutilizables de los que el equipo pueda disponer a lo largo de su ciclo de vida.

4. Métodos HTTP estándar para la comunicación de servicios

En SOA, los servicios web se comunican mediante XML. Los microservicios han adoptado métodos de comunicación modernos como HTTP, y las solicitudes y respuestas utilizan JSON para describir los datos.

BENEFICIOS DE USAR MICROSERVICIOS PLM

Escalabilidad y agilidad a través de la reutilización

En la arquitectura de microservicios, los grandes proyectos de software se dividen en módulos más pequeños e independientes. El software construido en forma de microservicios puede dividirse en múltiples servicios de componentes, de modo que cada uno de estos servicios puede ser implementado de forma independiente sin comprometer la integridad de una aplicación. Esto significa que la arquitectura de microservicios ofrece a los desarrolladores la libertad de desarrollar e implementar servicios de forma independiente.

Mejor aislamiento de errores

Las arquitecturas de microservicios mejoran el aislamiento de errores y permiten la entrega continua: si un microservicio falla, los otros seguirán funcionando. De esta forma las aplicaciones más grandes pueden no verse afectadas por el fallo de un solo servicio.

Apoyo al desarrollo de terceros

Dado que los microservicios representan una pequeña parte de la funcionalidad, es más fácil de entender, y por lo tanto subcontratar el desarrollo de aplicaciones. Otra ventaja es que el código para diferentes servicios puede ser escrito en diferentes lenguajes de programación.

Cambiar operaciones por resultados

Una consecuencia directa con la llegada de los microservicios es el cambio en la mentalidad. Las operaciones se descomponen y se definen en términos de resultados. Esto permite a las empresas visualizar el trabajo que clientes y proveedores están realizando en términos de propósito y actividad. Las organizaciones pueden identificar fácilmente qué actividades deben mantenerse internamente porque son estratégicas y proporcionan una ventaja competitiva, cuáles pueden ser subcontratadas y cuáles pueden venderse como un servicio para los clientes.

Mejor experiencia de usuario (UX) para las funcionalidades de cara al cliente

Las nuevas tecnologías web son mucho más fáciles de usar que las aplicaciones monolíticas tradicionales. La disponibilidad de datos importantes a través de los servicios nos permite el empleo de capas de presentación web modernas y la personalización de las aplicaciones de los usuarios finales.

BARRERAS A LA HORA DE PASAR A LOS MICROSERVICIOS PLUG-AND-PLAY

El desafío de la coordinación: asegúrate de que todos tus microservicios trabajen bien yen armonía

Has comenzado a encapsular tu feo código en microservicios plug-and-play. Hasta aquí todo bien, pero ¿cómo estás orquestando exactamente todos tus microservicios para asegurar el servicio integral deseado? Si los microservicios no se componen de forma clara y ordenada, la complejidad se desplaza desde el interior de un servicio a las conexiones entre ellos.

Además, es difícil determinar exactamente cuáles deben ser los límites de los servicios para asegurar que los microservicios y las aplicaciones tradicionales funcionen bien y en sintonía. Cualquier cambio en la interfaz debe ser coordinado entre los equipos, la compatibilidad debe ser comprobada cuando se hacen las actualizaciones, y las verificaciones pueden convertirse en algo bastante complejo.

Esta vez, ¿quién va a ser el poli malo que ayude a prevenir accidentes? Se necesitará una junta de gestión sólida en torno a los microservicios si no queremos acabar creando una jungla y, una vez más, limitar la flexibilidad y la agilidad.

Cuando la reutilización simplemente no funciona

El primer paso para reutilizar los microservicios es crear transparencia. ¿Cómo saben los de compras que los de fabricación ya han desarrollado un servicio de gestión de pedidos? ¿Hay alguien que organice la biblioteca de servicios y se asegure de que estos sean debidamente comprendidos y estén disponibles?

En mi experiencia, los desarrolladores suelen preferir escribir cosas nuevas que reutilizar o modificar cosas viejas. Cuesta aproximadamente tres veces más crear un servicio reutilizable que el código de un solo uso, por ello la creación de microservicios reutilizables es una inversión.

Cuando dinosaurios monolíticos y microservicios ligeros se casan

Los sistemas monolíticos tradicionales, como PLM o ERP, no son muy flexibles. Algunas de estas aplicaciones no están preparadas para los procesos de consulta y recuperación de datos más actuales, y es posible que esto acabe generando grandes problemas de rendimiento y fiabilidad. Para crear microservicios eficaces que utilicen datos de estas aplicaciones centrales, se necesita un gran nivel de experiencia. Si experimentas demasiado, puedes terminar confundiendo la gestión del tráfico, la supervisión y el rendimiento de la infraestructura central de la empresa.

¿SON LOS MICROSERVICIOS EL SIGUIENTE GRAN PASOEN PLM?

La capacidad de ofrecer aplicaciones plug-and-play se ha convertido en un importante factor de competitividad. Impulsadas por la convergencia de las redes sociales, la tecnología móvil y cloud y la creciente demanda de flexibilidad y usabilidad, las empresas deben ser ágiles, flexibles, y rápidas para satisfacer las expectativas de los clientes.

Saltar a este nuevo modelo no es sencillo. Requiere una combinación de nueva mentalidad, procesos y tecnología. Los microservicios no garantizan un viaje sin problemas, libre de preocupaciones empresariales. Pero sí representan un intento significativo de avanzar hacia una IT más flexible y moderna, que apoye la «necesidad de velocidad» en esta nueva era digital.

Todavía queda por ver si los microservicios son la nueva fórmula mágica. Algunos sugieren una arquitectura de dos velocidades: para desarrollar capacidades de cara al cliente a alta velocidad, mientras se desacoplan sistemas heredados a un ritmo más lento. Sin embargo, es cuestión de tiempo que los sistemas centrales tradicionales como el PLM comprendan los beneficios y se sumen al cambio.

Ahora mismo ya se presiona a los proveedores de PLM para que den un paso adelante y desempeñen un papel fundamental de apoyo a las empresas, para que naveguen a través de esta transición. Y es que una cosa es clara: aquellas que prevean cómo evolucionará la industria y actúen en consecuencia tendrán grandes oportunidades de prosperar.

Aún no hay comentarios, ¡añada su voz abajo!


Añadir un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas recomendadas