UNIDAD 1 - DISEÑO CONCEPTUAL DE ARQUITECTURAS

❖ Definición de Arquitectura de Software

Arquitectura de software: es el conjunto de decisiones significativas sobre la
organización de un sistema de software que define los principios que guían el desarrollo,
los componentes principales del sistema, sus responsabilidades y la forma en que se
interrelacionan

Vistas y Perspectivas (viewpoints)

Un viewpoint define los propósitos, la audiencia objetivo y el contenido de una clase de
vistas, y define los concerns que las vistas de esta clase va a enfocar
- funcional
- concurrencia
- desarrollo
- operacional
- despliegue

Una vista está basada en un viewpoint y, de esta manera, comunica la resolución de un

número de concerns.
Cada stakeholder necesita consumir la arquitectura de diferentes maneras. A un
programador le muestro el de desarrollo.
Se puede analizar y ver la arquitectura, dependiendo de los diferentes concerns de
los stakeholders.

Desarrollo: se ve la organización de los módulos, los componentes y la relación entre ellos

Concurrencia: tener un diagrama de estados, ver cómo van interactuando
Despliegue: visión de cómo, dentro del despliegue, se pueden ver los componentes, zonas
de red, nodos, firewalls entre otros.

❖ Proceso de arquitectura

1. entendimiento: requerimientos funcionales, no funcionales, restricciones, contexto,

influencias
 2. tomar las decisiones: elegir un camino
3. comunicación: comunicar a los diferentes interlocutores las decisiones
4. evaluación y análisis
5. construcción de prototipo: ver que cumpla con los requisitos. Asegurarse de que la
arq cumpla con los requerimientos. Validar la arq
6. construir la aplicación

Entradas / Inputs de la arquitectura de software

● Requerimientos
- Funcionales: lo que el sistema tiene que hacer. Ej: tener un buscador, y que
cuando el usuario pone una palabra y la busque, que se despliegue una lista
etc etc etc. Es lo que tiene que hacer el sistema. El QUÉ.
El requerimiento funcional responde a la lógica del negocio.
ej requerimiento funcional básico: "recibir pedido online"

Los requerimientos funcionales se extraen del Diagrama de Contexto

Interacción del sistema con otros sistemas, y con los usuarios.
Con este diagrama se puede ver dónde hay que hacer foco dentro de la arquitectura, viendo
los objetivos del negocio.

- NO funcionales (atributos de calidad): son aspectos del sistema que no

afectan a la funcionalidad, sino que definen la calidad y las características
que el sistema debe soportar. Cómo se tiene que comportar el software,
la aplicación. Pueden ser determinísticos o probabilísticos, y generalmente
poseen números. Es el CÓMO de la solución.
Usabilidad
Seguridad
Rendimiento/Performance
Modificabilidad
Disponibilidad
Testabilidad
 Drivers de arquitectura
Son los escenarios (funcionales + atributos de calidad) críticos y principales que van a
permitir modelar, comunicar y evaluar la arquitectura. Son los requerimientos más
prioritarios de los stakeholders.
Los drivers de la arquitectura de software son los que van a guiar la toma de decisiones.
Los drivers pueden ser restricciones, atributos de calidad y hasta requerimientos
funcionales.

Acoplamiento: dependencia entre componentes. Si están muy acoplados, significa que si

cambio uno tengo que cambiar los dos.
Componente Cohesivo: todas las responsabilidades tienen sentido.

❖ Atributos de calidad

Rendimiento: Tiempos de respuesta, latencia, cantidad de usuarios, cantidad de

transacciones, nivel de concurrencia de las transacciones

Modificabilidad: capacidad del sistema para poder evolucionar (desde un punto de vista de
mantenibilidad). Poder agregarle nuevas funciones, poder escalarlo, etc.

Disponibilidad: grado de operabilidad (qué tanto tiempo tiene que estar disponible un
sistema). Ej: 24/7 los 365 días del año.

3 escenarios para especificar a los atributos de calidad:

1. Estímulo: es lo que genera que un sistema responda de una determinada manera.
Tiene:
- Origen del estímulo: cualquier actor que interactúa con el sistema. Puede
ser un usuario, un tipo de usuario o un sistema
- Estímulo: es una condición que se necesita considerar cuando entra al
sistema. ES EL TRIGGER. ej, COMPRA DE TICKETS, 10 / SEG
Ej estímulo: un usuario realiza una registración. El origen es un posible cliente. El
estímulo es la registración.

2. Ambiente: tiene que ver con qué componente y en qué contexto

- Componentes: son los componentes del sistema que son afectados
- Contexto: son las condiciones en la cual se encuentra el sistema en el
momento que se recibe el estímulo.
Ej anterior: El componente puede ser SI va a ser recibido por el componente “sign
up” o por toda la aplicación, o una parte de la solución. El contexto puede ser en
qué horario, en qué momento del sistema, con cuánta concurrencia está
recibiendo ese estímulo.

3. Respuesta: qué es lo que el sistema debe responder, Respuesta: la respuesta es

la actividad que debe realizar el sistema
- Medida de la respuesta: es un tipo de medida con la cual debe cumplir la
respuesta para que el requerimiento pueda ser testeado. SON SIEMPRE
CANTIDADES
 Ej anterior: podría ser un procesamiento de la transacción, un diálogo de
“procesando”, una pantalla de confirmación.

Atributos de Calidad

➔ Rendimiento
Ofrece un grado de eficiencia a la hora de responder ciertos estímulos, respetando
ciertas características de velocidad, precisión y cantidad en la concurrencia.
- Tiempo de respuesta: le vamos a pedir que cada vez que el usuario interactúa con
el sistema haya “x” tiempo de respuesta
- Rendimiento (throughput): qué cantidad de transacciones va a poder ejecutar
nuestro sistema
- Escalabilidad: cuánto tiempo le vamos a dar al sistema para que pueda tomar más
transacciones
- Carga pico

Ej: los usuarios inician 1.000 transacciones X por

minuto bajo condiciones normales, de 9 a 18 hs.
El sistema debe procesarlas (resultado en
pantalla) en una latencia menor a 3 segundos.

➔ Disponibilidad
Es el grado de operabilidad de un sistema o componente. Se puede medir en cómo el
sistema se recupera ante un fallo; o una vez caído, en cuánto vuelve a estar operable
Es importante diferenciar entre desperfecto/error (fault) y falla (failure)
- Desperfecto: si no es controlado, puede provocar una falla. No son observables.
- Falla: el sistema no responde en el tiempo esperado. Son observables y el cliente
final las percibe
Disponibilidad (%): Tiempo medio entre fallas / Tiempo medio entre fallas + tiempo medio de
reparación

Ej: los usuarios realizan el inicio de sesión mediante

el componente de login bajo condiciones normales,
de 9 a 18 hs. El servicio debe estar disponible el
99,99% de las veces.

➔ Modificabilidad
Es el grado de facilidad que tiene un sistema para ser modificado, ya sea para agregar
nuevas funcionalidades como para modificar las existentes (mantenibilidad). Tomando
facilidad como costo y tiempo
Se pueden agrupar en
- Maintainability: Relacionado con la resolución de problemas
- Extensibility: Permitir extender el software con nuevas funcionalidades

Ej: Un stakeholder desea que el sistema publique

algún servicio existente para ser consumido por otra
aplicación (y no por pantalla) luego de que el
sistema esté en su primera release de producción, y
el tiempo de desarrollo no supere los 14 días desde
la aprobación del Change Request

➔ Usabilidad
Es el grado de facilidad que tiene el sistema para ser operado por los usuarios.
Cómo se logra, desde el punto de vista arquitectónico, que el sistema sea intuitivo.
Tiene que ser fácil de usar y recordar ; que el diseño sea simple y consistente ; que haya
prevención de errores ; que las tareas se ejecuten eficientemente. También que haya Ayuda
disponible

➔ Testabilidad
Es el grado de facilidad que tiene un sistema para que se pruebe de forma completa, ya
sea unitariamente, integración, aceptación y regresión

El 40% del costo lo consume el testing. Cuando más fácil se puede hacer que un sistema
sea probado, se tiende a minimizar el costo y los tiempos de testeo

➔ Seguridad
Es el grado de habilidad del sistema para resistir a usos NO autorizados mientras
sigue proveyendo sus servicios a los usuarios legítimos.
Se puede caracterizar en confidencialidad e integridad de los datos, aseguramiento,
disponibilidad, auditoría.
 UNIDAD 2 - DISEÑO TÉCNICO DE ARQUITECTURAS

ORGANIZACIÓN EN COMPONENTES DE INTERFAZ, NEGOCIO Y PERSISTENCIA

Toda aplicación nace en base a una problemática existente.

Las aplicaciones lógicamente se dividen en capas (3 o 4 generalmente).

1. Capa de presentación / Interfaz de usuario: capa que va a ser el nexo entre los
usuarios y el sistema o la solución que estemos diseñando
2. Business Logic (BL) o Lógica de Negocio: corazón del sistema, de mi solución.
Acá es donde voy a tener todo el procesamiento, transformación de los datos.
Voy a tener el modelo de dominio de mi solución. Depende del rubro las entidades
de negocio que va a tener
Van a estar todos los procesos que permiten hacer cosas con esa información, y
poder brindárselas a la capa de presentación, que va a ser la que se la da al
usuario. Se comunica para darle la información
3. Capa de acceso a datos o Persistencia: capa que realmente tiene la info a largo
plazo que se la va a presentar a la capa subyacente (BL). Para guardar algo a lo
largo del tiempo. Puede ser un archivo, un excel, una base de datos, etc.

Si la aplicación con sus datos NO es suficiente para trabajar y requiero acceder a info a otra
app que está fuera de mi dominio, aparece la 4ta capa. Ocurre cuando la App necesita algo
de otra aplicación, de un tercero

4. Integración: permite comunicarme con otras aplicaciones, ya sea para proveer

la información o para consultarla. Ej: Rappi con Google Maps con la funcionalidad de
rastreo

Front end: capa de interfaz de usuario (Capa 1)

Back end: unión entre lógica de negocios y el acceso a datos. Capas 2 y 3.

❖ Lenguajes de programación

Son lenguajes formales para crear procesos que se pueden llevar a cabo por una
computadora.

Lenguajes de programación
- Tipado: a las variables se les definen “tipos” de dato (ej, número, letras, fechas,
etc.). Si el lenguaje es tipado me da más control, y necesito datos estructurados.
No tipado es lo contrario, que da agilidad y velocidad en el desarrollo del código,
menos costoso y más fácil de hacer.
- Compilación: el lenguaje entendible por las personas se pasa a uno entendible por
las máquinas. El lenguaje compilado al tener el proceso, si bien tarda mucho, ese
proceso también optimiza el espacio que ocupan los archivos y las variables y los
datos.
Ej: Java, C, C++
- Intérprete: “motor” que se encarga de leer línea por línea el código y ejecutar los
pasos. El lenguaje interpretado cualquier cosa que escribo la ejecuta.
 Ej: Python, donde la computadora entiende lo que el usuario escribe
- Transpilación: pasar de un lenguaje a otro. Ej: de TypeScript a Javascript

Alto o bajo nivel: depende de qué tan cerca estoy del sistema operativo. Bajo nivel
brinda más rendimiento porque ya se mueve por las capas más bajas, porque está más
cerca del sistema operativo. En bajo nivel, tiene que ser tipado sí o sí.

Ejs tipados: C, Java

Ejs no tipados: Ruby, Python

Framework vs Librería
Librería: paquetes de código que son de alguien más, y yo los puedo integrar en mi
aplicación para tener más funcionalidades. Tu código llama a una librería. La librería sólo
resuelve un problema

Framework: impone un marco de trabajo. Yo me tengo que adaptar a ese marco de

trabajo. El framework también contiene librerías

Este framework maneja los pdfs. Te dice que armes la clase

así tal cuál, y tu código de lógica de negocios la escribas en
donde está el marco rojo.

Los frameworks sirven para

- evitar escribir código repetitivo
- utilizar buenas prácticas
- permitir hacer cosas avanzadas que vos no harías
- desarrollar más rápido

❖ Frontend y Presentación

Es el grado de interacción entre un usuario y el sistema. Lo que permite al usuario

interactuar con el modelo de dominio de la aplicación (lógica de negocios)

Consideraciones para la Usabilidad / Experiencia de uso

- fácil de aprender
- fácil de usar: que sea intuitivo
- fácil de recordar
- tolerante a errores
- robusto

Decisiones técnicas a tomar

1. Distribución
La presentación puede ser condicionada por el despliegue
- Muchos clientes requieren muchas máquinas.
- Si los usuarios están en distintos lugares
2. Cliente liviano y pesado
- liviano es el que tiene la mínima validación necesaria, y delega muchas
funcionalidades en el back-end. Las acciones se disparan hacia el
back-end. El mayor esfuerzo de cómputo lo pone el mismo usuario.
- el pesado manda al back-end sólo cuando es necesario, y ejecuta
validaciones y acciones en el front-end directamente

3. Control de la iniciativa
A. User Initiative
- pedido-respuesta (te piden algo y vos respondés)
- orientado a eventos

B. Application Initiative
- usuario contesta preguntas
- Wizzard
- Alarmas y eventos disparados por la aplicación

C. Combinada
- interactivo, conversación
- continuation

4. Formas de navegación
A. Pantallas y formularios: Stateless ; Terminal boba / Mainframe, Web
Tradicional
B. Ventanas o diálogos: Stateful / Wizards ; Cliente - Servidor, RIA
C. Manipulación directa: objetos

5. Estado conversacional (sesión)

Sesión es si guardamos datos del usuario que se logea, si la sesión se almacena en
un servidor, etc.
- cliente
- en cada pedido
- servidor (session)
- compartido
- caso de uso (flow)

6. Integración con el dominio de la aplicación

Lo mismo que el 5

7. ¿Dónde se integra la lógica?

A. Campo a campo: validaciones, máscaras o Pickers y otros controles más
elaborados. Restringe las cosas por lógica. Fechas y demás
B. Por formulario o pantalla: es lo más utilizado
C. Por caso de uso: ejecución de un caso de uso de negocio. Involucra varias
pantallas
 ❖ Lógica de Negocio

Gestión de lógica de negocio

Es el conjunto de operaciones que procesan y producen la información que requiere el
usuario para llevar adelante el negocio
- interactúa con el resto de las capas de una arquitectura, consumiendo o
proveyendo info
- es modelada por medio de abstracciones (representaciones lógicas de un problema
real), entendiendo la interacción entre ellos para lograr la operación deseada
- esas operaciones son representadas por decisiones lógicas, evaluaciones y
cálculos (algoritmos)
- Consideraciones de los lenguajes, tales como Readability, Writability (qué tan fácil es
agregar nuevas cosas en ese lenguaje), Reliability (qué tanto soporta el lenguaje en
cuanto a diferentes estímulos) y Productivity (qué tan rápido puedo dar valor al
negocio con el lenguaje)

Modo de distribución
Cómo voy a ordenar las 3 capas, y cómo van a estar distribuidas
A. Desktop: cliente pesado. La UI está acoplada con la lógica de negocios. Las
capas están juntas.
B. Web: la UI está separada de la lógica de negocio. UI tiene que estar distribuida, y
la lógica en un servidor central. Las responsabilidades están separadas.
C. Embebidas
D. Distribuidas: la UI está distribuida, y la lógica de negocios se encuentra en un
servidor centralizada
E. Mobile: para clientes muy livianos. Capa de cliente liviano separada de la lógica de
negocio

Concerns
Estos concerns no dependen de la lógica de negocio que estoy modelando, siempre los voy
a tener.
- Testing
- Tracing: trazabilidad. Cómo me doy cuenta por dónde pasó el usuario
- Monitoring: monitoreo. Entender cómo se comporta mi aplicación en un momento
dado
- Logging: registro de actividad.
- Authentication
- Fault injection: inyección de fallas
- Alfa/Beta testing: dos modelos de app para diferentes segmentos
- Security
- Persistence

Separation of concerns
- concerns: pieza de software (componente, clase, etc) que debe ser implementada en
el sistema
- Cross-cutting concern: funcionalidad que afecta a toda la arquitectura. Tiene que
ejecutarse para todo un conjunto de componentes, no para uno específico. Ejemplos
 de estos son los que están arriba listados (Security, Logging, etc.). No son concerns
sólo para el Back-end, sino también para el Front-end

Si los concerns están metidos en el código, si cambio las reglas de negocio se vuelve
complejo cambiar esos concerns.

❖ Persistencia de datos

Base de datos relacionales

Lo que ofrece siempre una base de datos relacional es A.C.I.D (Atomicity, Consistency,
Isolation and Durability)
Es relacional porque las tablas en las bases de datos se relacionan
- Consistencia: en los tipos de datos, y en las consultas
- Aislamiento: se pueden poner bloqueos en las bases de datos

Tablas con columnas y registros. La información NO es flexible, es estructurada

NoSQL
Hay diferentes tipos de bases de datos. Se usan cuando los datos son semiestructurados
o no estructurados.
Ventajas: no tienen penalización a la hora de escribir los datos, no tienen constraints, son
más rápidas. Se puede escalar.

● Documental Grafos

Permiten armar relaciones entre objetos. Se usa

mucho para el motor de recomendaciones. Ej: Neo 4J

● Columnar
Para consultar los datos en varias
dimensiones.
Ejemplo BD columnar: Cassandra
 ● Clave-Valor
Me permite modelar clave y valores. La clave identifica el registro que quiero
consultar, y el valor puede ser cualquier cosa (string, nro, imagen, etc.).
Se usa para mantener la sesión de los usuarios

Data Warehouse vs Data Lake

Data Warehouse Data Lake

Dato estructurado, procesado estructurado, semi-estructurado, no estructurado,

en crudo (vienen de sensores, social media, etc.)

Procesamiento esquema on-write esquema on-read

Almacenamiento costoso para grandes volúmenes de datos hecho para un bajo costo de almacenamiento

Agilidad poco ágil, configuración fija muy ágil, se puede configurar y reconfigurar

Seguridad madura en maduración

Usuarios profesionales de negocio data scientists

Distribución vs Consistencia
Cuando evaluamos una base para usar hay un teorema llamado “CAP” donde se ponen en
una balanza Consistencia, A de Disponibilidad y Particionamiento de red.
Todas las bases de datos cumplen 2 de los 3 aspectos al 100%, y el último en mucha menor
medida. Dependiendo de eso y qué priorice, elijo la base de datos.
 INTEGRACIÓN DE APLICACIONES, API AS PRODUCT + MICROSERVICIOS

❖ Integración de aplicaciones

Hoy se busca estandarizar la comunicación, para que los sistemas se comuniquen en un

idioma en común. Que con ese idioma haya un diálogo entre los sistemas.

Objetivos
- consumir información de terceros
- distribuir información centralizada
- centralizar información variada y proveniente de diferentes fuentes
- resolver una problemática de forma integral

Estrategias de integración
1. User interface
Busca emular de manera automatizada las tareas manuales que implica usar
un sistema
Este mecanismo se usa en el caso de modernización de aplicaciones, o en la
búsqueda de eficiencia operativa sin necesidad de modificar profundamente los
sistemas existentes. Un robot que se encarga de hacer el scrapping (entender
la interfaz de usuario, y después interactuar).
Permite facilitar tareas para modernizar el sistema legado. Con el nuevo
front-end se le saca complejidad al legado. Es como una “máscara”

Pros: rapidez de implementación ; no requiere modificaciones en legados

Cons: complejo de gobernar o evolucionar ; arrastra problemas existentes en legados ; alto
acoplamiento

Caso: RPA. Hace un scrapping

2. Transferencia de archivos
Dos roles aplicativos: el productor (genera la info a transmitir) y el consumidor (obtiene y
procesa)
El contrato es el archivo, cuestiones como el
encoding, el formato y cómo lo maneja cada
aplicación puede atentar a la interoperabilidad
Otros aspectos como frecuencia de creación y
manejo de novedades también son claves

Pros: oculta detalles internos de aplicaciones ; desacoplamiento mediante file server

Cons: complejo de implementar ; acuerdo en muchas cuestiones

3. DB Compartido
Se usa cuando el tiempo en la entrega es un aspecto a
cumplir si o si
Permite desacoplar de igual manera que los archivos, pero se
recomienda para los casos en donde se necesite una
integración online
Cuando mi app necesita info de una base de datos de otra aplicación. Entonces hago
queries sobre esa DB.

Pros: performance y entrega inmediata ; robustez al delegar el servicio a la DB; simplicidad

e interoperabilidad
Cons: acoplamiento en modelo de datos ; los despliegues pueden generar mucho
impacto ; el gobierno y la evolución son complejos

4. Llamada remota
Se usa para aplicaciones que necesitan trabajar en forma coordinada
Cada aplicación brinda funciones para que puedan ser aprovechadas por aplicaciones
externas

Una app invoca a otra con algún pedido particular

(ej: le pide info de un cliente que tiene ese nro) y la
otra aplicación le da esa info (le da info del cliente
con ese nro). De aplicación a aplicación.
Pros: contrato claro y estándar ; independiente a la tecnología
Cons: ambas aplicaciones deben estar disponibles al mismo tiempo
Ejs: Java RMI, SOAP, REST, GRPC, WebSockets

5. Orientado a mensajes
Hay 3 roles distintos
- app proveedora (responde a ese request)
- app consumidora (hace el request, recibe mensajes)
- canal (asegura la transmisión)

La comunicación puede ser asincrónica, es

decir, que el proveedor de la información no
requiera una respuesta inmediata del
consumidor
El canal es responsable por la entrega de los paquetes, pudiendo tener que reintentar en
caso de errores

Pros: desacoplamiento y asincronía ; no depende de disponibilidad de extremos ;

entregar el mensaje a varias entidades ; actuar en base a eventos
Cons: casos en los que se necesita una respuesta inmediata ; manejo más complejo por
reintentos ante demoras o errores

❖ API as Product

A.P.I = Application Programming Interface

¿Qué es?
Es una interfaz definida explícita y deliberadamente, diseñada para ser invocada a través
de la red que permite a los desarrolladores obtener acceso programático a los datos y
la funcionalidad dentro de una organización de una manera controlada y cómoda.
Estas interfaces abstraen los detalles de la infraestructura tecnológica que los implementa.
 Es una interfaz que nos permite tener una comunicación común entre todas las
aplicaciones.
Proveedores: expone las capacidades y funcionalidades de la API. Manejan el flujo que
se solicita.
Cliente: hace solicitudes

La importancia de las APIs como activo

Permiten exponer capacidades de las compañías como activo a clientes, partners y
proveedores de una manera estándar, fácil de integrar y flexible

Pasos más comunes ej: API de AFIP

1. Mobile
2. API Core
3. API Omnicanal: que uno tenga varios canales para acceder a
la misma API
4. Terceros

Gobernanza de API

Modelo de administración de API: ciclo de vida completo

Como la API es un producto, lo tenemos que

gobernar
Vamos a tener una estrategia, un diseño, donde
vamos a tener que pensar en los parámetros de
entrada, en la salida, etc.

Testearlas, manejarlas, chequear su seguridad

Pensar en cómo van a encontrar la API los clientes
Monitoreo de cómo funciona la API

Arquitectura de gestión de las APIs

Hay componentes de arquitectura

- Portal de APIs, donde va a haber un desarrollador. Va a
descubrir cuáles son las apis que tienen (en el portal). Va a ver
cómo se va a invocar esa API
- API Gateway: se encarga de funciones de control, y va a llamar
a la API.
El desarrollador pone que se pueda llamar a la API desde un
browser/mobile/service

Capacidades más importantes del API manager

- seguridad
- dar un límite a la cantidad de invocaciones
- observabilidad, reportes
 ❖ Estilos de Arquitectura actuales (Microservicios)

➔ Evolución a Microservicios
Las funciones de la aplicación se componen de muchas APIs, entonces la app
es más chica y cohesiva. Cada servicio lo expone una API, y el API Gateway
maneja/rutea el tráfico que viene de dicha aplicación.
- Los sistemas se ordenaron en base a las jerarquías y dominios de negocio, y los
productos empezaron a ser digitales (no analógicos)
- Se integran recursos, no acciones
- Cada equipo es responsable de su dominio

➔ Estilo de Arquitectura de Microservicios

Se parte de arquitecturas monolíticas a una arquitectura de microservicios.

Antes, en cada capa, todos los dominios estaban implementados en el mismo sistema.
Ahora, todas los dominios similares se agrupan en una misma aplicación.

¿Qué son los microservicios?

Son un conjunto de aplicaciones que
- altamente mantenibles y testeables
- no tienen acoplamiento entre sí: cada uno de esos microservicios tiene una
responsabilidad concreta. Ante un cambio en uno, no afecto al resto
- son desplegables: se instalan de manera independiente
- permiten organizar las capacidades de negocio de forma más sencilla

Fomenta la entrega continua de aplicaciones complejas. Permite que la organización

evolucione su stack tecnológico.

Conceptos relacionados
- Single Responsibility Principle: cada componente de la arquitectura tiene que hacer
una sóla cosa, y hacerla BIEN. Poco acoplamiento.
- Circuit Breaker
- Separación entre componentes
- Manejo de transacciones distribuidas
- Design for failure: diseñar arquitecturas para las fallas. Diseñar aplicaciones a
prueba de fallos. Que todo puede fallar, entonces prevenirlas
 ➔ APIs, Gateway y Seguridad

Api Gateway: nuevo componente que permite localizar todos los microservicios (tenerlos en un
mismo punto de acceso), y rutear el tráfico que viene de la app. En caso que dichos microservicios se
modifiquen en algún aspecto, tiene que ser capaz de identificarlos y rutear el tráfico nuevamente.

Cuando recibe el tráfico, el API Gateway aplica un conjunto de reglas de seguridad y después
distribuye en cada uno de los microservicios que tiene la aplicación.

Seguridad
Se delegan las cuestiones de seguridad en un Authorization Server. Cada microservicio
va a tener que validar cuestiones mínimas de seguridad (ej quién es el usuario que usa la
API y a través de qué app). Cuando tienen que autenticarse en una plataforma
El Authorization Server puede ser el de Google, el de Instagram etc.

➔ Persistencia e integración

Persistencia
En cuanto a la persistencia, cada microservicio tiene que tener su propia base de datos.
Cada microservicio va a tener el tamaño de DB que requiera.

Integración
Puede ser sincrónica o asincrónica, dependiendo si se requiere que los microservicios estén
comunicándose en tiempo real o no (si la respuesta tiene que ser inmediata)

Conclusiones de microservicios

TTM = Time To Market

Acoplamiento de sistemas: Que, cuando hay una
modificación en un sistema, éste impacta en el otro. Si
hago un cambio en un sistema y no necesito cambiar la
integración, están débilmente acoplados.
Cohesión: cuando hay alto acoplamiento, hay baja
cohesión. Y viceversa. Responsabilidades limitadas.
 UNIDAD 3 - DISEÑO DE ARQUITECTURA TECNOLÓGICA

INFRAESTRUCTURA, VIRTUALIZACIÓN Y CONTAINERS

❖ ¿Qué entendemos por infraestructura?

Arquitectura tecnológica: llevar ese software que se está construyendo a una

infraestructura (dispositivo) para que se ejecute. Ya sea un servidor, un celular, etc.
Sobré qué dispositivos va a correr la aplicación, es decir, todo el hardware necesario para
que nuestra solución se ejecute.

5 partes de la infraestructura (de abajo 1 hacia arriba 5)

1. Edificio: los data centers
2. Electricidad y climatización: ese edificio necesita electricidad y climatización.
Consume mucha energía y hay que usar tecnologías de enfriamiento para que
no se sobrecalienten
3. Redes y seguridad: el servidor se conecta a la nube. Y el data center tiene que ser
seguro, que no se pueda atacar fácilmente
4. Hardware computacional: los recursos computacionales que necesito para
ejecutar las aplicaciones que estoy desarrollando. CPU, Memoria, Hardware
Storage y Networking.
5. Componentes de SW de Base: lo que nos permite utilizar eficientemente el hardware
que está debajo

1. Edificio
Hay que considerar la localización geográfica donde vamos a poner nuestros recursos
computacionales. Dónde voy a ubicar el datacenter.

Hay cuestiones edilicias que hay que cumplir:

- provisión constante de agua y energía
- acceso controlado 24/7
- soporte de carga (estructura reforzada)
- lugares especiales (carga y descarga de combustible, cajas, despacho)

Posibilidad de crecimiento. Diseño escalable.

Control de incendio: detección temprana de fuego, sensores de humo puntuales, servicio

bombero en el lugar 24/7.

2. Electricidad y climatización
Para tener buena electricidad hay que tener un Sistema Redundante de Energía. Tener
mínimo dos proveedores de energía para el mismo edificio por si un servicio se
interrumpe.
Grupos electrógenos, UPSs, tableros eléctricos que se alimentan de esas UPSs.

Sistemas de enfriamiento: pasillos de aire frío y caliente, bombeo de agua helada, control
automático de la temperatura
3. Redes y seguridad
Red de Datos WAN (Wide Area Network): qué tipo de tecnología para interconectar los
edificios. Generalmente la red para interconectar nos las dan las empresas de
telecomunicaciones. Te dan enlaces entre los edificios (son cables especiales privados).
Gralmente se usan L2L (Lan to Lan).

Se necesita equipamiento para conectar los equipamientos: con Módems, Routers y

Switches

Red de data center: los dispositivos principales son los Load Balancers y Firewall
- Firewall: analiza que la info que entra y sale del data center sea segura. Ya sea
info que viene de la red pública o que sale del data center. Impide que nos roben
info, que nos ataquen, etc.
- Load Balancers: son dispositivos de networking que nos permiten mantener una
alta disponibilidad entre los servidores

4. Hardware computacional

Hardware sizing: estimación realizada para asignar equipamiento para una aplicación

- Hay que contar con info previa al análisis: tipo de aplicación, estimar cantidad de
(usuarios, de concurrencia, transacciones, etc.). Para definir los requerimientos
mínimos del hardware para que funcione bien la infraestructura
- Para definir los recursos computacionales, hay que definir el tipo de aplicación:
página web, base de datos, OLAP, OLTP, etc.
- Definir el espacio requerido en disco, especialmente en bases de datos

❖ Virtualización

La virtualización permite simular varios servidores lógicos en un sólo hardware físico.

Permite compartir los recursos del equipo host entre todos los equipos virtuales: CPU,
memoria, Disco, IO.

- La virtualización permite dividir a un gran servidor físico (hardware físico) en

varios servidores (hardware) virtuales. Esto facilita la administración y
expansión de la capacidad de los servidores, porque se trata a cada hardware
virtual como si fuese uno físico. A cada virtual se le instala su sistema operativo y
sus aplicaciones. Se usa una pequeña porción del físico
- Existe la posibilidad de crear “granjas” de servidores de virtualización, lo
cual nos brinda varias ventajas:
1. Alta disponibilidad: Si se cae un equipo físico, todos los
virtuales que se ejecutaban en éste son levantados por otros
equipos de la granja
2. Mejor aprovechamiento de los recursos: con la virtualización se
pueden consolidar muchos servidores en uno solo,
aprovechando mejor los recursos. Los servidores tienen menos
capacidad ociosa
 3. Menor consumo de energía y menor espacio ocupado: como se cuentan
con menos servidores físicos, hay un menor consumo de energía
4. Menores costos de refrigeración: como hay menor servidores físicos, se
reduce el costo de enfriamiento de los mismos

Ejemplo de arquitectura de virtualización

Hay 3 servidores físicos, que tienen una capa de virtualización

con ESX, y varias máquinas virtuales

Cada máquina virtual reside en un servidor de storage,

entonces si el servidor físico en el que están falla, se las
mueve a otro.

❖ Containers

Linux permite asignarle recursos a los procesos.

Namespaces: identificación y manejo de los procesos

Container: se desarrolla la aplicación de una forma tal

que sus procesos corren de una manera estándar y que
puedan funcionar en cualquier servidor. Que funcione
en cualquier datacenter y demás que soporte Docker.
- los containers se pueden crear en milisegundos
- todas las aplicaciones tienen que correr en
containers

Con un Docker Engine, un servidor puede tener miles de containers en una sola
máquina, teniendo un solo sistema operativo (Linux).

Beneficios
Docker file: manera repetitiva de generar una imagen, y esa imagen se puede empaquetar
y desplegar en cualquier contenedor, y por ende en cualquier servidor que soporte Linux.
- rápido aprovisionamiento: se pasa de minutos a segundos
- cambios controlados: docker file. Que las imágenes se puedan recrear las veces
que sean necesarias, en el momento que sea necesario
- uso eficiente de recursos: menos storage y mayor portabilidad
- Time To Market (TTM): tiempos de aprovisionamiento y permite utilizar
infraestructura inmutable

Plataformas más utilizadas: Docker, Linux Containers. Los containers SON PROCESOS.

Es una VM más chica / disposable (es inmutable). Es una porción del sistema operativo,
con librerías necesarias y con las librerías aplicaciones que uno quiere poner ahí
adentro. Son instancias de software y hardware más chicas.
 KUBERNETES

❖ Kubernetes

¿Qué es Kubernetes?
Es un sistema de código abierto para la
automatización del despliegue, escalamiento
y manejo de aplicaciones en contenedores​que
permite adaptarse a cualquier Cloud Provider.

Esta herramienta permite manejar muchos

contenedores, y monitorearlos, provisionales,
auto-escalarlos, actualizarlos (con Rolling
Updates). Es un sistema de gestión de
containers

Pod = container o grupo de containers

Ctrl Plane (primer círculo rojo)

Si yo quiero configurar nuevas aplicaciones,
asignar más recursos (a mis aplicaciones), etc.
entro por el plano de control. O por el Kubectl
o por UIs comunitarias.
Sabe dónde ubicar cada aplicación nueva y que ejecute la nueva aplicación, en función de los
requerimientos que tengo.
API server: hay API para acceder al server
También tiene una base de datos de las aplicaciones que tengo, dónde están, cómo se están
ejecutando, etc. Para que Kubernetes sepa cómo operar

Data Plane (segundo círculo rojo)

Es la VM donde las aplicaciones ejecutan. Necesitamos que estén virtualizados. Cada Nodo es una
VM, y cada VM tiene Docker

Kubelet: le informa al Ctrl Plane dónde poder ubicar aplicaciones para que el consumo de recursos sea
performante y distribuido, con alta disponibilidad.

❖ Principales abstracciones

Pods
El pod es la unidad de trabajo fundamental en Kubernetes, que especifica un único
contenedor o grupo de contenedores de comunicación que se despliegan juntos
- conjunto de Containers
- posee una IP interna
- puede tener volumen persistente
Deployments

Replica set: objeto que permite que haya más de una réplica
de un pod. Cada Replica set tiene su versión

En el dibujo es una misma aplicación, con 3 versiones distintas

si se cae un nodo, trata de ponerlo en uno que todavía no

tenga una réplica. Si todos tienen, lo reasigna a un nodo que
ya tiene una réplica

Services

Cómo hacemos para que nuestro pod, estando dentro de un

nodo, pueda ser accedido desde afuera

El service es el balanceador de carga de Kubernetes. Provee acceso unificado a los

nodos. Los pods se pueden comunicar entre ellos.

Ingress: es un objeto que permite el acceso a sus servicios de

Kubernetes desde fuera del cluster de Kubernetes. Esto permite
consolidar las reglas de enrutamiento en un sólo recurso.

Los contenedores no están atados ni a hardware ni a un sistema operativo, como sí están

las máquinas virtuales

El container es la unidad mínima para correr una aplicación

Se le puede especificar a kubernetes cuántas réplicas quiero levantar. Lo que hace

Kubernetes es que si se me cae una, me levanta otra. También, en función del tráfico,
Kubernetes me rutea y distribuye el tráfico entre los pods. Si ve que necesita más réplicas,
en función de los tiempos de respuesta que especifiqué, me va a levantar una réplica
nueva.
Sirve también para escalar, ya que le puedo indicar que me levante muchas copias de un
contenedor para soportar los momentos en los que hay un pico de actividad. Lo bueno es
que no tengo que levantar copias de toda la aplicación, sino de lo que necesite. Por
ejemplo, que me levante copias de mi sistema de transacciones.
 UNIDAD 4 - ENTREGA CONTINUA

PARTE 1: CONTINUOUS INTEGRATION, C DELIVERY AND C DEPLOYMENT

Application Lifecycle Management: se administra el ciclo de vida de la aplicación. Define

las reglas del camino para todo el ciclo de vida del software y los sistemas

Etapas del ALM

Es un ciclo que se repite indefinidamente, no tiene fin
Plan: planificación de tareas, realizar análisis de la app a
desarrollar. Se planifica para cada una de las iteraciones
Code: varias personas codificando a la misma vez
Build: construir el software y tener una unidad de despliegue del
mismo
Testing: del build
Release: se crea la versión de la app
Despliegue: se pone la versión en algún entorno
Monitoreo: ver cómo está funcionando la aplicación

Deployment Pipelines
Es una implementación automatizada del proceso de creación, implementación,
prueba y lanzamiento de la aplicación.

Commit: hay un repositorio de código centralizado, donde todos los desarrolladores

mandan lo que desarrollan. Cada desarrollador hace un testeo unitario de lo que está
haciendo. El servidor de integración de código agarra todo el código que está en el
repositorio, y hace un build (crea una unidad de despliegue), y si hay un error en el código
informa para que se corrija

Testing automático: que se pueda automatizar la mayor cantidad de testing posible. Más
funcional

Testing de capacidad: testing de stress. Si el software que se está desarrollando soporta la

capacidad requerida. Se puede automatizar

Testing manual: es necesario sí o sí. La usabilidad de la aplicación. Se testea lo que no lo

puede hacer la computadora
 Continuous Integration
1. Pre-checks: el desarrollador pone el código en el repositorio, y el repositorio le
aplica chequeos, como por ejemplo ver si hay código repetido.
2. Commit Messages - Semantic Commits: se estandarizan los mensajes del commit
3. Test driven deployment / Unit test: tener, antes de empezar a desarrollar, tener
primero los testings. Se empieza por el testing.
4. Build automation: cuando los testing son exitosos, que se pueda realizar el build
de forma rápida

A la izq, varios desarrolladores trabajando con su

repositorio local. El commit se hace sobre el
repositorio centralizado.
El servidor de Continuous Integration toma ese código
centralizado y lo ejecuta con pre-checks, y el testing.
A partir de esto, si es exitoso se hace el build, y se le
da feedback con mensaje a los desarrolladores

Git
Es un software de control de las versiones del código. Lleva registro de los cambios
en archivos de computadora y coordina el trabajo que hacen los desarrolladores

Hay diferentes ramas de desarrollo: existe desarrollar en paralelo, y con diferentes features.

Continuous Delivery
La diferencia con CI es que CD agrega un paso más. Agrega un release del producto.
El objetivo del CD es probar que el resultado final es desplegable, no desplegarlo. Que
como mucho le quede un testing manual para después poder pasar a producción
- artefactos agnósticos al entorno: tener un release que soporte los diferentes
entornos
- testing strategy: que se haga un testng más integral, que se mida la capacidad
- coding metrics and analysis
- que la infraestructura sea como código

Testing strategy
Automatizar el testing permite reducir los tiempos de entrega y mejorar la calidad,
aunque no siempre genera ahorros. Hay que contemplar los diferentes niveles de testing:
Unit, Component, Contract, Integration, Performance, UX/UI, E2E (end-to-end) y Regression
Testing (repaso por todas las funcionalidades del sistema).
Automatizar todo lo posible para pasar al release final

Static Code Analysis

Las herramientas de análisis estático de código permiten realizar chequeos sobre el código
fuente y brindar detalles de la calidad y posibles inconvenientes
- bugs ; seguridad ; líneas de código
Continuous Deployment
Es el paso final, el más complejo. Implica la salida a producción
Es un proceso que se puede agregar al final del proceso de entrega continua. Se
automatiza el proceso de implementación y se despliega el resultado
- Manual check: testing manual del código
- Staged deployments
- Blue/Green deployment

Blue/Green Deployment
Se despliega una nueva instancia del servicio (Green), y hasta que no está probado el
Green, no se rutea ni se apaga el blue.
Es una estrategia para dos cosas:
1. Lograr automatizar lo máximo posible la salida a producción
2. Minimizar el riesgo de la salida a producción del producto

RESUMEN CI / CD / CD
Hasta donde llega cada uno.
El Continuous delivery va más allá que el CI, llegando hasta el release. No lo lanza, sino
que se encarga de que sea desplegable
El Continuous Deployment va más allá que el Delivery, desplegando el producto.

PARTE 2: SRE

DESIGN

❖ Modelos operativos

Cómo la organización, con su recurso, se adapta al enfoque de agilidad, velocidad y

autonomía que pensamos cuando hablamos de arquitecturas distribuidas

Los squads son interdisciplinarios y multidisciplinarios. Están

alineados, no hacen cualquier cosa. Los squads colaboran entre ellos.

El Product Owner va a ser el líder funcional del squad, y ve qué se tiene

que trabajar en el squad

Propuesta de valor --------------->

Desafíos arquitecturales
1. Producto vs Proyecto: orientar la estructura a los productos
2. Modelo operativo / cultura: implementar el modelo operativo, y que esté presente
en la cultura, en el mindset cultural
3. Arquitectura tecnológica: arquitectura distribuida

Prácticas del modelo operativo

❖ SRE Intro

Devops: es una práctica que permite unificar los mundos de Dev y Ops. El objetivo de la
práctica es dar las condiciones, desde el punto de vista de infraestructura/arquitectura,
para que el equipo de desarrollo tenga esa agilidad que da el enfoque. Para que haya
entrega continua de valor

SRE: es la persona que tiene la responsabilidad de asentar las prácticas de

automatización sobre los componentes que son desarrollados, para brindar escalabilidad
en la organización, ser tolerante a fallos y dar confiabilidad de lo que se está
implementando. El SRE ayuda a cumplir este modelo operativo

- Tipo 8: hay un rol que se llama Devops. Es la persona que permite

configurar/implementar las prácticas para automatizar las tareas y lograr
agilidad y eficiencia en los despliegues. El rol tiene conocimientos técnicos de la
arquitectura, y de contenedores
- Tipo 7: si tu rol es ser “Devops”, en realidad tu rol se llama SRE. Porque Devops es
una práctica

SRE = Site Reliability Engineering

SRE son las actividades que siempre habían sido realizadas por Operaciones, pero
realizadas por ingenieros que prefieren automatizar completamente la infraestructura.
Se busca mejorar la confiabilidad de IT a través de minimizar el trabajo manual que se
necesita para la operación
 Modelo operativo cloud
Habíamos dicho que teníamos squads, uno por cada funcionalidad. Puede haber un SRE
en cada squad, o que tenga más de un squad (para aplicar Devops)
Brinda las herramientas necesarias para que el squad trabaje de forma automatizada y
brindando agilidad al negocio.
- KPIs de un Devops en un squad: uptime (disponibilidad), que los containers se
puedan desplegar fácilmente
- Servicios que va a utilizar un Devops: frameworks de automatización, estrategias de
métricas, estrategias de escalabilidad (ej, Kubernetes)

PROVISIONING

Arquitectura Provisioning
Infraestructura como código: enfoque de la automatización de la infraestructura,
basada en las prácticas del desarrollo de software. Trata que el aprovisionamiento y
cambio de sistemas y su configuración sean rutinas consistentes y repetibles

Con código, se puede hacer que se levante un Cluster de Kubernetes por ejemplo. Es
reutilizable el código, entonces es repetible. El código permite cambiar la arquitectura.

Está práctica implica una toma de decisiones

- infraestructura inmutable
- pipelines que me generen infraestructura
- tooling por Layers

GitOps como patrón

- infraestructura como código
- uso de CI como fuente de verdad
- Pull vs Push
- Developers y operaciones (Git)
- Actualizaciones

GitOps pipeline
El desarrollador sube su código al
repositorio

El CI genera las pruebas, realiza las

pruebas de integración, ejecuta calidad de
código/cobertura

Si está ok el código, genera un

contenedor que lo sube a un Registry de
Docker, y luego eso se sube a
Kubernetes
Terraform
- agnóstico: es “fácil” de cambiar de proveedor
- open source
- extensible: ofrece APIs de las Cloud Providers
- herramienta IaC declarativa (declaro el estado deseado)

LA VENTAJA DE QUE LA NUBE TE OFREZCA UNA API ES QUE PUEDO UTILIZAR

ESA API PARA AUTOMATIZAR PROCESOS. Por ejemplo, crear infraestructura para
una organización ; bajarse una aplicación y validar algo, y volver a subir código. Permite
trabajar de forma desacoplada la nube, y automatizar procesos contra esa API, de
forma declarativa

Un desarrollador sube su código al repositorio de infraestructura. Mediante el Terraform

Plan se valida lo que está pasando, y genera un pull request. Este pull request lo aprueba
otra persona, y eso se aplica (con Terraform Apply), y se genera la infraestructura en la
nube