Uso de Containers y Serverless para acelerar el desarrollo de aplicaciones modernas
•Descargar como PPTX, PDF•
1 recomendación•197 vistas
Los microservicios proponen un abordaje tanto de arquitectura como organizacional en el desarrollo de software para acelerar los ciclos de implementación, fomentar la innovación, y mejorar la capacidad de mantenimiento y escalabilidad de las aplicaciones en nuestras organizaciones. En esta sesión, compartiremos el uso de Containers y Serverless para acelerar nuestras implementaciones y comenzar nuestro viaje para modernizar nuestras aplicaciones, compartiendo las mejores prácticas para el desarrollo y despliegue de Serverless y Containers.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Uso de Containers y Serverless para acelerar el desarrollo de aplicaciones modernas
Similar a Uso de Containers y Serverless para acelerar el desarrollo de aplicaciones modernas (20)
Más de Amazon Web Services LATAM
Más de Amazon Web Services LATAM (20)
Último
Último (19)
Uso de Containers y Serverless para acelerar el desarrollo de aplicaciones modernas
- 1. © 2020, Amazon Web Services, Inc. or its Affiliates. Javier Cristancho Sr. Solutions Architect Amazon Web Services 2020 Uso de contenedores y serverless para acelerar el desarrollo de aplicaciones modernas
- 2. © 2020, Amazon Web Services, Inc. or its Affiliates. Agenda Despliegue de Software Modelo Operativo Patrones de Arquitectura
- 3. © 2020, Amazon Web Services, Inc. or its Affiliates. Agilidad con two-pizza teams Plena propiedad y autonomía Lo construyes, lo ejecutas Innovación enfocada
- 4. © 2020, Amazon Web Services, Inc. or its Affiliates. Valor de los bloques de construcción Reducir trabajo en resolver problemas comunes Encontrar respuestas innovadoras a problemas duros Exponiendo las mejores prácticas
- 5. © 2020, Amazon Web Services, Inc. or its Affiliates. Construyendo aplicaciones modernas Despliegue de software Modelo Operativo Patrones de Despliegue
- 6. © 2020, Amazon Web Services, Inc. or its Affiliates. Despliegue de Software
- 7. © 2020, Amazon Web Services, Inc. or its Affiliates. Pipeline por equipo Crear la Aplicación Prueba unitaria Despliegue de artefactos Prueba de integración Push
- 8. © 2020, Amazon Web Services, Inc. or its Affiliates. Despliegue Automatizado Crear la app Prueba unitaria Push Monitorear/métricas SNS Despliegue canario Servicio canario Servicio primario Ingress Servicio canario Servicio primarioServicio primarioServicio primario Despliegue controlador Artefacto Integrar
- 9. © 2020, Amazon Web Services, Inc. or its Affiliates. Infraestructura y aplicación Recursos en la nube y aplicación Proceso común de revisión de código Desplegado como paquete
- 10. © 2020, Amazon Web Services, Inc. or its Affiliates. Modelo operativo
- 11. © 2020, Amazon Web Services, Inc. or its Affiliates. ¿Qué quieren nuestros clientes ? Construir aplicaciones, no infraestructura Escalar rápidamente y sin problemas Seguridad y aislamiento por diseño
- 12. © 2020, Amazon Web Services, Inc. or its Affiliates. Modelos de responsabilidad operacional de AWS Compute Virtual máquina Amazon EC2 AWS Elastic Beanstalk AWS LambdaAWS Fargate Bases de datos MySQL MySQL en Amazon EC2 Amazon RDS para MySQL Amazon RDS Amazon Aurora Amazon DynamoDB Almacenamiento Almacenamiento Amazon S3 Mensajería ESBs Amazon MQ Amazon Kinesis Amazon SQS/Amazon SNS Analítica Hadoop Hadoop en EC2 Amazon EMR Amazon ES Amazon Athena On-premises Nube Menos Más
- 13. © 2020, Amazon Web Services, Inc. or its Affiliates. Los sistemas de gestión de clúster agregan complejidad accidental
- 14. © 2020, Amazon Web Services, Inc. or its Affiliates. Complejidad esencial y accidental A B BA Complejidad esencial Complejidad accidental
- 15. © 2020, Amazon Web Services, Inc. or its Affiliates. Aplicación debe guiar infraestructura
- 16. © 2020, Amazon Web Services, Inc. or its Affiliates. Foco en la Aplicación con “Capacity Providers”de Amazon ECS Clúster Clúster A B EC2 Spot 100% EC2 on-demand 100% A B Fargate Spot 70% EC2 on-demand 60% EC2 Spot 40% Fargate 30%
- 17. © 2020, Amazon Web Services, Inc. or its Affiliates. ECS/Fargate soporte para Amazon EFS Clúster A B Fargate Spot 70% EC2 on-demand 60% EC2 Spot 40% Fargate 30% Sistema de archivos de Amazon Elastic (Amazon EFS)
- 18. © 2020, Amazon Web Services, Inc. or its Affiliates. Traer computación serverless a Amazon EKS Beneficios sin servidor de Fargate Mejores prácticas de EKS Extensibilidad de Kubernetes
- 19. © 2020, Amazon Web Services, Inc. or its Affiliates. AWS administra El cliente gestiona Integraciones de fuentes de datos Hardware físico, software, redes, e instalaciones Aprovisionamiento Código de aplicación Orquestación de contenedores, aprovisionamiento Escalado de clústeres Hardware físico, SO host/kernel, redes e instalaciones Código de aplicación Fuente de datos integraciones Config y actualizaciones de Seguridad Config de red Tareas de gestión Orquestación de contenedores plano de control Hardware físico, software, redes e instalaciones Código de aplicación Integraciones de fuentes de datos Clusters de trabajo Config y actualizaciones de seguridad, config de red, firewall, tareas de administración Hardware físico, software, redes e instalaciones Código de aplicación Integraciones de fuentes de datos Escalado Config y actualizaciones de seguridad Config de red Tareas de gestión Aprovisionamiento, administración, escalado y parches de servidores Operaciones Serverless con Fargate y Lambda AWS Lambda Funciones serverless AWS Fargate Contenedores serverless Amazon ECS/EKS Manejo de contenedores -as-a-service Amazon EC2 Infraestructura-as-as- Servicio Menos Más Simplicidad
- 20. © 2020, Amazon Web Services, Inc. or its Affiliates. Acelerando productividad de desarrollador A medida que te mueves hacia arriba, las capas de simplicidad en AWS, su equipo avanza más rápido
- 21. © 2020, Amazon Web Services, Inc. or its Affiliates. Patrones de arquitectura
- 22. © 2020, Amazon Web Services, Inc. or its Affiliates. Piezas pequeñas, bajo acomplamiento Arquitecturas diseñadas para la nube son formadas por piezas pequeñas, con bajo acoplamiento
- 23. © 2020, Amazon Web Services, Inc. or its Affiliates. API son la puerta de entrada a los microservicios
- 24. © 2020, Amazon Web Services, Inc. or its Affiliates. API son contratos endurecidos API API
- 25. © 2020, Amazon Web Services, Inc. or its Affiliates. Administrar API con API Gateway Función Lambda Función Lambda AWS VPC Monitorización de Amazon CloudWatch Amazon CloudFront Aplicaciones móviles Endpoints en Amazon EC2 Endpoints en tu PCAPI Gateway Cache Sitios web Endpoints regionales de API Internet Servicios Cualquier otro Servicio de AWS Todos los endpoints públicos
- 26. © 2020, Amazon Web Services, Inc. or its Affiliates. API Gateway : Estructura
- 27. © 2020, Amazon Web Services, Inc. or its Affiliates. API Gateway : Estructura
- 28. © 2020, Amazon Web Services, Inc. or its Affiliates. Amazon Cognito: Fully Managed App Identity Built-In UI for Applications SPAWebAndroidiOS Out of the box support for Open Standards SAML OAuth2 OIDC Flexible and Scalable API & SDK Support AWS SDKs IonicVue AngularNode JS React iOS Android MFACompromised Password DB Secure & Available Adaptive Auth 99.9% SLA Google Facebook Amazon Out of the box support for Social Federation Extensible AuthN & AuthZ AWS Lambda Amazon ALB Amazon API Gateway AWS AppSync
- 29. © 2020, Amazon Web Services, Inc. or its Affiliates. Amazon API Gateway - API HTTP Hasta 70% menos costo Latencia 50% menor Autenticación estándar API Gateway
- 30. © 2020, Amazon Web Services, Inc. or its Affiliates. Aplicación Serverless ... comprendida por servicios desacoplados que escalan de forma independiente y desencadenan la ejecución usando eventos
- 31. © 2020, Amazon Web Services, Inc. or its Affiliates. Arquitecturas Orientada a eventos Cliente Móvil IoT Amazon Kinesis Amazon DynamoDB Eventos Step Functions AWS Amazon SQS Amazon SNS Mensajería Step Functions AWS Step Functions AWS AWS Lambda AWS Lambda
- 32. © 2020, Amazon Web Services, Inc. or its Affiliates. Servicio de Notificación Simple de Amazon (Amazon SNS) Conectando fuentes de eventos de AWS Mensajería Queues Pub/sub Sincronización Amazon EventBridge Amazon Simple Servicio de colas (Amazon SQS)
- 33. © 2020, Amazon Web Services, Inc. or its Affiliates. Objetivos AWS Lambda Amazon Kinesis Data Firehose Amazon SNS Ampliando origenes de eventos Integraciones de SaaS Amazon EventBridge Bus de eventos personalizado Bus de eventos SaaS Bus de eventos por defecto
- 34. © 2020, Amazon Web Services, Inc. or its Affiliates. Desarrollando con eventos Amazon EventBridge Presentación Lógica Datos Servidor de aplicaciones Funciones de paso de AWS Amazon SQS Amazon SNS Mensajería Funciones de paso de AWS Funciones de paso de AWS AWS Lambda AWS Lambda Bus de eventos personalizado Bus de eventos SaaS Bus de eventos por defecto
- 35. © 2020, Amazon Web Services, Inc. or its Affiliates. Flujos de datos Amazon DynamoDB Ingerir Flujos de datos Procesamiento de datos Tiempo real Data store Microservicios Desempeño a escala Rápido y flexible Amazon Kinesis Flujos de Datos
- 36. © 2020, Amazon Web Services, Inc. or its Affiliates. Amazon RDS Proxy instancia de MySQL Conexion pooling Pinning de conexión Soporte : Amazon RDS( MYSQL & PostgreSQL Amazon Aurora (MySQL & PostgreSQL) Reintentos automáticos Multiplexación de conexión AWS Lambda Proxy Amazon RDS
- 37. © 2020, Amazon Web Services, Inc. or its Affiliates. Coordinar ejecución de función Seguimiento de estado de datos y ejecución Quitar código redundante
- 38. © 2020, Amazon Web Services, Inc. or its Affiliates. Express Workflows Alto volumen, corta duración Rentable a escala Procesamiento de datos de streaming — ingestión de IoT Soporta más de 100 mil eventos por segundo
- 39. © 2020, Amazon Web Services, Inc. or its Affiliates. Encontrar el éxito UsodeLambda Automatización de TI Transformación de datos Aplicación crítica para el negocio Producción misión crítica Curva de adopción Consideraciones Desarrollo rápido Tiempo para el mercado — agilidad Negocio cambiante
- 40. © 2020, Amazon Web Services, Inc. or its Affiliates. Entregan innovación Agilidad Eficiencia total de costosElasticidad “Nos basamos en AWS Lambda para conseguir nuestra plataforma en el mercado en menos de cuatro semanas. En seis meses, habíamos escalado a 40,000 usuarios sin ejecutar un servidor único.” —A Cloud Guru “Podemos tener un roll commit en producción en literalmente minutos — también ya que proporcionan un montón de opciones de enrutamiento flexibles dinámicamente”. —Pinpoint “Usando aplicaciones sin servidor basadas en Lambda, Resnap puede ejecutar múltiples modelos de aprendizaje automático en un promedio de 600 fotos, lo que da como resultado miles de invocaciones y aún genera un libro fotográfico en un minuto”. —Resnap “Nuestros enfoques basados en servidores nos permiten ofrecer anuncios a las audiencias un 60% más rápido que con los enfoques basados en la instancia”. —Infinia Móvil “Nuestros costos bajaron en más de 25% y nuestro tiempo promedio mensual para completar el procesamiento de datos cayó a 7 segundos, haciendo que el proceso termine 99% más rápido”. —Medios de cambio de velocidad “Usando AWS Lambda y AWS Step Functions, recortamos los tiempos de incorporación de clientes de 20 minutos a 30 segundos y sus 'costos esperados son de $20 USD por 10,000 pedidos'”. —Mercurio
- 41. © 2020, Amazon Web Services, Inc. or its Affiliates. Construyendo aplicaciones modernas Entrega de software Modelo Operativo Patrones de Despliegue
- 42. © 2020, Amazon Web Services, Inc. or its Affiliates. Muchas Gracias ! Javier Cristancho Sr. Solutions Architect Amazon Web Services 2020
Notas del editor
- Vamos a contarles de la agenda de esta presentación
- Re inventando la reuda, todos tenian los mismos problemas, y las mismas soluciones enter equipos por ello salio el tema de building blocks
- 1/ Encontramos que la motivación para invertir en estos bloques constructores variaba un poco - no todos los bloques constructores que ideamos provienen de la misma necesidad. 2/ Hubo casos en los que los equipos estaban replicando tareas sobre problemas bastante comunes, y alguien presentó una propuesta de solución para abstraer el trabajo común. Un ejemplo de un problema tan común es el almacenamiento. Nuestros servicios de almacenamiento como Amazon S3, Amazon EBS y AWS Backup resolvieron algunos de los problemas más comunes para el equipo al tiempo que proporcionaban el más alto nivel de seguridad, confiabilidad y escala. 3/ en otros casos varios equipos estaban desconcertados por las soluciones a problemas duros -por ejemplo Networking. Varias áreas de complejidad necesitan ser abordadas de manera holística para abordar Redes para aplicaciones modernas. Estas áreas incluyen equilibrio de carga, aislamiento de recursos y descubrimiento de servicios. 4/ Entonces, ya sea que trataras de abordar problemas comunes como el almacenamiento o problemas multifacéticos como las redes, el beneficio que todos recibieron fue que nuestros bloques de construcción nos permitieron empaquetar las mejores prácticas de una forma utilizable, y los equipos podrían escoger entre los bloques de construcción disponibles, y obtener el beneficio de las experiencias combinadas de toda la organización. 5/ El proceso de identificar bloques de construcción útiles, y crear la capa de abstracción adecuada para interactuar con estos nuevos bloques de construcción se ha convertido en nuestra misión.
- todos usamos la frase, “necesitamos aumentar la agilidad”, - Despliegue de software, ver cómo los objetivos de la entrega de software automatizada a la producción influyen en casi toda la cultura, los procesos y los cambios tecnológicos que implementa - y la mayor parte de esa agilidad se expresa en el estandar, sencillez y naturaleza de las actualizaciones desplegadas a la producción. 3/ Seguiré la discusión de entrega de software con un resumen de lo que hemos venido haciendo este año para seguir simplificando las tareas operativas de nuestro lado de este modelo de responsabilidad compartida que todos hemos acordado. 4/ Entonces, David echará un vistazo extendido a los patrones de aplicación que influyen en nuestro pensamiento sobre cómo estos bloques de construcción se ensamblan en sistemas integrados... tenemos mucho que cubrir en 3 horas, así que mejor lleguemos a ello
- 2/ Siempre hemos preferido buscar formas de mantener alta la propiedad para cada equipo, y esta noción de permitir que los equipos guarden sus propias actualizaciones en la producción fue uno de los cambios más importantes que instituimos. 4/ Incluso con el despliegue automatizado, existen múltiples formas de ver una actualización de versión — 5/ La ventaja uque nosotros tenemos cuando usamos containers, o serverless, es la reducción de impacto. Como funcionaba anteriormente el proceso de despliegue anteriormente, buscaba una ventana de tiempo para hacer el despliegue, sacar de linea el servidor de aplicaciones y hacer el despliegue, probar que funcionaba y luego ponerlo en linea de nuevo.
- Cuando estamos hablando de aplicaciones modernas y lo que logramos hacer al implementar estas teçnologias de contenedores y serverless, es que conseguimos hacer un proceso más limpio en el despliegue de nuevas versiones de software. AppMesh (contenedores) como conn serverless, con API Gateway y CodeDeploy Cuando ustede tiene equipos con equipos servidores, y se necesita hacer un despliegude una nueva versión de esta aplicaciones, lo que sedebe poner es una inafraestructura completamente nueva y aislada para ir mudando el trafico levemente de este trafico para ir probando que la aplicaciones esta funcionando, e ir monitoreando si la aplicación esta ejecutando las acciones deseadas y si llegamos a tener un proceso de falla, podemos hacer un rollback facilmente. Escenario tradicional en VM es mucho más complejo (Instalar/desinstalar paquetes)
- 1. Tema importante - desarrollo de aplicaciones modernas, infraestructura y aplicación se empiezan a mezclar 2. En el nuevo modelo, la infra y el cod, se empiezan a ver como una cosa sola, en el contenedor se tiene una abstraccion mayor, porque la idea con los contenedores usted puede empaquetar y controlar el proceso de construcción de su código con el contenedor 3. En el caso de Serverless, prácticamente usted no tiene infraestructura. Ud logra actualizar mucho más rapido, y usted puede hacer revisión de código y hacerlo más facil 4. Cada uno de estos 2pizza team — y, en muchos casos, por equipos separados. Se aplicaría la configuración de la infraestructura, y el sistema “listo” para la actualización del software. Sólo después de que eso estuviera completo, se pudo instalar la aplicación. Había limitadas opciones para actualizaciones seguras, porque retroceder después de que se iniciara una actualización a menudo sería poco práctico. 2/ Saltar adelante hasta hoy, implementar una aplicación sin servidor en la plataforma AWS, es más fácil si agrupas el código de aplicación y las configuraciones de servicio de AWS juntas y las pones a ambas bajo control de origen. 3/ El proceso para comprometer actualizaciones, pasar por revisiones de código y empujar a la producción tiene el mismo aspecto si la actualización es únicamente un cambio de configuración de AWS, un cambio de sólo aplicación o una combinación de los dos. 4/ y ahora que estos cambios van a la producción sin un operador, los monitores y chequeos de salud necesitan detectar fallas y desencadenar un rollback. Y, los rollbacks necesitan restaurar todo el entorno a su estado anterior. 5/ iRobot ha sido lo suficientemente graciosa como para delinear los elementos de su enfoque con el fin de tener una sensación de un enfoque del mundo real...
- Logramos desplegar, y aplicar mejores prácticas Cómo es que los two pizza team o estos equipos logran avanzar luego de automatizar este proceso, es empezar a aplicarun modelo operative estandar
- Con base en la retroalimentación y conversación con nuestros clientes, respecto al desarrollo de aplicaciónes modernas, ellos buscan 3 cosas principalmente 1. El cliente quiere enfocarse en la aplicación, no en la infraestructura. Se quiere construir su lógica de negocio, no tener equipos enteros tratando de averiguar cómo administrar la infraestructura 2. Poder escalar facilmente de acuerdo a la demanda de mis clientes, y eso no significa unicamente crecimiento, tambien ajustarse ante una baja de uso de recursos y consumir lo menos posible 3. Asegurameinto y aislamiento por diseño, como puedo aplicar los controles de aseguramiento y tener el asegurado mi negocio y a su vez cumplir con las regulaciones y cumplimiento exigidos
- 1/ Serverless también nos requiere y nos permite innovar en cada capa de la pila. Una de las innovaciones clave que vino debido a la falta de servidor fue Firecracker. 2/ Así que laño pasado, anunciamos el proyecto Firecracker, que fue desarrollado para habilitar servicios como Lambda y Fargate para mejorar la utilización de recursos y la experiencia general del cliente 3/ Petracker es una tecnología de virtualización de código abierto que está especialmente construida para crear y administrar servicios basados en funciones y contenedores seguros, multi-tenant. 4/ Petardo es solo uno de varios otros ejemplos como Nitro, y Amazon Linux 2 de nosotros buceando profundamente en la ingeniería de infraestructura para que pueda ejecutar sus aplicaciones de forma más rápida y eficiente.
- 1/ Una de las formas en que puedes ver nuestras capas de abstracción es a través del modelo de responsabilidad compartida. 2/ Explicar la responsabilidad compartida — (los clientes son dueños de algunas cosas, AWS es dueño de otras). ¿De qué posees y de qué somos nosotros? Tienes la opción de dibujar la línea en diferentes lugares. 3/ Dar ejemplo para mostrar ow esto funciona sobre una gama de servicios (DB o Compute). 4/ Nuestro objetivo es brindarte más opciones y también seguir empujando esta línea en una dirección para que seas responsable de cada vez menos y gestionamos más de tu infraestructura. Esto liberará tu tiempo para enfocarte en la lógica empresarial para tu empresa 5/ Y si bien abstraemos toda esta complejidad para ti, también te brindamos la opción de controlar tanta de la infraestructura como quieras. 6/ Este es el lado de la abstracción: la capacidad de personalizar donde te importa, ya sea que eso signifique control sobre cuánto quieres pagar, o cuántas perillas quieres retocar.
- Volviendo un poco al escenario de EC2, una de las cosas que vemos con mucha frecuencia, es cuando los clientes quieren gerenciar la infraestructura de clusters Trabajar con herramientas que ofrecen cluster y un conjunto de infraestructura que es necesario estar administrando Cuando hablanos de gerenciamiento de cluster, containers, adicionan una complejidad accidental. y qué es?
- 1/ Complejidad esencial es una propiedad del problema que estás tratando de resolver. Que tan complejo es de resolver el problema, tengo tiempo y esfuerzo para resolver el problemas 2/ Si bien alguna complejidad es inherente al problema, también traemos nuestra propia complejidad. A esto se le llama complejidad accidental. Por ejemplo los cluster y quiero gerenciar el cluster, la configuración, como hago el namespace, con varias aplicaciones, varios cluster, como distribuyo la gestión de los recursos, actualización del sistema oeprativo, que no resuelven el problem inicial, pero son escenciales para lelgar a su solución. La pregunta es, como resolvemos eso, o dismunuir la complejidad accidental La complejidad esencial es lo difícil que es hacer algo, independientemente de lo experimentado que tengas, qué herramientas usas o qué nuevo patrón de arquitectura usaste para resolver el problema. Algunas cosas son simplemente difíciles y tardan mucho tiempo. 3/ Echemos un vistazo a cómo hemos abordado este tema en particular con la forma en que proporcionas capacidad de cómputos a tu aplicación.
- Si no está abundantemente claro por ahora, creemos que el servidor serverless es la de las respuestas clave a esa pregunta, al menos desde una perspectiva operativa. Con Fargate y Lambdaya ya no es necesario conocer cómo empaquetar aplicaciones en nodos, ni decisiones sobre el número de nodos en un clúster o cómo es posible que desee configurar clústeres de máquinas para cada equipo, y no tiene que averiguar su estrategia de colocación óptima. Estas son todas las decisiones que toma el servicio con base en metas. Pero también sabemos que nuestros clientes no siempre empiezan con Fargate o lambda. Lo más probabilidades es que muchos de ustedes comenzaron a ejecutar aplicaciones en EC2. La mayoría de ustedes probablemente todavía están.. 1/ El viaje del cliente a los contenedores suele comenzar con escribir una aplicación totalmente nueva o trasladar una aplicación existente de EC2 a algo así como ECS. En cada caso, aún tiene instancias EC2 en el núcleo de su infraestructura. 2/ Eso es lo que pagas, pones en un auto escalado grupos, y tienes que pensar en qué tipo de instancia, etc. Algunas personas empiezan con Fargate desde el primer día, y vemos que más del 40% de los nuevos clientes que utilizan nuestros servicios de contenedores comienzan con Fargate. 3/ Pero a pesar de que el constructo de Task es el mismo que lo son las API de ECS, encontramos que a nuestros clientes todavía les resulta difícil escoger uno u otro por lo que tienden a tomar sus decisiones con anticipación. Preferirían que esas decisiones se convirtieran en vinculantes tardías en base a sus necesidades empresariales.
- 1 2/ Permítanme pasar rápidamente por qué son los proveedores de capacidad y cómo funcionan. 3/ Esencialmente puedes escoger dos tipos de proveedores de capacidad y adjuntarlos a tu “clúster”. En este contexto un cúmulo es sólo un recipiente sin ningún significado físico real. 4/ Este proveedor puede ser un Grupo Autoscalng o Fargate. Aquí la parte divertida, en cualquiera de las dos puedes decidir cuánto de tu capacidad debe estar usando Spot.. incluyendo para Fargate.
- 1/ Entonces, ¿cómo podemos darle a nuestros clientes aún más valor desde serverless? Los clientes de ECS se han beneficiado con el poder que obtienen de Fargate. Bueno, ahora los mismos beneficios van también para nuestros clientes de EKS. 2/ El soporte de EKS para Fargate facilita mucho a los clientes la ejecución de aplicaciones basadas en Kubernetes en AWS al eliminar la necesidad de aprovisionar y administrar la infraestructura para los pods, dimensionar adecuadamente la utilización del servidor y los costos para cada pod, y proporcionar un sólido aislamiento de seguridad para cada pod por diseño.
- Entonces hablamos de ECS, Fargate, y Lambda y así el modelo de operaciones sin servidor se ve así 1/ Puedes empezar por la parte inferior con EC2 y tener acceso a todas las perillas que quieras administrar o podrías ir completamente sin servidor con lambda y Fargate donde te estás enfocando solo en tu aplicación. 2/ Así que las capas de abstracciones disponibles para ti con AWS son súper empoderadoras porque tus equipos tienen la opción de elegir la capa de abstracción con la que se sientan más cómodos y te proporcionaremos las herramientas, servicios y API necesarias para ayudarte a construir tu aplicación Fargate sigue empleando ECS y EKS
- En ocasiones podemos simplificar las operaciones para usted: eliminar los arranques en frío relacionados con VPC y la complejidad de escalar las VPC. mayor controls: error mejorado y reintento (max, max age, bisect, on-error destinos); stream para low (Batch Windowsize) y high (auto-paralelización para no sharding) ya haciendo: destinos asíncros para encadenar 1/ En este tema de engranajes más altos, hemos visto a Lambda como la opción de cómputos operativa con más manos libres — simplemente sube código, y lo ejecutaremos cuando sea necesario. Hay equipos de tecnología (recién ensamblados, o transformados) como iRobot, Fender Digital, Dunelm y DAZN (zona DA-) que han diseñado sus aplicaciones para ser optimizadas para aprovechar esta mayor planeación de engranajes, 2/ Hemos tenido una serie de constructores nos piden unos controles más. 3/ PERO, el control de rendimiento más solicitado por los constructores de control de rendimiento es la capacidad de configurar la concurrencia de Lambda para los tiempos de inicio más bajos posibles, y mantenerlo listo para funcionar
- Lanzamos Concurrencia Aprovisionada para responder a esta solicitud. 1/ Ahora, sin cambios en su aplicación, puede utilizar Lambda CLI, CloudFormation, Terraform, o AWS Management Console, (o la API de AWS) para establecer un nivel de concurrencia que desea mantener hiper-lista 2/ Concurrencia aprovisionada estará ejecutando tu código dentro de los milisegundos de dos dígitos de cualquier invocación, hasta la cantidad que hayas indicado. Más allá del nivel de concurrencia hiperlista, las funciones obedecerán las reglas predeterminadas de las invocaciones bajo demanda 3/ Uno de los aspectos emocionantes del lanzamiento, es que se apoya Auto Scaling. Aquellos que han tenido acceso anticipado a esta función han sugerido que crear una regla de Seguimiento de Target en Auto Scaling es una manera fácil de extraer el beneficio con muy poca planificación (o, análisis de capacidad histórica) 4/ Consideramos este control de grano más fino, porque hemos separado el precio de duración de ejecución y Concurrencia Aprovisionada. Si su aplicación necesita tiempos de inicio de baja latencia en todas las circunstancias, ahora puede controlar la cantidad de concurrencia para mantener inicializada. Notarás que el costo de duración de ejecución de Concurrencia aprovisionada es menor que las funciones bajo demanda, porque pagas por mantener la concurrencia hiper-lista por separado —en otras palabras, pagar por valor (*** o, tal vez.. Paga el beneficio que se adapte a tu caso de uso ***)
- Todo lo que estamos pensando desde una perspectiva de modelo de operación está fuertemente enfocado en la productividad de los desarrolladores. ¿Cómo podemos facilitarle la ejecución de sus aplicaciones sin preocuparse por los detalles de la infraestructura La analogía que utilizaría para resumir nuestro pensamiento es que te estamos proporcionando una gama de engranajes para operar tu aplicación. Te estamos dando la opción de escoger el equipo que sea adecuado para ti y tus equipos. Si eliges una marcha más baja, obtienes el control total de cómo ejecutas tu aplicación y si eliges escoger una marcha más alta, nos encargamos de todo el levantamiento pesado indiferenciado para ti.
- El patrón que apoya la innovación de alta velocidad (agilidad, velocidad, toma de decisiones) Patrones de arquitectura de 3 núcleos: API, Eventos, Flujos de datos *** narrativa para explicar cómo esto aprovecha la resiliencia de la plataforma de AWS, y de forma natural se escala con el volumen de eventos *** 1/ Una de mis descripciones favoritas de Internet, que se pegó conmigo desde temprano es — una colección de piezas pequeñas unidas flojamente (le permitió crecer tan rápidamente con tanta diversidad) 2/ innovar — muchos experimentos 3/ cosas sueltas unidas por APIs, Eventos y flujos de datos son capaces de crecer en diferentes direcciones
- Y como funciona esa comunicación, la primera forma para poder visualizar eso, es con los APIs, los APIs son la puerta de entrada a los microservicios. Tengo un microservicio que es expuesto, el API es una puerta de entrada, como espero recibir esas peticiones, y como voy a dar respuesta a las mismas. Adicionalmente, me permite establecer un estandar de comunicación de bajo acomplamiento para evitar dependencias fuertes de código entre las aplicacione
- Contrato, define como viene la petición, que parametros son necesarios para dar respuesta a su petición. Positivo – Mudar el backend, la lógica como quiera, imientras tanto el API no cambie Diseño de Org Innovar detrás de API - promesas 1/ Dentro de Amazon cuando hablamos de equipos de 2-pizza, muchas veces hacemos de una API endurecida un requisito de cualquier equipo nuevo - usando API para definir el contrato estable entre equipos. 2/ Un servicio de Team-A necesita llamar a una API y obtener una respuesta valiosa de la función construida por Team-B. API en el perímetro de los servicios de Fargate y las funciones Lambda, permiten a los equipos iterar activamente sin cambiar la estructura solicituda-respuesta entre los equipos.
- ** Guión 2018 ** 1/ hemos construido muchos microservicios, y hemos visto muchos patrones en el manejo de las API 2/ a menudo comienza con auth, y está bien integrado con cognito y IAM 3/ control de recursos - regulación 4/ integrado con X-Ray y CloudWatch 5/ opciones de reabilidad 6/ conexión directa
- Cognito enables customers to add user sign-in, sign-up and access control to web and mobile apps Differentiators Most extensible end-user authentication and authorization workflows can be customized using out of the box integration with AWS lambda granular APIs and SDks on all Fully managed Built-In, hosted UI Out of the box support for open standards (Azure AD B2C does not support SAML) Secure Temporary AWS Credentials Advanced Security Features - Compromised Password DB and Adaptive Authentication
- 1/ Me complace anunciar una vista previa abierta de una nueva capacidad en API Gateway, estamos llamando API HTTP. Esta es una gran manera de exponer API REST entre servicios. 2/ reducir su costo 70% y reducir los tiempos de latencia en las llamadas API en un 50% o mejor. 3/ Esta nueva característica tiene su propia interfaz de configuración, y le permitirá importar API existentes desde la herramienta API Gateway Management, o cualquier sistema de administración de API de 3 rd party. 4/ Autenticación usando OIDC/OAUTH2 *** esperemos que podamos pasar un poco más de tiempo en esto ***
- Mundo real (IoT); Viejo mundo (bus empresarial); Moderno (móvil, desacoplado) Evento un cliente hacienda una requisición Cliente web. IoT generando información 1/ Eventos te dan este gran beneficio de desacoplamiento 2/ servicios individuales que reaccionan entre sí
- SQS FIFO; SNS DLQ; Controles de integración El primer lugar en iniciar es con las fuentes de eventos de AWS que ya existen. Contamos con nuestros servicios de colas nativas en la nube y notificación... 1/ Cualquier servicio existente que pueda publicar mensajes para publicar mensajes en SNS, puede comenzar a construir NUEVOS microservicios impulsados por eventos construidos como funciones en Lambda. 2/ AirBnB ha creado un proyecto de código abierto para tal escenario. Tener mensajes originados a partir de aplicaciones contenerizadas lo que resulta en un evento desencadenando un Lambda es un caso de uso muy común. 3/ cada vez que utilice un servicio de AWS, puede generar un evento a través de EventBridge .
- Pero, a principios de año dimos otro paso con EventBridge al crear un programa de integración de 3rd party. Trabajamos activamente con algunos de los servicios de software 3 rd party más comunes que se ejecutan en AWS — servicios como: *** lista partners ***. Creemos que este programa seguirá haciendo más sencillo que los constructores se suscriban a eventos estándar 3rd party que ya usan *** pregunta si debemos señalar a alguien *** ** hablar de la nueva integración MongoDB?
- — Para los equipos que parten de una hoja limpia, que son capaces de construir sin restricciones existentes, disfruto hablar de los beneficios de las arquitecturas impulsadas por eventos. Pero, para equipos con una inversión existente en un sistema de producción, ¿cómo se conceden el uso de eventos para construir nuevas incorporaciones utilizando un diseño impulsado por eventos? Pero, a veces no existe un evento estándar para la acción que quieres atrapar. Entonces, apoyamos eventos personalizados *** describimos el proceso previo de construcción, documentación y publicación de eventos personalizados ***
- constructores que llevan un tiempo haciendo esto preguntaron por qué no podría ser más descubrible, ¿por qué requirió de configuración para unir a todos desde el equipo que produce el evento, hasta el equipo escribiendo nuevo código tratando de acceder a los datos que llegan con el evento? Entonces, hoy estamos anunciando la disponibilidad de una vista previa abierta del Registro de Esquema EventBridge
- El tercer patrón de diseño común — orientado al flujo de datos 1/ el tejido conectivo clave son flujos de datos... 2/ cada vez que cambia una tabla de dinamo, puedes reaccionar a ese cambio 3/ o, una corriente de datos de Kinesis de propósito general
- RDS Database Proxy se sienta entre la aplicación y una base de datos RDS Simplicidad: Alberca de conexiones incorporada abstrae las complejidades de la administración de conexiones Escalabilidad: Multiplexación de conexiones permite abrir más conexiones simultáneas Resiliencia: Los reintentos automáticos maneja a la perfección errores transitorios como instancias de db fallidas sin esfuerzo adicional Consistencia: El pinning de conexión garantiza que cada declaración o transacción posterior de su cliente es procesada por la misma conexión de base de datos subyacente Soporte de vista previa: RDS MySQL 5.6 y 5.7, Aurora 5.6 y 5.7, Aurora Serverless 5.6 y 5.7
- Ciertamente estamos haciendo todo lo que podemos para facilitar la creación de fuentes de eventos, pero ¿qué estamos haciendo para sumar la capacidad de consumir los eventos y construir una coordinación más compleja entre funciones? Step Funcciones es una herramienta útil para consumir eventos, y definir la ejecución coordinada de múltiples servicios en respuesta a esos eventos — a menudo, acortaremos esa descripción a “flujo de trabajo”. *** explicación más larga de Step Funcciones? *** Entonces, ¿cómo hacemos un seguimiento del estado entre todas estas cosas? ¿Cómo nos aseguramos de que las cosas se estén ejecutando en el orden correcto y en el momento adecuado? Necesitamos una máquina estatal por supuesto En términos más simples, necesitamos una forma de orquestar los diferentes flujos de trabajo entre todos los servicios Establecer tiempos de espera en las tareas, interrumpir la ejecución, hacer que las tareas envíen latidos del corazón, y monitorear y auditar con una granularidad fina.
- Entonces, esto fue una hora llena, con mucho en lo que pensar. Pero, la mayoría de ustedes están aquí porque están considerando planes futuros, y validando ideas que tienen. Equipos que buscan adoptar modelos de programación sin servidor introducen los fundamentos desde un par de perspectivas diferentes
- *** PAYOFF pitch - enviaremos algo alrededor en correo electrónico sobre esto, porque necesitamos capturar nuestros pensamientos sobre todo el espacio ocupado por contenedores y funciones en la cultura moderna de los devops ***
- 1/ Organizaremos hoy la discusión por: 1/ entrega de software. 2/ modelo operativo. 3/ y patrones de aplicación. 2/ Empezaré con la entrega de software, porque es interesante ver cómo los objetivos de la entrega automatizada a la producción influyen en casi toda la cultura, los procesos y los cambios tecnológicos que implementa - todos usamos la frase, “necesitamos aumentar la agilidad”, y la mayor parte de esa agilidad se expresa en la regularidad, sencillez y naturaleza manos libres de las actualizaciones desplegadas a la producción. 3/ Seguiré la discusión de entrega de software con un resumen de lo que hemos venido haciendo este año para seguir simplificando las tareas operativas de nuestro lado de este modelo de responsabilidad compartida que todos hemos acordado. 4/ Entonces, David echará un vistazo extendido a los patrones de aplicación que influyen en nuestro pensamiento sobre cómo estos bloques de construcción se ensamblan en sistemas integrados... tenemos mucho que cubrir en 3 horas, así que mejor lleguemos a ello