PRESENTACIÓN
NOMBRE: Federico Benjamin Bencosme Díaz
MATRICULA: 2019-8210
MAESTRO: Juan Emmanuel Rosario
TRABAJO: Patrones de Arquitectura
PATRONES DE ARQUITECTURA
■ Microkernel
■ Microservicios
■ MVC
■ Cliente Servidor
Definicion del Patrón de Arquitetura
Microkernel
■ El patrón arquitectónico Microkernel también se conoce como un patrón arquitectónico
enchufable. Se utiliza típicamente cuando los equipos de software crean sistemas con
componentes intercambiables.
■ Se aplica a los sistemas de software que deben ser capaces de adaptarse a los
requisitos cambiantes del sistema. Separa un núcleo funcional mínimo de la
funcionalidad ampliada y de las partes específicas del cliente. También sirve de enchufe
para conectar estas extensiones y coordinar su colaboración.
■ El patrón de la arquitectura Microkernel es un patrón natural para implementar
aplicaciones basadas en productos. Y una aplicación basada en el producto es aquella
que está empaquetada y disponible para su descarga en versiones como un típico
producto de terceros. Sin embargo, muchas empresas también desarrollan y lanzan sus
aplicaciones empresariales internas como productos de software, completas con
versiones, notas de lanzamiento y funciones enchufables.
Descripcion del Patrón de Arquitetura
Microkernel
Como descripción es valido poner los componentes del patrón:
■ Esta arquitectura esta compuesta por 2 componentes, el sistema core y los
modulos plug-in. El core contiene la mínima funcionalidad y los módulos plug-in son
componentes autónomos e independientes que contienen procesamiento
especializado, características adicionales y código personalizado que está diseñado
para mejorar o ampliar el sistema central para producir capacidades empresariales
adicionales. Generalmente, los módulos plug-in deben ser independientes de otros
módulos plug-in, pero ciertamente puede diseñar plug-ins que requieran que otros
plug-ins estén presentes. De cualquier manera, es importante mantener la
comunicación entre plug-ins a un mínimo para evitar problemas de dependencia.
Casos de uso (Aplicaciones o sistemas
donde se aplique el patrón)
■ Netflix: En el pasado, cuando todavía no era un servicio de streaming, sino que enviaba por correo
películas en formato DVD, Netflix se basaba, como la mayoría de empresas, en un sistema
monolítico, hasta que en 2008 un error en una base de datos provocó una interrupción del servicio
durante cuatro días. A partir de este momento se decidió desintegrar el antiguo sistema y dividirlo
en microservicios. Con esto se logró que la empresa pudiera lanzar los cambios mucho más
rápidamente y que las reparaciones también pudieran llevarse a cabo con mucha más agilidad.
■ Spotify: Spotify, otro popular servicio de streaming, también apuesta por los microservicios. El
mayor desafío al que la empresa debe hacer frente a diario es la enorme competencia: con
Amazon, Apple y Google, el mercado del streaming de audio tiene a algunas de las empresas
informáticas más poderosas del mundo como compañeros de equipo. Al mismo tiempo, los
desarrolladores, debido al incremento sostenido de suscriptores, han de cubrir una demanda en
constante crecimiento y observar ciertas reglas propias del negocio, como los derechos de
licencia.
■ eBay: La plataforma de ventas eBay comenzó, como la mayoría de sistemas, como uno monolítico,
pero con el tiempo acumuló 3,4 millones de líneas de código en un único archivo. Esto llevó a la
empresa a plantearse romper el monolito y desarrollar microservicios en Java. Aquí los diversos
servicios también se comunican con el resto por REST.
Ventejas del Patrón de Arquitetura
Microkernel
■ 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 del Patrón de Arquitetura
Microkernel
■ 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.
Definicion del Patrón de Arquitetura
Microservicios
■ La arquitectura de microservicios es un método de desarrollo de aplicaciones software
que funciona como un conjunto de pequeños servicios que se ejecutan de manera
independiente y autónoma, proporcionando una funcionalidad de negocio completa. En
ella, cada microservicio es un código que puede estar en un lenguaje de programación
diferente, y que desempeña una función específica. Los microservicios se comunican
entre sí a través de APIs, y cuentan con sistemas de almacenamiento propios, lo que
evita la sobrecarga y caída de la aplicación.
■ La arquitectura de microservicios esta basada en un patrón cuyo máximo objetivo es
poder desacoplar lo máximo posible todos los componentes. No existe una definición
formal sobre microservicios, pero lo que sí existen en estas arquitecturas, son una serie
de características comunes.
■ El objetivo de los microservicios es aumentar la velocidad de las versiones de la
aplicación mediante la descomposición de la aplicación en servicios autónomos
pequeños que se pueden implementar de forma independiente. Una arquitectura de
microservicios también conlleva algunos desafíos. Los modelos de diseño que se
muestran aquí pueden ayudar a mitigar estos desafíos.
Descripcion del Patrón de Arquitetura
Microservicios
Como descripción es valido poner los componentes del patrón:
■ Los microservicios de SiteWhere hacen algunas suposiciones sobre la
infraestructura subyacente en la que se están ejecutando. Como mínimo, las
instancias de Apache ZooKeeper y Apache Kafka deben estar disponibles para que
el sistema funcione correctamente. De forma predeterminada, SiteWhere también
produce datos de seguimiento distribuidos a través del estándar open tracing para
el análisis del rendimiento en tiempo de ejecución. Un servidor de backend que
admita la API se puede configurar para almacenar y analizar los datos.
Casos de uso (Aplicaciones o sistemas
donde se aplique el patrón)
■ No hay mejor forma de conocer el alcance que ha tenido este método de desarrollo que ver
quiénes lo han implementado. Multitud de webs que sirven aplicaciones a gran escala han
decidido invertir en la evolución hacia los microservicios en vistas de un futuro donde el
mantenimiento y escalabilidad de sus productos es mucho más simple, efectivo y rápido. Vamos a
destacar algunas de estas compañías, que lo mismo hasta os suenan:
■ 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.
Ventejas del Patrón de Arquitetura
Microservicios
■ Modularidad: al tratarse de servicios autónomos, se pueden desarrollar y desplegar de forma
independiente. Además un error en un servicio no debería afectar la capacidad de otros servicios
para seguir trabajando según lo previsto.
■ Escalabilidad: como es una aplicación modular, se puede escalar horizontalmente cada parte
según sea necesario, aumentando el escalado de los módulos que tengan un procesamiento más
intensivo.
■ Versatilidad: se pueden usar diferentes tecnologías y lenguajes de programación. Lo que permite
adaptar cada funcionalidad a la tecnología más adecuada y rentable.
■ Rapidez de actuación: el reducido tamaño de los microservicios permite un desarrollo menos
costoso, así como el uso de “contenedores de software” permite que el despliegue de la aplicación
se pueda llevar a cabo rápidamente.
■ Mantenimiento simple y barato: al poder hacerse mejoras de un solo módulo y no tener que
intervenir en toda la estructura, el mantenimiento es más sencillo y barato que en otras
arquitecturas.
■ Agilidad: se pueden utilizar funcionalidades típicas (autenticación, trazabilidad, etc.) que ya han
sido desarrolladas por terceros, no hace falta que el desarrollador las cree de nuevo.
Desventaja del Patrón de Arquitetura
Microservicios
■ Alto consumo de memoria: al tener cada microservicio sus propios recursos y bases de datos,
consumen más memoria y CPU.
■ Inversión de tiempo inicial: al crear la arquitectura, se necesita más tiempo para poder fragmentar
los distintos microservicios e implementar la comunicación entre ellos.
■ Complejidad en la gestión: si contamos con un gran número de microservicios, será más
complicado controlar la gestión e integración de los mismos. Es necesario disponer de una
centralización de trazas y herramientas avanzadas de procesamiento de información que permitan
tener una visión general de todos los microservicios y orquesten el sistema.
■ Perfil de desarrollador: los microservicios requieren desarrolladores experimentados con un nivel
muy alto de experiencia y un control exhaustivo de las versiones. Además de conocimiento sobre
solución de problemas como latencia en la red o balanceo de cargas.
■ No uniformidad: aunque disponer de un equipo tecnológico diferente para cada uno de los
servicios tiene sus ventajas, si no se gestiona correctamente, conducirá a un diseño y arquitectura
de aplicación poco uniforme.
■ Dificultad en la realización de pruebas: debido a que los componentes de la aplicación están
distribuidos, las pruebas y test globales son más complicados de realizar.
■ Coste de implantación alto: una arquitectura de microservicios puede suponer un alto coste de
implantación debido a costes de infraestructura y pruebas distribuidas.
Definicion del Patrón de Arquitetura MVC
■ 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.
■ El patrón MVC fue una de las primeras ideas en el campo de las interfaces gráficas de
usuario y uno de los primeros trabajos en describir e implementar aplicaciones software
en términos de sus diferentes funciones.
■ MVC fue introducido por Trygve Reenskaug (web personal) en Smalltalk-76 durante su
visita a Xerox Parc en los años 70, seguidamente, en los años 80, Jim Althoff y otros
implementaron una versión de MVC para la biblioteca de clases de Smalltalk-80. Solo
más tarde, en 1988, MVC se expresó como un concepto general en un artículo sobre
Smalltalk-80.
Descripcion del Patrón de Arquitetura MVC
Como descripción es valido poner los componentes del patrón:
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, tanto 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)
■ StackOverflow: Teníamos que sacar este del camino. Para los
desarrolladores, este es el sitio cuando un desarrollador tiene una pregunta
sobre una determinada tecnología. Ahora se está convirtiendo en un verbo
de desarrollador ("¿Por qué no lo StackOverflow?").Con todo el sitio
construido en ASP.NET MVC, no se trata solo del desarrollo web. Hay muchos
otros temas como matemáticas, desarrollo de juegos y gramática, solo por
nombrar algunos.
■ Microsoft: Este es otro para salir del camino. Tiene sentido que
Microsoft coma su propia comida para perros. Traducción: las
herramientas que crearon para los desarrolladores son las mismas
que utilizaron internamente para crear su sitio web.
■ GoDaddy: He estado con GoDaddy.com por un tiempo (desde hace 15
años). No me di cuenta de que el sitio estaba construido sobre MVC.
Ventajas del Patrón de Arquitetura MVC
■ Separación clara de dónde tiene que ir cada tipo de lógica, facilitando el mantenimiento
y la escalabilidad de nuestra aplicación.
■ Sencillez para crear distintas representaciones de los mismos datos.
■ Facilidad para la realización de pruebas unitarias de los componentes, así como de
aplicar desarrollo guiado por pruebas (Test Driven Development o TDD).
■ Reutilización de los componentes.
■ No existe ciclo de vida de las páginas. Con menos peso, menos complejidad.
■ Motor de Routing asociando una URL concreta con su correspondiente controlador,
permitiendo URL semánticas. Las URL semánticas se indexan mejor en los buscadores,
siendo más adecuadas para el posicionamiento web.
■ Recomendable para el diseño de aplicaciones web compatibles con grandes equipos de
desarrolladores y diseñadores web que necesitan gran control sobre el comportamiento
de la aplicación.
Desventajas del Patrón de Arquitetura MVC
■ Para desarrollar una aplicación bajo el patrón de diseño MVC es necesario una mayor
dedicación en los tiempos iniciales del desarrollo. Normalmente el patrón exige al
programador desarrollar un mayor número de clases que, en otros entornos de
desarrollo, no son necesarias. Sin embargo, esta desventaja es muy relativa ya que
posteriormente, en la etapa de mantenimiento de la aplicación, una aplicación MVC es
mucho más mantenible, extensible y modificable que una aplicación que no lo
implementa.
■ MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir
clases e interfaces para modificar y comunicar los módulos de una aplicación. Esta
arquitectura inicial debe incluir, por lo menos, un mecanismo de eventos para poder
proporcionar las notificaciones que genera el modelo de aplicación; una clase Modelo,
otra clase Vista y una clase Controlador genéricas que realicen todas las tareas de
comunicación, notificación y actualización que serán luego transparentes para el
desarrollo de la aplicación.
■ MVC es un patrón de diseño orientado a objetos por lo que su implementación es
sumamente costosa y difícil en lenguajes que no siguen este paradigma.
Definicion del Patrón de Cliente-Servidor
■ 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. Esta idea también se puede
aplicar a programas que se ejecutan sobre una sola computadora, aunque es más
ventajosa en un sistema operativo multiusuario distribuido a través de una red de
computadoras.
■ Algunos ejemplos de aplicaciones que usen el modelo cliente-servidor son el Correo
electrónico, un Servidor de impresión y la World Wide Web.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. Esta idea también se puede aplicar a programas que se ejecutan
sobre una sola computadora, aunque es más ventajosa en un sistema operativo
multiusuario distribuido a través de una red de computadoras.
Descripcion del Patrón de Cliente-Servidor
Como descripción es valido poner los componentes del patrón:
■ En esta aproximación, y con el objetivo de definir y delimitar el modelo de referencia de
una arquitectura Cliente/Servidor, se identifican cinco componentes que permitan
articular dicha arquitectura, considerando que toda aplicación de un sistema de
información está caracterizada por lo siguiente:
■ Presentación/Captación de la información.
■ Procesos.
■ Almacenamiento de la información.
■ Puestos de trabajo
■ Comunicaciones.
Casos de uso (Aplicaciones o sistemas
donde se aplique el patrón)
En el lado Servidor, los sistema mas habituales son:
■ Microsoft Windows Server (principalmente las versiones 2003 y 2008)
■ GNU/Linux Server (son frecuentes las distribuciones (RedHat, Ubuntu Server, CentOS, SuSE Linux
Enterprise Server, …)
■ UNIX (IBM AIX, HP-UX)
■ Solaris/OpenSolaris
■ Apple OS X Server
Antes de relacionar los sistemas operativos que se despliegan en la parte cliente, debemos decir que
todos los sistemas anteriores pueden actuar, si fuese necesario, como clientes en una infraestructura
cliente/servidor, aunque no estén específicamente diseñados para ello. Incluso pueden actuar como
servidores para un grupo de clientes y, para llevar a cabo su cometido, actuar al mismo tiempo como
clientes de otro, u otros servidores.
No obstante, los sistemas que solemos llamar “de escritorio” son los que están diseñados para
constituir la parte cliente en este tipo de entornos. Los más frecuentes son estos:
■ Microsoft Windows (XP, Vista, 7, 8, …)
■ GNU/Linux Desktop (Ubuntu Desktop, Fedora, Debian, SuSE Linux)
■ Apple OS X
Ventajas del Patrón de Arquitetura
Cliente/Servidor
■ 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 del Patrón de Arquitetura
Cliente/Servidor
■ 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, cuanto 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
