Primer patrón: Cliente-servidor

Tiene la variación de 3 capas

Cliente servidor también llamado de

dos capas, pero es un mal nombre.

3 capas

El cliente es “thin”/liviano porque solo

hace la interacción con el usuario.
Ejemplo: Un browser/navegador
Distribución de la
interfaz, la aplicación y
la base de datos en el
cliente y el servidor.

Cliente

Servidor

Three-tiers:

El cliente interactúa
con el application
server y el application
server interactúa con el
database server.

El app server es el que

tiene la responsabilidad
de la lógica de negocios
(básicamente lo que
permite la
funcionalidad del
programa).
Three-tiers:

El cliente tiene la
interfaz de usuario y el
servidor de database
tiene la base de datos.
Duh.
Ejemplo

Segundo patrón:
arquitectura de capas

En inglés: Layered

Ejemplo: Capas con distintos protocolos →

Dato: Se pueden comunicar de una capa a otra no

consiguiente/ de abajo? En la práctica se permite, pero
no debería ser la regla. No es la idea. Uso excepcional
(por buena performance a veces se usa).

Se puede modificar una capa sin tener que alterar

todas.
Uso excepcional:

Ejemplo: Cliente y el Servidor pueden cada uno tener capas.

Otro ejemplo de combinaciones: Tener 2 tier, pero en el server

tener un MVC (Modelo Vista Controlador)
 Patrón 3: Arquitectura de servicios

En las palabras del profe: “La que la

lleva hoy en día.”

El servicio no corre en el proceso

de la aplicación sino en otro
propio, y se comunica con la
aplicación por medio de
protocolos estándar,
especialmente http.

La aplicación sigue funcionando si

se reemplaza el servicio, ya que
los servicios son independientes.
Esto no se cumple en otras
componentes que no sean
servicios.

Como está en el esquema →

Los servicios son todos independientes, incluso en diferentes lenguajes

Los acuerdos
son
independientes

Usa distintas
tecnologías en
distintos
servicios

Resiliencia: si se
cae parte de la
aplicación no se Escalamiento: monolítico tendríamos que hacer
cae todo copias de la aplicación completa. O hacerla de
nuevo. Sin estructure de servicios → monolítica
Esquema a la derecha: Se replican los servicios Todo contenido en un mismo lugar
necesarios al nivel que se requieren.
 Primera aproximación formal a la Tienen mucha relación
estructura de servicios con las APIs: interfaz a un
servicio.

Tema siguiente

Pregunta: Se necesitan
adaptadores del lenguaje?

Respuesta: No. La gracia de

la estructura de servicios es
La interfaz de los que no necesitan
servicios está adaptadores.. Lo único que
acordada/definida importa es la interfaz, no
cómo están construidos los
servicios.

Un servicio web (en inglés, web

service o web services) es una
tecnología que utiliza un conjunto de
protocolos y estándares que sirven
para intercambiar datos entre
aplicaciones.

Enterprise
Service Bus
coordina todo

Web Services: Para que

una aplicación se
conecte con un servicio
necesitan ponerse de
acuerdo → protocolos

La comunicación es
standard

Los servicios
pueden
corresponder a
más de una
aplicación
Ventaja de
arquitectura de
servicios
 Total de la lógica
a implementar

Aplicando
servicios a parte
del código se
ahorra un 15%

Aplicando
servicios a todo
el código se
ahora casi la
mitad.
Sin servicios:

Dos aplicaciones que

pueden estar escritas en
formas muy distintas se
podrían comunicar por
ejemplo mediante
compartir archivos con
información.

Es una mala práctica de

integración.

Con servicios se integran

naturalmente.

No son dos aplicaciones,

son servicios
comunicándose.
Derivando de servicios

SOAP es un protocolo

Ahora se usa REST

Decentralized microservice communications enable engineering teams
to do parallel work on different edges of the architecture without
breaking other components. If each microservice treats other services as
external resources with no differentiation between internal services and
third party resources, it means each microservice encapsulates its own
logic for formatting its outgoing responses or supplementing its
incoming requests. This allows teams to independently add features or
modify existing features without needing to modify a central bus. Scaling
the microservice communications is also decentralized so that each
service can have its own load balancer and scaling logic.
Se dividen servicios, no
se separa por
especialidad

Smart
endpoints y
dumb pipes.
Granularidad: tamaño
de cada unidad

➔ Dumb pipes!

Es una parte pequeña

Los microservicios interactúan unos con otros

 Middleware

Servicios

API

Microservicios aparecen
accediendo cada uno a sus
propios datos
Enfoque
clásico
Microservicios

Transacción: Se asegura la integridad de la

base de datos.

Con microservicios, como son

independientes, pueden producirse
inconsistencias temporales, que se
solucionan luego.
El Gateway
transforma de un
protocolo a otro
 Los servicios se registran como servicios públicos (Registry
Service) que pueden ser llamados por el API.

Ejemplo: Imprimir es un servicio. El API lo llama sin saber

quién proveerá el servicio. El driver de la impresora se
define como ejecutor del servicio y por lo tanto se registra
como tal en el Registry Service, que hace el contacto entre
los dos.

Si hay 5 computadores que

brindan el servicio A, se
reparten equitativamente para
no sobrecargarlos/balancear.

Si uno falla, redirige entre los

que quedan.
Microservicios

En sistemas de baja
complejidad,
microservicios agrega
complejidad
innecesaria.
Entrega continua:

Nueva tendencia: Cada

iteración se pone
inmediatamente a
producción. El ciclo ágil se
extiende hasta que está A veces no es
instalado, no solo hasta claro qué
desarrollo. servicio falló.

Tiempo en que
los múltiples
servicios se
comunican

Muchas versiones
de muchos
servicios

Complejidad:
muchos
elementos
interactuando

Transacción bancaria: Si hay una falla

en medio de la operación es más fácil
manejarla si el programa es
monolítico, en vez de estar dividido
en microservicios. Esto puede
provocar fallas en la consistencia. En
este caso, un error en la transacción y
pérdida de dinero.
 No usar una base de datos común

Provee la estructura de
comunicación

Inventario de servicios existentes

SLA: System Level Agreement.

Acuerdo de calidad. Ejemplo: Mi
App se cae no más de 3 veces por
una hora al mes. Mala mi app.
market