Puntos clave: La arquitectura N-tier organiza el software en múltiples capas distintas, mejorando la escalabilidad, la seguridad y la resiliencia. Separa la presentación, la lógica de negocio y los niveles de datos en diversos entornos, optimizando el rendimiento y permitiendo un mantenimiento flexible.
- Mejora la escalabilidad y la seguridad mediante la separación de niveles.
- Permite una mayor flexibilidad en recuperación ante desastres y mantenimiento.
Cuando la computación empresarial empezó a pasar del mainframe a máquinas más asequibles, uno elegía un ordenador y lo "promovía" a servidor instalando un motor de base de datos, algún tipo de intérprete de código con compilador, y desarrollando código que luego Crea la herramienta necesaria. Esto significaba que el software de interfaz de usuario (UI), el propio programa y la base de datos se ejecutaban en la misma plataforma (sistema operativo y ordenador). No pasó mucho tiempo hasta que la industria informática empezó a darse cuenta de que cosas como plazos de parcheo distintos de los fabricantes de sistemas operativos y motores de bases de datos, incidentes recurrentes comunes o incluso la necesidad de actualizar o actualizar componentes requerían una mitigación urgente dividiendo física y lógicamente los niveles de procesamiento y base de datos. Así, comenzaron a utilizarse soluciones de arquitectura Tier 2. A medida que internet se popularizó en los años 90, trajo consigo una revolución en términos de interfaz de usuario más eficiente y capaz, pero que requería un servidor web específico. Esto facilitó ampliamente la proliferación de la arquitectura Tier 3, en la que el componente de interfaz se separaba del núcleo de computación y la base de datos. El gráfico a continuación muestra cómo se desarrolla esto en la web:
¿Qué es la arquitectura N-Tier?
La arquitectura N-tier (o multi-tier) se refiere a software cuyas múltiples capas están renderizadas por diferentes entornos TI (tiers) bajo una lógica cliente-servidor. La interfaz de usuario (Presentation Tier) se ejecuta en un entorno separado del "computation" (Business Logic Tier), que a su vez también se ejecuta en un entorno distinto al motor de base de datos y las instancias (Data Tier). Estos entornos distintos (Tiers) suelen involucrar diferentes servidores, redes de centros de datos y, a menudo, geografías. Antes de avanzar, es importante aclarar la diferencia entre un "Tier" y una "Layer". Una capa están un componente lógico dentro de un conjunto de software que realiza una funcionalidad determinada, mientras que un tier están la plataforma lógica y hardware donde se ejecuta dicha capa. La mayoría de las veces tiene sentido separar los niveles mencionados para Lograr mayor flexibilidad, sinergia, seguridad y eficiencia arquitectónicas. considera Amazon.com como ejemplo:
- Amazon debe ser accesible desde cualquier lugar, en cualquier momento y en cualquier plataforma (PC; Tablet; Smartphone), así que solo en el Nivel de Presentación son, de hecho, varios niveles con "sabores" distintos (Windows, iOS, Android).
- El propio Business Logic Tier comprende no solo servidores distribuidos por varias geografías que procesan datos, sino también la entrada automatizada de almacenes y componentes logísticos (tiers) que procesan datos por sí mismos (capas de software distintas) para transmitir información al Amazon Business Logic Tier (así que aquí también hay varios niveles).
- Finalmente, el Nivel de Datos no solo están replicado y distribuido, sino que también se divide en niveles distintos de instancias de datos (capas) en servidores separados (tiers).
Un ejemplo detallado de la arquitectura N-Tier
Veamos un ejemplo concreto de la industria automovilística relacionado con software logístico que pretende servir a la línea de montaje del fabricante con información actualizada en fracciones de segundo sobre el estado de entrega de piezas, por lo que debe ser alimentado por datos de:
- El taller de la fábrica (línea de montaje): ¿llegaron las piezas o no
- Empresas de terceros proveedores de repuestos: fueron las piezas producidas
- Almacenes logísticos: ¿las piezas salieron/llegaron al almacén
- Camiones en la carretera – ¿dónde son, transportando qué piezas
- Sala de control logística – dónde está todo y todos
- Área de planificación anticipada de la producción en fábrica: qué piezas necesitamos, para cuándo, para Lograr ciclos de producción optimizados
Para lograr esto, se está necesario un sistema que pueda:
- Recopila constantemente información de varias fuentes distintas (internas y externas/remotas) sobre el estado.
- Luego procesarla y devolver información valiosa sobre el estado que Permite a los responsables de la toma de decisiones una conciencia precisa y asertiva sobre cómo se está logrando el progreso respecto a la previsión de producción, de manera que estos puedan actuar para mitigar cualquier alto riesgo potencial de incumplimiento.
- Permitir que el equipo de planificación avanzada emita órdenes de producción de piezas para los días siguientes para cumplir con el plan de producción establecido.
A continuación están la arquitectura del sistema para los niveles de software necesarios:
Nivel de Presentación
El nivel de presentación debe abordar varios tipos de protocolos y plataformas de interfaz de usuario, en concreto:
- Los usuarios internos del fabricante de automóviles, tanto de la sala de control logística como de las áreas de planificación de producción, donde los usuarios podían Haz cambios en las reglas y procesos de negocio. Esto requiere una interfaz de usuario robusta y segura (como una aplicación cliente de escritorio); además, los usuarios clave en la planta de taller necesitan consultar y facturar las piezas a medida que llegan. Esto se ejecutaría desde una capa de software de servicio cliente en una máquina que estaría físicamente dentro de la red del fabricante y servida por toda la infraestructura LAN/WAN (asegurando redundancia, mayor seguridad y velocidad).
- Los proveedores de terceros y los usuarios del almacén logístico residen en los entornos informáticos de entidades de terceros terceros y, por tanto, no son autorizados a acceder a la LAN o WAN del fabricante. Por lo tanto, la solución más adecuada, segura y rápida sería desarrollar una capa de software de servicio cliente basada en la web que recurra a un clúster de servidores web con un clúster de máquina dentro del centro de datos del fabricante y otro en la DMZ (donde los proveedores autorizados puedan acceder mediante protocolos de autenticación fuertes). Ambos nodos del clúster (interno y DMZ) deberían instalarse en geografías distintas para permitir redundancia y alta disponibilidad.
- Los camiones tendrían que estar equipados con clientes de E/S automatizados que transmitieran las coordenadas GPS y el ID de la lista del material a través de un servicio público móvil de datos web a través de servidores web instalados en la DMZ mediante dos ISP de países distintos para garantizar redundancia y alta disponibilidad.
- Algunos usuarios especiales, como los gerentes de área y directores de planta, tendrían que Obtén alertas y mensajes para acceder al sistema desde una perspectiva de informes de gestión a través de sus smartphones o tabletas mediante servidores web centralizados dentro de la red del fabricante (dos geografías para garantizar la redundancia), así como en movimiento a través de los ISP.
Nivel de Lógica de Negocio
El nivel de lógica de negocio estaría constituido por varios niveles de clústeres de servidores de aplicaciones distribuidos por varios centros de datos en geografías separadas, con una capa de producción ejecutándose en un servidor y una capa de calidad/pruebas ejecutándose en otro servidor en cada centro de datos.
Nivel de datos
La capa de datos consistiría en un clúster activo de servidores de bases de datos con múltiples nodos (servidores), cada uno ejecutando su capa distribuida por dos centros de datos en geografías separadas, además de una capa histórica de datos/recuperación rápida en otra ubicación geográfica distinta. Este ejemplo asume que la organización está responsable de toda la infraestructura: una arquitectura basada en la nube con entornos virtualizados proporcionaría aún más flexibilidad, resiliencia y "Tiers" así como "Layers" a toda la solución.
Ventajas de la arquitectura N-Tier
- Escalabilidad – tener varios componentes separados en la arquitectura permite una escalabilidad fácil actualizando uno o más de esos componentes individuales. Por ejemplo, si el número de clientes públicos crece, puede requerir separar el Webservice añadiendo nueva capacidad para atender la demanda del cliente, lo que significa más servidores web en el Nivel de Presentación; otro ejemplo sería un lanzamiento online que amplie su cartera de productos; en este caso, la necesidad de crecer probablemente estará en el Nivel de Datos.
- Seguridad mejorada – Una arquitectura que están distribuida en varios niveles permite situarlas en zonas de seguridad distintas (tanto lógicas como geográficas) para asegurar que cada componente están protegido según su nivel central de criticidad empresarial. En el ejemplo presentado, los servidores web, aunque están en una DMZ protegida por cortafuegos, tienen menos necesidad de cobertura de seguridad que los servidores de aplicaciones o bases de datos donde se están procesar o reside todos los datos críticos del negocio.
- Resiliencia y redundancia – Los componentes críticos pueden dividirse fácilmente en niveles que son agrupados y geográficamente para asegurar la conmutación por error, de tanto un sistema más resiliente.
- Flexibilidad de mantenimiento – Como en el caso de la escalabilidad, tener niveles distintos permite acciones de mantenimiento precisas que no generen efectos secundarios colaterales. Esto significa que la programación de mantenimiento tiene menos dependencias de componentes de terceros terceros.
- Recuperación ante desastres – Una arquitectura N-Tier permite restaurar componentes individuales en caso de interrupciones parciales del servicio, sean graves o no, permitiendo así tiempos de recuperación más cortos. En el caso de sistemas robustos, redundantes y bien distribuidos (como los que soportan Google, Amazon, PayPal, otros), las actividades de restauración ni siquiera son registradas por los usuarios finales debido a la redundancia existente.
- Entorno amigable para desarrolladores – Tener las distintas capas de código divididas en niveles distintos permite a los desarrolladores centrarse en su tarea individual sin tener que compartir recursos ni tener en cuenta posibles impactos colaterales en las tareas o dominios de los demás. Este es tipo de arquitectura que también potencia frameworks y culturas de programación como DevOps y Agile/Lean.
Desventajas de la arquitectura N-Tier
- Rendimiento – Parece una paradoja que dividir los varios componentes para permitir una mejor eficiencia y rendimiento pueda suponer el riesgo de menor rendimiento. Este riesgo se refiere básicamente a componentes/servicios de terceros. Tener la arquitectura distribuida por diferentes geografías y niveles significa que todo el sistema depende mucho del flujo de E/S. Si está dentro de una red cerrada (una LAN/WAN), el elemento crítico están toda la infraestructura de cableado, conmutación y enrutamiento, mientras que en el caso de usar infraestructura basada en la nube el tema también incluye varios ISP, cuya infraestructura de comunicación individual puede no ser sincrónica en términos de rendimiento.
- Mayor CAPEX y OPEX – añadir componentes a la arquitectura implica la necesidad de inversión inicial adicional, gastos de mantenimiento operativos, presupuesto así como servicios de soporte. Esto está especialmente preocupante cuando no se dependen de servicios basados en la nube.
Cómo ha evolucionado N-Tier hacia la nube
En las últimas décadas, los sistemas informáticos se han convertido en uno de los pilares de nuestra economía global y factores clave como la seguridad, la alta disponibilidad y la flexibilidad han llevado a la mayoría de las empresas a migrar sus sistemas informáticos principales a una arquitectura N-Tier. Entonces, ¿cuál era el problema? ¡OPEX y CAPEX! Multiplicar el número de niveles y capas de software dentro de una arquitectura geográficamente distribuida para asegurar los factores clave mencionados no era rentable para la mayoría de las empresas, pero luego ... el mercado respondió con una sólida oferta de computación en la nube. Empresas como IBM o AWS (Amazon Web Services) crearon grandes entornos informáticos informáticos y ahora las empresas podían migrar progresivamente sus entornos IT a esos entornos cloud pagando solo una tarifa que representaba un pequeño porcentaje del coste de implementar y mantener sus propios entornos informáticos basados en arquitectura N-Tier.
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.