En muchos de los posts anteriores, sobre modernización de Oracle forms, hemos tratado el complejo tema de modernizar aplicaciones Forms desde diferentes tipos de vista sobre todo haciendo énfasis en ecosistemas híbridos. En este post, trataremos de dar un enfoque a que estrategias podemos seguir si lo que nos ronda por la cabeza es actualizar nuestro aplicativo Forms a una arquitectura basada en microservicios. Con el objetivo de beneficiarnos de las ventajas que nos aportan.

Pero, ¿Necesito Microservicios?

Lo primero que deberíamos plantearnos es si realmente es lo que necesita mi negocio.  Es decir, debemos hacernos una serie de preguntas que nos encaminarán hacia un tipo de arquitectura u otro:

• ¿Tengo escenarios de negocio con necesidades de escalado poco previsibles en cada unidad funcional (campañas, negocio estacional, etc.)?

• ¿Tengo unidades funcionales con requisitos no funcionales diferentes (elasticidad, alta disponibilidad, seguridad, rendimiento)?

•¿Tengo  necesidades de actualización diferentes en cada unidad funcional (Time To Market)?

•...

Esta claro que cuando leemos los objetivos que se pueden alcanzar y la forma que tienen de gestionar los proyectos empresas como Netflix o Spotify es tentador. Pero seamos sinceros con nosotros mismos y analicemos profundamente si nuestro negocio tiene las mismas necesidades que este tipo de empresas.

Y quizá lo mas importante, si realmente nuestra organización interna y nuestros equipos de IT se parecen mínimamente, a nivel organizativo. Ya que según la Ley de Conway

“el software suele reflejar de una forma u otro la estructura de las empresas que lo han realizado.”

Seria la excepción o milagro que una organización basada en equipos grandes con poco comunicación entre ellos, sin una pieza o mecanismo creíble de unión y con muchas capas de supervisión y aprobación realicen un software de forma ágil y que refleje una buena integración entre las diferentes unidades de negocio.

En todo caso, la respuesta no tiene por qué ser un sí o un no. Puede que tras analizar nuestras necesidades,  necesitemos microservicios en ciertas unidades de negocio y, en cambio, en otras no tanto.

Pongamos por caso que la respuesta es SÍ. O quizás no es al 100%, pero si en parte de mi negocio.

Fase 0

0. Análisis

Llegados a este punto debemos crear una verdadera capa de análisis. Huir de soluciones o discursos que en muchas ocasiones parecen  los 50 logos más molones y actuales de microservicios, frameworks, plataformas, etc. En realidad, eso no es tan importante y cada vez tiende a serlo menos.

Lo verdaderamente importante es plantearnos la estrategia que vamos a seguir en nuestro objetivo de actualización de nuestra aplicación. Posteriormente escogeremos un modelo de implementación que se adapte a nuestra necesidad. Esto se traduce en responder preguntas como:

• ¿Qué estrategia de división funcional voy a seguir?

• ¿Cómo convivirá el sistema antiguo con los nuevos desarrollos?

• Si voy a partir mi aplicación, ¿qué hago con la BBDD? ¿Tiene sentido que siga siendo una única capa centralizada?

•¿Que papel tendrá mi equipo actual en este proyecto?

• …

Estas y muchas mas preguntas son las que deberemos ir trabajando, antes de entrar en temas de si quiero, Spring Boot, Python, tipo de despliegue X y todo mediante contenedores, etc.

Como se ha comentado anteriormente, puede que optemos por un enfoque basado en microservicios solo para parte de nuestro aplicativo. Y entonces: ¿el resto? ¿Lo mantengo en Forms?.

En este punto considero que herramientas como APEX, que proporcionan una actualización de nuestro core junto con una adaptación muy rápida de nuestro equipo de desarrollo Forms pero a la vez con un enfoque basado en servicios REST, pueden ser una opción muy interesante a tener en cuenta.

En una solución híbrida y no 100% basada en microservicios, APEX y ORDS pueden ser unos "aceleradores" sobre todo a corto plazo, en un proceso de modernización (que no nos engañemos no será corto en el tiempo).

1. En apoyo al Monolito

Aunque nuestro aplicativo Forms no tiene por qué cumplir de manera estricta con la definición de monolito, es probable que lo sea o que como mínimo se haga referencia a él en esos términos cuando nos embarcamos en un proyecto de estas características.

Es importante destacar, que nuestro aplicativo Forms, por grande que sea, no tiene por qué ser un desastre.

El tener el software modularizado, documentado, con separación clara de capas y de responsabilidades, etc. son conceptos muy antiguos. No sólo se puede hacer buen software si esta basado en microservicios. Esta claro que la realidad nos dice, que suelen ser aplicativos core que han pasado por muchas manos y no siempre es facil mantener la calidad y pulcritud que seguramente se gestó en los inicios del proyecto.

Tener o empezar con un monolito no tiene porqué ser negativo. De echo es incluso recomendable

2. Estrategia de división

Llegamos a la parte de cómo voy a dividir mi aplicativo.

El cómo se realice esa división, dependerá de muchos factores y de las propias necesidades del equipo pero es importante mantener cierto orden y pautas. Podemos basarnos en complejidad, en Time to Market del módulo funcional, en la propia división funcional o menú de la aplicación, etc.

Siempre es recomendable empezar por aquellos módulos que nos aporten mas valor a todos los niveles (tanto a nivel de negocio, IT, usuarios finales, etc.) e intentando mantener una buena relación entre ese valor y la complejidad. Y ahí entrarán en juego las dependencias que haya entre todos aquellos módulos que hemos identificado. Sobre todo a nivel de BBDD, que seguramente será la parte mas compleja de trabajar a nivel de división.

En este punto la documentación y el conocimiento funcional del aplicativo es fundamental. En cualquier caso, hacer uso de herramientas de análisis para recopilar toda la información posible será una buena idea. Herramientas como PITSS o Forms API Master nos pueden ayudar a algunas tareas importantes en la fase de análisis.

Por otro lado, podemos hacer uso de Oracle SQL Developer y su Data Modeler para obtener todo tipo de informes y documentación de nuestra BBDD.

A continuación podemos ver a modo de ejemplo, alguno de los diagramas y documentación que podemos obtener con este tipo de herramientas:

3. Estrategia de división de la capa de datos o BBDD

Como hemos comentado anteriormente, este será uno de los puntos mas conflictivos.

Si realmente queremos que cada uno de los servicios sean independientes tendremos que ver como trabajaremos temas como:

• Relación entre tablas (FK), tablas maestras de datos, tablas maestras con pocos cambios (países, provincia, etc.), típicas tablas que contienen un montón de columnas que han ido creciendo con el tiempo y dan servicio a varios fmbs, etc.

Nuestro objetivo final es que cada microservicio tenga su propia gestión de los datos y sea independiente.

A la hora de ir desmontando el monolito, es importante pensar en el objetivo o responsabilidad que tendrá el microservicio y no tanto en los datos que maneja. De otro forma corremos el riesgo de caer, en anti-patrones como el de servicios de entidad. Michael T. Nygard, expone de forma muy clara algunos de los problemas y algunas consideraciones a la hora de enfrentarnos a ello en tiempo de diseño.

4. Independencia de BBDD

Tal como hemos comentado, respecto a nuestro objetivo final, si realmente queremos tener servicios pequeños e independientes, unidades de despliegue pequeñas y políglotas (multitecnología), etc. no podemos olvidar la BBDD. Es una parte más de nuestro negocio y del mismo modo que puede que para un microservicio nos venga mejor Java o Python, también puede que para ciertos módulos nos convenga una base de datos relacional y para otros no tanto (por poner un ejemplo).

Y ahí también será muy importante qué estrategia seguiremos a la hora de gestionar ciertos problemas que derivaran de no tener una transacción única como posiblemente teníamos hasta ahora. Aquí ya se ha hablado de ello, desde el punto de vista del patrón saga

5. Nuevos retos

Todo lo expuesto anteriormente nos llevará hacia un camino con toda una serie de nuevos desafíos que anteriormente es posible que nuestra organización no tuviera. Temas tan diversos como:

• Latencia, complejidad en la infraestructura, monitorización y trazabilidad de los microservicios, consistencia de datos, testeo, etc.

Cada punto es profundo y podemos dejarlos como temas para posts posteriores, pero es importante que ya tengamos en cuenta todos los puntos en esta fase previa que queremos asentar. Ya que es un proceso exponencial que a medida que vayamos avanzando en nuestra nueva arquitectura, sin duda, surgirán.

Conclusiones

El objetivo de este post no era tanto entrar en detalle en frameworks de implementación o despliegue sino más en asentar esa fase de análisis que es de vital importancia en este tipo de proyectos.

¡Puedes dejarnos tus opiniones en los comentarios del blog, o a través de Twitter!