Webinar: Incrementa la productividad de tus aplicativoscon el uso de contenedores

Muchas gracias por acompañarnos el día de hoy en el webinar Incrementa la productividad de tus aplicativos con el uso de contenedores. Esta presentación será grabada y será compartida con ustedes a través de nuestro canal de YouTube. Les pedimos de favor poner en mute sus micrófonos y cualquier duda o sugerencia favor de hacérnoslo saber a través del chat. Al final de esta presentación tendremos una sesión de preguntas y respuestas, mismas que pueden ir realizando a través del chat cuando les surja esa duda. A continuación les comparto el nombre de mis compañeros que me apoyarán a impartir este webinar, que es la Ingeniera Daniela y el ingeniero Jared Hernández, ambos Support Engineer de Cloud Computing. Bien, comencemos con la agenda del día de hoy. Hablaremos lo que son aplicaciones en forma de monolitos, como segundo punto estaremos ahondando en el tema de microservicios, tercer punto vamos a tener lo que son contenedores en la nube de AWS, el cuarto punto vamos a hacer una demo de DevOps y contenedores en AWS y por último vamos a platicar de los servicios enfocados en seguridad para los contenedores de AWS. Bien, comencemos el día de hoy platicando un poco de CompuCloud. CompuCloud es un partner especializado únicamente en Amazon Web Services. Inició sus operaciones en el año del 2012 y a lo largo de estos ocho años se ha conseguido una amplia experiencia en la implementación de los servicios de AWS y formar departamentos con ingenieros certificados y calificados con las certificaciones que se cuentan actualmente, como lo podrán ver ahí en la presentación, son Sysops, Administrator, Cloud Practitioner, Solution Architect y Developer. El año pasado AWS nos otorgó el reconocimiento Advanced Consulting Partner. Este premio como su nombre lo indica, somos el partner que mejor ha asesorado a sus clientes a lo largo del 2019, basándonos en las mejores prácticas de AWS y como consecuencia somos uno de los pocos partners avalados por AWS para hacer un estudio que se llama Well Architect y está basado en los cinco pilares de AWS que Excelencia operacional, Seguridad, Fiabilidad, Eficiencia de Desempeño y Optimización de costos. La ventaja es que al realizar este estudio se puede obtener hasta 5 mil dólares en créditos aplicables a su consola. También en búsqueda de la excelencia y seguir ofreciendo el mejor servicio a nuestros clientes, este año se consiguió la certificación de ISO 20000. Con esta norma lograremos las mejores prácticas que nos ayudarán a mejorar la prestación de servicios de TI que ofrecemos a todos nuestros clientes. Nosotros también contamos con pólizas de servicio. Esto les permite a todos el personal de TI que se dediquen a la innovación y no preocuparse por el tema operativo de la infraestructura. Bien, pues para comenzar a hablar de contenedores, vamos a andar un poco en lo que es un monolito. ¿Cuál fue el motivo de su creación? Los contenedores fue porque todas las aplicaciones y o servicios estaban concentradas en un monolito, donde si fallaba este servicio, colapsaba toda la aplicación. Por ejemplo, hablemos de una aplicación de pagos, donde está el servicio de facturación, el servicio de pagos, el comercio electrónico, el catálogo de productos, la consulta de estados de cuenta, etc. Supongamos que falla la aplicación de estado de cuentas que no se pueden descargar o la aplicación de pagos. Esto en un monolito se tendría que revisar todas las líneas de código y detectar en cuáles hubo una corrupción, ya que una línea podría afectar a los demás servicios y esto obviamente generaría caídas por completo en el servicio. El tiempo es valioso para todas las empresas, sin embargo, en un contenedor con un microservicio, la historia sería completamente diferente. A continuación dejo a mi compañero, el ingeniero Jared, que nos explique cómo comenzó el tema de contenedores, pero vamos a hablar primero de el desacoplamiento de aplicaciones. Adelante Jared.

Muchas gracias, Ingeniero David. Gracias a todos por acompañarnos en este webinar. Yo les voy a venir hablar acerca del desacoplamiento de aplicaciones, entre otros puntos. Bueno, primero, ¿Qué es el desacoplamiento de aplicaciones? Como bien mencionó el Ingeniero David, antes se tenían monolitos, es decir, toda la lógica del negocio estaba centralizada y estaba en forma de código, tras código, tras código. Entonces, lo que hace el desacoplamiento de aplicaciones es dividir las funcionalidades del código en pequeñas funciones totalmente independientes y que tienen comunicación entre ellas para resolver un conflicto y así crear esta lógica de negocios totalmente enfocada a microservicios o desacoplamiento. ¿Qué ventajas tiene? Bueno, elimina el único punto de fallo, es decir, si falla una parte de la aplicación, por ejemplo, falla la parte de clientes, solo los desarrolladores van a ir hacia este microservicio, hacia esa funcionalidad a la cual la van a componer. Te ofrece mayor escalabilidad. ¿Por qué? Porque es más fácil levantar más máquinas que tengan este servicio que levantar monolitos enteros y es más fácil trabajar en actualizaciones, es decir, nuestro equipo de desarrollo puede trabajar en mejoras solo en la parte cliente sin afectar a lo que ya se tiene en cuentas y préstamos. Esto con un monolito no sería posible, ya que como todo el código está en una sola función como tal gigantesca, se tiene que modificar partes de la misma afecta directamente a todas las partes. A continuación vamos a hablar acerca de lo que son microservicios, OK, y en este desacoplamiento de aplicaciones se hace a través de lo que se vendría llamando microservicios. Los microservicios se pueden realizar en dos formas principalmente, en la forma de contenedores, como lo veremos el día de hoy, o en la forma de serverless. Estas se diferencian en que los contenedores trabajan bajo un motor de contenerización y los aplicativos serverless trabajan sin servidor, por ejemplo, en los microservicios es un estilo de arquitectura software enfocado a servicios pequeños e independientes. Como les platicaba, esta parte independiente es importante ya que para no afectar a todo el aplicativo si hay un fallo en alguno de esos microservicios, se tiene que tener esta independencia. ¿Cómo se puede manejar la comunicación? Bueno, a través de llamadas, APIs de tipo SOAP, de tipo REST, etcétera. A continuación vamos a hablar acerca de qué son los contenedores. ¿Y bueno, qué son los contenedores a final de cuentas? Bueno, software empaquetado en unidades estandarizadas. Esto es importante ya que una de las grandes ventajas es de lo que vendría siendo un contenedor, es que van a llevar un estándar, es decir, antes se tenía el dicho entre los programadores de que OK, funciona en mi máquina y luego no funciona en el servidor con contenedores, este dicho se acabó, ya que si funciona en tu máquina que tiene instalado Docker y tú lo contenerizas, va a funcionar perfectamente igual en un servidor, ya sea en un datacenter o en cualquiera de las nubes, incluyendo Amazon Web Services. Por cierto, Amazon Web services tiene el 80 % de los contenedores en la nube y tiene clientes tan importantes como Samsung, Xperia, KP, MG y Snap. ¿Entonces, por qué lo eligen? Bueno, por la seguridad, fiabilidad y escalabilidad que ofrece Amazon Web Services al trabajar con contenedores. A continuación hablaremos acerca de las diferencias entre las máquinas virtuales y los contenedores. Bueno, estas dos tecnologías muchas veces la comparan como si fueran enemigas, en realidad pueden ser un complemento. ¿Cuál es la diferencia entre una máquina virtual y un contenedor? Simplemente que la máquina virtual necesita un software llamado Hypervisor. Este Hypervisor lo que va a hacer es emular hardware para correr sistemas operativos dentro de ese hardware emulado, o sea, todo es software al final de cuentas, si tú quieres levantar tres aplicativos diferentes en máquinas virtuales, tienes que montar tres sistemas operativos diferentes, todos estos con sus librerías y sus bibliotecas de dependencias de las aplicaciones y sobre ellas montar las aplicaciones como tal. ¿Esto que hace? Que sea muy lento el reinicio y la eliminación de una máquina virtual, por lo cual, al igual que pesado, ocupa muchísimos recursos lanzar una máquina virtual. En cambio un contenedor no, ¿Por qué? Porque solo está el sistema operativo base que puede ser ya sea tu máquina, una máquina de AWS o y arriba el motor del contenedor, que vendría siendo Docker, ya que es el motor más importante y que lo seguirá haciendo a lo largo de los años. Después de eso ya tenemos nuestros contenedores junto con nuestras aplicaciones. Esto a nivel sistema operativo se va a traducir en un proceso en lo que vendría siendo Windows o en un daemon en lo que vendría siendo Linux. Entonces es simplemente eso, no está simulando ningún hardware, por lo cual desplegar más contenedores del mismo aplicativo es de una manera muy sencilla y muy rápida. A continuación vamos a hablar acerca de las ventajas de los contenedores. Bueno, como les vengo platicando, no se necesita ningún tipo de virtualización de hardware, es muy rápido a la hora de escalar, como les comento, al no emular hardware ni tener un hypervisor como tal y no tener esta, ahora sí que aprender el sistema operativo o apagarlo, es muy fácil, tanto crear más contenedores de la misma aplicación como eliminarlas, se eliminan casi al instante. Portabilidad, Esto es súper importante como les comento, cómo se va a ejecutar tu aplicativo a nivel local, se tiene que ejecutar a nivel AWS u otro servidor y es muy fácil adaptar un ciclo DevOps. Ya con un ciclo DevOps vamos a tener lo que vendría siendo el desarrollo, las pruebas y el despliegue, el lanzamiento o despliegue de una manera automatizada y es muy sencillo desplegar nuestro aplicativo a través de un ciclo de bops, como lo vamos a ver en la demo, a través de contenedores. A continuación hablaremos del motor más importante que se llama Docker. Bueno, ¿De qué se encarga Docker? Es el software que te permite empaquetar, ahora sí que tu aplicativo a contenedores. Este es el motor que hace la magia y el motor que crea estos contenedores. Se puede implementar y ajustar la escala de aplicaciones rápidamente y vas a tener la certeza de que tu código se va a ejecutar tal cual y lo estás creando. Entonces ya se eliminó toda esta complejidad de montar un servidor, instalar y hacer estas pruebas de que funcione como está en tu máquina local. A eso es lo que apunta Docker con la tecnología de contenedores. A continuación vamos a hablar acerca de otro software súper importante a la hora de trabajar con contenedores, que es el orquestador. Como bien dicen, el orquestador vendría siendo el administrador de los contenedores. Se encarga de administrar lo que vendría siendo la ejecución de tus contenedores. ¿Por qué? Porque si vas a tener tu infraestructura trabajando en microservicios, vas a tener algo que se denomina clústeres. Clústeres van a ser como pequeños paquetes donde adentro vas a tener tus contenedores. Y para administrar tantos, supongamos que tiene 700 contenedores. Entonces, para hacer esa administración y que tanto la infraestructura de redes, cómputo y almacenamiento trabajen de manera adecuada, se necesita un orquestador. ¿Cuál es el orquestador más famoso del mercado? Bueno, es el de Google, se llama Kubernetes. AWS también cuenta con esta tecnología de Kubernetes, con un servicio AWS llamado EKS. Este servicio, por ejemplo, si su equipo ya está muy acostumbrado a trabajar con Kubernetes, pues puede seguir trabajando con esta tecnología en Amazon Web Services gracias a este servicio. También AWS ofrece su propio servicio de orquestador que se llama AWS SS Elastic Container Service. Este vendría siendo el reemplazo de Kubernetes de enfocado totalmente inactivo a AWS. A continuación vamos a hablar acerca de los servicios. OK, estos son los servicios de AWS enfocados a contenedores. Bueno, para empezar tenemos el inicio de toda la magia que vendrá siendo Docker. Después se va a la parte de SR. SR es Elastic Container Registry, es decir, lo que hace SR va a ser registrar tu imagen de local que tienes en tu computadora local o en tus servidores locales a AWS, entonces ya para que lo tengas en un repositorio de AWS. Después tú vas a elegir tu orquestador de contenedores, ya sea SS o Amazon EKS como les platiqué en el anterior es el administrador de todos tus contenedores, cualquiera de los dos que elijas son compatibles con la máquina sobre la cual va a estar corriendo tus contenedores, porque necesitas una máquina pero AWS te ofrece el servicio serverless que vendría siendo Fargate o un servicio más tradicional de una máquina virtual que vendría siendo s Es importante recalcar, no es que estés ocupando como tal tu aplicativo en una máquina virtual, sino que esos contenedores necesitan vivir en algún lado, si ocupas EC, o sea una máquina virtual de Amazon ese va a ser como que tu base la cual vas a montar tus clústeres de contenedores, si ocupas Fargate tú ya no te vas a preocupar por lo que vendrían siendo elegir familias de Amazon EC, tú lo que te vas a preocupar es decir OK, este task definition, definición de tarea vendría siendo tu aplicativo o tu microservicio, por ejemplo clientes, OK, mi microservicio clientes necesita para ejecutarse 2 GB de RAM y un virtual CPU OK, la de facturación necesita 4 gigas de RAM y 2 virtual CPU entonces tú apartas pero ahora sí que totalmente servicios de procesamiento tanto de CPU como de memoria RAM, eso es lo que tú apartas en Fargate, no apartas máquinas. A continuación vamos a ver una pequeña demo donde les voy a explicar más o menos cómo funciona esta magia de Docker y de contenedores en lo que vendría siendo AWS. Ya estoy compartiendo pantalla OK, bueno aquí tengo un aplicativo hecho en Node JS Node JS es un runtime de JavaScript para el servidor en el cual es una simple API REST que mandas a llamar a través del método httpGet, dos rutas y te trae un mensaje OK, lo primero es que ya tengo el aplicativo corriendo de manera local, perfecto, lo que vendría siendo después es crear una imagen de Docker, en la imagen de Docker elegimos el runtime de programación que queramos utilizar, existen distintos runtimes compatibles, la mayoría de hecho todos son compatibles, antes no era compatible la tecnología NET porque no existían Windows Containers pero ahorita ya existen entonces también ya es compatible un la Tecnogade.net eliges el directorio donde vas a guardar todo tu registro de aplicaciones, todo lo que hace tu aplicativo y lo que guarde en disco lo va a guardar en este directorio. Vamos a copiar el package JSON, este package JSON en node js significa las dependencias que va a utilizar tu aplicativo, aquí va a depender totalmente del lenguaje de programación y el runtime que estés corriendo. ¿Después yo elijo el comando npm install que se ejecute, este npm install lo que hace es instalar todas las dependencias que encuentran package JSON Después digo que ejecute este comando que hace que mi aplicativo node js corre en modo producción, pongo el puerto en el cual se va a ejecutar, en este caso 8080 y por último corro un comando de CLI el cual es node arcjs porque es el nombre del archivo que va a contener mi ejecutable main de node js que vendría siendo la API rest Después nos pondremos a escribir estos ciertos comandos, lo primero que haremos es irnos a docker login pero antes tenemos que irnos a la parte de AWS de Amazon sr crear un repositorio, en este caso ya tengo un repositorio, qué te da este repositorio? Te da un URI, una URL, entonces esta URL la copias y va a ser la URL del registro donde se van a guardar tu imagen local a una imagen externa, en este caso de AWS. Es importante recalcar que estos comandos es necesario tener el AWS CLI versión 2, no importa si es 2.0, 2.1 pero la versión 2 después lo que haremos es crear la imagen a través de este aplicativo, por ejemplo nos tenemos que ir al directorio donde está esta aplicación, poner el comando build t significa ponerle un título, en el caso será el nombre de la imagen, dos puntos y el tag, por ejemplo una convención al usar la parte de docker es poner siempre latest significa como la última versión, después el espacio y el punto, el espacio punto significa que va a crear la imagen o va a buscar el dockerfile en la carpeta donde estamos, por eso es importante ir al directorio, si no estamos en el directorio en lugar de este punto será un path de tu computadora. ¿Después crearemos otro docker tag pero ahora también con la URL del registro, es decir esta dos puntos y el mismo tag que pusiste en el inicio en el de arriba y por último vamos a hacer un docker push de este tag qué va a hacer ese docker push? Bueno, por ejemplo aquí en el Node test tenemos varias imágenes, cada una de estas fueron ahora sí que empujadas o subidas a través de ese comando por si quieres trabajar en actualizaciones. Después de esto vamos a checar lo que son los Task Definition. Un Task Definition vendría siendo un blueprint sobre el cual se va a montar este microservicio, por ejemplo en caso de esta PIREST, si vemos el JSON tiene información como el puerto, el puerto del contenedor y el puerto del host, tiene información acerca también de los gigas, de los gigas que se van a ocupar de cuánta CPU, en este caso yo le puse 512, etcétera. Toda esta información es que a partir de de esa imagen registrada yo creo este Task definition que va a decir OK, esa imagen registrada va a tener estos valores tangibles, es decir estos dos virtual CPU, este giga de RAM. Después nos proponemos a crear un clúster, dentro de este clúster creamos lo que vendrían siendo servicios. ¿Qué son los servicios? Vendría siendo la ejecución de estas task Definitions, por ejemplo, me pide por ejemplo el servicio cuántos tasks, es decir, cuántos contenedores vamos a estar corriendo, si ven aquí me pide elegir mi Task definition como tal. También es importante mencionar para que funcione, por ejemplo si tengo cinco contenedores o cinco aplicativos de microservicios de clientes necesito un Application Load Balancer para balancear la carga y que no se sature solo un contenedor. Esto es muy fácil de realizar con lo que vendría siendo AWS. Por último, como la parte del demo que es de DevOps, ustedes pueden crear un pipeline. ¿Qué es un pipeline? Bueno, este es otro servicio AWS que se llama AWS Code Pipeline, simplemente vendría siendo la definición de fases para que se haga un despliegue automatizado de tu aplicativo, por ejemplo en el más sencillo de los casos se puede realizar de tres fases. El source, que es decir, ¿De dónde voy a traer este código? Este código como tal, OK, yo lo voy a traer de mi GitHub. Es importante señalar que AWS también tiene su propio controlador de versiones basado en Git que se llama, o más bien repositorio de Git que vendría siendo Code Commit, trabaja sobre la misma tecnología Git, entonces los comandos son iguales, así que si tienen un equipo de desarrollo y van a trabajar en AWS se le recomienda que trabaje con code commit. En este caso también podemos trabajar con el más popular que es GitHub. En la parte de build son los comandos que se tienen que meter en un jam, en este caso le puse buildspec jam por convención. En este comando es donde se realizan, si ven, los mismos comandos en fases de lo que hicimos de manera local, pero ahora lo va a hacer directamente en AWS, Es decir, le decimos OK, antes de crearlo plogueate, después ya cuando lo estás creando, crea la imagen, asignale un tag y después de que la crees tú, haz un push, despliega la imagen en SR y por último créame un image definition. Un image definition no es más que un JSON que te va a traer el nombre del aplicativo del task definition y la URL que te da este push, ese vendría siendo la magia. Después todo eso con el comando printf lo que haces es pasarlo a un JSON, a un archivo JSON y por último lo guardas en un artifact que vendría siendo el resultado de un build, un artifact para posteriormente hacer un deployment a través de Amazon SS, que lo que busca es este image definition, dice OK, hay una nueva imagen registrada, entonces todo lo de mi clúster aquí guardado en esta tarea, entonces ya no quiero ocupar la versión anterior, quiero ocupar la última. Y así es como funciona un despliegue continuo, un ciclo DevOps en lo que vendría siendo Amazon Web Services con contenedores. A continuación les voy a mostrar lo que vendría siendo un diagrama de lo que les enseñé, cómo se ve de manera, ahora sí, en forma de diagrama, es algo así muy sencillo. Tenemos nuestros usuarios, primero nuestros desarrolladores crean la imagen de Docker, la registran en SR, nuestros usuarios van a entrar a una application load balancer que está en una red pública para que entren todos a través de Internet, y esa public subnet va a tener un security group, la cual va a estar enlazada con la private subnet y dentro de esa private subnet voy a tener mis contenedores de mi aplicativo. ¿Esto qué ventajas tiene? Bueno, pues nadie va a entrar directamente al contenedor como tal, sino que para entrar a lo que vendría siendo la aplicación tienes que entrar a mi balanceador de cargas, que ese sí está público. Bueno, esto sería todo de mi parte, a continuación viene la ingeniera Daniela que les va a hablar acerca de seguridad en contenedores. Muchas gracias.

¿Qué tal? Buenos días. Bueno, ahora vamos con el quinto y último tema que es Acerca de servicios de AWS enfocados en seguridad para los contenidos Es importante tener presente que la seguridad es uno de los pilares principales en una buena arquitectura y sin embargo quizás es uno de los que en ocasiones más se deja olvidado. Por ello a continuación les voy a hablar acerca de dos servicios que pueden proporcionarnos una capa de seguridad adicional tanto a las aplicaciones como al acceso de nuestros recursos. El primer servicio es Web Application Firewall, este es un servicio que básicamente es un firewall a nivel de aplicación web que monitorea las peticiones, en este caso HTTP, quizás las llamadas a APIs, con la finalidad de poder prevenir ataques web comunes mediante un control de contenido basado en reglas. Estas reglas de seguridad se encuentran previamente configuradas ya sea desde de la Marketplace o algunos partners adicionales de AWS. Y bueno, estos servicios o estas reglas nos permiten tener un mayor control en el tráfico web que vamos a tener en nuestra aplicación como tal. Hablando acerca de las reglas, tenemos reglas que nos permiten bloquear todo el tráfico de ciertas IPs, así como poder permitirlas básicamente pueden generar un filtrado de estas IPs. También tenemos lo que son las inyecciones SQL, básicamente estas reglas se enfocan a la protección hacia las queries para que desde la URL de nuestro navegador o del navegador en general no puedan estar generando como tal peticiones que puedan acceder u obtener información de la base de datos que se encuentra en la parte privada. El HTTP Flu, esta regla nos previene o evita el riesgo de sufrir ataques de denegación de servicios. Una vez que se encuentra o que recibe muchísimas peticiones de una misma IP, lo que va a hacer va a ser bloquear esta IP correspondiente para que no esté generando tráfico. Además de ello tenemos Scanner and Proof, que es básicamente una regla que ayuda a identificar y bloquear direcciones IP de origen malicioso, lo que hace es de que ya se encuentra, digamos que de un historial de ciertas IPs con origen malicioso, va a tomar de aquí la información para hacer una comparativa e ir detectando si les puede afectar o no el servicio. Además de ello tenemos las listas de reputación de direcciones, bueno esta es una regla que igual permite aprovechar las listas previamente existentes para bloquear las solicitudes de direcciones IP maliciosas. Y también tenemos las reglas acerca de bot maliciosos, que son reglas que evitan que los bots se estén ejecutándose en las aplicaciones, evitando que estos eludan más que nada las restricciones de la web. Hablando acerca de los beneficios de Web Application Firewall, se cuenta con una protección ágil ante ataques en la web, se dice que es ágil porque la implementación o la replicación o propagación más que nada de estas reglas tarda menos de un minuto, o sea, en el momento en que nosotros configuramos WAV y configuramos ciertas reglas específicas, la replicación de estas va a tardar menos de un minuto, es decir, vamos a estar protegidos rápidamente. También se cuenta con un ahorro de tiempo con las reglas administradas, ya que estas reglas ofrecen una protección ante los 10 principales riesgos de seguridad de los proyectos de seguridad de aplicaciones web abiertas, que igual va aunado con la parte de las reglas que se encuentran del lado derecho. Tenemos la opción o el beneficio de una visibilidad de tráfico web, ya que el servicio ofrece una visibilidad de este gráfico casi en tiempo real, lo cual puede proporcionarnos ciertos patrones, lo que nos permite configurar nuevas reglas o aunarlo a otros tipos de servicios como por ejemplo puede ser CloudWatch para generar alarmas y acciones específicas hasta ciertos eventos. También está la protección rentable para aplicaciones web, esto debido a que se va a pagar solo por lo que se esté consumiendo del servicio, así como la cantidad de reglas que se estén configurando tal cual. Y el último beneficio es la seguridad que se integra con el modo en que se va desarrollando la aplicación, esto va mucho o va muy de la mano con el proceso de desarrollo por ejemplo de un equipo de bots, los cuales pueden ir incorporando ciertas reglas.

A.

Lo largo del proyecto, de vida del proyecto, durante diferentes puntos de cadena del desarrollo, entonces se va obteniendo una protección aún más robusta. Cabe mencionar que WAV es un servicio que se tiene que implementar o ir de la mano ya sea con un balanceador, un API Gateway o un cloudfront, ya que WAV nos sirve como un primer filtrado para detectar estas solicitudes. Una vez que ya detectó la solicitud, la analizó, entonces ah OK, es una solicitud buena, la puedo dejar pasar hacia el balanceador o hacia el servicio que tengamos configurado para que esta solicitud pueda llegar directamente a la aplicación sin ningún problema. Bueno, a continuación tenemos el servicio que sería Cognito Amazon Cognito es un servicio que básicamente nos permite gestionar, administrar los usuarios, los accesorios, este se controla principalmente mediante un directorio previamente configurado, de igual forma se puede utilizar Cognito con usuarios federados, tiene integraciones tanto como por ejemplo con Facebook, Google, inclusive como ya mencionaba un directorio activo o SAM. La funcionalidad que tiene Cognito es de que va a realizar un análisis previo o una solicitud previa de inicio de sesión para que los usuarios puedan validar su autenticidad. En este caso por ejemplo si Amazon Cognito detecta alguna actividad de inicio de sesión que sea por ejemplo inusual, algún intento de sesión desde ubicaciones o dispositivos que pueden ser nuevos, le asigna un tipo de puntuación de riesgo a la actividad y le va decir básicamente OK, este es un nuevo inicio de sesión, necesito que tengas una verificación adicional o en su defecto se va a bloquear este inicio de sesión ya que no se encuentra previamente registrado. A continuación les voy a hablar un poco acerca de los beneficios de Amazon Cognito. Lo que ya venía mencionando es que Cognito se puede integrar con un directorio de usuarios que previamente se configura en la aplicación o se puede hacer una integración además de la federación de identidad, es decir, si ya tenemos un directorio por ejemplo activo, lo podemos utilizar para hacer esta integración y tener un acceso mucho más rápido. La seguridad para aplicaciones y usuarios OK, esto va mucho de la mano con el punto de que Cognito da una protección adicional para la protección de aquellos recursos vaya en los que primero se van a tener que loguear para poder acceder a los recursos que se encuentran integrados con la aplicación y obviamente en la parte de seguridad para el usuario es porque te va a pedir un doble método de autenticación cuando sea un nuevo inicio de sesión como les mencionaba anteriormente. Además de ello Cognito se encuentra basado en diferentes tipos de estándares, lo que hace que esté en compliance es uno de los beneficios que en su mayoría ofrece Amazon es de que todos los servicios estén en compliance con diversos estándares de seguridad. El control de acceso a los recursos Bueno, esto es básicamente porque les va a pedir un logueo para poder acceder, además de ello internamente se pueden configurar roles para definir qué usuario va a tener acceso a qué tipo de recurso dentro del aplicativo o de los recursos de AWS que se encuentren integrados a la aplicación. Y la parte de integración sencilla con la aplicación. La integración de Cognito simplemente requiere de un código inicial que se puede integrar tanto para dispositivos móviles, sea Android o iOS o como aplicaciones web. A continuación les voy a hablar acerca del funcionamiento de de Amazon Cognito. Bueno, como les venía mencionando, el funcionamiento de Cognito es de que va a pedir que el usuario se identifique una primera vez, esto si se encuentra previamente registrado en un grupo de usuarios, en un directorio activo, le va a proporcionar un token a este usuario para que en el segundo paso se haga un intercambio de estos tokens y decir, ah, OK, si es una identidad activa eso, una identidad válida, no hay problema, lo podemos dejar pasar. En el tercer punto va a ser que una vez que se autenticó este usuario, el usuario va a poder acceder entonces a los recursos o servicios asociados a la aplicación. Este es básicamente el funcionamiento de Cognito y es una de las bondades o ventajas que éste nos puede ofrecer, es una protección adicional que podemos tener en nuestro aplicativo si queremos tener un logueo o quizás la mejor opción en este caso sea integrar Amazon Cognito, además de que por ejemplo, los usuarios pueden de manera propia ir generando o restaurando más bien sus credenciales de una forma autónoma sin tener que estar generando o tener una administración adicional. Bueno, continuando con la última parte de esta presentación, les voy a mostrar lo que sería ya el diagrama general ya implementando los servicios de seguridad tal cual con lo que Jared les venía explicando acerca de los contenedores. Básicamente estas peticiones se generan en primer lugar hacia un DNS, digamos al dominio existente con el que se encuentra registrado nuestra aplicación. Los usuarios van a acceder a este DNS, a este dominio registro. Esta petición llega al servicio de WAV y posteriormente una vez que es analizada, pasa al balanceador. Cabe mencionar que también el balanceador nos ofrece una ventaja adicional porque ofrece protección ante ataques 2, es decir, tiene un modo de monitoreo que puede ser tanto estricto como defensivo, lo que permite ir analizando las peticiones, ver que también se encuentran en completo con ciertos estándares de seguridad y una vez que valida, deja pasar esta petición a los contenedores, en este caso nuestra aplicación. En el caso de Cognito, bueno, la solicitud se hace obviamente desde una página web, un dispositivo móvil igual a un dominio registrado para generar el logueo. Esta petición llega a una API, la API llama en este caso a un directorio de CO para hacer la autenticación, para obtener el token y una vez que se valida esta autenticación es pasada hacia la parte de Cognito y dice, OK, es una parte segura, lo puedo dejar pasar. Y bueno, ya la parte acerca de los contenedores, Jared ya se las explicó, pero este sería el diagrama y la integración de estos servicios de seguridad con la parte de contenedores. Los dejo ahora con David nuevamente para que nos de la conclusión de este webinar y una información adicional. Muchas gracias por su tiempo.

Muchas gracias, Dani. Muchas gracias, Jared. Gracias a todos por seguir aquí acompañándonos. Pues bien, la conclusión de este tema es, o podemos sacar que a medida que más organizaciones adoptan un proceso de desarrollo orientado a servicios, la contenerización se ha convertido en un método cada vez más popular para crear estas aplicaciones que sean más rápidas de implementar y más fáciles de escalar. Hoy en día, las empresas modernas buscan reemplazar las operaciones de TI tradicionales basadas en forma manual, con software que automatice los procesos de prueba, configuración y tiempo de ejecución. Y los contenedores han surgido como una tecnología habilitadora crítica para lograr esta transformación. Entonces, como consecuencia, ya lo había comentado Jared, qué se logra con el tema de los contenedores es eliminar único punto de falla, tener mayor escabilidad y es más fácil de trabajar en actualizaciones.

Bien.

A todos los prospectos que nos están acompañando el día de hoy, tenemos una promoción en el cual ofrecemos un mes sin costo en cualquiera de nuestras pólizas de soporte. Manejamos prácticamente dos pólizas de soportes, que está orientado a lo que es milésimo Quingen y lo que está orientado a al tema Enterprise. Hemos concluido el día de hoy con el webinar, pasamos a la sesión de preguntas y respuestas. Adelante, puede ser a través del viachat y nuestros compañeros Daniela y Jared nos ayudarán a contestarlas. Muchas gracias.