Serverless 3.0 Implementación de aplicaciones web de última generación, Cloud Native.

Iniciamos con el Webinar del día de hoy, que como saben es Serverless 3.0, implementación de aplicaciones web de última generación Cloud Native. ¿Por qué Serverless 3? ¿Cero? Bueno, para algunas personas que tal vez ya nos conocen o ya han participado en alguno de otros webinars anteriormente, tuvimos lo que fue el Webinar sobre Serverless y sobre serverless 2.0. Entonces esta ocasión tenemos lo que es el webinar Serverless 3.0, que es una evolución que está teniendo lo que son los servicios serverless en la nube de AWS y que el día de hoy nos están acompañando lo que es el Ingeniero Pedro Serrano y el Ingeniero Carlos Esparza, quienes son los expertos de CompuCloud y en lo que es la parte serverless DevOps y todo lo que es los servicios en nube que tenemos en compuclo. Muchísimas gracias a Carlos y Pedro que nos acompañan el día de hoy y pues ellos estarían respondiendo lo que son sus preguntas sobre los temas que estaremos revisando. Y muy bien les comparto lo que es la agenda que tendremos en la sesión. Iniciamos con las definiciones de lo que es Serverless, algunos de sus beneficios, el modelo de responsabilidad operacional, la parte de desarrollo de aplicaciones de Cloud Native, que es el punto importante que vamos a platicar el día de hoy. También algo muy importante que es la parte de Seguridad Serverless en lo que es la nube de AWS, que ya es seguridad por defecto que nos brinda lo que es Amazon Web Services. También tenemos la parte de despliegues con AWS Serverless Framework, servicios tradicionales de Serverless que justamente hacen referencia a temas pasados que hemos visto en serverless 2.0 y ahora los servicios de última generación Serverless que son justamente los 3.0 y que estaremos viendo el día de hoy. Algunos casos de uso que nos van a compartir los ingenieros y por último una demo en la cual el Ingeniero Carlos Esparza les estará llevando más a la práctica lo que estaremos viendo el día de hoy. Y antes de iniciar les va a estar apareciendo lo que es una pregunta en lo que es su pantalla. Si me ayuda Sandy con lanzar la pregunta, por favor. Muy bien, y si nos apoyan a responder la pregunta que les está apareciendo en donde hacemos mención si ustedes creen viable que el serverless 3.0 es el serverless más bien es el futuro de la computación. Muy bien, muchas gracias a los que nos están apoyando a responder. Y bien, damos inicio con lo que es el primer tema antes de iniciar con lo que es serverless. Muy rápido, tal vez algunos ya nos conocen, pero quisiera compartirles quiénes somos nosotros, quién es Compuclo. Nosotros somos partner Advanced de Amazon web services. Estamos 100 enfocados en lo que son servicios y soluciones de la nube de AWS. Tenemos presencia en México y Centroamérica y somos especialistas en la parte de diseño de arquitecturas, cloud, planeación y migración, implementación, la parte administración, respaldo y monitoreo continuo de la infraestructura en la nube, que esto abarca tanto infraestructuras actuales como son ahora serverless o infraestructuras tradicionales. Esto ya depende mucho de la necesidad que estén buscando ustedes como empresa. ¿Y qué nos avala para ser expertos en esto? Bueno, tenemos diferentes certificaciones, aquí en los iconos que pueden ver del lado derecho son las especialidades que tienen nuestros ingenieros, como la parte de seguridad de Developer de Solution Architect, Salesops Administrator y tienen diferentes certificaciones todo el equipo CompuCloud para justamente poder brindar servicios y soluciones en la nube que estén correctamente aplicadas en lo que es Amazon web services. También CompuCloud ha cumplido con ciertos requisitos para ser especialistas en lo que son servicios muy específicos de AWS, como son el SDP de RDS basado en lo que son bases de datos relacionales, el SDP de API Gateway Delivery. También tenemos un S P de lo que son migraciones de Windows a la nube de AWS, que esto son como algunas pruebas que realizamos para poder tener este expertise y que el cliente esté seguro del servicio que va a revisar. Y también tenemos una competencia en lo que es Digital Customer Experience, en la cual nos encargamos que el cliente de ustedes tenga la mejor experiencia al utilizar lo que son los servicios, ya sea tu página web o algunos servicios que tengas en un servidor en la nube y que estén siempre disponibles y con alta seguridad. También este año recibimos lo que fue el reconocimiento de Manage Service Provider, en donde pues estuvimos bajo una auditoría en donde revisamos todo lo que son los procesos que llevamos a cabo en la nube, desde la parte de seguridad hasta los reportes que el cliente recibe en cuanto a lo que es su infraestructura y todos los pasos que tenemos en conjunto para que tengan la mejor experiencia en lo que es Amazon Web Services. Y por último, también somos expertos en lo que es Google Architected Framework, que es una serie de las mejores prácticas al momento de estar en AWS. Entonces, ahora sí que ya nos conocen un poquito más, pues damos inicio a lo que es el webinar del día de hoy y los dejo con mi compañero, el ingeniero Pedro Serrano.

Muchas gracias, Gio, muchas gracias a todos por acompañarnos. Pues bueno, me presento nuevamente, soy el ingeniero Pedro Serrano y como bien comentó Gio, pues vamos a estar hablando acerca de lo que es serverless. Aquí tenemos una definición de lo que es serverless para poder entender un poquito más en contexto, para poder tener como. Bueno, para aquellos que no están tan familiarizados con el concepto serverless, pues prácticamente lo que se refiere serverless es la infraestructura o la arquitectura nativa de la nube, así tal cual, con la cual permite trasladar las responsabilidades operativas a AWS o a una nube pública y se aumenta la agilidad y la innovación. Esto quiere decir que nos vamos a olvidar de la administración, de las infraestructuras, nos vamos a olvidar de todo lo que tenga que ver para poder montar, por así decirlo, un servidor tradicional. Digo, normalmente los que sabemos de TI conocemos este tipo de situaciones, de casos donde tenemos que montar un servidor, pensamos en el sistema operativo, pensamos en las cuestiones de configuración que tenemos que hacerle. Entonces, eso es la ayuda. Podemos crear, ejecutar aplicaciones sin tener que preocuparnos por los servidores tal cual, ¿No? Y permite eliminar las tareas de administración, lo que nos ayuda a que nuestros desarrolladores o nuestro equipo operativo que va a estar ejecutando en estas cargas de trabajo, pues obviamente se enfoquen a la operación como tal y no a estar manteniendo que la actualización del sistema operativo, el parche, el antivirus, etcétera, tantas cosas que necesita una instancia, un servidor, ¿Verdad? Posteriormente vamos a entender un poquito datos, unos datos como tal, datos duros, por así decirlo, de la tecnología serverless, para entender qué tanto auge está teniendo o hacia dónde está caminando. Como bien la pregunta inicial decía que si creíamos que el serverless era el futuro de la computación, entonces la realidad es que Estamos convencidos en CompuCloud y en AWS que sí es el futuro de lo que es la computación como tal, porque es hacia donde muchas empresas están virando y obviamente tiene muchísimos beneficios que más adelante lo vamos a ver. Por ejemplo, el 30% en estos datos, el 30% de las compañías están trasladando una o más cargas de trabajo a servicios serverless y esta tendencia va en la alza. ¿Qué es la recomendación aquí? Que por lo general nosotros hacia ustedes podemos decirles es si, ya tenemos identificadas algunas cargas de trabajo, a lo mejor tenemos cargas de trabajo críticas que requieren toda una planeación, requieren todo un lapso a lo mejor más prolongado de tiempo para hacer esta adopción hacia las tecnologías serverless, pero tenemos cargas de trabajo que califican totalmente, ¿No? Cargas de trabajo que vamos empezando, que están en temas de PoC, que califican porque no es muy crítica su operación, por así decirlo, y podemos adoptar estas tecnologías en esas cargas de trabajo y obviamente probar, por así decirlo, estos servicios y nos va a ayudar adoptarlos de una mejor manera y obviamente una vez que prueben las mieles del serverless, por así decirlo, nos vamos a decantar por estas tecnologías ¿No? Aquí hay otro dato duro, Airbnb ha servido más de 200 millones de clientes en 191 países optimizando sus cargas con servicios como Lambda y Dynamo, o sea, cuando nos metemos a la aplicación de Airbnb tras bambalinas, Dynamo y Lambda están haciendo las operaciones, no se requieren servidores, son servicios totalmente escalables, totalmente resilientes y que le ayudan a Airbnb ser mucho más eficiente sus operaciones. Y un ejemplo que nos quede muy claro es el de Kavak, Kavak, el unicornio mexicano, pues obviamente sus operaciones están potencializadas con servicios como Lambda y API Gateway, prácticamente ellos utilizan todo el poder del serverless. Entonces a continuación vamos, vamos a analizar un poco los beneficios de serverless, los beneficios que nos va a contribuir usar estos servicios de serverless tal cual. Pero aquí viene una pregunta, una segunda pregunta. ¿Has utilizado algún servicio de serverless? Aquí vemos que están participando está entre el sí y entre el No. 50-50. OK, bueno, veo, vemos que con agrado que hay algunos que sí tienen experiencia utilizando servicios serverless, hay otros que no, pero obviamente pues esa es una adopción ¿No? Y es el futuro lo que nos demanda que tenemos que caminar hacia allá. Obviamente esto tiene beneficios, utilizar estos servicios serverless, pues no es moda, simple y sencillamente es porque tiene beneficios tangibles como el bajo mantenimiento, por ejemplo, no hay necesidad de aprovisionar ni mantener servidor Bueno, eso ya nos quedó claro, no hay que instalar, no hay que administrar, no hay que configurar un tiempo de ejecución. El mantenimiento prácticamente se lo vamos a delegar a AWS, más adelante vamos a ver un modelo de responsabilidad, pero prácticamente eso es lo que nos dice este punto de beneficio, que la administración pásasela hacia AWS y tú preocúpate únicamente por hacer tu producto y por mantenerlo para que tus desarrolladores se mantengan innovando y todo este tipo de cuestiones. Uno de los puntos muy importantes, este como tal, es el pago por uso, pagas por rendimiento uniforme y por la duración de ejecución en lugar de hacerlo por unidad de servidor. Cuando nosotros tenemos un servidor, obviamente, pues los que somos de TI sabemos que lo necesitamos tener 24 7 prendidos si la operación es crítica, por así decirlo, ¿No? Entonces, pero no siempre está recibiendo peticiones, por ejemplo, si es un. Está muy orientado esto a lo web o a lo móvil, no siempre se están recibiendo peticiones, no siempre está operando, no siempre está procesando, entonces a lo mejor el servidor tiene tiempos de ocio, pero obviamente necesita estar prendido. Ahora, si es una instancia en la nube, obviamente este servidor está corriendo y está generando costo. Aquí la ventaja del serverless es que únicamente vas a pagar cuando se ejecute tu función o tu servicio y el tiempo que dure en ejecutarse y la capacidad de cómputo que se aprovisione, por así decirlo, en esa ejecución. Va a haber ejecuciones que son mucho más pesadas, todos nosotros lo sabemos, en las que a lo mejor la capacidad de cómputo requiere ser mayor y en otras que requiere ser menor. Entonces esto se autoprovisiona y es una. Es un beneficio que es el siguiente, la escalabilidad es un beneficio muy tangible de lo que es AWS. Entonces pagas exactamente por lo que usas y escalas la aplicación se puede escalar automáticamente con el ajuste de la capacidad mediante la alternancia de las unidades de consumo, memoria, CPU, todo este tipo de métricas que nos ayudan a medir cuánto es el consumo que estamos utilizando en lugar que se utilice con servidores tradicionales, que por ejemplo, monitorear un servidor tiene sus capacidades fijas, bueno, los servidores de AWS son escalables, pero aún así tienen sus capacidades fijas, tenemos que escalarlos nosotros manualmente. Entonces lo que aquí nos vamos a ahorrar es estar monitoreando que obviamente hay un monitoreo en AWS, pero el monitoreo es más como proactivo, no es tanto reactivo, entonces más que nada como estar monitoreando el servidor ¿No? El servidor lo estoy monitoreando, veo que ya tengo mi capacidad, ya se está cumpliendo, ¿Qué es lo que sigue? Pues es hacerle un upgrade manual no, o a lo mejor automatizado pero bajo una regla que ya definimos que ocupa una operación, bueno el serverless nos va a ayudar a hacer esto por nosotros, por ser administrado por parte de AWS, va a entender que obviamente si la capacidad de cómputo requiere un ajuste de capacidad pues nos va a ayudar a hacerlo como tal ¿No? Entonces a eso se refiere con escalabilidad. Y otro de los beneficios pues es la alta disponibilidad. Con la informática sin servidor se proporciona disponibilidad prediseñada y tolerancia a errores. Esto quiere decir que AWS por default ya tiene las características extras de alta disponibilidad que nosotros le podemos poner a un servidor, a una instancia, pero esto ya lo trae por default, ¿Esto qué quiere decir? Pues se replica en varias zonas de disponibilidad. Entendamos por ejemplo que tenemos un código lambda que nosotros aprovisionamos como tal, nosotros le pasamos el código a la función lambda y pues esto es lo que vemos, vemos la consola, hacemos algunas configuraciones que obviamente pues compuclo puede ayudarlos como tal, pero detrás de bambalinas no vemos como por ejemplo si lo veríamos en una instancia lo que es la alta disponibilidad que tenemos que configurar, el multi az que tenemos que configurar, el balanceador, el auto scaling, todo este tipo de cosas AWS ya lo trae embebido en estos servicios, entonces nos va a ayudar a la tolerancia a fallas porque se está replicando en varias zonas de disponibilidad, no solo lambda, también por ejemplo el servicio de almacenamiento s, el servicio de bases de datos no SQL como DynamoDB, entonces todos estos tenemos la seguridad de que nuestros datos no viven en un solo lugar, se ejecutan en una sola función por así decirlo, pero viven en diferentes, están replicando en diferentes tipos de zonas de disponibilidad y se proporciona esto de forma predeterminada, no beneficios totalmente tangibles como tal. En resumen, mediante la informática sin servidor puedes crear aplicaciones modernas, que esa es la intención, eso es hacia dónde vamos a virar, por eso este webinar se llama serverless 3.0. Virando hacia aplicaciones cloud native bueno, las cloud native como tal aplicaciones modernas con mayor agilidad y menor costo, que esa es como la intención de AWS. AWS tiene muchos programas en los que nos va a ayudar a modernizar, porque esa es una de sus intenciones. Su intención no es como tal que paguen más teniendo un servidor muy robustote, muy grande, un servidor, una caja, como así le dicen, enorme para que haga todas nuestras operaciones. Mejor rómpelo, mételo a cuestiones de serverless que se autoprovisionen, que se ejecuten únicamente cuando tú requieras. Y la creación de aplicaciones sin servidor implica que los desarrolladores, esto es muy importante, se puedan enfocar en un producto en vez de preocuparse por la administración tal cual de la infraestructura, el funcionamiento de los servidores, tiempos de ejecución y todo este tipo de cuestiones. Nuestros desarrolladores o nuestro equipo técnico se va a ver liberado de eso y gracias a esto van a tener más tiempo para hacer un producto de mejor calidad, innovar, bueno, todas las cosas y beneficios que conlleva. Y como les mencionaba, este es el modelo de responsabilidad operacional. Este cuadrito es muy interesante. AWS nos da a entender tal cual que, por ejemplo, yéndose hacia la izquierda es menos, menos serverless, hacia la derecha más serverless. Y nos dice que este es el modelo de responsabilidad operacional, ¿Sale? ¿Qué quiere decir? Que mientras más serverless, más responsabilidad le estamos delegando a AWS en la operación. Mientras menos serverless, nosotros estamos adoptando o estamos siendo responsables completamente de lo que es la responsabilidad operacional de la infraestructura. Va en el on premise, por ejemplo, de cómputo. Tenemos una máquina virtual, una base de datos MySQL, un storage común, bueno, todo este tipo de cuestiones. Nos vamos un poquito a la derecha y AWS nos ayuda con instancias de C, ¿No? Instancias que nosotros tenemos que administrar, las podemos levantar, las podemos configurar, todo este tipo de cuestiones, ya estamos en la nube, pero no estamos en un proceso de que le estamos delegando a AWS la responsabilidad operacional de las cuestiones internas de nuestra operación MySQL y este tipo de cuestiones. Bueno, nos vamos un poquito más a la derecha y están los servicios administrados. Estos son muy interesantes y muy, muy importantes para AWS, pero todavía no estamos en serverless. Simple y sencillamente es infraestructura administrada. Nosotros le vamos a delegar a AWS la administración, pero no a serverless. Sigue teniendo capacidades de cómputo bien definidas, y limitadas a lo que le pusimos, que se puede escalar, sí, pero está limitada a lo que le pusimos en el momento como v install, como RDS. Entonces, un poquito más, tenemos una RDS Aurora, que es el motor nativo de AWS, pero obviamente sigue siendo cuestiones tradicionales. Y ya totalmente serverless, tenemos lo que son los contenedores Fargate, que son contenedores como tal que nos van a ayudar a montar, valga la redundancia, estos contenedores en infraestructura serverless. Tenemos lo que es Aurora serverless, si, la base de datos, el motor de base de datos de AWS en cuestiones serverless, esto es súper interesante y el corazón de los servicios serverless de AWS, Lambda Lambda para hacer ejecuciones de código en diferentes lenguajes, que más adelante mi compañero Carlos Esparza les va a platicar, y DynamoDB para cuestiones de NoSQL s para almacenamiento, SQS y SNS para cuestiones de mensajería y Atina para cuestiones de datos, procesamiento de datos como tal. Entonces, esta tablita nos da a entender hacia dónde vamos, qué es lo que queremos, qué es lo que le podemos delegar hacia AWS. Y ahora vamos a hablar de una cuestión muy importante, si no podría decir tal vez la más importante para AWS, la seguridad para AWS es muy importante, es una de las cuestiones a las que más recursos le invierte, por no decir a la que más les comento como tal, es la seguridad. Y estos servicios serverless de AWS ya traen cuestiones embebidas por default de seguridad, cuestiones que AWS tiene en servicios, por ejemplo, tiene servicios, tiene addons que podemos agregar, si nosotros montáramos un servidor, una instancia EC, si se las podemos agregar, pero hay que levantar servicios adicionales para cuestión del cifrado o todo este tipo de cuestión, hay que levantar estos servicios. Y estos servicios héroes ya los traen, por ejemplo, de reforzar el nivel de conformidad y seguridad en sus entornos TI, prácticamente con registros o con compliance que cubren estos servicios. AW tiene muchos compliance que cubren estos servicios, ISOs, IPAs y ese tipo de cuestiones ya están por default, entonces pueden ayudar, si tenemos algún compliance nos pueden ayudar con eso, tal cual. Seguimiento de cambios versionado, esto es muy importante, por default lo traen los servicios serverless AWS, Vamos a seguir los cambios paso a paso, vamos a poder versionar los lanzamientos que hagamos, tanto como de almacenamiento, o sea, esto aplica todo, tanto de almacenamiento como de base de datos, como la cuestión de los códigos. En Lambda vamos a tener esto, Controles de acceso muy bien definidos con servicios serverless, tal cual como cognito, administración, autenticación de los usuarios finales, esto es importante obviamente. Cifrado en tránsito y reposo, como les comentaba, vamos, tiene cuestiones de cifrado en tránsito, en reposo, como está muy diseñado para la cuestión de la operación, obviamente es por petición y las peticiones suelen ser públicas, ¿No? Entra una petición, el servicio crea una respuesta, un response como tal y sale, entonces obviamente se van a cifrar los datos como tal. Roles, políticas y logs, esto es para cuestiones de seguridad, roles para las cuestiones de ejecución, seguridad de ejecución, políticas, para qué es lo que va a tener permisos y logs, para tener un registro total de todo lo que está operando como tal. Va súper muy bien. Pues bueno, ya vimos un poquito de los conceptos de serverless, ahora vamos a hablar de algo que se llama Serverless Framework, que este es un framework, como bien lo dice su nombre, que nos va a ayudar a hacer despliegues como tal, Serverless Framework nos va a ayudar a desarrollar, a implementar las funciones Lambda, está muy orientado a funciones Lambda, pero también a toda la infraestructura que lo rodea. El core es Lambda, pero Lambda no trabaja solo, Lambda como algunos que han utilizado Lambda, si los conocen o si no les comento, Lambda puede interactuar con todos los servicios, bueno si no con todos, con la gran mayoría de servicios de AWS de forma nativa. Entonces nos va a ayudar a lanzar el core y a lanzar lo que trabaje en coordinación con Lambda como tal. Es una CI, si han usado la CI de AWS, es algo muy común, muy parecido, una CI que nos va a ayudar a la estructura, la automatización y mejores prácticas para usar este lenguaje como tal. Usa algunos comandos diferentes a las quin, pero la estructura es la misma y la forma de operación es la misma. Y lo más importante, admite múltiples idiomas, Node, JS, Python, Java, entre otros. Pero bueno, obviamente estos son los más comunes y hay que mencionarlo ¿No? JS, tanto Node, JS como Python son lenguajes que AWS adoptó y son por así decirlo nativos como tal, va súper muy bien. Bueno y ya hablamos de estos tipos de características y lo que compete ahorita es exhortar o platicar un poquito del porqué desarrollar aplicaciones cloud, native, bueno, Linux, tiene una fundación que se llama Cloud Native Computing Foundation, en la que según ellos dicen que estas tecnologías empoderan a las organizaciones para construir y correr aplicaciones escalables en ambientes dinámicos modernos como lo son nubes públicas, privadas o híbridas. Temas como servidores, mallas, microservicios, infraestructuras, APIs, que es lo que más, por ejemplo, estamos hablando ahorita con Lambda. Entonces, he ahí los puntos o el por qué AWS exhorta tanto a virar o adoptar estas tecnologías serverless, ser cloud native, tus desarrollos. Las ventajas, pues ya como todos lo sabemos, son aplicaciones escalables, esto es súper importante. Las integraciones y despliegues continuos. Estos servicios son totalmente amigables con despliegues continuos e integraciones, lo que nos va a dar ciclos DevOps, lo que nos va a dar agilidad en todas nuestras operaciones. Los que conocen, bueno, ya hemos dado anteriormente otros webinars de cuestiones de DevOps, pero los que conocen este tema saben cómo se puede agilizar toda esta operación. Resilientes, administrados, cuestiones de microservicios y un tema no menos importante que es el bajo costo de desarrollo. Porque vuelvo a lo mismo, se cobra por ejecución y los costos son bastante económicos, por así decirlo. Bueno, pues a continuación les cedo la palabra a mi compañero Carlos Esparza. Muchísimas gracias a todos por su atención, que tengan un excelente día.

Muchas gracias, ingeniero Pedro. ¿Qué tal? Buen día a todos. Soy Carlos Esparza, soy una de las personas que está en el área de preventa de CompuCloud y ahora les voy a hablar un poquito de lo que son los servicios dentro de AWS, ¿De acuerdo? Empezaremos hablando un poco de lo que son los servicios tradicionales serverless. ¿A qué nos referimos con servicios tradicionales? A aquellos servicios dentro de AWS que ya llevan mucho tiempo en el mercado. Como lo decía el buen Ingeniero Pedro, AWS Lambda es el corazón de los servicios serverless, así como EC en su momento fue el corazón o es el corazón de aquellos servicios que sí requieren de cómputo. Lambda es su contraparte para los servicios serverless. Y por definición, AWS Lambda es aquel servicio que te permite ejecutar código para prácticamente cualquier tipo de aplicación o servicio de backend, sin necesidad de aprovisionar o administrar servidores. Así como lo mencionó el Ingeniero Pedro, pues es que los programadores se enfoquen en lo que realmente importa, que es construir una buena aplicación. ¿De acuerdo? Entonces lo que haríamos en este caso, en vez de preocuparnos por el servidor per se, lo que es grupos de seguridad, reglas en la red, entre otras cosas, aprovisionamiento del sistema operativo, más bien nos vamos a encargar de construir una buena aplicación y que solo se ejecute cuando sea necesario, así no tenemos servidores que se están ejecutando 24 7 y que están realizando un consumo de recursos económicos cuando no se requiere, mejor viramos por servicios como lo es AWS Lambda que nos permite ser ejecutados exclusivamente cuando se necesita. Por contraparte tenemos lo que es Amazon API Gateway. Recordando un poquito la definición informática de lo que es una API, pues es la que nos ayuda a la comunicación entre un backend y un frontend dentro de una aplicación. ¿De acuerdo? ¿Entonces, para qué nos va a servir Amazon API Gateway? Como ahí mismo lo indica, es un servicio completamente administrado que nos va a facilitar a los desarrolladores la creación, la publicación y el mantenimiento y monitoreo de protección de APIs a cualquier escala. ¿Esto qué quiere decir? Que va a ser el puente entre el backend y el frontend mediante métodos GET, POST, options o delete, mediante distintas etapas que vayamos creando, ya sea para un ambiente productivo, para un ambiente de desarrollo. Además podemos agregar métodos de autenticación como lo es Cognito, eso lo veremos un poquito más adelante en la demo que les estaré presentando. ¿Continuando con la presentación, lo que les voy a platicar es cuál es el alcance de Lambda, de acuerdo? Como pueden ver aquí hay cinco de los lenguajes principales en los cuales se enfoca lambda, estos son node, js de la versión 12 a la 14, go en su versión 1, python de la versión 3.6 a la 3.9, c en la versión 6 y java de la 8 a la 11. ¿Ojo, aquí hago hincapié que aunque estas versiones las estoy mencionando, no son permanentes, esto qué quiere decir? Que las versiones más viejas AWS las va a ir descontinuando conforme vaya pasando el tiempo por obvias razones y va a ir actualizando también para que se agreguen las nuevas versiones de cada lenguaje, pero es algo que debemos de tener en cuenta como programadores, el siempre estar actualizados a las últimas versiones estables de cada lenguaje de programación que AWS Lambda requiera. Dando un paso más adelante y continuando con los servicios tradicionales dentro de AWS, nos vamos a enfocar en tres servicios, ¿De acuerdo? Los dos servicios si se ven, si se fijan en la parte de arriba, como con un color rosado, es porque son servicios de mensajería, ¿De acuerdo? Son servicios de desacoplamiento de aplicaciones. ¿A qué me refiero con el desacoplamiento? A que una función o un mensaje en específico se desacople para realizar dos funciones distintas, ¿De acuerdo? Siempre que pensemos en desarrollar una aplicación, ya sea web o ya sea una aplicación normal, tenemos que pensar siempre en el desacoplamiento para que si un stage falla, tengamos todavía el otro en pie. Empecemos por el primer servicio que es el Simple Queue Service, que es el servicio de colas administradas dentro de AWS, que como ahí lo indica, nos permite desacoplar y ajustar la escala de los microservicios, sistemas distribuidos y aplicaciones sin servidor. Este es un servicio de uno a uno, ¿A qué me refiero? A que es desde un solo productor hasta un solo consumidor, pero es importante indicar que es un servicio de colas únicamente de mensajes de texto, ¿De acuerdo? Lo que vamos a mandar entre productor a consumidor simplemente va a ser un mensaje o una cadena de texto, ¿De acuerdo? Y esto nos va a permitir la comunicación entre aplicaciones. También es importante indicar que si este mensaje no se procesa correctamente, podemos virar por hacer otra cola que sea una deadletterqueue, que no es más que una cola de mensajería muerta a la cual podamos recurrir en caso de que nuestro mensaje no se procese correctamente. Me voy a la DeathletterQueue y veo por qué no se procesó ese mensaje correctamente, ¿De acuerdo? Eso en cuanto al servicio de SQS. En cuanto al segundo servicio de mensajería, tenemos lo que es el Simple Notification Service, que como lo indica aquí, es un servicio de mensajería completamente administrado para la comunicación de aplicación a aplicación o de aplicación a persona. ¿Qué cosas es importante indicar de este servicio? Que al igual que el anterior, es un servicio de mensajería, pero ya no tanto enfocado a lo que son los mensajes de texto convencionales, sino un poquito refiriéndonos a otras cosas como lo pueden ser las notificaciones, por eso se llama Simple Notification Service. ¿Qué tipo de notificaciones? Pues podemos mandar notificaciones push a móviles, a correos electrónicos y a mensajes de texto SMS, ¿De acuerdo? A diferencia de lo que es el Simple Queue Service, Simple Notification Service sí permite que un solo productor mande a distintos consumidores un mismo tópico, incluso en el mismo icono de lo que es el servicio, se ve bien representado que

es

un solo productor, manda distintos suscriptores, ¿De acuerdo? Y es aquí un poquito lo que hablábamos del desacoplamiento. Más adelante veremos una arquitectura en la cual se utiliza y se puede ver mejor esa ramificación, ¿De acuerdo? Por tercero, el servicio que les voy a hablar es Amazon s, que es el Simple Storage Service. Si ya tienen un poquito de idea de lo que es la nube de AWS, han escuchado de Amazon s, que al igual que Amazon EC o al igual que AWS Lambda, son de los servicios más conocidos dentro de la nube. ¿Y por qué es conocido Amazon s? Porque a diferencia de los dos de arriba, no es de mensajería, es de almacenamiento. Y muchas personas en el día a día, al pensar en la nube, lo primero que se les viene a la cabeza es pensar en almacenar objetos en la nube. ¿Creen que sólo funciona para eso? Y sí, es una de las funcionalidades principales, obviamente abarcando servicios. Pero ¿Qué nos ofrece este servicio de almacenamiento de objetos? Pues nos ofrece escalabilidad, nos ofrece disponibilidad de datos, nos ofrece seguridad y es uno de los servicios líderes en el mercado en cuanto almacenamiento en la nube se refiere. Otra cosa importante a recalcar dentro de Amazon s es que cuenta con distintas capas de almacenamiento, desde algunas más frías como lo es Glacier, hasta otras más calientes como lo puede ser los tipos de almacenamiento estándar. ¿A qué me refiero con estas temperaturas? A que Amazon s cuando nos hablamos de un almacenamiento Glacier, es un almacenamiento de objetos que no se va a estar retribuyendo, que no lo vas a estar descargando, funciona más para históricos de archivos que no vas a estar consultando y por lo tanto, al simplemente tenerlos almacenados, pues el costo se va a rebajar a una cantidad exageradamente absurda de lo pequeña que es. En cambio, en un almacenamiento estándar, que si vamos a estar retribuyendo y descargando los datos, pues el costo se eleva un poco, ya que vas a estar trayéndote la información desde la nube hasta el cliente que la consuma. Esto en cuanto a servicios tradicionales serverless se refiere. Dando continuidad a la presentación, pues vamos a hablar de una de las funcionalidades principales cuando hablamos de conjuntar dos servicios serverless dentro de la nube de AWS, ¿De acuerdo? Ya les hablé de dos de los servicios tradicionales más importantes que es Lambda y apigeateway. Pero ¿Cómo puedo crear una aplicación que haga una sinergia entre ambos servicios? Pues aquí queda bastante bien explicado, dice, Puede crear un API Gateway Web con un punto de enlace HTTP para la función Lambda utilizando Amazon API Gateway. Amazon API Gateway dispone de herramientas para crear y documentar APIs web que enruten solicitudes HTTP a funciones Lambda. Esto se ve ejemplificado de bastante buena forma en el diagrama de aquí abajo, en el cual tenemos una aplicación que es consumida por los clientes a un servicio web. ¿Quién es el primero que lo va a detectar? El API. ¿Por qué? Porque es la comunicación entre el frontend y el backend. Entonces, API Gateway va a detectar lo que es el método, ya sea GET, POST o delete, y va a llamar esta función Lambda, que es el backend de nuestra aplicación, para que se encargue de procesar la información correspondiente o de ejecutar la función que haga lo que tenga que hacer, devolver al valor que HTTP que la API Gateway lo detecte y devolverlo a lo que es el cliente. ¿De acuerdo? Entonces API Gateway va a ser el intermediario de estos métodos getPost o delete de nuestro backend en una función Lambda. Dando continuidad a lo que es la presentación, vamos a ver los servicios de última generación serverless. Aquí vamos a hablar de dos, que si bien ya tienen tiempo dentro del mercado de AWS y ya los consumimos dentro y ya los implementamos en CompuCloud con algunos clientes, son aquellos servicios donde nuestros clientes suelen tener la mayor cantidad de dudas. ¿Que es AWS Fargate? Que es un motor informático sin servidor de pago por uso que permite centrarse en la creación de aplicaciones sin tener que administrar los servidores. ¿A qué nos referimos con esto cuando hablamos de contenedores de Dockers? De por sí es una tecnología que no muchos clientes están familiarizados, pues el hablar de contenedores serverless es todavía más un dolor de cabeza, pero realmente facilita mucho lo que es el trabajo con contenedores. Mientras trabajar con contenedores que sí lleven algún servidor es bastante, bastante tedioso, ya que te tienes que preocupar también por aprovisionar lo que es la instancia con su sistema operativo, con sus grupos de seguridad, con sus permisos correspondientes, AWS Fargate dice no, no, olvídate de eso y vamos a levantar distintos contenedores sin la necesidad de preocuparnos por aprovisionar servidores o instancias dentro de AWS. Esto si se fijan es un icono un poquito distinto a los que ya hemos visto, porque como tal AWS Fargate no cuenta como un servicio solitario dentro de AWS, realmente es una capa adicional que se encuentra dentro del servicio de SS, que es el servicio de contenedores de AWS. Por su contraparte y no teniendo mucho que ver la verdad, está Amazon DynamoDB. ¿Que DynamoDB? Pues ya muchos han de conocer la cantidad de bases de datos que se manejan dentro de AWS. Dentro de AWS tenemos una inmensa cantidad de bases de datos dependiendo de sus necesidades, como lo pueden ser RDS, que van un poquito más allá de las bases de datos relacionales comunes, que viene a ser Aurora, que es también para bases de datos relacionales con servidor y sin servidor de los motores MySQL y Postgres, que te ofrece mayor rendimiento y mayor escalabilidad. Pero ¿Qué hay de aquellos clientes que están preocupados o que están desarrollando sus aplicaciones con bases de datos no SQL? Pues Amazon DynamoDB es la solución. ¿Por qué? Porque es una base de datos no SQL, sin servidor y completamente administrada por AWS, que nos permite ejecutar aplicaciones de alto rendimiento a cualquier escala, basándonos en tablas de objeto clave valor, en las cuales con un par de clics ya van a estar aprovisionadas, simplemente estableciendo una clave principal que va a ser nuestro identificador principal de cada una de las tablas, incluso si lo vemos necesario también establecer un index secundario. De acuerdo, entonces dando continuidad vamos a pasar a la siguiente fase que es AWS Amplify. AWS Amplify es un conjunto de herramientas y características específicas creados para los desarrolladores web y móviles. Aquí es importante recalcar que es tanto de frontend como de backend de las aplicaciones, ¿De acuerdo? Entonces nos ayuda a aquellas aplicaciones que estén desarrolladas en React, crear un ciclo de despliegue continuo en el cual aprovisionemos un servicio web de manera fácil para todos nuestros desarrolladores. Este servicio va a ser bastante importante en la demo y lo vamos a ver más adelante. Ahora sí, pasando a los casos de uso dentro de AWS, vamos a ver algunos principales, vamos a ir un poquito rapidito para pasar al tema de la demo. De acuerdo, en este caso vemos dos arquitecturas, aquí queríamos hacer la comparación entre una aplicación tradicional y una aplicación serverless, en la cual si se fijan tiene algunas similitudes pero a la vez tiene muchas diferencias. En la parte de arriba en ambas arquitecturas tenemos la parte de Ruta 53, el icono de hasta arriba de la aplicación tradicional es ruta 53 y a la derecha también tenemos ruta 53. En la parte de abajo tenemos lo que es una CDN con CloudFront en la parte derecha también, pero a partir de ahí abajo ya es cuando se notan las diferencias. Del lado izquierdo en una aplicación tradicional tendríamos que configurar una VPC que sería una red privada virtual con sus servidores y su grupo de autoescalamiento pero va a ser tanto el backend como el frontend en esa misma instancia y se puede saturar por la cantidad de usuarios. De acuerdo, tenemos que hacer muchas configuraciones dentro de los grupos de seguridad y de los grupos de autoescalamiento y nos tenemos que preocupar porque el rendimiento de las instancias sea el máximo, esto conectado con una base de datos. También en una instancia RDS que sería una mysql nos tendríamos que preocupar por los grupos de seguridad y porque nadie entre dentro de las vulnerabilidades de nuestra base de datos. Pero por la contraparte del lado derecho tenemos un frontend en un bucket estático de Amazon s y aquí es donde vemos un poquito lo que ya les había platicado, la comunicación entre el frontend y el backend va a ser con ayuda del API Gateway con la función lambda la cual va a funcionar única y exclusivamente cuando se necesite como backend de nuestro aplicativo. Podemos hacer un procesamiento de imágenes en el bucket DS que está en la parte de abajo o incluso podemos almacenar nuestros datos en una base de datos Dynamo no SQL que también es serverless. Y así cumplimos con una aplicación web completamente administrada y serverless que nos va a reducir los costos, nos va a tener nuevas tecnologías y nuevas ventajas sin tener que preocuparnos por administrar servidores como lo sería la parte de la izquierda. Dando continuidad entonces nos vamos a la parte de la derecha a la siguiente diapositiva en la cual tenemos otras dos arquitecturas una aplicación web que es bastante similar en la cual tenemos el backend en el API Gateway con distintas funciones, ahora no solo es una, sino es una lista de funciones que va a estar llamando el API Gateway también conectados a una base de datos serverless. Pero ¿Que cambia aquí? Que se agrega un método de identificador de usuarios como lo es Cognito y un frontend en la consola de Amplify conectado a un repositorio Git. Esto se va a ver un poquito más reflejado en la demo que les mostraré más adelante. Y del lado derecho tenemos una arquitectura todavía más robusta, pero en vez de ser una aplicación web, que no es solo el objetivo de serverless, también funciona para el procesamiento de datos, en el cual aquí ya vemos una sinergia entre lo que es el servicio de Simple Notification Service, que envía una notificación a los colas de SQS para que ejecute el mismo mensaje, dos funciones distintas, una en la parte de arriba, en la cual es una función lambda que se encarga de convertir el texto que le trajimos a un texto en HTML y otra en la parte de abajo que es un análisis de sentimientos con el servicio de Comprenhead. Ahí ya nos metemos a temas mucho más avanzados de inteligencia artificial. Y si se fijan, tanto en la parte de arriba como en la parte de abajo, replicamos íconos porque estamos mandando los mensajes no procesados a una Dead letter queue, la cual va a ser notificado al usuario mediante el Simple Notification Service. Esto eran los casos de uso de Serverless. Ahora procederemos a realizar una pregunta hacia ustedes que sería ¿Actualmente tienen proyectos de desarrollo que crean que califiquen para servicios serverless? Si me pueden ayudar contestándola, ahí está, Sí estoy por generar nuevos proyectos, apenas estoy conociendo la tecnología o me gustaría tener una consultoría previa. Si nos ayudan por favor, de la manera más amable contestando esta pregunta. ¿OK, estamos viendo que la segunda opción está ganando por diferencia y qué bueno, se están adentrando todavía a este mundo y quién mejor que compuclo para ayudarles a hacer este viaje, de acuerdo? Muchas, muchas gracias por ayudarnos a contestar esa pregunta. Entonces pasaríamos rápidamente a lo que es el tema de la demo. En esta demo vamos a ver una arquitectura similar a la cual ya vimos en las arquitecturas anteriores. ¿Esta demo funciona como, sonará un poco chistoso, pero no es más que un aplicativo web que es como un Uber de unicornios, de acuerdo? Completamente ficticio porque sé que los unicornios no existen en la vida real. Tenemos la parte del frontend con lo que es AWS Amplify en un ambiente desarrollado por completo en lenguajes de etiqueta como lo es HTML y CSS para el diseño. Y ya las funcionalidades más principales con JavaScript tenemos una autenticación de usuarios como lo es Amazon Cognito que nos va a ayudar a identificar a los usuarios, a la parte del registro, a la parte de la autenticación y a la parte de la autenticación también a las llamadas a la API y por la parte de abajo unas llamadas API dinámicas con Amazon API Gateway que va a estar llamando a una función Lambda, que esa función Lambda va a ser el backend de nuestro aplicativo que se va a encargar de llamar a estos unicornios y todas estas llamadas se van a ejecutar y se van a almacenar en una base de datos DynamoDB, de acuerdo, procederé a proyectarles lo que es la demo que les estoy comentando, de acuerdo, si me dan un momento procederé a compartir mi pantalla, De acuerdo, ahorita deben de estar viendo lo que es la consola de AWS, de acuerdo, aquí lo que vamos a ver es que dentro de la consola de AWS con los cambios recientes en la consola podemos ver que están distintos servicios utilizados recientemente que son todos los de la arquitectura amplify, cognito, dynamo, apigeateway, code commit y lambda. ¿Procederemos a ejecutar la demo y ahorita les explicaré cómo es que funciona correctamente, de acuerdo, entonces este es el servicio de Amplify, dentro del servicio de Amplify tengo un sitio que se llama wheelwrights, de acuerdo, que no es más que la demo o la página web que vamos a estar demostrando, no es más que un servicio de hosting Amplify en el cual está conectado con un repositorio el cual detecta los commits recientes y cada vez que detecta un commit nuevo se va a encargar de aprovisionar, compilar, implementar y verificar una nueva página, de acuerdo, entonces tenemos aquí la URL que nos vamos a estar metiendo en ella? ¿Aquí si pueden ya ver lo que es la demo que es una página web desarrollada y lo recalco porque es bastante impresionante, completamente serverless sin la necesidad de aprovisionar ningún recurso informático, todo con tecnologías serverless, esto sería la página principal, de acuerdo, entonces lo que vamos a hacer aquí es demostrar dos cosas, la primera es el diagonal register que se fijen que nos lleva correctamente a lo que es la página de registro y en esta página de registro lo que está detrás que lo mostraré más adelante es todo lo referente al registro de la página con Amazon Cognito, de acuerdo? Podemos poner nuestro email, nuestra contraseña, confirmamos nuestra contraseña y después de esto manda un correo al email que pusimos aquí para terminar el registro como cualquier otra página en la cual nos podamos registrar, de acuerdo, Todo esto desde la parte de Cognito. ¿Después tenemos la parte de RAID que es donde se realizan los viajes, en esta página de RAID vamos a loggearnos también con ayuda del servicio de Cognito y lo que vamos a hacer es poner el usuario que es el email y la contraseña que establecí previamente, le doy en ingresar y lo que va a pasar ahora sí es llevarme a este uber de unicornios que les mencioné anteriormente, de acuerdo? ¿Entonces aquí lo que podemos ver es un mapa del mundo que ahorita está cargando, si se fijan nos mostró en Seattle, pero realmente pues puedo pedir unicornios de cualquier parte del mundo, por ejemplo desde México, desde Guadalajara que es donde nos localizamos, coloco un puntero y en la parte lateral derecha, superior derecha puedo pedir un unicornio, de acuerdo? ¿Le doy en Request Unicorn y lo que va a pasar es que un unicornio viaja directamente hasta nuestra ubicación, un unicornio blanco llamado shadowfax y ese unicornio está completamente en nuestra ubicación como si fuera un Uber, de acuerdo? ¿Recalco, esto es completamente serverless sin la necesidad de aprovisionar ningún servidor o algún servicio que requiera de algún servidor, esto como tal es la demo del servicio, pero rápidamente navegando entre ellos puedo ver lo que es Cognito, puedo administrar los grupos de usuarios, ver que tengo aquí la demo que es Wild Rights y aquí dentro de los usuarios y grupos puedo ver lo que es mi usuario que es el único usuario creado dentro de la aplicación, de acuerdo? Entonces como si se fijan pues a esto nos ayuda Cognito a tener un identificador de usuarios para las tablas tenemos lo que es la tabla donde se van a ir registrando cada uno de los viajes con Dynamo para la API vamos a tener lo que es la conexión a LAPI mediante un método POST que se conecta a la función de Lambda y el repositorio de todo nuestro código en una servicio que es Code Commit dentro de AWS, como le indico, todo esto dentro de solo servicios serverless de AWS. Entonces hasta aquí queda la demo para no consumir un poquito más de tiempo de la presentación, ahora sí cedo los micrófonos a mis compañeros para que den como finalizada esta presentación. Muchas gracias.

Muchas gracias, Carlos. Muy bien, bueno, pues este tiempo lo tenemos por si tienen alguna duda, alguna pregunta hacia lo que es el equipo que nos estuvo acompañando el día de hoy, el Ingeniero Pedro y el Ingeniero Carlos. Entonces, si tienen alguna duda o alguna pregunta sobre el tema, pueden aquí ponernos a través del chat la pregunta y de igual manera les reitero que les estaremos compartiendo más información del tema que vimos el día de hoy y también podrán consultar lo que es este webinar a través de nuestras redes sociales o a través directamente de nuestro canal de YouTube. Bien, entonces, si tienen alguna duda, tenemos aquí un par de minutos para responderla. Entonces, adelante, aquí estaremos atentos a sus preguntas. De igual manera, también les comparto lo que es la información del equipo comercial de CompuCloud, quienes pueden apoyarlos en cuanto a algún proyecto futuro o si quieren revisar algún tema en específico de lo que vimos el día de hoy o sobre algún otro tema sobre AWS. Aquí está el Ingeniero Carlos González, la Ingeniera Zadia y el Ingeniero Gabriel, quienes están a su disposición para cualquier pregunta o solicitud. Y muy bien, tenemos una pregunta que nos dice, ¿Cómo se puede medir el performance de la arquitectura desplegada para asegurar su efectividad? Si nos apoya el Ingeniero Pedro.

Gracias. Muchas gracias Jaime Medina por tu pregunta. Sí, mira, hay diversos tipos de mecanismos para poder medir lo que es el performance, pero te comento, por default los servicios serverless de AWS vienen con cuestión de monitoreo que nos provee el servicio de cloudwatch. El servicio de cloudwatch nos va a ayudar a medir todas estas métricas que maneja como tal los servicios serverless, por ejemplo, tiempos de ejecución, que nos ayuda a conocer, por ejemplo, cantidades de peticiones, tiempos de respuestas, peticiones en cola, todo este tipo de cuestiones obviamente nos ayuda. Ahí están los servicios de AWS que son totalmente compatibles. El servicio de cloudwatch es totalmente compatible con todos los servicios serverless de AWS y la capa de monitoreo ya viene embebida en lo que es estos servicios. No sé si contesté tu.

Perfecto, muchas gracias Pedro. Igual, este, si tiene alguna otra duda. Y claro, aquí nos preguntan por una cotización. Perfecto, domingo, nosotros te contactamos, igual si te encuentras en el norte de lo que es la República Mexicana, el Ingeniero Carlos puede ayudarte en esta cotización o si estás en el centro de la República, Ciudad de México, Puebla y Sur, la Ingeniera Zadia. Y si estás en la zona occidente, todo lo que es Jalisco, Guanajuato, está el ingeniero Gabriel, pero ya con tus datos, igual nosotros te contactamos. Perfecto. Domingo en Monterrey. Muy bien, entonces el ingeniero Carlos, quien está por aquí, pues te estará buscando en lo que es en unos minutos. Y también nos pregunta Francisco, ¿Cómo es el cobro de serverless?

Muchas gracias, Francisco, por tu pregunta. Sí, mira, como tal serverless, los servicios de serverless tienen, por así decirlo, un costo cada uno de los servicios, pero por lo general es el mismo esquema de cobro, ¿No? Lo que se cobra es la ejecución, o sea, nosotros mandamos una ejecución, hacemos una petición o ejecutamos el servicio, entonces se cobra la ejecución, el tiempo que dure la ejecución y la capacidad de cómputo que aprovisione para esa ejecución. Entonces, estos elementos se conjuntan y y nos da el costo de los servicios serverless. Ahora, yo te comento, tendríamos que evaluar bien tu caso para ver qué servicios serverless es el que requieres en tu particular carga de trabajo, pero los servicios serverless suelen ser muy, muy, muy, muy económicos. Para muestra, un botón Lambda nos da un millón de ejecuciones gratis. Entonces, pero sí tenemos que hacer todo un análisis, ¿No? Y fuera de ese millón de ejecuciones gratis, el costo por ejecución y por tiempo de operación que te digo que tarda en hacer esta ejecución, todo eso, pues son algo centavos de dólar, ¿No? Entonces, si gustas podemos hacer un análisis de tu carga de trabajo para que quede como más claro cuánto es exactamente lo que estarías.

Perfecto, muchas gracias, ingeniero. Y claro que sí, Omar, estaremos compartiendo la grabación del webinar, igual por si quieren volver a ver la demo o si quieren consultar algún tema en específico del que hablamos el día de hoy, pues puedan volverlo a revisar. Y de igual manera les vamos a compartir la presentación que estuvimos viendo para que también tengan esta información. Y bueno, aprovechando y agradeciendo por su participación, como les comentó el ingeniero Pedro Serrano, si quieren hacer alguna consultoría, un análisis previo antes de adoptar un servicio serverless, se pueden acercar a lo que es CompuCloud. Realizamos esta consultoría sin costo para que ustedes puedan tener una idea de cómo podría aplicarse en servicios serverless a su infraestructura actual. Y también tenemos un cupón de descuento de 200 dólares en cuanto a implementación basados en lo que son servicios serverless. Igual, este cupón se los estaremos enviando vía correo para si lo quieren utilizar y puedan seguir con lo que es alguna aplicación ya serverless. Ya después de que tuvieron su consultoría, pues también puedan aprovechar este descuento en la implementación y puedan comenzar lo que es su transformación digital a serverless mucho más rápido. Y pues, bueno, nuevamente, muchas gracias por acompañarnos el día de hoy. Les repito, les enviamos la información a través de su correo electrónico y también pueden consultar este tema sobre serverless que hemos hablado ya anteriormente para que vean desde serverless este punto 0. 1 hasta serverless 3.0 a través de todo lo que son nuestras redes sociales y principalmente nuestro canal de YouTube en donde pueden encontrar las grabaciones de webinars anteriores. Pues, muchas gracias al ingeniero Carlos y el ingeniero Pedro por acompañarnos el día de hoy y sobre todo a ustedes por regalarnos un momento de su tiempo y por conocer lo que son servicios serverless en AWS. Gracias a todos y nos vemos muy pronto. Hasta luego. Buen día.