Aplicaciones móviles super-escalables
•Descargar como PPTX, PDF•
2 recomendaciones•556 vistas
El documento describe los desafíos del desarrollo de aplicaciones móviles a gran escala, incluyendo la diversidad de dispositivos, actualizaciones frecuentes de sistemas operativos y nuevas capacidades de hardware. También discute cómo la nube puede ayudar mediante servicios como Azure para proporcionar infraestructura elástica y cómo los microservicios y Service Fabric de Microsoft permiten construir aplicaciones escalables.
Recomendados
Recomendados
Más contenido relacionado
Similar a Aplicaciones móviles super-escalables
Similar a Aplicaciones móviles super-escalables (20)
Último
Último (10)
Aplicaciones móviles super-escalables
- 1. Aplicaciones móviles super- escalables Sergio A. Borromei Cowboy Coder sergiob@lagash.com NickA. Rivas Psycho Code Reviewer nickr@lagash.com
- 4. Embrace the challengelagash.com 2014: Los usuarios móviles superan a los usuarios de escritorio
- 5. Embrace the challengelagash.com Crecimiento en el uso mobile
- 6. Embrace the challengelagash.com El desarrollo móvil... • Diversidad de dispositivos y plataformas • Muchas actualizaciones de SO • Nuevas capacidades de hardware
- 7. Embrace the challengelagash.com Tus usuarios son expertos (muy)
- 8. Embrace the challengelagash.com Desafíos... • Runtime de servicios de backend • Integrar datos y procesos de diversas fuentes • Brindar continuidad de servicio (24x7) • Capacidad de crecer elásticamente • Delivery continuo • Monitoreo proactivo de la plataforma • MILLONES DE REQUESTS!!!
- 9. lagash.com Como afecta esto a la forma en que diseñamos nuestras aplicaciones?
- 10. User Interface APIs Runtime Identity Notifications Database Cache Search Media Storage Networking
- 16. lagash.com La nube al rescate...
- 17. Embrace the challengelagash.com Infraestructura Como Servicio (IaaS) Como accedo a los datos? Donde guardo los datos? Como resuelvo la transversalidad?
- 18. Embrace the challengelagash.com Mobile Backend As A Service (MBaaS) On Premises / Private Cloud / Public Cloud Microsoft Azure App Service Active Directory App Insights Notifications Hubs Media Services Service Bus Azure Search DocumentDB SQL Database
- 19. App Service • “Runtime” para ejecutar aplicaciones en la nube • Escala automáticamente (dependiendo del App Service Plan) • Deployment slots • Integración continua • GitHub / Git / VSTS / Bitbucket / Dropbox • Varios “sabores” • API App • Mobile App • Web App
- 20. Notification Hubs • Servicio para enviar notificaciones “Push” a dispositivos • Broadcast a los principales proveedores • Apple APNS, Google GCM, Windows WNS, Windows Phone MPNS, Amazon ADM, Baidu (Android China) • Una sola API / SDK para dominarlos a todos
- 21. Media Services • Servicios para encoding y streaming de video • Jobs automáticos de encoding para varias resoluciones y dispositivos • Endpoints para reproducción • Live streaming
- 22. DocumentDB • Base de datos NoSQL • Compatible a nivel API / funcionalidad con MongoDB • Soporta colecciones “particionadas” • Prácticamente no tiene límites de escalabilidad
- 23. Azure Search • Servicio de indexación y búsqueda de documents • Permite búsquedas por filtros, facetas, tags y ordenamientos • Se conecta con “DocumentDb” • Prácticamente no tiene límites de escalabilidad
- 24. App Service #1 App Service #2 App Service #3 App Service #4 App Service #5 App Service #6 Partitioned collection 10000 RU/s Partitioned collection 5000 RU/s Single collection 1500 RU/s 2 Replicas x 2 Partitions 10 reserved S1 processing units 10M Pushes 10M Devices
- 27. lagash.com Que es un Microservicio?
- 29. Desarrollado y operado por un equipo pequeño
- 30. Desarrollado en cualquier lenguaje o framework
- 32. Posee una dirección única para ubicarlo en la red (URI)
- 33. Tolerante a fallos y escalable
- 34. Expone interfaces e interactúa mediante protocolos definidos
- 35. Embrace the challengelagash.com My App Cluster #1 Cluster #2 Cluster #3
- 36. Embrace the challengelagash.com My App Cluster #1 Cluster #2 Cluster #3
- 37. Embrace the challengelagash.com High Density Computing
- 38. lagash.com Como administrar & gobernar mis apps de microservicios?
- 39. Embrace the challengelagash.com Stacks de microservicios Azure App Service Docker Container Cloud based stack Cloud & On Premises Azure Service Fabric
- 40. Embrace the challengelagash.com VM vs. Docker
- 43. Embrace the challengelagash.com Service Fabric: una plataforma para microservicios hyper-escalables y confiables Azure Windows Server Linux Hosted Clouds Windows Server Linux Service Fabric Private Clouds Windows Server Linux High Availability Hyper-Scale Hybrid Operations High Density Microservices Rolling Upgrades Stateful services Low Latency Fast startup & shutdown Container Orchestration & lifecycle management Replication & Failover Simple programming models Load balancing Self-healingData Partitioning Automated Rollback Health Monitoring Placement Constraints
- 45. Embrace the challengelagash.com Service Fabric Programming Models Reliable Actors APIReliable Services API Azure Private Clouds Applications composed of microservices High Availability Hyper-Scale Hybrid Operations High Density Rolling Upgrades Stateful services Low Latency Fast startup & shutdown Container Orchestration & lifecycle management Replication & Failover Simple programming models Load balancing Self-healingData Partitioning Automated Rollback Health Monitoring Placement Constraints Service Fabric
- 46. Collections • Single machine • Single threaded Concurrent Collections • Single machine • Multi threaded Reliable Collections • Multi machine • Multi threaded • Replicated (HA) • Persistence • Asynchronous • Transactional
- 48. P2 S S S P4 S P1 S S P3 S S S S Node 100 S Node 101 Node 102 Node 103 Node 104 Node 105
- 49. Service Description Azure Database Scale-out relational database Azure DocumentDB No-SQL store for JSON documents Integrated with O365 Azure Power BI BI Pro Data Analysis Services Azure Networking Regional Network Manager (RNM) for cross cluster/DC VNET Azure Compute and Networking Resource Providers for Compute (CRP), Networking (NRP), Storage (SRP) Event Hubs Streaming messaging and event processing Service Bus Service Bus Resource Provider (SBRP) Intune Unified management of PCs and devices on the cloud. Bing Cortana Personal assistant Cinco años en producción Mismo código utilizado por estos servicios
- 50. Ultimate Control Rapid Development VMs / VM Scale Sets VM Extensions Service Fabric Web Apps/ App Service IaaS PaaS
- 52. Argentina | Buenos Aires +54 (11) 4982 4185 info@lagash.com Chile | Santiago de Chile +56 (2) 2231 9428 info_chile@lagash.com Colombia | Bogotá +57 (1) 750 5276 info_colombia@lagash.com México | México DF +52 (55) 6394 0617 info_mexico@lagash.com USA | Seattle - US +1 844 4 Lagash infousa@lagash.com Uruguay | Montevideo +598 2623 2546 info_uy@lagash.com Let’s keep in touch
Notas del editor
- The mobile statistics that the team at Smart Insights curate in the regular updates to this article include: Ownership of smartphone vs Desktop Mobile vs desktop media and website use Mobile advertising response Smartphone vs Tablet vs Desktop conversion rates Well, we're now past the mobile Tipping Point as this report from comScore shows. So it's no longer a case of asking whether mobile marketing important, we know it is! It's now a question of using the statistics to understand how consumers behave when using different types of mobile devices and what their preferences are.
- Todos los años hay versiones nuevas de iOS y Android Cada dispositivo nuevo requiere considerar nuevas funcionalidades y capacidades Frecuentemente los cambios ocurren durante el desarrollo Hay que mantener compatibilidad con la base instalada Las aplicaciones mas exitosas se actualizan frecuntemente.
- Los usuarios esperan experiencias similares a las que ofrecen apps de consumo masivo como Facebook, Instagram, Whatsapp o Youtube Algo que no funciona “como debería” se transforma automáticamente en un defecto La falta de funcionalidad es fuente de frecuentes quejas y malos “ratings” La seguridad es una preocupación crucial de los usuarios para el uso de las aplicaciones Always-on: una aplicación con cortes de servicio frecuentes no es tolerada
- Resumiendo, los aspectos a tener en cuenta para para generar una experiencia digital consistente atraviesan las diferentes áreas de la organización, desde procesos cercanos a los usuarios y el negocio, como el diseño de las funcionalidades, hasta cuestiones mas duras como la escalabilidad o la protección de datos. Lo importante a entender es que, hoy mas que nunca todos, estos aspectos están relacionados y no pueden ser tratados en forma desconectada. Lograr la coordinación de todos estos aspectos implica una profunda transformación respecto del enfoque con el cual las empresas piensan su cadena de valor.
- Por décadas, el costo, tiempo y complejidad de provisionar hardware (físico o virtual) a influenciado el desarrollo de aplicaciones. Estos factores son mas influyentes cuando esas aplicaciones son de misión crítica, dado que un uptime elevado requiere infraestructura de alta disponibilidad, incluso hardware muy costoso como SANs y balanceadores de carga. Aún cuando las aplicaciones son descompuestas para minimizar los requerimientos de hardware y ofrecer cierto nivel de agilidad y escalabilidad independiente, esto es realizado bajo el modelo clásico de “N-hileras o niveles (tiers)”. Este enfoque sigue siendo válido y utilizado en muchos escenarios, sobre todo en aplicaciones con demandas de escalabilidad limitada. No obstante, en aplicaciones de gran escala con millones de requests y usuarios, se evidencian limitaciones que requieren un cambio de paradigma.
- Desde el punto de vista de despliegue, este tipo de aplicaciones son monolíticas. Principalmente porque incorporar la nueva funcionalidad implica el despliegue de la aplicación completa sobre un hardware pre-dimensionado para una carga específica. La primer limitación que nos encontramos con esta arquitectura es que cuando, debido a la carga, se llega al límite de operación del hardware, típicamente la respuesta es “escalar horizontalmente (agregar mas servidores a un tier) y/o verticalmente (agregar mas recursos a un servidor)”. Estas reconfiguraciones de infraestructura frecuentemente resultan complejas, sobre todo cuando implican modificaciones en hardware real. Y si bien la virtualización ha ayudado a mitigar varias limitaciones, la realidad es que cuando en la escala de millones de usuarios, aún resulta muy complejo lidiar con peaks de carga muy variables. Crear 10 o 20 servers con la aplicación completamente instalada, configurada y funcionando no es algo trivial y puede demandar mucho tiempo y esfuerzo. Así mismo, actualizar una nueva versión del monolito sobre una infraestructura replicada N-veces, también implica un esfuerzo y desafío muy grande. Seguramente, la aplicación debió ser instalada y testeada previamente en una infraestructura paralela (ambiente UAT), con lo cual el esfuerzo de instalación se multiplica. El resultado es la pérdida de agilidad, no solo para implementar nuevas versiones, sino además para modificar o adaptar la infraestructura a una demanda variable.
- La segunda limitante tiene que ver con que no es posible aislar componentes que tienen mucho uso de recursos de otros componentes, con lo cual al escalar horizontalmente La tercer limitante tiene que ver con el manejo de las interdependencias entre componentes y que típicamente las aplicaciones monolíticas comparten un gran modelo de datos. Imaginemos que estamos agregando una nueva funcionalidad que requiere modificar algunas tablas en la base de datos, agregar algunas clases nuevas y exponerlas al mundo como Web APIs. Actualizar una nueva versión del monolito sobre una infraestructura replicada N-veces, también implica un esfuerzo y desafío muy grande. Seguramente, la aplicación debió ser instalada y testeada previamente en una infraestructura paralela (ambiente UAT), con lo cual el esfuerzo de instalación se multiplica. El resultado es la pérdida de agilidad, no solo para implementar nuevas versiones, sino además para modificar o adaptar la infraestructura a una demanda variable. Las consecuencias redundan en: Complejidad crece al ritmo de cada nueva funcionalidad Dificultad para recrear condiciones de ejecución reales (producción) Pérdida de libertad para modificar piezas existentes Tiempo de desarrollo y testing se incrementa exponencialmente Se requiere mayor interacción humana (mas reuniones, mas definiciones, mas documentación...)
- La segunda limitante tiene que ver con que no es posible aislar componentes que tienen mucho uso de recursos de otros componentes, con lo cual al escalar horizontalmente La tercer limitante tiene que ver con el manejo de las interdependencias entre componentes y que típicamente las aplicaciones monolíticas comparten un gran modelo de datos. Imaginemos que estamos agregando una nueva funcionalidad que requiere modificar algunas tablas en la base de datos, agregar algunas clases nuevas y exponerlas al mundo como Web APIs. Actualizar una nueva versión del monolito sobre una infraestructura replicada N-veces, también implica un esfuerzo y desafío muy grande. Seguramente, la aplicación debió ser instalada y testeada previamente en una infraestructura paralela (ambiente UAT), con lo cual el esfuerzo de instalación se multiplica. El resultado es la pérdida de agilidad, no solo para implementar nuevas versiones, sino además para modificar o adaptar la infraestructura a una demanda variable. Las consecuencias redundan en: Complejidad crece al ritmo de cada nueva funcionalidad Dificultad para recrear condiciones de ejecución reales (producción) Pérdida de libertad para modificar piezas existentes Tiempo de desarrollo y testing se incrementa exponencialmente Se requiere mayor interacción humana (mas reuniones, mas definiciones, mas documentación...)
- - Todos estos servicios pueden ser
- Los apps services pueden ser Windows o Linux Puedo usar .NET o el lenguaje o framework que mas me guste Node, Ruby,
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Una entidad de software + (opcional) datos durables y que encapsula un escenario de negocios Desarrollado y operado por un equipo pequeño Escrito en cualquier lenguaje de programación y usando cualquier framework Su versionamiento, despliegue y escalablidad es independiente Interactúa con otros servicios mediante una interfaz y protocolos bien definidos Tienen un nombre único para resolver su locación Son tolerantes a fallas
- Cualquier interacción con otro microservicio se asume que puede fallar y esta es una situación que la aplicación debe atender. Si un microservicio depende fuertemente de otro para funcionar, probablemente se deba reconsiderar el diseño.
- Cada “set”de VMs puede escalar horizontalmente. Ese necesario un sistema de “clusterizacion” que realice esto automáticamente y que