Aplicaciones pensadas para la nube

Qué tenemos que tener en cuenta para desarrollar aplicaciones que sean aptas para la nube

Transcript

1. APLICACIONES PENSADAS PARA LA NUBE APLICACIONES PENSADAS PARA LA NUBE Esta obra está bajo una . Lic. Christian A. Rodríguez Licencia Creative Commons Atribución 4.0 Internacional
2. TEMARIO TEMARIO Clasificación de la infraestructura Cloud Computing Escalabilidad The Twelve-Factor App APIs Herramientas
3. CLASIFICACIÓN DE LA CLASIFICACIÓN DE LA INFRAESTRUCTURA INFRAESTRUCTURA
4. TIPO DE SERVIDORES TIPO 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ÍSICOS SERVIDORES 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: PROBLEMAS SERVIDORES 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ÓN VIRTUALIZACIÓ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ÓN TIPOS 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ÓN TIPOS 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 VIRTUALES SERVIDORES VIRTUALES Concepto de virtualización de un servidor
11. SERVIDORES VIRTUALES SERVIDORES VIRTUALES Clasificaciones del tipo de virtualización de un servidor
12. PRODUCTOS DE VIRTUALIZACIÓN TOTAL PRODUCTOS 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ÓN PARAVIRTUALIZACIÓ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 SO VIRTUALIZACIÓ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 COMPUTING CLOUD COMPUTING
16. CLOUD COMPUTING CLOUD 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 CC CARACTERÍ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 CC CLASIFICACIÓ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 CC CLASIFICACIÓ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 CC CLASIFICACIÓ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 CC EJEMPLOS 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. ESCALABILIDAD ESCALABILIDAD
23. ESCALABILIDAD ESCALABILIDAD ¿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 ESCALAMIENTO TIPOS 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 RELACIONADOS CONCEPTOS RELACIONADOS Instancias descartables Healthchecks y auto-healing Caching
28. THE TWELVE-FACTOR APP THE TWELVE-FACTOR APP
29. THE TWELVE-FACTOR APP THE 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 APP THE 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ÓN INTRODUCCIÓ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 FUENTE I - 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 - DEPENDENCIAS II - 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ÓN III - 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 SERVICES IV - 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, EJECUTAR V - 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, EJECUTAR V - 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 - PROCESOS VI - 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 - PROCESOS VI - 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 PUERTOS VII - 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 - CONCURRENCIA VIII - 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 - CONCURRENCIA VIII - 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 - CONCURRENCIA VIII - 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 - DESECHABILIDAD IX - 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 OPS X - 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 OPS X - 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 - LOGS XI - 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ÓN XII - 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. APIS APIS
50. CONSIDERACIONES PARA DESARROLLAR CONSIDERACIONES PARA DESARROLLAR APIS APIS 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 APIS SEGURIDAD 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. MICROSERVICIOS MICROSERVICIOS No confundir API monolítica con microservicios Con microservicios aparecen nuevos problemas: Tracing Transacciones distribuidas Leer más de microservicios acá
53. HERRAMIENTAS HERRAMIENTAS
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. ALTERNATIVAS ALTERNATIVAS Docker: ventajas Swarm K8S Modelo y precios Serverless / FaaS: Modelo y precios Amazon Lambda / Google Functions / Azure Functions / Kubeless Serverless framework
56. EJEMPLO EJEMPLO VIDEO ON DEMAND USANDO AWS VIDEO ON DEMAND USANDO AWS Basado en serverless