Instituto Tecnológico de las Américas

Presentación
Alfredo Fermín de los Santos
2019-8582
Programación II
Patrones de Arquitectura
Patrones a tratar
1.Microkernel
2.Microservicios
3.MVC
4.Cliente Servidor

1.Microkernel
Definición
El estilo arquitectónico de Microkernel o también conocido como arquitectura de Plug-in,
permite crear aplicaciones extensibles, mediante la cual es posible agregar nueva funcionalidad
mediante la adición de pequeños plugins que extienden la funcionalidad inicial del sistema.
Un microkernel es un minimalista. núcleo diseñado para ser lo más pequeño posible. Contiene
solo el código básico necesario para comunicarse con hardware y cargar un sistema operativo.

Casos de uso (Aplicaciones o sistemas donde se aplique el patrón)

Entre los sistemas operativos con micronúcleo podemos citar:
AIX
AmigaOS
Amoeba
Minix
Hurd
MorphOS
NeXTSTEP (algunos lo consideran un núcleo híbrido)
L4
Netkernel
RaOS
RadiOS
ChorusOS
QNX
SO3
Symbian
SymbOS
Zircon
AmayaOS
RedoxOS
Ventajas
 Testabilidad: Debido a que los Plugins y el sistema Core son desarrollados de forma por
separado, es posible probarlos de forma aislada.
 Performance: En cierta forma, muchas de las aplicaciones basadas en Microkernel
trabajan de forma Monolítica una vez que el Plug-in es instalado, lo que hace que todo el
procesamiento se haga en una sola unidad de software.
 Despliegue: Debido a la naturaleza de Plugins es posible instalar fácilmente todas las
características adicionales que sea necesarias, incluso, pueden ser agregar en tiempo de
ejecución, lo que en muchos casos ni siquiera requiere de un reinicio del sistema.
 Dinamismo: Las aplicaciones basadas en Plugins pueden habilitar o deshabilitar
características basadas en perfiles, lo que ayuda que solo los plugins necesarios sean
activados, incluso, pueden ser activados solo cuando son utilizados por primera vez (hot
deploy), lo que hace que los módulos que nunca se utilizan, no se activen nunca,
ahorrando una gran cantidad de recursos.
 Construcción modular: El sistema de Plugins permite que diferentes equipos puedan
trabajar en paralelo para desarrollar los diferentes Plugins.
 Reutilización: Debido a que los Plugins puede ser instalados en cualquier instancia del
sistema Core, es posible reutilizar los módulos en varias instancias, incluso, es posible
comercializarlas de forma independiente. Solo como ejemplo, existe empresas que se
dedican exclusivamente a desarrollar Plugins para venderlos, como es el caso de los
Plugins de Wordpress.

Desventajas
 Escalabilidad: Las aplicaciones basadas en Microkernel son generalmente desarrolladas
para ser ejecutadas en modo Standalone. Si bien existen aplicaciones que implementan el
estilo de Microkernel que son altamente escalables como algunos servidores de
aplicaciones, la realidad es que este no es un estilo arquitectónico que se distinga por
crear aplicaciones altamente escalables.
 Alta complejidad: Las aplicaciones basadas en Microkernel son difíciles de desarrollar,
no solo por la habilidad técnica para soportar la agregación de funcionalidad adicional
por medio de Plugins, si no que requiere un análisis muy elaborado para identificar hasta
qué punto puede ser extendida la aplicación sin afectar la esencia del sistema Core.
2.Microservicios
Definición, Descripción
La arquitectura de microservicios es una aproximación para el desarrollo de software que
consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se
ejecutan en su propio proceso y se comunican con mecanismos ligeros (normalmente una API de
recursos HTTP). Cada servicio se encarga de implementar una funcionalidad completa del
negocio. Cada servicio es desplegado de forma independiente y puede estar programado en
distintos lenguajes y usar diferentes tecnologías de almacenamiento de datos.
La mejor manera de entender la arquitectura de microservicios es imaginarse las capas de
software de la pila del servidor web. El sistema operativo del servidor web puede ser Windows,
Linux o BSD. Hay herramientas para la gestión del centro de datos y el equilibrio de carga de la
red. Es posible elegir Apache, IIS, NGINX, Caddy, Tomcat, etc. para el servidor web. A
continuación, se encuentra la capa para el lenguaje de programación instalado, como PHP,
ASP.net, Python, Ruby, Perl, Java y Go. Después está la capa de los marcos de bases de datos,
como MySQL, MSSQL, PostgreSQL y MongoDB. Otra capa para las utilidades de
almacenamiento en caché, como Varnish, Redis, redes de distribución de contenido (CDN) y las
utilidades de optimización. Otras capas pueden incluir servidores perimetrales, plataformas sin
servidor y la integración de la inteligencia artificial o el aprendizaje automático. Dentro de un
ecosistema de cloud pública existen miles de microservicios que funcionan simultáneamente y
que es necesario gestionar en la red de servicios para facilitar la interoperabilidad, el
enrutamiento y las comunicaciones.
Casos de uso (Aplicaciones o sistemas donde se aplique el patrón)
Netflix: Esta plataforma tiene una arquitectura generalizada que desde hace ya un par de años
(coincidiendo con su “boom” en U.S.A.) se pasó a los microservicios para el funcionamiento de
sus productos. A diario recibe una media de mil millones de llamadas a sus diferentes servicios
(se dice que es responsable del 30% del tráfico de Internet) y es capaz de adaptarse a más de 800
tipos de dispositivos mediante su API de streaming de vídeo, la cual, para ofrecer un servicio
más estable, por cada solicitud que le pedimos, ésta realiza cinco solicitudes a diferentes
servidores para no perder nunca la continuidad de la transmisión.

Amazon: No soporta tantos dispositivos como Netflix, pero tampoco es que sea fundamental
para cubrir su sector. Migró hace tres años a la arquitectura de microservicios siendo una de las
primeras grandes compañías que la implementaban en producción. No hay cifra aproximada de
la cantidad de solicitudes que pueden recibir a diario, pero no son pocas. Entre éstas encontramos
multitud de aplicaciones, las API del servicio web que ofrecen o la propia web de Amazon,
cuyos ingenieros reconocen que habría sido imposible sobre la arquitectura monolítica con la que
trabajaban previamente.
Ebay: Cómo no, una de las empresas con mayor visión de futuro, siendo pionera en la adopción
de tecnologías como Docker o ésta que nos ocupa. Su aplicación principal comprende varios
servicios autónomos, y cada uno ejecutará la lógica propia de cada área funcional que se ofrece a
los clientes
Ventajas
 Innovación rápida: cuando es necesario crear funciones nuevas para las aplicaciones de
software, las empresas tanto tradicionales como emergentes pueden presentar
innovaciones en el mercado con mayor rapidez que si utilizan la arquitectura monolítica.
Los clientes que utilizan aplicaciones web y móviles exigen características nuevas. Las
tecnologías innovadoras reciben financiación a través de la adopción por parte de los
usuarios y las empresas. Tanto las empresas emergentes como las grandes empresas de TI
encuentran ventajas al mantenerse a la vanguardia de la programación y el desarrollo
mediante la integración de nuevos microservicios.
 Mayores niveles de automatización de los centros de datos: los desarrolladores
prefieren utilizar ciertas plataformas o estándares en su trabajo y esto incluye el uso de
lenguajes de programación y bases de datos en las aplicaciones web o móviles con
microservicios. Los microservicios se conectan a través de procesos controlados
mediante scripts, como las API, que pueden ofrecer mayores niveles de automatización
de los centros de datos.

 Fácil de entender y modificar, por lo que la integración de nuevos miembros al equipo de

desarrollo será muy rápida.

 Los desarrolladores podrán hacer uso de las tecnologías más actuales.

 El uso de contenedores hará el desarrollo y despliegue de la app mucho más rápido.

 Funcionalidad modular, con lo que la modificación de un módulo no afectará al

funcionamiento del resto.

 Fácil de escalar e integrar con aplicaciones de tercero

Desventajas
 Las pruebas o testeos pueden resultar complicados debido al despliegue distribuido.
 Un gran número de servicios puede dar lugar a grandes bloques de información que
gestionar.
  Será labor de los desarrolladores lidiar con aspectos como la latencia de la red, tolerancia
a fallos, balanceo de carga, cantidad de formatos admitidos, etc…
 Sistema distribuido puede llegar a significar doble trabajo.
 Si se cuenta con un gran número de servicios, integrarlos y gestionarlos puede resultar
muy complejo.
 Esta tecnología suele incurrir en un alto consumo de memoria.
 Fragmentar una aplicación en diferentes microservicios puede llevar muchas horas de
planificación (y casi podría considerarse un arte).
3.MVC
Definición y descripción
Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y
principalmente lo que es la lógica de negocio de una aplicación de su representación y el módulo
encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la
construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir,
por un lado, define componentes para la representación de la información, y por otro lado para la
interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de
reutilización de código y la separación de conceptos, características que buscan facilitar la tarea
de desarrollo de aplicaciones y su posterior mantenimiento.

De manera genérica, los componentes de MVC se podrían definir como sigue:

El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto,
gestiona todos los accesos a dicha información, tantas consultas como actualizaciones,
implementando también los privilegios de acceso que se hayan descrito en las especificaciones
de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada
momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de
acceso o manipulación de información llegan al 'modelo' a través del 'controlador'.
El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al
'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento
o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se
solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o
scroll por un documento o por los diferentes registros de una base de datos), por tanto, se podría
decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo' (véase Middleware).
La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para
interactuar (usualmente la interfaz de usuario), por tanto, requiere de dicho 'modelo' la
información que debe representar como salida.
Casos de uso (Aplicaciones o sistemas donde se aplique el patrón)
Ruby On Rails. Se trata de una aplicación experimentada (su desarrollo empezó en 2003) que
ofrece una estructura web open source basada en Ruby que permite la creación de aplicaciones
para el mundo real. Todas sus capas (usa el patrón de arquitectura MVC para organizar la
programación de aplicaciones) son construidas para trabajar integradas perfectamente. A través
de este framework, todo lo que va desde las plantillas para controlar el flujo hasta la lógica de
negocio está escrito en Ruby. Webs tan conocidas como Twitter, GitHub, Hulu o Slideshare usan
este framework.
CakePHP. Es un framework de desarrollo rápido de aplicaciones open source muy flexible,
basado en MVC e inspirado en Ruby On Rails. Esta estructura emplea patrones de diseño
comúnmente conocidos como Active Record, Association Data Mapping, Front Controler y
MVC. Su principal objetivo es proporcionar un framework estructurado que permita a los
usuarios de PHP en cualquier nivel desarrollar rápidamente aplicaciones web muy sólidas sin
perder nada de flexibilidad. Sitios como MapMe, Copify, Piano Marvel y Flipcomp usan
CakePHP.
Catalyst. Se trata de una elegante estructura open source para aplicaciones web. Entre sus
ventajas se encuentra su sencillez y flexibilidad. A través de ella, los desarrolladores pueden
construir aplicaciones que funcionan en la web o que lo hacen usando protocolos empleados para
ella. Catalyst ha sido diseñado para facilitar la gestión de una gran variedad de tareas necesarias
para que una aplicación funcione en la web, bien haciéndolas ella misma o bien permitiendo la
conexión de módulos Perl que puedan realizarlas. Este framework se inspira en otros similares
como Ruby on Rails, Maypole o Spring. Catalyst sigue el patrón de diseño basado en MVC, lo
que permite separar asuntos como el contenido, la presentación y el control del flujo en módulos
separados. Esta separación permite al desarrollador modificar el código que se encarga de un
asunto determinado sin afectar al código que maneja los otros. Sitios web como BBC iPlayer,
Edit Grid o Manchester Evening News usan este framework.
Ventajas
La clara separación de responsabilidades impuesta por el uso del patrón MVC hace que los
componentes de nuestras aplicaciones tengan sus misiones bien definidas. Por lo tanto, nuestros
sistemas serán más limpios, simples, más fácilmente mantenibles y, a la postre, más robustos.
Mayor velocidad de desarrollo en equipo, que es consecuencia de lo anterior, ya que al estar
separado en tres partes tan diferenciadas, diferentes programadores pueden ocuparse de cada
parte en paralelo. Esto la hace ideal para el desarrollo de aplicaciones grandes.
Múltiples vistas a partir del mismo modelo, pudiendo reaprovechar mucho mejor los desarrollos
y asegurando consistencia entre ellas.
Facilidad para realización de pruebas unitarias.
Desventajas
Hay que ceñirse a las convenciones y al patrón. El uso de las convenciones impuestas por el
framework y la estructura propuesta por el patrón arquitectural MVC nos obliga a ceñirnos a las
mismas, lo que puede resultar a veces algo tedioso si lo comparamos con la forma habitual de
trabajar con otros frameworks que dan más libertad al desarrollador. La división impuesta por el
patrón MVC obliga a mantener un mayor número de archivos, incluso para tareas simples.
Curva de aprendizaje. Dependiendo del punto de partida, el salto a MVC puede resultar un
cambio radical y su adopción requerirá cierto esfuerzo. Además, utilizarlo implica conocer bien
las tecnologías subyacentes con las que se implemente: la plataforma de programación utilizada,
además de la tecnología utilizada para la interfaz de usuario (HTML, CSS, JavaScript en el caso
de la Web).

4.Cliente Servidor
Definición y descripción
La arquitectura cliente-servidor es un modelo de diseño de software en el que las tareas se
reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes,
llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da
respuesta.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores,
aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la
gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el
diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se
ejecuta necesariamente sobre una sola máquina ni es necesariamente un solo programa. Los tipos
específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores
del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura
básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en
diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el
grado de distribución del sistema.
Casos de uso (Aplicaciones o sistemas donde se aplique el patrón)
Navegar una web funciona basándonos en un cliente web (navegador) y un servidor web como
Apache, Nginx o LiteSpeed
Protocolo FTP, funciona de idéntica forma, se utiliza un cliente de FTP (como Filezilla) para
conectar a un servidor FTP (como Pure-FTPD, Proftpd, etc)
SSH: es idéntico también, se utiliza un cliente SSH para conectar al servidor SSH que corre en
una red remota.
Juegos en red: existen clientes que permiten a jugadores online jugar desde sus casas
conectándose a servidores de juegos remotos.
Sistema DNS: el famoso servidor DNS interactúa con clientes DNS también, es decir, basa su
arquitectura en el modelo cliente servidor
Servidor de Correo: donde clientes de correo consultan el correo al servidor de correo remoto,
tanto desde móvil o una computadora de escritorio o laptop.
Ventajas
Centralización del control: los accesos, recursos y la integridad de los datos son controlados por
el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el
sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos (mejor
que en las redes P2P) …
Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier
elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos
nodos a la red (clientes y/o servidores).
Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios
ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un
servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán
mínimamente). Esta independencia de los cambios también se conoce como encapsulación.
Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que
aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de
empleo.
En las redes C/S los demás clientes no tienen acceso a las IP's por lo que se dificulta el rastreo
y/o hackeo de los usuarios.
Desventajas
La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran
cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause
muchos problemas para este (a mayor número de clientes, más problemas para el servidor). Al
contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuantos más
nodos hay, mejor es el ancho de banda que se tiene.
El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído,
las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los
recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos salgan o
abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de
los nodos en la red.
El software y el hardware de un servidor son generalmente muy determinantes. Un hardware
regular de un ordenador personal puede no poder servir a cierta cantidad de clientes.
Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para
satisfacer el trabajo. Por supuesto, esto aumentará el coste.
El cliente no dispone de los recursos que puedan existir en el servidor. Por ejemplo, si la
aplicación es una Web, no podemos escribir en el disco duro del cliente o imprimir directamente
sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores.
En las redes C/S la única forma de obtener la información es a través de la que proporciona el
servidor el cual los clientes no pueden compartir información entre ellos.