Cuatro opciones de arquitectura para el desarrollo de aplicaciones en la era digital

Todos conocemos la arquitectura de aplicaciones de 3 niveles: es una arquitectura cliente-servidor con una estructura típica que consta de la capa de presentación, la capa de aplicación y la capa de base de datos.

Tiene una interfaz de usuario, lógica de acceso a datos/negocios y acceso a datos. Muchas aplicaciones empresariales se crearon utilizando la sencilla arquitectura de aplicaciones de 3 niveles.

En pocas palabras, el modelo de aplicación de 3 niveles está desactualizado. Fue diseñado para el desarrollo de aplicaciones antes de la proliferación de la nube pública y las aplicaciones móviles y ha tenido dificultades para adaptarse a la nube.

Con el tiempo, una aplicación puede volverse demasiado grande y compleja para realizar cambios frecuentes. No solo eso, sino que también requiere el mantenimiento de al menos tres capas de hardware y software, lo que puede ser ineficiente para el negocio. 

El modelo de aplicación de 3 niveles también se denomina arquitectura monolítica. En estos días, tenemos varios modelos de arquitectura nuevos y, a continuación, examinaremos algunos que están disponibles ahora en la era de la nube.

En un modelo en la nube, las aplicaciones complejas diseñadas como una colección de servicios y datos están completamente desacopladas de la aplicación. Los microservicios son un estilo arquitectónico que estructura la aplicación como una colección de servicios. Cada servicio puede escribirse en un lenguaje de programación diferente y probarse por separado. Se pueden desplegar de forma independiente y están organizados en torno a las capacidades empresariales.

Tomemos el ejemplo de una aplicación de comercio electrónico desarrollada con arquitectura de microservicios. Cada microservicio puede centrarse en una única capacidad empresarial (por ejemplo, carrito de compras, búsqueda, comentarios de clientes). Cada uno de estos puede ser un servicio separado escrito en diferentes lenguajes de programación, desplegado en diferentes infraestructuras y administrado por diferentes equipos.

Cada servicio se comunica con los demás mediante un protocolo ligero. Para un modelo de 3 niveles, todos conocemos el marco Model View Controller (MVC). Sidecar, Ambassador y Adapter son algunas de las infraestructuras que admiten arquitecturas de microservicios.

Arquitectura de microservicios frente a arquitectura monolítica

En la arquitectura monolítica, todos estos componentes coexisten como un único módulo gestionado (en su mayoría) por un único equipo: todo está agrupado. Si necesita actualizar, debe desplegar toda la aplicación, y esto ralentiza los cambios para aplicaciones más grandes y complejas. Para aplicaciones más pequeñas, la arquitectura monolítica suele ser la mejor solución.

Microservicios, contenedores y Kubernetes

Una de las mejores opciones para crear y ejecutar arquitecturas de aplicaciones de microservicios es mediante el uso de contenedores. Los contenedores encapsulan un entorno de tiempo de ejecución de virtualización ligero para su aplicación y le permiten mover la aplicación desde el escritorio del desarrollador hasta el despliegue de producción. Puede ejecutar contenedores en máquinas virtuales o máquinas físicas en la mayoría de los sistemas operativos disponibles. Los contenedores presentan un entorno de software coherente, y usted puede encapsular todas las dependencias de su aplicación como una unidad desplegable. Los contenedores pueden ejecutarse en una computadora portátil, un servidor bare metal o en una nube pública.

Muchas organizaciones utilizan Kubernetes para gestionar contenedores y garantizar que no haya tiempo de inactividad. Kubernetes proporciona orquestación de contenedores en múltiples hosts y se utiliza para la gestión del ciclo de vida de los contenedores. Puede automatizar el despliegue, escalar automáticamente su aplicación y crear y enviar rápidamente con Kubernetes.

Para profundizar en Kubernetes, vea nuestro video "Kubernetes Explained":

Red Hat OpenShift es una de las plataformas de contenedores empresariales de nube híbrida líderes más populares. Muchos proveedores de la nube ofrecen contenedores como servicio (CaaS). Algunos de los otros motores de Kubernetes disponibles son IBM Cloud Kubernetes Service, Kubernetes de código abierto, AWS (EKS, ECS y Fargate), Google GKS y Azure AKS.

Por lo general, cada microservicio lo crea un pequeño equipo diferente, y eligen su lenguaje de programación y despliegue. Las empresas utilizan una malla de servicios como Istio para gestionar la comunicación entre los microservicios y la gestión. En una malla de servicios, las solicitudes se enrutan a través de proxies (como Sidecar) entre microservicios.

La arquitectura nativa de la nube está diseñada específicamente para aplicaciones que planean desplegarse en la nube, y los microservicios son una parte crítica.

Nativo de la nube es un enfoque para construir y ejecutar aplicaciones que explotan las ventajas del modelo de entrega de computación en la nube. Nativo de la nube es un término utilizado para describir entornos basados en contenedores, y se trata de cómo se crean y despliegan las aplicaciones, no dónde.

Las tecnologías nativas de la nube nos permiten ejecutar aplicaciones en nubes públicas, privadas e híbridas. El desarrollo nativo de la nube es esencial para llevar aplicaciones al mercado rápidamente; ayuda a las personas, los procesos y las tecnologías a construir, desplegar y gestionar aplicaciones que están listas para la nube.

El modelo de arquitectura nativa de la nube utiliza DevOps, integración continua (CI), entrega continua (CD), microservicios y contenedores. La mayoría de las empresas usan la metodología de doce factores para diseñar aplicaciones nativas de la nube escalables y robustas.

En la nube, las aplicaciones deben poder ejecutarse simultáneamente en varios nodos, compartir un estado de configuración/sesión, tener un mecanismo de registro centralizado y poder desplegarse mediante DevOps y un proceso de CI/CD. Muchos proveedores de la nube dan pautas para el desarrollo nativo de la nube: Amazon Web Services (AWS) tiene su infraestructura bien diseñada, Google tiene varias guías sobre cómo construir aplicaciones nativas de la nube y Microsoft Azure tiene su guía de patrones de la nube.

Por lo general, las aplicaciones nativas de la nube no tienen estado por naturaleza. Los servicios se comunican entre sí mediante protocolos o mensajes basados en REST. La API Gateway, el registro de contenedores, el middleware orientado a mensajes (MOM: Publish/Suscribe o Request/Response), la malla de servicios y las orquestaciones podrían ser parte de la arquitectura nativa de la nube.

La arquitectura basada en eventos (EDA) se basa en sistemas desacoplados que se ejecutan en respuesta a eventos. Una arquitectura basada en eventos utiliza eventos para activar y comunicar entre servicios desacoplados. La EDA ha estado aquí durante mucho tiempo, pero ahora tiene más relevancia en la nube.

Entonces, ¿qué hay de nuevo? Si se utiliza correctamente, puede proporcionar un aumento significativo de la agilidad, el ahorro de costos y los beneficios operativos. La EDA sin servidor distribuido puede ejecutar código conocido como funciones que escalan automáticamente en respuesta a una API REST o un desencadenador de eventos.

Para el modelo sin servidor, no se necesita gestión de servidores. El modelo sin servidor también es rápidamente escalable (por lo que son posibles actualizaciones y despliegues rápidos) y no tiene estado.

Estos son algunos de los servicios sin servidor en la nube actualmente disponibles de diferentes proveedores de la nube:

Tipos de tecnología sin servidor

• Funciones como servicio (FaaS): cargue piezas de funcionalidad en la nube y deje que estas piezas se ejecuten de forma independiente.
• Backend como servicio (BaaS): utilice servicios de terceros, como administración de aplicaciones, administración de bases de datos y almacenamiento en la nube.
• Backend móvil como servicio (MBaaS): funciones para aplicaciones móviles.

¿Cómo podemos hacer que las aplicaciones monolíticas funcionen bien en un entorno de nube? La arquitectura basada en la nube es la más adecuada para crear una aplicación web moderna (sitios web estáticos/dinámicos), desplegar una aplicación web, conectarse a una base de datos y analizar el comportamiento del usuario.

Una arquitectura de aplicaciones tradicional basada en la nube implica equilibradores de carga, servidores web, servidores de aplicaciones y bases de datos. Puede obtener un beneficio de las características de la nube, como la elasticidad de los recursos, las redes definidas por software, el aprovisionamiento automático, la alta disponibilidad y la escalabilidad.

Este tipo de arquitectura es ideal para organizaciones que no tienen que preocuparse por el mantenimiento de un servidor. Las funciones sin servidor admiten diferentes lenguajes de programación, como PHP, Java, .NET, Node.js, Python, Ruby, Docker y Go.

API Gateway es un servicio importante que facilita a los desarrolladores la creación y publicación de API seguras. Las API actuarán como puerta de entrada para que las aplicaciones accedan a los datos y a la lógica empresarial. También se encarga de la autorización y el control de acceso. Los desarrolladores utilizan API Gateway para invocar diferentes funciones sin servidor para diferentes llamadas a la API.

La decisión que tome al elegir un modelo de arquitectura puede influir en el éxito o el fracaso de su proyecto. Debe hacer su elección en función de su aplicación y de los requisitos no funcionales. Por ejemplo, usted no elige el transporte aéreo cuando desea viajar solo unas pocas millas.

Considere lo siguiente antes de elegir una arquitectura para su proyecto de aplicación:

• ¿Prioriza lo monolítico o el microservicio? (Para proyectos más pequeños con un requisito de aplicación simple, monolítico puede ser una opción correcta).
• ¿Su equipo está listo para utilizar microservicios?
• ¿Su equipo cuenta con un proceso existente de DevOps y CI/CD basado en la nube?
• ¿Cuál es su modelo de alojamiento? ¿Privado, público, híbrido?
• ¿Cómo afecta la arquitectura de la aplicación a su proyecto?
• ¿Le funciona una combinación de modelo de arquitectura múltiple?
• ¿Necesita persistencia y sesiones para sus aplicaciones?

La arquitectura de aplicaciones web sigue evolucionando para cumplir con los requisitos del negocio digital y el cambiante entorno de infraestructura de TI. Tecnologías como la inteligencia artificial, analytics, automatización, robótica avanzada, computación periférica, blockchain, Internet de las cosas (IoT) y API están redefiniendo lo que es posible en muchas industrias. El aumento de la complejidad en la infraestructura, las aplicaciones y el tamaño de los datos requiere nuevos enfoques de arquitectura. La mayoría de las empresas están adoptando un enfoque multinube mediante el uso de uno o más proveedores de la nube. Las empresas consumen servicios en la nube empleando modelos privados, públicos o híbridos como SaaS, PaaS o IaaS.

En días anteriores, el despliegue de aplicaciones era un proceso difícil y no podía realizarse durante el horario comercial normal. Sin embargo, los diferentes métodos de despliegue (como el despliegue blue-green y canary) junto con DevOps y CI/CD (integración continua y entrega continua) ahora permiten el despliegue en cualquier momento sin interrupciones de las aplicaciones.

Las arquitecturas monolíticas siguen siendo válidas para muchas aplicaciones, pero se debe utilizar la arquitectura adecuada para su caso de uso digital para lograr agilidad y tiempo de comercialización. Para una aplicación sencilla, considere elegir un enfoque monolítico tradicional. Los patrones nativos de la nube o de microservicios funcionan muy bien para aplicaciones en evolución con complejidades. Tiene sentido utilizar la arquitectura de microservicios cuando se tienen varios equipos experimentados que emplean varios idiomas y calendarios de despliegue. A continuación, se ofrece una comparación entre los modelos tradicionales de aplicación de 3/N niveles frente a los modelos de arquitectura basados en la nube como referencia.

Para comenzar a crear, regístrese para obtener un IBMid y cree su cuenta de IBM Cloud.