Comparación de microinterfaces con arquitecturas alternativas

Como ocurre con todas las estrategias de arquitectura, la decisión de adoptar microinterfaces debe basarse en criterios de evaluación que se guíen por los principios de la organización. Las microinterfaces tienen ventajas y desventajas. Si su organización decide utilizar microinterfaces, debe contar con estrategias para abordar los desafíos de los sistemas distribuidos

Al elegir una arquitectura de aplicaciones, las alternativas más populares a las microinterfaces son los monolitos, las aplicaciones de n niveles y los microservicios en combinación con una interfaz de aplicación de una sola página (SPA). Todos estos enfoques son válidos y cada uno de ellos tiene ventajas y desventajas.

Monolitos

Una aplicación pequeña que no necesite cambios frecuentes se puede entregar muy rápidamente como un monolito. Incluso en situaciones en las que se espera un crecimiento significativo, un monolito es un primer paso natural. Más adelante, el monolito se puede retirar o refactorizar para crear una estructura más flexible. Al empezar con un monolito, su organización puede lanzarse al mercado, obtener los comentarios de los clientes y mejorar el producto con mayor rapidez.

Sin embargo, las aplicaciones monolíticas tienden a degradarse si no se mantienen cuidadosamente o a medida que la base de código aumenta de tamaño con el tiempo. Cuando varios equipos contribuyen de manera significativa a la misma base de código, rara vez todos contribuyen a su mantenimiento y operaciones. Esto se traduce en un desequilibrio de responsabilidades, lo que repercute en la velocidad y provoca ineficiencias. Al mismo tiempo, el acoplamiento inadvertido entre los módulos de un monolito provoca efectos secundarios no deseados a medida que la base de código evoluciona. Estos efectos secundarios pueden provocar averías e interrupciones.

Aplicaciones de nivel N

Una aplicación más compleja que tenga un ritmo de evolución relativamente estático se puede crear como una arquitectura de tres niveles (presentación, aplicación, datos), con una capa REST o GraphQL entre el frontend y el backend. Esto es mucho más flexible y los equipos de los diferentes niveles pueden desarrollarse de forma independiente hasta cierto punto. La desventaja de una aplicación de n niveles es que es mucho más difícil implementar la funcionalidad. El frontend y el backend están disociados mediante un contrato de API, por lo que los cambios más importantes se deben implementar juntos o se debe versionar la API.

Considere el siguiente escenario común: si el lanzamiento de una nueva función requiere un cambio en el esquema de datos, los propietarios del producto pueden tardar días en ponerse de acuerdo sobre un conjunto de funcionalidades con el equipo de front-end. A continuación, el equipo de frontend pedirá al equipo de backend que desarrolle y publique la funcionalidad por su parte. El equipo de backend trabajará con los propietarios de los datos para publicar una actualización del esquema de la base de datos. A continuación, el equipo de backend lanzará una nueva versión de la API para que el equipo de front-end pueda desarrollar y publicar sus cambios. En este escenario, la propagación de todos los cambios a la fase de producción puede llevar semanas o incluso meses, ya que cada equipo tiene sus propias tareas pendientes, prioridades y mecanismos en relación con el desarrollo, las pruebas y la publicación de los cambios.

Microservicios

En una arquitectura de microservicios, el backend se divide en pequeños servicios, cada uno de los cuales aborda un problema empresarial concreto dentro de un contexto limitado. Cada microservicio también está fuertemente disociado de otros servicios al exponer un contrato de interfaz claramente definido.

Vale la pena mencionar que los contextos limitados y los contratos de interfaz también deberían existir en monolitos bien diseñados y arquitecturas de n niveles. Sin embargo, en una arquitectura de microservicios, la comunicación se produce a través de la red, normalmente a través del protocolo HTTP, y los servicios tienen una infraestructura de tiempo de ejecución dedicada. Esto permite el desarrollo, la entrega y el funcionamiento independientes de cada servicio de backend.

Elegir el enfoque que mejor se adapte a sus necesidades

Los monolitos y las arquitecturas de n niveles agrupan varios problemas de dominio en un solo artefacto técnico. Esto facilita la gestión de aspectos como las dependencias y el flujo interno de datos, pero dificulta la entrega de nuevas funcionalidades. Para mantener una base de código coherente, un equipo suele invertir tiempo en la refactorización y la desvinculación debido a la gran cantidad de código que tienen que gestionar.

Es posible que las aplicaciones desarrolladas por unos pocos equipos no necesiten la complejidad adicional que conlleva el paso a las microinterfaces. Esto es especialmente cierto si los equipos no están pagando las penalizaciones que supone el elevado número de conexiones y los largos plazos de entrega de los cambios.

En resumen, las arquitecturas más complejas y distribuidas suelen ser la elección correcta para aplicaciones complejas y de rápida evolución. En el caso de las aplicaciones pequeñas y medianas, una arquitectura distribuida no es necesariamente superior a una monolítica, especialmente si la aplicación no va a evolucionar drásticamente en un corto período de tiempo.