Qué hay que tener en cuenta cuando desarrollamos aplicaciones aptas para la nube

1. APLICACIONES PENSADAS PARA LA NUBEAPLICACIONES PENSADAS PARA LA NUBE
Esta obra está bajo una .
Lic. Christian A. Rodríguez
Licencia Creative Commons Atribución 4.0 Internacional

2. TEMARIOTEMARIO
Clasificación de la infraestructura
Cloud Computing
Escalabilidad
The Twelve-Factor App
APIs
Herramientas

3. CLASIFICACIÓN DE LACLASIFICACIÓN DE LA
INFRAESTRUCTURAINFRAESTRUCTURA

4. TIPO DE SERVIDORESTIPO DE SERVIDORES
Servidores físicos
Problemas
Virtualización
Tipos de virtualización
Servidores virtuales
Virtualización total
Paravirtualización
Virtualización a nivel del SO

5. SERVIDORES FÍSICOSSERVIDORES FÍSICOS
Servidor dedicado
No pueden compartirse por diferentes clientes
Toda la carga que realiza será para un único cliente
Puede utilizarse por varios usuarios simultáneamente, pero
todos de un mismo cliente
Controlables y monitorizables a través de
Monitoreo de temperatura, voltage, ventilación, fuentes,
chasis, etc
Acceso a log de eventos / Ciclo de apagado, encendido, reincio
/ Acceso al BIOS / Instalación remota
IPMI

6. SERVIDORES FÍSICOS: PROBLEMASSERVIDORES FÍSICOS: PROBLEMAS
Subejecución de recursos. Se considera que menos del 20% de la
capacidad del servidor puede utilizarse por un servicio estándar.
Un único sistema operativo por servidor.
Un mismo servidor con diferentes servicios podría aprovechar
mejor los recursos.
Compromiso de seguridad.
Alta cohesión.
Replicar uno o todos los servicios para realizar pruebas requiere
otro servidor físico o virtual.

7. VIRTUALIZACIÓNVIRTUALIZACIÓN
La virtualización es una abstracción de recursos
computacionales.
No únicamente de servidores.
Maximiza el uso del recursos físicos, minimizando la cantidad de
ellos.
Simplifica el aprovisionamiento.
Proveen APIs que simplifican tareas de automatización
habituales en un datacenter.

8. TIPOS DE VIRTUALIZACIÓNTIPOS DE VIRTUALIZACIÓN
Infraestructura:
Red: VPN, VLAN, virtualización de routers, forewalls,
segmentos, direccionamiento IP, etc.
Storage: LVM, RAID, NAS (NFS/CIFS), SAN (iSCSI)
Servidores: uno o más máquinas virtuales en un mismo servidor
físico.
Virtualización total
Paravirtualización
Virtualización del SO

9. TIPOS DE VIRTUALIZACIÓNTIPOS DE VIRTUALIZACIÓN
Aplicaciones: aplica a conceptos muy diferentes entre sí
Thinclients: Citrix, Terminal Services
Wine
Lenguajes de alto nivel como por ejemplo JVM y CLR

10. SERVIDORES VIRTUALESSERVIDORES VIRTUALES
Concepto de virtualización de un servidor

11. SERVIDORES VIRTUALESSERVIDORES VIRTUALES
Clasificaciones del tipo de virtualización de un servidor

12. PRODUCTOS DE VIRTUALIZACIÓN TOTALPRODUCTOS DE VIRTUALIZACIÓN TOTAL
Asistidos por SW: VMWare Workstation (32bits guests) / Microso
Virtual PC / Oracle VirtualBox (32-bit guests)
Asistidos por HW:
Hypervisor de Tipo I: VMWare ESXi/ESX / KVM / Microso
Hyper-V / Citrix XenServer
Hypervisor de Tipo II: VMWare Workstation (64 bits guests
only) / Oracle VirtualBox (64 bits guests only)

13. PARAVIRTUALIZACIÓNPARAVIRTUALIZACIÓN
No necesita simular el HW para las máquinas virtuales: el
Hypervisor se instala en un servidor físico, llamado host.
Los guests virtuales tienen conocimiento de encontrarse
virtualizados a diferencia de la virtualización total.
El SO guest requiere ser modificado para comunicarse con el
host y realizar llamadas al hypervisor como si fuesen system
calls.
Ejemplos: Citrix XenServer / IBM LPAR (usado por algunos
mainframes y Linux zSeries), Oracle VM for Sparc (LDOM)

14. VIRTUALIZACIÓN A NIVEL DEL SOVIRTUALIZACIÓN A NIVEL DEL SO
También conocida como contenerización
El SO instalado en el host permite manejar múltiples espacios de
usuario, procesos y recursos.
Existe un pequeño o inexistente overhead por utilizar el kernel
del SO anfitrión para su ejecución.
Ejemplos: Oracle Solaris Zones / Docker / Linux LXC

15. CLOUD COMPUTINGCLOUD COMPUTING

16. CLOUD COMPUTINGCLOUD COMPUTING
Características de CC
Clasificación de servicios de CC
Clasificación de servicios emergentes de CC
Ejemplos por tipo de CC

17. CARACTERÍSTICAS DE CCCARACTERÍSTICAS DE CC
Diferencia marcada entre el negocio y las herramientas
necesarias para el negocio (Distribuir contenido multimedia es el
negocio)
Los clientes se enfocan en sus proyectos. Los proveedores de
servicio se encargan del resto.
Según el las principales características de CC son:
Auto gestión por demanda
Amplio acceso por medio de la red
Pool de recursos multitenant
Simple elasticidad
NIST

18. CLASIFICACIÓN DE SERVICIOS DE CCCLASIFICACIÓN DE SERVICIOS DE CC
SaaS: un servicio desarrollado, desplegado, corrido y mantenido
por el proveedor, y que es accedido por web. El cliente utiliza el
producto, sin interactuar con la infraestructura que provee el
servicio.
PaaS: un servicio que provee una plataforma de desarrollo y
despliegue de aplicaciones web. El cliente no tiene control sobre
la infraestructura, pero sí accede a los recursos que son
administrados a través de APIs.
IaaS: ofrecen utilidades y herramientas que permiten gestionar
storage, vms, redes y otros recursos básicos. No se tiene aceso
físico al HW.

19. CLASIFICACIÓN DE SERVICIOS DE CCCLASIFICACIÓN DE SERVICIOS DE CC
On premises: es un servicio de CC hosteado en máquinas que
pertenecen a un mismo cliente. El cliente ofrece a su empresa
servicios privados de SaaS, PaaS, IaaS

20. CLASIFICACIÓN DE SERVICIOS EMERGENTES DE CCCLASIFICACIÓN DE SERVICIOS EMERGENTES DE CC
FaaS: un servicio que provee una plataforma donde desarrollar,
correr y desplegar funciones sin la complejidad de construir y
mantener la infraestructura asociada con el servicio de una
aplicación.
Este modelo se corresponde con una arquitectura Serverless
empleada en microservicios.
CaaS: un servicio intermedio entre IaaS y PaaS. Se ofrece un
servicio que independiza los motores de contenedores
( / / ), su orquestación y recursos.docker rkt lxc

21. EJEMPLOS POR TIPO DE CCEJEMPLOS POR TIPO DE CC
SaaS: Gmail, Google Office, Dropbox.
PaaS: , , .
IaaS: , , , .
FaaS: , , ,
, .
CaaS: , , , .
Heroku Google AppEngine AWS Beanstalk
Digital Ocean Droplets AWS EC2 GCE Azure
AWS Lambda Google Functions Azure Functions
Kubeless Open FaaS
AWS ECS AWS EKS GKE AKS

22. ESCALABILIDADESCALABILIDAD

23. ESCALABILIDADESCALABILIDAD
¿Qué significa?
Tipos de escalamiento
¿Cualquier aplicación escala?
Conceptos relacionados con escalabilidad

24. ¿QUÉ SIGNIFICA?¿QUÉ SIGNIFICA?
El escalamiento nos permite ajustar la capacidad de un recurso
cambiando su escala.
Se escala para crecer o decrecer, según sea la necesidad del recurso
en cuestión.
Pareciera que la única necesidad es la de crecer.

25. TIPOS DE ESCALAMIENTOTIPOS DE ESCALAMIENTO
Escalamiento vertical: consiste en aumentar los recursos.
Paradójicamente, no escala en grandes magnitudes.
X-scaling: replica una aplicación detrás de un load balancer.
Y-scaling: es una aplicación que implementa microservicios.
Z-scaling: particionamiento de datos, sharding. Muy usado en
bases de datos o ejemplo de dovecot / imap proxy
Escalamiento en ejes de un cubo:

26. ¿CUALQUIER APLICACIÓN ESCALA?¿CUALQUIER APLICACIÓN ESCALA?
No
En lenguajes como Java debe tenerse particular cuidado con
patrones como Singleton.
Hay que considerar los recursos utilizados por la aplicación:
Sesiones
Logs
Bases de datos
Assets / Uploads

27. CONCEPTOS RELACIONADOSCONCEPTOS RELACIONADOS
Instancias descartables
Healthchecks y auto-healing
Caching

28. THE TWELVE-FACTOR APPTHE TWELVE-FACTOR APP

29. THE TWELVE-FACTOR APPTHE TWELVE-FACTOR APP
¿Qué es?
I - Código fuente
II - Dependencias
III - Configuración
IV - Backing services
V - Construir, distribuir, ejecutar

30. THE TWELVE-FACTOR APPTHE TWELVE-FACTOR APP
VI - Procesos
VII - Asignación de puertos
VIII - Concurrencia
IX - Desechabilidad
X - Aproximación entre desarrollo y producción
XI - Logs
XII - Procesos de administración

31. INTRODUCCIÓNINTRODUCCIÓN
Esta metodología se enuncia en y describe un
conjunto de prácticas para construir aplicaciones web o SaaS.
https://12factor.net

32. I - CÓDIGO FUENTEI - CÓDIGO FUENTE
La aplicación debe usar un SCM como por ejemplo GIT.
Si hay múltiples repositorios de fuentes, es porque se trata de un
sistema distribuido y no una aplicación. En tal caso, cada
aplicación puede aplicar 12 factor.
Pueden existir mútiples despliegues.
Depende de los ambientes.
Los fuentes son los mismos en todos los despliegues (salvo por
diferencias de versiones).

33. II - DEPENDENCIASII - DEPENDENCIAS
Declarar y aislar dependencias de forma explícita.
Usando Gemfile, Pipfile, package.json (Yarn, Composer),
Gopkg.toml.
Las librerías descargadas por el manejador de dependencias
deben poder instalarse en el sistema o bajo un directorio del
proyecto (vendor).
A veces estas dependencias pueden requerir la instalación de
librerías o comandos en el sistema base.

34. III - CONFIGURACIÓNIII - CONFIGURACIÓN
La configuración de una aplicación es lo único que puede variar
entre despliegues de una misma versión en diferentes
ambientes:
Bases de datos, cachés u otros backing services.
Credenciales para servicios externos tales como Amazon S3,
APIs, etc
Valores propios del despliegue.
Guardar constantes de configuración en el código viola 12 factor.
La configuración varía entre despliegues, no el código.
Se propone utilizar variables de entorno.

35. IV - BACKING SERVICESIV - BACKING SERVICES
Tratar estos servicios como recursos conectables:
Bases de datos (no)SQL
SMTP
Colas como ZeroMQ, RabbitMQ, Celery, ActiveMQ
Deben poder configurarse mediante URLs o variables de entorno
Ser fácilmente reemplazables

36. V - CONSTRUIR, DISTRIBUIR, EJECUTARV - CONSTRUIR, DISTRIBUIR, EJECUTAR
Separar siempre la etapa de construcción de ejecución.
Los fuentes se transforman en un despliegue al completarse las
etapas de:
Construcción: compilación del código en binarios ejecutables
o intermedios.
No aplica a lenguajes interpretados. Sí para docker.
Distribución: preparado de un paquete listo para ser
desplegado.
Ejecución: etapa que se instancia luego del despliegue en un
ambiente.

37. V - CONSTRUIR, DISTRIBUIR, EJECUTARV - CONSTRUIR, DISTRIBUIR, EJECUTAR
Las herramientas de despliegue como por ejemplo ,
realizan la distribución en directorios diferentes que son
referenciados con links simbólicos.
La fase de ejecución controla los procesos de la aplicación
funcionales.
Generalmente se delega en algún manejador de procesos
como systemd, upstart, init-scripts, supervisord, etc.
caspitrano

38. VI - PROCESOSVI - PROCESOS
Ejecutar la aplicación como uno o más procesos sin estado.
Los procesos que componen una aplicación 12 factor no tienen
estado y no comparten nada.
Cualquier información que deba persistirse debe utilizar algún
backing service con estado (por ejemplo bases de datos, NFS,
S3).

39. VI - PROCESOSVI - PROCESOS
Los compresores de assets, se recomiendan que se apliquen en la
fase de construcción en vez del momento de ejecución.
Esto responde algunas cuestiones acerca de cómo armar un
Dockerfile.
El uso de sticky sessions asumen que alguna aplicación guarda
datos que no son sin estado, por ejemplo en memoria. Esto viola
12 factor app.
Tratar de usar caches como Memcached o Redis.

40. VII - ASIGNACIÓN DE PUERTOSVII - ASIGNACIÓN DE PUERTOS
Publicar servicios usando puertos diferentes.
Las aplicaciones 12 factor son autocontenidas, esto es, no
dependen de un web server o application server en ejecución
para crear un servicio web público.
Analogía con docker.

41. VIII - CONCURRENCIAVIII - CONCURRENCIA
Escalar mediante el modelo de procesos.
Según el lenguaje, el modelo de proceos varía:
PHP, Ruby y ¿Python? utiliza preforks (no threads). Los últimos
por GIL.
Go y Java explotan el uso de threads.

42. VIII - CONCURRENCIAVIII - CONCURRENCIA
Los modelos de proceos muestran su potencial a la hora de
escalar.
Al ser cualquier 12 factor app, una aplicación que no comparte
nada, y sin estado, el escalamiento horizontal es simple y
confiable.
Los procesos nunca deberían ser daemons.
Deben correr en foreground.
Don't daemonize your daemons!

43. VIII - CONCURRENCIAVIII - CONCURRENCIA
Cuando una aplicación debe atender proceos lentos, es
aconsejable utilizar threads. Cuando esto no es posible, se aconseja
utilizar procesos fuera de banda como es el caso de:
EventMachine / Sidekiq
Twsited / Celery
NodeJS

44. IX - DESECHABILIDADIX - DESECHABILIDAD
Si los sistemas inician rápido y su muerte (kill) es segura, el
sistema se vuelve robusto.
Los procesos de una aplicación 12 factor debe ser desechable.

45. X - APROXIMACIÓN ENTRE DEV Y OPSX - APROXIMACIÓN ENTRE DEV Y OPS
Mantener todos los ambientes lo más similares que sea posible.
Evitar las diferencias de ambientes considerando:
Diferencias de tiempo: evitar que el desarrollo de un feature
no se suba al repositorio de fuentes en períodos largos de
tiempo.
Diferencias de personal:el despliegue lo hacen operadores y
lo desarrollan programadores. Unificar roles.
Diferencias de herramientas: producción usa Postgres y
desarrollo SQLite.

46. X - APROXIMACIÓN ENTRE DEV Y OPSX - APROXIMACIÓN ENTRE DEV Y OPS
Las aplicaciones 12 factor deben estar preparadas para realizar
despliegues continuo.
Hoy utilizar backing services en desarrollo se simplifica con
herramientas como docker-compose o vagrant.

47. XI - LOGSXI - LOGS
Una aplicación 12 factor nunca se preocupa del direccionamiento,
almacenamiento o rotación de logs.
En general debe escribir los logs en stdout.

48. XII - PROCESOS DE ADMINISTRACIÓNXII - PROCESOS DE ADMINISTRACIÓN
Hace mención a tareas de gestión de la aplicación:
Correr migraciones de la base de datos.
Aplicar algún parche.
Iniciar una consola REPL.
Estas tareas deben ejecutarse en un entorno similar al que
ejecuta la aplicación habitualmente.

49. APISAPIS

50. CONSIDERACIONES PARA DESARROLLARCONSIDERACIONES PARA DESARROLLAR
APISAPIS
Respetar estandarizaciones como
Los estándares se apegan a implementar una API RESTful
Hypermedia (HATEOAS: Hypermedia as the Engine of
Application State)
Ayudarse de herramientas como
OpenAPI
Swagger

51. SEGURIDAD DE LAS APISSEGURIDAD DE LAS APIS
Autorización de servicios:
No es autenticación, sólo autorización
Flujos de OAuth2: Implicit Flow, Authorization Code (+PKCE)
Barear tokens: The name “Bearer authentication” can be
understood as “give access to the bearer of this token.”
Autenticación basada en .
Capa de identidad por sobre OAuth2
API gateways: conceptos
OAuth2
OIDC

52. MICROSERVICIOSMICROSERVICIOS
No confundir API monolítica con microservicios
Con microservicios aparecen nuevos problemas:
Tracing
Transacciones distribuidas
Leer más de microservicios acá

53. HERRAMIENTASHERRAMIENTAS

54. ¿POR QUÉ ELEGIR UNA U OTRA¿POR QUÉ ELEGIR UNA U OTRA
HERRAMIENTA?HERRAMIENTA?
En general se piensan las aplicaciones sin considerar la
infraestructura (IDD), mientras que si se desarrollara considerando
herramientas de infraestructura para tomar decisiones durante el
desarrollo (DDI), entonces ahorraríamos dinero.

55. ALTERNATIVASALTERNATIVAS
Docker: ventajas
Swarm
K8S
Modelo y precios
Serverless / FaaS:
Modelo y precios
Amazon Lambda / Google Functions / Azure Functions /
Kubeless
Serverless framework

56. EJEMPLOEJEMPLO
VIDEO ON DEMAND USANDO AWSVIDEO ON DEMAND USANDO AWS
Basado en serverless