La evolución del mundo de las bases de datos es fascinante. Estábamos familiarizados con las bases de datos monolíticas tradicionales y, en la última década, nos hemos familiarizado con las bases de datos en la nube. Las principales diferencias entre estos dos consiste básicamente dónde se alojan los datos y sus implicaciones. La necesidad de pasar de bases de datos monolíticas a nubes de bases de datos se deriva de la necesidad de un almacenamiento de datos rápido y una reducción general de recursos. En otras palabras, escalabilidad. Hoy, somos testigos de la evolución del almacenamiento en la nube hacia algo aún más flexible que una base de datos como entidad única. Aquí es donde entraría en juego un marco para microservicios.
Los fundamentos
En las aplicaciones o bases de datos monolíticas tradicionales, todos los componentes y funciones se alojan en una única instancia. Todas las tablas, consultas, esquemas, lenguajes de programación, sistemas operativos, etc., todo, está en la misma instancia. Esto significa que si algo cambia, todo debe adaptarse a ese cambio. A medida que crece la base de datos o el almacén de datos, crece su complejidad y el costo de mantenimiento. Esto ha funcionado bien durante décadas, ya que el ritmo de generación y almacenamiento de datos ha sido manejable para los ingenieros.
Por el contrario, en una base de datos implementada con microservicios, cada componente de la base de datos se divide en partes más pequeñas. Cada componente es independiente del resto; se comunican entre ellos mediante el uso de interfaces de programación de aplicaciones (API) o red/red virtual. En esta arquitectura, si la base de datos de microservicios crece, es fácil ubicar la parte que crece y enfocarse en mantener solo esa parte, dejando de lado la complejidad de mantener el resto.
Por qué se necesita un framework para microservicios
El enfoque de “divide y vencerás” de los microservicios está diseñado para manejar la complejidad del mundo empresarial actual. Sin embargo, existen algunos inconvenientes, como la mayor complejidad de administrar muchas partes individuales y el desafío de la integración continua de nuevos servicios y el rastreo de errores. Para mitigar todos esos problemas, es esencial adoptar un marco. Un framework -o marco- es una estructura lista para el desarrollo de software. No se trata de una solución estandarizada e inflexible, sino que es capaz de adaptarse a cualquier necesidad.
Los marcos ahorran tiempo en la planificación, ejecución y desarrollo. Hay una buena cantidad de marcos disponibles en el mercado, algunos de código abierto y otros distribuidos comercialmente. Tres ejemplos importantes son:
- Docker y Kubernetes
Docker es la plataforma de software de microservicios de referencia en la actualidad. Es de código abierto y permite que cualquier desarrollador implemente cualquier tipo de aplicación sin servidor, en paquetes o bloques autónomos llamados “contenedores”. Kubernetes es una plataforma de código abierto diseñada para orquestar contenedores.
Trabajando en conjunto, ambas plataformas permiten que cualquier aplicación se ejecute en cualquier sistema operativo y en cualquier lenguaje de programación, de manera altamente escalable. Esto proporciona flexibilidad y alta eficiencia en términos de uso de recursos.
- Framework de microservicios de Oracle Helidon
Esta es una plataforma de microservicios desarrollada por Oracle, basada en un repositorio de librerías Java. Hay varias variantes de Helidon, como Helidon MP y Helidon SE. Ambas variantes son aplicaciones basadas en Java, diseñadas para programación asíncrona y secuencias reactivas para Helidon MP; Helidon SE es especialmente adecuado para la creación rápida de prototipos y una pequeña huella de recursos.
- Framework de microservicios de Eclipse Vert.X
Este es otro marco popular que se ejecuta en Java Virtual Machine y admite muchos lenguajes de programación. Una de las características interesantes de Vert.X es que la aplicación desarrollada puede manejar una alta concurrencia mediante el uso de una pequeña cantidad de subprocesos del núcleo. También permite una escala rápida con un hardware mínimo.
Al seleccionar entre estos tres u otros marcos de microservicios, asegúrese de que el equipo de desarrollo y quienes mantienen el marco entiendan los requisitos de desarrollo: cómo estructurar los microservicios que reflejen la operación y estructura del negocio (y no al revés); cómo se comunicarán los microservicios (API, red, redes virtuales, etc.); y por último, pero quizás lo más importante, es la seguridad. Asegúrese de que la solución y el proveedor tengan implementadas medidas de seguridad sólidas.
Pensamientos finales
Si bien la adopción de la arquitectura de microservicios es un importante paso de modernización hacia una estructura más flexible y adaptable, es importante comprender primero el proceso comercial y el viaje del cliente, especialmente en lo que respecta al seguimiento de datos generado y cómo lo administrará cada equipo. Además, este proceso requiere múltiples iteraciones antes de tener un producto mínimo viable (MVP), y tenga en cuenta que este proceso iterativo nunca terminará.
