El mundo de las bases de datos es fascinante en términos de evolución. Estamos familiarizados con las bases de datos monolíticas tradicionales y, de repente en la última década también nos estamos familiarizando con la base de datos en la nube. Las principales diferencias entre estos dos paradigmas están basados en ‘dónde se alojan los datos’ y sus implicaciones. La necesidad de adoptar nubes de bases de datos a partir de bases de datos monolíticas se funda en la necesidad de acelerar la generación de almacenamiento de datos y reducir la necesidad general de recursos. En otras palabras, escalabilidad y eficiencia.
Ahora estamos siendo testigos de la evolución del almacenamiento en la nube hacia algo aún más flexible que tan sólo pensar en una base de datos como una entidad per se. Aquí es donde entran en juego los microservicios.
Los fundamentos
En las aplicaciones o bases de datos monolíticas tradicionales, todos los componentes y funciones de esa base de datos se alojan en una única instancia o entorno. Todas las tablas, consultas, esquemas, lenguaje de programación, sistema operativo, etc… todo está en la misma instancia. Entonces, si algo cambia, todo debe adaptarse a ese cambio consecuentemente. A medida que crece la base de datos o almacén de datos, también crece su complejidad y el costo de mantenimiento. Esto ha funcionado bien durante décadas, ya que los ingenieros han manejado el ritmo de generación y almacenamiento de datos.
En una base de datos de microservicios, cada componente individual de la base de datos se divide en partes más pequeñas (contenedor). Cada componente es independiente de los demás pero siempre se comunica entre sí y fuera de la aplicación contenerizada -mediante red/red virtual o APIs-. En este escenario, si la base de datos de microservicios crece, es fácil ubicar la parte o partes que están creciendo y enfocarse en mantener solo esa parte, dejando de lado la complejidad de mantener el resto de las partes.
¿Por qué necesitamos un marco?
Por lo tanto, el enfoque de “divide y vencerás” que representan los microservicios es un excelente enfoque para manejar la compleja realidad del mundo empresarial actual; sin embargo, existen algunos inconvenientes a considerar, entre otros: el aumento de la complejidad de administrar muchas partes móviles individuales simples; la dificultad de integración continua de nuevos servicios; o incluso rastrear errores. Para mitigar todos esos problemas, la adopción de un marco de trabajo -framework- es muy importante, ya que establece la base de buenas prácticas a seguir en el manejo de microservicios. Un marco es una estructura lista para el desarrollo de software, que no es una solución de ‘plantilla única’, ya que es capaz de adaptarse a cualquier necesidad.
Los frameworks ahorran tiempo en la planificación, ejecución y desarrollo, y lo más importante, el soporte de la solución implementada. Hay un buen número de frameworks disponibles en el mercado, algunos de código abierto y otros de licenciamiento comercial, y no es fácil definir uno sobre otro a la hora de esoger el más adecuado.
Al seleccionar un marco de microservicios, asegúrese de que el equipo de desarrollo y los futuros mantenedores comprendan los requisitos para ejecutar el desarrollo; comprender cómo estructurar los microservicios que reflejen la operación y estructura del negocio -y no al revés-; comprender cómo se comunicarán los microservicios -API, red, redes virtuales, etc-; y por último, pero quizás el aspecto más importante: la seguridad. Asegúrese de que cualquiera que sea la solución y el proveedor tengan implementadas medidas de seguridad sólidas.
Pensamientos finales
Si bien pensar en adoptar 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 será administrado por cada uno. equipo. Además, este proceso requerirá múltiples iteraciones antes de tener un Producto Mínimo Viable -MVP- pero tenga en cuenta que este proceso iterativo nunca terminará.
