AWS Certified Cloud Practitioner

TIPOS DE ALMACENAMIENTO
OBJETOSINFORMACIÓN ESTATICA

TIPOS DE BASES DE DATOS:

Infraestructura como código: Permite gestionar y desplegar la

infraestructura en un proveedor de servicios de nube a través de código,
en vez de hacerlo con procesos manuales.
Función: Es un entorno de ejecución serverless para ejecutar código sin la
necesidad de administrar un servidor.
**-Contenedor Docker: ** Contenedor ejecutable, independiente que
tiene todo lo necesario para ejecutar una aplicación.
-Microservicio: Un concepto en el cual una aplicación se construye
como una serie de pequeños servicios.
Definición de CLOUD COMPUTING (NUBE)++: es la entrega POR
DEMANDA de infraestructura y todo tipo de servicios de aplicación vía
internet. Con precios por demanda, donde solo se paga por lo que se
consume.
MODELO++: Pago por uso (Pay as you go. Se calcula multiplicando la
cantidad de minutos consumidos referidos a horas, por el precio por hora
de uso)

Ventajas de la Nube
1. Agilidad: La capacidad de escalar y desplegar recursos
rápidamente según la demanda, lo que agiliza el desarrollo y la
entrega de aplicaciones y servicios.
2. Ahorro de costos: Reducción de los gastos de inversión en
infraestructura y mantenimiento, además de pagar solo por lo que
se utiliza, lo que optimiza los costos operativos.
3. Elasticidad: La habilidad de aumentar o disminuir los recursos de
manera automática para adaptarse a picos de carga o cambios en
la demanda, asegurando un rendimiento óptimo.
4. Innovación: Al eliminar la preocupación por la gestión de
infraestructura, los equipos pueden centrarse en la creación y
mejora constante de aplicaciones y servicios innovadores.
5. Despliegue global en minutos: La posibilidad de implementar
aplicaciones y recursos en múltiples regiones del mundo de manera
rápida y sencilla.
6. Catálogo de servicios: Acceso a una amplia variedad de servicios
preconfigurados, como bases de datos, análisis y machine learning,
lo que acelera el desarrollo y ahorra tiempo.

Recomendación: Establecer alertas sobre el consumo para ir

midiendo el costo de la infraestructura
DIFERENCIA NUBE – ON PREMISE

MODELO DE COSTOS: Modelo basado en demanda. Cambiar CAPEX por

OPEX. ) ON-PREMISES (CAPEX): costos (servidor, lugar, cable de red, aire
acondicionado, ups para alimentación contínua). 10000 dólares + 2
meses para instalar. NUBE (OPEX): en 10 minutos luego de logueado,
empiezas a pagar los costos por demanda (lo que me cobran por
segundo). Costo más operativo.

MODELO DE ENTREGA / DESPLIEGUE: Automatización, y creación de

ambientes. Cambia la forma de trabajar. Automatización (Roles DevOps,
crear Pipelines para automatizar el despliegue de aplicaciones e
infraestructura). En la NUBE se pueden crear ambientes muy rápido.
Pensar en MODO NUBE. Definiciones de cómo utilizar los SERVICIOS
orientados a mejores prácticas.

ESCALABILIDAD Y RESILIENCIA: Recuperación antes fallas, utilizar zonas

y regiones. Puedo tener una copia de PlatziWallet en cualquier parte del
mundo (resiliencia).
Tecnologías disruptivas a la mano. IA, BLOCKCHAIN, MACHINE LEARNING

MODELO DE SEGURIDAD COMPARTIDA: Responsabilidad del usuario y

proveedor de serv icios Cloud¿ Que es responsabilidad del
proveedor de nube y que es nuestra?
Infraestructura Global: Red de centros de datos y recursos de TI en
todo el mundo para brindar servicios en la nube.
Regiones: Áreas geográficas con centros de datos, permiten a los
usuarios elegir ubicaciones para sus datos y cargas de trabajo.
Zonas de disponibilidad(AZ): Divisiones dentro de una región con
infraestructura aislada, brindan resiliencia y alta disponibilidad al
permitir la conmutación automática en caso de falla.

Esta estructura global, regiones y zonas, permite a las organizaciones

elegir ubicaciones estratégicas y precios, garantizando la disponibilidad
y confiabilidad de los servicios en la nube, incluso en situaciones
adversas.

Recomendación: Arquitectura multizona, si la

zona 1 se cae, el b alanceador envía a la
zona 2
1. NUBE PRIVADA: solamente puede ser accedida por nosotros como
empresa. Se puede pensar como un ON-PREMISE. Con nuestro
datacenter, servidores, almacenamiento e infraestructura. Para
instalar APP y DB, usar el STORAGE, etc. La empresa es la única
que tiene acceso a esa nube.
2. NUBE PÚBLICA (AWS, AZURE, GCP, etc): donde múltiples empresas
tienen acceso. Son los CLOUD PROVIDERS del mercado.
NUBE HÍBRIDA: sistema o aplicación que funciona con una nube
pública coexistiendo con otra privada. Ej: PlatziWallet la
desplegamos en AWS sin embargo la aplicación todavía tiene una
DB que no hemos migrado hacia la nube.
3. MULTI NUBE: cuando coexisten 2 nubes públicas. Ej: PlatziWallet la
tenemos desplegada en AWS, sin embargo toda la parte de
autenticación de usuarios la tenemos en un AZURE en un servicio
de directorio activo. Necesitamos conectividad entre AWS y AZURE
para hacer la autenticación de usuarios.
4. MULTI NUBE HÍBRIDA: 2 nubes públicas + 1 nube privada. Ej:
PlatziWallet corre en AWS, pero tenemos la parte de procesamiento
de datos y analítica en GCP. Todos los eventos que genera
PlatziWallet los enviamos a GCP. Pero la APP tiene que consumir
una DB que está en on-premise en una nube privada
CLOUD NATIVE

Continuous delivery se refiere a despliegues

automáticos
Escalabilidad – ampliación de recursos
Inmutable – elástica ante picos de demanda
CLOUD NATIVE COMPUTING FOUNDATION (CNCF)++: es una
fundación de software open-source que promueve la adopción de Cloud
Native Computing. Algunos proyectos (que podemos usar en CLOUD
NATIVE):
ARGO: se utiliza para hacer despliegue de imágenes en Cluster de
Kubernetes
ETCD y KUBERNETES son vitales para desplegar cualquier aplicación
cotenedrizada y orquestarla.
FLUENTD y PROMETHEUS para toda la parte de observabilidad,
monitoreo, trazas. PROMETHEUS se utiliza para las DB de series de
tiempo.
HELM: nos ayuda a desplegar y automatizar despliegues de aplicaciones
dentro de KU BERNETES

BENEFICIOS de una APLICACIÓN CLOUD NATIVE++:

1. INDEPENDENCIA: cada aplicación es totalmente independiente de

las otras.
2. RESILIENCIA: Puede soportar una caída de infraestructura.
3. ESTANDARIZACIÓN (integraciones) Para interoperabilidad (con
otros proveedores o con un on-premises, por ejemplo) y
portabilidad (que se pueda mudar a otro cloud provider) de nuestra
aplicación, están basadas en OPEN-SOURCE.
4. AGILIDAD: Flexibilidad en sus despliegues y usualmente más
pequeñas (de forma RÁPIDA).
5. AUTOMATIZACIÓN: utilización de prácticas DevOps para
despliegues.

1) automatizar el despliegue de la infraestructura (TerraForm)

pipelines.

2) Pipelines para automatizar el despliegue de la APP en la

APPSTORE y PLAY STORE.

3) Automatizar el despliegue de imágenes en las funciones y los

contenedores. Pipelines para el backend de nuestra aplicación.

6. 0 Downtime: (siempre operativa así se hagan cambios) utilizando

las ventajas de la nube la hago siempre operativa a pesar de los
despliegues que haga, de las nuevas features y servicios, o de los
cambios que haga sobre la misma. Esto marca ventajas en el
mercado.

Características Arquitectura: Altamente disponible (AZ): 2 zonas de

disponibilidad.
1. CAPA DE CONECTIVIDAD: para el on-premises, las instalaciones de
la empresa o una capa de networking. A través de un VPN o una
conexión dedicada que nos ofrece Cloud P.
2. ZONA PRIVADA: donde corre el backend de nuestra aplicación. No
va a estar expuesta a internet. Nosotros exponemos nuestros
servicios, pero nuestra aplicación, los contenedores, las funciones
quedan en esta zona privada.
3. ZONA PÚBLICA: servicios que deben estar expuestos hacia internet.
Reciben los requests directamente de los usuarios y se comunican
con la capa privada donde está el backend. DNS: nombre de
dominio (platziwallet com). Le agregamos las reglas de
enrutamiento. Se pueden crear a nivel de los DNS opciones de
redireccionamiento (basados en el nombre de dominio).
CDN (content delivery network ): expone el servicio de forma global
a través del uso de ubicaciones de borde. Ubicaciones de borde son
datacenter pequeños distribuidos por el mundo sobre los cuales
puedo poner el contenido estático o dinámico de la aplicación. Esto
ayuda a que la experiencia de usuario sea mucho mejor. WAF +
CERTIFICADO (seguridad). Va a ver usuarios que van a estudiar
cómo toman ventaja para hacer fraude. Web Application Firework +
Certificado de seguridad para agregarle reglas de seguridad a
nuestra aplicación. De esta manera protegemos nuestra aplicación
de ataques de denegación de servicios, sql injections, ataques de
script API GATEWAY: recibe toda la información se la manda al
BALANCEADOR de aplicaciones. Detrás del balanceador podemos
tener nuestro backend corriendo en Kubernetes. Este clúster de
Kubernetes donde está corriendo PlatziWallet y donde están los
microservicios de pagos, cobro, recarga, login, biometría, etc. Estos
tienen una capa de almacenamiento (objetos, bloques y archivos).
DESPLIEGUE: para desplegar nuestro backend tenemos:
Kubernetes, argo y helm
SERVERLESS (sin servidor)++. ++DEFINICIÓN DE SERVERLESS++:
es la idea de que se puede ejecutar una aplicación basada en servidor
sin la necesidad de administrar un servidor. Los CLOUD PROVIDER tienen
servicios SERVERLESS. El cloud provider administra el sistema operativo
(parcheo, administración, escalabilidad del SO) y el usuario se enfoca en
su aplicación. El cloud provider le da al usuario una FUNCIÓN y un
CONTENEDOR SERVERLESS. El usuario pone la aplicación en el
CONTENEDOR en esa FUNCIÓN

1. ESCALABILIDAD: es muy grande pero está limitada por las cuotas y

los límites que pone el cloud provider. Por ejemplo la FUNCIÓN
puede tener un límite de concurrencia (ej: 1000 ejecuciones
concurrentes por segundo). Estos límites se pueden ampliar a
través de una solicitud al cloud provider por medio de un ticket de
ampliación de límites. El costo tiene que ver con estos límites.
2. SEGURIDAD: el usuario se enfoca en proteger el código que publica
en la función (comunicación de cifrado en tránsito). El usuario no se
preocupa de la seguridad del servidor.
3. FIABILIDAD: El cloud provider se compromete con unos niveles de
disponibilidad por arriba del 99 % (los servicios que tienen que ver
con la fiabilidad y alta disponibilidad tienen un SLA muy alto).
4. PAGO POR USO: por el tiempo de ejecución y la cantidad de
memoria que uso para una ejecución. Ej: una FUNCIÓN se demora
200 milisegundos en tomar una imagen y convertirla en miniatura.
El precio se calcula por ejecución, por consumo, cantidad de
peticiones, tiempo de ejecución y cantidad de tráfico.
5. AHORRO de TIEMPO y DINERO: ej: on-premises a serverless. No hay
ocupación en administrar o instalar servidores. MEJORA la
PRODUCTIVIDAD del DESARROLLADOR: porque los entornos
actualmente en nube, los servicios, la forma de testearlos
localmente, la forma de automatizar su despliegue y de probarlos
es muy fácil. La agilidad para desplegar un servicio por medio de
una función, teniendo el código, va a ser muy rápida (10 o 15
minutos).

RETOS DE SERVERLESS

6. COLD START (tiempo de inicio frío): tiempo para que una FUNCIÓN
se “despierte”. Hay que esperar unos 2 o 3 segundos en su primera
ejecución. Esto puede afectar a algunas arquitecturas cuando no se
tolera ese tiempo de latencia.
7. TIEMPO de CÓMPUTO: Ejemplo. Hay FUNCIONES que su tiempo
máximo de vida es 15 minutos y necesitamos un tiempo de
ejecución de 30 minutos. FUNCIÓN limitada por un timeout.
8. CONECTIVIDAD: Ejemplo. Consumo de direcciones IP que hace una
función dentro de una capa de red. Si es alto hay que evaluar la
utilidad que tiene esa función dentro de la capa. Pues es
 aconsejable que esa función no se ubique dentro de una VPC o una
Virtual Private Cloud dentro de la red. Sino que se ejecute fuera de
ella para tener más flexibilidad.
9. VENDOR LOCK-IN: si queremos migrar una aplicación de AZURE a
AWS lo más probable es que la tengamos que hacer de nuevo.

STREAMS++: es una secuencia de eventos, mensajes o datos que

pueden ser procesados una vez ocurren, los cuales pueden ser
distribuidos a múltiples consumidores Abundan en los proyectos donde la
palabra clave es “data” o “real-time”. Real-time: es cuando se puede
utilizar un evento o una acción que se acabó de generar hace poco. Es
streams tiene la capacidad de recibir muchísimos eventos en paralelo
(millones) y se los puede enviar a un dashboard para que los grafique y
lo pueda ver un equipo de marketing, por ejemplo. De esta manera estoy
utilizando un streams para aprovechar al máximo el poder del real time.
En los cloud provider estos streams son servicios completamente
serverless. El streams tiene que tener la capacidad de recibir esos
millones de eventos y enviarselo a un consumidor en tiempo real.
++COLAS++: método para retrasar el trabajo, utilizadas para
desacoplar componentes de un sistema. Ejemplo: cola para el cajero del
banco. Entonces las COLAS se ubican para no saturar a un componente
de la arquitectura. Ejemplo: miles de usuarios piden un certificado a la
APP, la COLA en cola estas solicitudes y la aplicación lo va procesando a
medida que pueda. De esta manera la APP nunca se cae.
++BUCKET++: estructura donde se puede almacenar una colección de
OBJETOS. Estos objetos se pueden consultar. Su costo se basa en la
cantidad de solicitudes y espacio utilizado. Almacenamiento por objetos.
Un objeto puede ser la foto de cada usuario de la APP.
++API++: es una abreviatura de APPLICATION PROGRAMMING
INTERFACES, son mecanismos que permiten a dos componentes de
software comunicarse entre sí, mediante un conjunto de definiciones y
protocolos. API REST, API HTTPS, API WebSocket, API GraphQL y todos
son servicios serveless. La API es la puerta de entrada a nuestra
aplicación.
++DATASTORE++: es una base NoSQL creada para proporcionar
autoescalamiento, alto rendimiento y facilidad para el desarrollo de
aplicaciones. No SQL: llave valor, de memoria, por grafos y
documentales.
++IDENTITY SERVICES++: servicios en la nube que ayudan a
implementar la administración de acceso e identidad de los usuarios a
nuestras aplicaciones web o móviles. Servicios para hacer autenticación
y autorización. Ejemplo para PlatziWallet: yo puedo registrarme como
usuario (autenticación) pero hasta que no registre una tarjeta de crédito
no voy a poder realizar un pago (autenticación).
++MOTOR DE CONSULTAS++: motor de consulta SQL que pueden
consultar data estructurada, semiestructurada y no estructurada de
diferentes fuentes de datos. Ej: PRESTO (Open Source). Query a
múltiples fuentes, centralizadas y el costo es por la cantidad de data
escaneada. A datos que tengamos en almacenamiento por objetos, a DB
no relacionales y relacionales.
++BALANCEADORES DE CARGA++ de aplicación y de red:
componente que distribuye el tráfico entre varios destinos, puede ser a
nivel de aplicación, red o transporte. Recibe los requests y los distribuye
entre las zonas de disponibilidad. El balanceador de aplicaciones es el
que va ser nuestro foco, porque va a trabajar en capa 7 del modelo OCI,
es decir, va a balancear a nivel de HTTP y HTTPS. El balanceador de red
se enfoca en las capas 3 y 4 del modelo OCI, es decir, en balancear
tráfico IP, tráfico UDP y tráfico TCP.

Resumen del libro: El libro "Aprendizaje sin servidor: diseño, desarrollo e

implementación con confianza" de Jason Katzer es una guía práctica para
crear aplicaciones sin servidor. El libro cubre los conceptos básicos de la
computación sin servidor, así como temas más avanzados como la
seguridad, la supervisión y el registro.

El libro se divide en tres partes:

1. El camino a la producción cubre los conceptos básicos de la

computación sin servidor, incluidos los diferentes tipos de servicios
sin servidor, cómo elegir el servicio adecuado para sus necesidades
y cómo diseñar y desarrollar aplicaciones sin servidor.
 2. Las herramientas cubre las herramientas que necesita para crear y
implementar aplicaciones sin servidor, como proveedores de nube,
lenguajes de programación y marcos.
3. Conceptos cubre temas más avanzados relacionados con la
computación sin servidor, como la seguridad, la supervisión y el
registro.

El libro también incluye una serie de ejercicios prácticos que puede usar
para aprender los conceptos y crear sus propias aplicaciones sin
servidor.

Aquí hay algunas de las conclusiones clave del libro:

 La computación sin servidor es un modelo de computación en la

nube en el que el proveedor de nube se ocupa de la
infraestructura, por lo que no tiene que preocuparse por
aprovisionar, administrar o escalar servidores.
 Hay muchos tipos diferentes de servicios sin servidor disponibles,
cada uno con sus propias fortalezas y debilidades.
 Al elegir un servicio sin servidor, debe considerar sus necesidades
específicas, como el tipo de aplicación que está creando, la
cantidad de tráfico que espera y su presupuesto.
 Las aplicaciones sin servidor se pueden desarrollar utilizando una
variedad de lenguajes de programación y marcos.
 Hay una serie de herramientas disponibles para ayudar a crear y
implementar aplicaciones sin servidor.
 La seguridad es una consideración importante al crear aplicaciones
sin servidor.
 Es importante supervisar sus aplicaciones sin servidor para
garantizar que estén funcionando según lo esperado.
 El registro es importante para solucionar problemas y comprender
cómo se utilizan sus aplicaciones sin servidor.

Si está interesado en aprender más sobre la computación sin servidor,

recomiendo encarecidamente leer este libro. Es una guía completa y
práctica que lo ayudará a comenzar con la computación sin servidor y
crear sus propias aplicaciones sin servidor.
Que es un proveedor de servicios de Nube (CSP)

"Es una empresa que ofrece recursos de computación escalables, bajo

demanda a través de internet para que sean consumidos "

Vendor Lock-in (Encierro del proveedor): Depender en gran medida de

un proveedor específico para servicios o soluciones, lo que dificulta
cambiar a otro proveedor.

 Ejemplo: Utilizar herramientas y servicios de Amazon Web

Services (AWS) exclusivamente, lo que hace que la migración a
otro proveedor sea complicada debido a la dependencia de las
características y servicios de AWS.

Product Lock-in (Encierro del producto): Estar atado a un producto o

software particular, lo que dificulta cambiar a otro producto.

 Ejemplo: Utilizar una suite de productividad específica que

requiere un proceso complicado para migrar a otra suite debido a
las diferencias en formatos y características.

Version Lock-in (Encierro de versión): Depender de una versión

específica de un producto, lo que dificulta actualizar o cambiar debido a
incompatibilidades.

 Ejemplo: Utilizar una versión más antigua de una base de datos

que no es compatible con las aplicaciones modernas, lo que
restringe la migración sin una actualización costosa.

**Architecture Lock-in **(Encierro de arquitectura): Diseñar una

arquitectura de manera que sea difícil cambiar debido a las
dependencias profundas en componentes específicos.

 Ejemplo: Diseñar una aplicación con dependencia en una

tecnología de base de datos propietaria, lo que hace que sea difícil
migrar a una base de datos diferente sin un rediseño importante.

Platform Lock-in (Encierro de plataforma): Quedar atrapado en una

plataforma específica que dificulta la portabilidad de aplicaciones y
servicios.

 Ejemplo: Elegir una plataforma de desarrollo que solo es

compatible con un proveedor de nube, lo que hace que la
migración a otro proveedor sea desafiante.

Skills Lock-in (Encierro de habilidades): Tener personal con habilidades

especializadas en una tecnología o plataforma específica, lo que dificulta
cambiar a algo diferente.
  Ejemplo: Contar con personal altamente capacitado en una
plataforma de análisis de datos específica, lo que hace que migrar
a otra plataforma sea costoso debido a la necesidad de
reentrenamiento.

Legal Lock-in (Encierro legal): Estar limitado por acuerdos

contractuales que dificultan cambiar de proveedor o producto.

 Ejemplo: Tener contratos a largo plazo con un proveedor de

servicios en la nube, lo que hace que la transición a otro proveedor
sea complicada debido a las restricciones contractuales.

Mental Lock-in (Encierro mental): Permanecer apegado a una

tecnología o enfoque familiar, incluso cuando hay mejores alternativas
disponibles.

 Ejemplo: Rechazar la adopción de nuevas tecnologías en una

empresa debido a la resistencia al cambio, a pesar de que esas
tecnologías podrían mejorar la eficiencia.

Definición de Multi-Nube++: Utilizar más de un proveedor de

servicios de nube pública para desplegar una aplicación, plataforma o
sistema. Ejemplo: PlatziWallet corriendo en AWS teniendo servicios en
GCP. Hay empresas que son multi nube. ++Estrategias de multi nube
++(que puede definir que despliegue determinada parte de la aplicación
en la nube A o B):

1. ARBITRARIO: no es una decisión técnica. Puede ser por un convenio

ó MSA con el Cloud Provider, decisión de negocios, skills lock-in (los
trabajadores saben X plataforma), legal lock-in (contrato por varios
años con el CP).
2. ELECCIÓN: seleccionar lo mejor de los mundos que se acomode a
nuestro caso de uso. Mirar pros y contra de los CP realizando un
estudio.
Ejemplo: Backend corre en AWS (Kubernetes) y DevOps corre en
Azure (despliegue). Estoy tomando lo mejor de los mundos. Puedo
tener Vendor Lock-in porque si Azure DevOps lo quiero llevar a
AWS tengo que rehacerlo todo prácticamente. Por otro lado, los
trabajadores van a tener que saber de AWS y de Azure.
3. AGNÓSTICO: que los servicios de la aplicación puedan ser
desplegados fácilmente en todos los Cloud Provider. Ejemplo:
desplegar una aplicación usando Open Source en Kubernetes en
AWS y hago su réplica en Kubernetes en Azure. Al ser todo
Kubernetes y Open Source puedo replicarlo más fácil. La limitación
Lock-in puede estar dada por los productos específicos de Open
Source.
4. PARALELO: Si se me cae una nube que entre otra. Es muy difícil de
implementar porque tiene una complejidad técnica muy alta.
 Porque necesitas personal con conocimiento muy alto en 2 nubes.
Funciona como un DRP (disaster recovery). Para esto las empresas
tienen que definir el RTO y el RPO.
5. SEGMENTADO: Ejemplo: todo nuestro Backend va a correr en Azure
pero toda la parte de Data, Analítica y Machine Learning va a correr
en GCP. Segmentando cargas de trabajo para que sean ejecutadas
en distintos CP. Existe un skill lock-in porque el equipo de data
saba GCP y el equipo de backend sabe Azure.
Alta Disponibilidad: Mantener un sistema funcionando incluso cuando
ocurren problemas, minimizando el tiempo de inactividad y asegurando
servicios continuos.
 RTO (Tiempo de Recuperación Objetivo): El tiempo máximo
deseado para que un sistema vuelva a funcionar después de una
falla, reduciendo el impacto del tiempo de inactividad.
 RPO (Punto de Recuperación Objetivo): La cantidad máxima de
datos que una organización está dispuesta a perder en una
interrupción, marcando cuán actualizados deben estar los datos
recuperados.
Tolerancia a Fallos: La tolerancia a fallos es la capacidad de un
sistema, aplicación o servicio para continuar funcionando de manera
aceptable incluso cuando uno o varios componentes experimentan
problemas o fallas. Implica diseñar sistemas de manera que sean
capaces de manejar errores y problemas sin que todo el sistema se vea
comprometido, lo que garantiza la disponibilidad y la continuidad de los
servicios incluso en condiciones adversas.

ESCALABILIDAD: es la capacidad de incrementar o decrementar los recursos

necesarios para complir la demanda cambiante en una aplicación o servicio. Crecer y
decrecer basado en la demanda que recibe nuestra aplicación. Ejemplo: descuentos
por pago en Black Friday. Entonces, los servicios que reciben pago crezcan y soporten
al incremento de la cantidad de usuarios por la oferta y luego de pasada la oferta
estos mismos servicios decrecen.

 ESCALABILIDAD VERTICAL: es la escalabilidad de añadir más

recursos a un nodo particular dentro de un sistema. Hay una caída
 del servicio mientras se hace el cambio. Ejemplo: A un determinado
servidor lo apago, le aumento los recursos (cpu, ram, disco) y lo
vuelvo a prender. Luego tendré que apagarlos para volver a los
recursos a sus niveles anteriores. No cambia la cantidad de
servidores. Hubo caída del servicio cuando lo apago.
 ESCALABILIDAD HORIZONTAL: es la capacidad de agregar más
nodos para soportar una demanda creciente de solicitudes en un
sistema. Ejemplo: replicar servidores en el momento de más carga.
No tenemos DOWNTIME (caída del servicio).

¿Sirve ESCALABILIDAD sin alta DISPONIBILIDAD? La ESCALABILIDAD está

en más de un a ZONA. Porque si solo escalamos en una zona
perdemos ALTA DISPONIBILIDAD.

Componentes de la arquitectura agnóstica ++ (distribuida en al

menos 2 zonas de disponibilidad):
 DNS (platziwallet com): nombre de dominio. Donde llegan todos los
usuarios. Reglas de enrutamiento para el dominio¿ Cómo
administro el dominio? ¿Dónde va a estar? ¿Lo voy a tener en el CP
o en GoDaddy?
 CDN(Content Delivery Network): Recibe el tráfico. Puede tener
reglas de direccionamiento basado en ciertos criterios y según el
origen de los requests. TIene certificado de seguridad (HTTPS)
¿Que CDN voy a utilizar?Cloudflare, Akamai, CloudFront, entre
otros.
 WAF (Web Application Firewall): Para seguridad y protección.
Reglas de denegación de servicio ¿Que WAF voy a tener? Imperva,
utilizar el del CP, voy a comprar reglas de OWASP.
 BALANCEADOR - API GATEWAY: Puerta de entrada a la app.
 AUTENTICACION y AUTORIZACION: Si el usuario está registrado y
que permisos tiene. Antes de que el requests llegue a nuestro
backend. ¿Que servicio de autenticación voy a usar del mercado?
BACKEND - (Servidores, Funciones o Contenedores): donde está
gran parte de nuestra app (microservicios). Zona privada (no
acceso directo por internet). ¿ Dónde va a correr nuestro backend?
 BASE DE DATOS: DB Master y DB Standby. DB Master:
continuamente recibe requests de lectura y escritura. DB Standby:
modelo activo- pasivo. Si se cae el DB Master, DB Standby
comenzará a recibir los requests¿La DB va a ser relacional o
noSql(llave valor o memoria o documentos)? ¿Que motor de BD voy
a usar
 ALMACENAMIENTO: Objeto, Bloques o Archivos.
 CONECTIVIDAD - HÍBRIDA (on-premises): ¿Cómo me conecto? ¿VPN
y sacrifico rendimiento?¿Contrato una conexión dedicada con
mayor costo?
++SERVICIOS TRANSVERSALES++:
  OBSERVAVILIDAD: Monitoreo (medición de métricas, umbrales,
alertamiento) , trazas (el tiempo que se demoran en conectarse los
componentes de nuestra aplicación y logs), experiencia de usuario,
detección de anomalías del monitoreo,
 COMPLIANCE: reglas. Ejemplo: toda la información que se guarde
en reposo debe estar cifrada (almacenamiento y db).
 AUDITORÍA: Para todos los roles y personas que pueden modificar
la arquitectura, tener la trazabilidad de que cambios hizo, cuando
los hizo y sobre que componentes de la arquitectura.
 CIFRADO - KMS: todo debe estar cifrado en reposo y en tránsito.
KMS (Key Management System Service): administración y gestión
de llaves.

Arquitectura agnóstica
Base de datos M – Maestra de
lectura y escritura – base de datos
S – standby

Cómo sería nuestra arquitectura si la app corriera completamente

basada en servidores? ++DIFERENCIAS (balanceador y backend)++:
 Balanceador de aplicaciones: balanceamos tráfico HTTPS. Capa 7
del modelo. El algoritmos del balanceador va a ser un round robin
(alterna una y otra zona).
 AUTOESCALAMIENTO (autoscaling group): ante más demanda,
basándonos en una imagen del servidor (AMI: Imagen base que ya
tiene todo preinstalado), estos crecen en cantidad. Cada servidor
nuevo tarda 3 minutos en crearse desde la AMI y hasta que el
balanceador determina que está saludable para mandarle tráfico.
La escalabilidad horizontal que no requiere downtime (que la app
se caiga). Definir cantidad mínima de servidores para soportar la
app, la cantidad deseada y la cantidad máxima. Debemos definir la
cantidad máxima para no crecer indefinidamente y que se nos
consuma todo el costo de un mes.
 Métricas de monitoreo: para definir cuando comenzamos a crecer
en servidores. Ejemplo: cuando la CPU > 60 % sume un servidor y
cuando la CPU > 80% sume 2 servidores. También: cuando la CPU
% < 60 % reduzca 1 servidor y cuando CPU < 40 % reste 2
servidores. Siempre y cuando no llegue a menos de la capacidad
mínima.
Se puede escalar en cualquier parámetro (% CPU, RAM, etc) pero lo
mejor es escalar sobre parámetros de demanda. Ejemplo: Cantidad
de usuarios.
 Tener en cuenta: como escalar, el tiempo de escalamiento y la alta
disponibilidad.

Arquitectura basada en servidores

- Autoescalamiento
Cuando la app corre en un orquestador de contenedores+
+ (nuestro backend corre en contenedores): ++DIFERENCIAS
(backend)++. KUBERNETES va a ser el orquestador de los
contenedores: Vamos a tener por lo menos 2 zonas donde en cada zona
va a ver al menos 1 servidor. Cada servidor va a tener los contenedores
donde van a correr los microservicios. Ejemplo de microservicios para
PlatziWallet: pagos, cobros, saldo, cash-in (consignación), cash-out
(retirar), etc. ESCALAMIENTO: por servidores pero también por
microservicios. Porque la escalabilidad del microservicio de cash-in es
diferente a la escalabilidad del servicio pagos. Porque se puede ingresar
dinero una vez (cash-in) pero realizar 25 pagos. Tengo 2 tipos de
escalabilidad: del servidor y del microservicio (contenedor).
 Por SERVIDOR. reglas como: el microservicio de cobros si lo tengo
que escalar lo hago en el servidor que tenga disponible menos ram.
 Por MICROSERVICIO (servicio de contenedores serverless). El CP se
encarga de los servidores. Es más sencillo el escalamiento porque
nos enfocamos en el microservicio puntual y no como escalamos
los servidores.
CICD: configurar estrategia para llegar a desplegar determinado servicio,
versionamiento del microservicio, como lo voy a desplegar, etc.
REPO de código: como va a ser el CICD, que pasos se van a automatizar,
qué pruebas le voy a hacer a la imagen. BASES de DATOS: vamos a usar
el STORAGE de los servidores incrementales u otro tipo.
Cómo sería tener muchos de los servicios en funciones++: +
+DIFERENCIAS++:
 CDN: hay servicios de cdn que pueden tener funciones. Por
ejemplo: para cuando venga un requests transformarlo, para hacer
un redireccionamiento 301 o 302 (redireccionamiento de dominio
temporal o permanente).
 FUNCIONES del BACKEND: El API recibe el requests y se lo manda
alguna FUNCIÓN. Las reglas del API para la designación de los
requests a las funciones sería, por ejemplo: Si la API recibe el
 request con el pass “/saldos”, le va a mandar ese request a la
FUNCIÓN saldos. Entonces para el caso de PlatziWallet tendríamos
la funciones de: Saldos, Cash-in, Pagos, entre otras.
 BASE de DATOS: 1) No Relacional: La DB será llave-valor y cada
FUNCIÓN actualizará determinada tabla en la DB. 2) Relacional: No
todas las BD relacionales son serverless. Cuando tenemos múltiples
funciones consumiendo una BD relacional puede ser que la
cantidad de conexiones se caiga. Entonces para la DB relacional los
CP están sacando un PROXY de BD. Estos servicios se encargan de
todas las conexiones entre cada FUNCIÓN y la DB. Van a manejar el
borrowing (pedir prestado canales de conexión). También,
garantizan que si se cae el DB Master, solo se pierda un paquete
para cuando empiece a funcionar la DB Standby.
Entonces, las ventajas del PROXY son: 1) seguridad: garantiza que
la comunicación siempre sea en TLS. 2) gestión de conexiones 3)
mejorar el tiempo de un failover ante una caída de una zona, por
ejemplo.
 ORQUESTADOR DE FUNCIONES: se encarga de las relaciones entre
funciones. Ejemplo de orquestador: en AWS (step Functions),
Apache Airflow se usa como orquestador.
 ESCALABILIDAD: va a estar dada por los límites de CP. También
podemos reservar concurrencia. Por ejemplo: en AWS para todas
las funciones la concurrencia es de 1000 ejecuciones por segundo.
Entonces en PlatziWallet se puede reservar 200 concurrencias por
segundo para las funciones de Pagos y Consulta de Saldo. Es decir
400 concurrencias por segundo para mis funciones más
demandadas. Los otros 600 se van a distribuir a medida de que
cada uno de los servicios los vaya utilizando. Por otro lado también
se puede hacer un ticket al CP para subir la concurrencia de 1000 a
2000 por ejemplo.
 REPO y CICD: hay que ver cómo vamos a desplegar del CICD a la
función.
 VPC: ¿La función va a correr en una VPC o no? Si es en una VPC hay
que tener en cuenta la cantidad de direcciones IP disponibles
versus la cantidad de ejecuciones que va a tener esa función para
garantizar que tenga IP disponibles.
 COLD START: Si la APP no soporta esos segundos iniciales de las
funciones podemos pensar en una arquitectura dividida donde
tengamos unos servicios en funciones y otros en contenedores.
Pues Kubernetes, por ejemplo, no tiene esos segundos iniciales de
demora.