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

Todos conocemos la arquitectura de aplicaciones de tres 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.

Cuenta con 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 tres niveles.

En pocas palabras, el modelo de aplicación de tres niveles está anticuado. Se diseñó 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 resultar ineficaz para la empresa. 

El modelo de aplicación de tres niveles también suele denominarse arquitectura monolítica. En la actualidad, disponemos de múltiples modelos de arquitectura nuevos y, a continuación, examinaremos algunos de los que están disponibles ahora en la era de la nube.

En un modelo de nube, las aplicaciones complejas diseñadas como un conjunto de servicios y datos están totalmente 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 implementar 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 utilizando una arquitectura de microservicios. Cada microservicio puede centrarse en una única capacidad empresarial (por ejemplo, carrito de la compra, búsqueda, reseña del cliente). Cada uno puede ser un servicio independiente escrito en diferentes lenguajes de programación, implementado en una infraestructura diferente y gestionado por diferentes equipos.

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

Arquitectura de microservicios vs. 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, tiene que implementar toda la aplicación y esto ralentiza los cambios en las 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 utilizar 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 la implementación de producción. Puede ejecutar contenedores en máquinas virtuales o físicas en la mayoría de los sistemas operativos disponibles. Los contenedores presentan un entorno de software coherente y puede encapsular todas las dependencias de su aplicación como una unidad implementable. Los contenedores pueden ejecutarse en un ordenador portátil, en un servidor bare metal o en una nube pública.

Muchas organizaciones utilizan Kubernetes para gestionar los contenedores y garantizar que no haya tiempos de inactividad. Kubernetes proporciona la orquestación de contenedores en varios hosts y se utiliza para gestionar el ciclo de vida de los contenedores. Puede automatizar la implementación, escalar automáticamente su aplicación y crear y enviar rápidamente utilizando Kubernetes.

Para profundizar en Kubernetes, vea nuestro vídeo "Kubernetes Explained":

Red Hat OpenShift es una de las plataformas de contenedores empresariales líderes más populares de  nube híbrida. Muchos proveedores de servicios en la nube ofrecen contenedores como servicio (CaaS). Algunos de los otros motores 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 equipo pequeño diferente y ellos eligen su lenguaje de programación y su calendario de implementación. Las empresas utilizan una malla de servicios como Istio para controlar 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 implementar en la nube, y los microservicios son una parte crítica.

Nativo de la nube es un enfoque para crear y ejecutar aplicaciones que explotan las ventajas del modelo de entrega de cloud computing. Nativo de la nube es un término utilizado para describir los entornos basados en contenedores, y se trata de cómo se crean e implementan las aplicaciones, no de dónde.

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

El modelo de arquitectura nativo de la nube utiliza DevOps, integración continua (CI), entrega continua (CD), microservicios y contenedores. La mayoría de las empresas utilizan la metodología de los 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 información de registro centralizado y poder implementar mediante DevOps y un proceso CI/CD. Muchos proveedores de servicios en la nube ofrecen directrices para el desarrollo nativo en la nube: Amazon Web Services (AWS) cuenta con su marco bien diseñado, Google tiene varias guías sobre cómo crear aplicaciones nativas en la nube y Microsoft Azure tiene su guía de patrones en la nube.

Normalmente, las aplicaciones nativas de la nube son apátridas 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: publicación/suscripción o solicitud/respuesta), la malla de servicios y las orquestaciones podrían formar 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 servicios desacoplados y comunicarse entre ellos. La EDA lleva aquí mucho tiempo, pero ahora tiene más relevancia en la nube.

Entonces, ¿cuál es la novedad? Si se usa correctamente, puede aumentar significativamente la agilidad, el ahorro de costes y los beneficios operativos. El EDA distribuido sin servidor puede ejecutar código conocido como funciones que se escalan automáticamente en respuesta a una API REST o a un desencadenante de eventos.

Para el modelo sin servidores, no es necesaria la gestión de servidores. El modelo sin servidor también es rápidamente escalable (por lo que es posible realizar actualizaciones e implementaciones rápidas) y no tiene estado.

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

Tipos de sin servidor

• Funciones como servicio (FaaS): suba partes de la funcionalidad a la nube y deje que estas partes se ejecuten de forma independiente.
• Backend como servicio (BaaS): utilice servicios de un tercero, como la gestión de aplicaciones, la gestión de bases de datos y el almacenamiento en la nube.
• Mobile backend 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 en la nube es la más adecuada para construir una aplicación web moderna (sitios web estáticos/dinámicos), implementar una aplicación web, conectarse a una base de datos y analizar el comportamiento de los usuarios.

Una arquitectura de aplicaciones tradicional basada en la nube implica equilibradores de carga, servidores web, servidores de aplicaciones y bases de datos. Puede beneficiarse 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 las organizaciones que no tienen que preocuparse del 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 elegir en función de su aplicación y de los requisitos no funcionales. Por ejemplo, no se elige el transporte aéreo cuando se quiere viajar solo unos pocos kilómetros.

Tenga en cuenta lo siguiente antes de elegir una arquitectura para su proyecto de aplicación:

• ¿Se antepone lo monolítico o los microservicios? (Para proyectos más pequeños con un requisito de aplicación simple, monolítico puede ser una opción correcta).
• ¿Está su equipo preparado para utilizar microservicios?
• ¿Su equipo tiene un proceso de DevOps y CI/CD basado en la nube existente?
• ¿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 conviene una combinación de varios modelos de arquitectura?
• ¿Necesita persistencia y sesiones para sus aplicaciones?

La arquitectura de las aplicaciones web sigue evolucionando para satisfacer los requisitos de las empresas digitales y el cambiante entorno de las infraestructuras de TI. Tecnologías como la inteligencia artificial, el análisis, la automatización, la robótica avanzada, el edge computing, el blockchain, el Internet de las cosas (IoT), y las API están redefiniendo lo que es posible en muchos sectores. La creciente complejidad de 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 servicios en la nube. Las empresas consumen servicios cloud por medio de modelos privados, públicos o híbridos con SaaS, PaaS o IaaS.

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

Las arquitecturas monolíticas siguen siendo válidas para muchas aplicaciones, pero hay que utilizar la arquitectura adecuada para su caso de uso digital a fin de lograr agilidad y tiempo de comercialización. Para una aplicación sencilla, considere la posibilidad de 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 una arquitectura de microservicios cuando se cuenta con varios equipos experimentados que utilizan múltiples lenguajes y calendarios de implementación. A continuación se ofrece una comparación entre la aplicación tradicional de 3/N niveles y los modelos de arquitectura basados en la nube, a modo de referencia.

Para comenzar, regístrese en un IBMid y cree su cuenta de IBM Cloud.