Derribando Monolitos: 7 Razones por las que migrar a una Arquitectura de Microservicios.
NOTICIA
25 may 2018
Commentarios 0

Prepara el martillo y el cincel. Ha llegado la hora de enfrentarte a tu enemigo más temido, aquel que se esconde tras el aplazamiento tecnológico más legendario de tu banco: La arquitectura monolítica.

Una larga sombra se viene proyectando desde hace tiempo sobre el monolito. Una sombra que se come cada vez más rápido la luz de un modelo que se está quedando obsoleto en el entorno del desarrollo tecnológico bancario. Y es que hay un problema muy concreto que subyace a estas anticuadas aplicaciones bancarias: Todos los ciclos de cambio están vinculados unos a otros. Como bien sabes, al señor monolito no le gusta delegar. La más mínima modificación en una remota sección de la app de tu banco podría conllevar la creación y despliegue de una versión completamente nueva, y obviamente con ello todo el gasto de recursos correspondiente. Hoy te vamos a explicar con 7 razones muy concretas, ese potencial que tiene enamorados a los desarrolladores de arquitecturas bancarias de todo el mundo: El potencial de los microservicios.

1. Menos es más, la simpleza como estandarte: Olvídate de enrevesadas interrelaciones que comuniquen varias bases de datos. Con los microservicios, cada módulo de tu arquitectura bancaria tendrá su propia base de datos y su propio proceso, lo que le da independencia por sobre todas las cosas. Asúmelo, el niño se va de casa.

2. Transparente como el agua clara: Cada servicio hace lo que debe hacer y tiene claras sus prioridades. Con ellos podrás dejar a un lado esa infinidad de funciones que apuntan a acciones inútiles que jamás vas a necesitar en tu arquitectura bancaria. De esta manera, cada microservicio puede hacer uso de otros microservicios para completar así una acción que se le ha solicitado y para la que no tiene capacidad. Más claro, agua.

3. Quieres menos riesgos y lo sabes: A la hora de programar el riesgo de fallo no es lineal ascendente, sino exponencial. A menor código a ejecutar, obviamente menos riesgos de errores vamos a tener. Y de aparecer, el hecho de que cada módulo funcione de manera independiente, nos otorgará un aislamiento que nos facilitará el encontrar dicho fallo. Conclusión, con una arquitectura de microservicios tú estarás más tranquilo y nosotros estaremos más felices sabiendo que duermes a pierna suelta.

4. El Usain Bolt de las arquitecturas: La mayoría de los equipos de desarrollo usan o procuran usar una metodología ágil a la hora de programar una aplicación. ¡Un banco actualizado es un banco fit! Ya se trate de SCRUM, XP u alguna otra variante, el sistema de trabajo se repite porque se ha comprobado que ofrece resultados positivos. Piénsalo un momento, en el fondo sólo se trata de dividir un gran volumen de trabajo en pequeñas partes manejables en las que se pueda centrar un equipo de desarrolladores o un único programador. ¡No corras! Que aún hay más...

5. Despreocúpate, tu trabajo está bien hecho: Los microservicios fomentan el desarrollo en paralelo. Como decíamos antes, al ser cada microservicio independiente de los demás, el desarrollo de tu aplicación bancaria puede darse en paralelo, sin incurrir en tiempos de espera o que un grupo de desarrollo finalice una parte imprescindible para que otro equipo de programadores pueda continuar con su tarea. ¿Te acuerdas que más arriba decíamos que al señor monolito no le gusta delegar? Pues con los microservicios, eso se ha terminado.

6. Fast&Furious V.S. Matrix: Intentar localizar un fallo en una aplicación bancaria monolítica puede llevar muchas horas de prueba. Con los microservicios, el 99% de los fallos se reportan indicando que un servicio o microservicio determinado no funciona o no lo hace correctamente. Esto hará que tu programador pueda acotar muchísimo su búsqueda del error en Matrix, pudiendo solventar la incidencia en un breve espacio de tiempo y salvar al mundo de la debacle. ¿Estás preparado para entrar hasta el fondo de la madriguera a todo gas?

7. Un paso atrás primero, dos adelante después: Sabemos lo que estás pensando: “Al tratarse de una aplicación basada en microservicios me voy a dar la nariz contra muchísimas más API’s que si nos enfrentamos a un mega-servicio”. No te asustes, recuerda lo que te acabamos de decir en el punto anterior. Localizar los fallos es una tarea mucho más simple si el servicio únicamente hace lo que tiene que hacer, acelerando así el tiempo requerido en cada API y por ende aumentando el rendimiento al no verse atrapados los testers por cientos de errores en cada servicio que prueben.

En definitiva, con los microservicios hablamos de un nuevo banco fácil. Un banco con una arquitectura que otorga a los desarrolladores libertad de desarrollar servicios de forma independiente y con un equipo de trabajo mínimo. Una arquitectura en la que podrás usar diferentes lenguajes de programación, en diferentes módulos, con fácil integración y un despliegue totalmente automático. Hablar de microservicios es hablar de una arquitectura fácil de entender y modificar, con una funcionalidad modular en la que la modificación de un módulo no afectará al funcionamiento del resto. Una arquitectura que también fácil de escalar e integrar con aplicaciones de terceros. Fácil, esa es la palabra... Derribar de una vez por todas el monolito a base de microservicios te hará la vida mucho más fácil. 

Lo dicho, martillo, cincel, y manos a la obra.

SÍGUENOS EN REDES

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.