Architecture championship - Técnico | Modernización en AWS a través del uso de microservicios.

Soy líder del departamento de implementaciones. Soy responsable de las implementaciones de aquellas soluciones diseñadas y propuestas para nuestros clientes en CompuCloud. Actualmente tengo tres certificaciones en AWS, siendo la más básica la Cloud Practitioner. Posteriormente tengo ambas certificaciones en SolutionArKitect, tanto en su nivel Associate como en su nivel Professional. Y además de ello, nos acompaña por aquí nuestro DevOps Engineer, el ingeniero Carlos Esparza.

Muchas gracias arquitecto. ¿Qué tal? Buen día a todos, un gusto tenerlos por aquí. Bienvenidos a este primer Architecture Championship, esperemos sea de su agrado. Traemos este tipo de dinámicas para que se familiaricen un poquito de cómo es el proceso de nosotros para construir arqueólogos, arquitecturas dentro de la nube de AWS y no solo arquitecturas sencillas, sino un poquito arquitecturas de más alto nivel con servicios un poquito más especializados que van un poquito orientados a lo que es la modernización de sus servicios y de sus aplicativos. De acuerdo, de este lado habla Carlos Esparza, actual líder del área de preventa del equipo de CompuCloud, encargados de desarrollar las arquitecturas para nuestros clientes. Tengo tres certificaciones a nivel AWS, que es la Cloud Practitioner, de nivel Foundational, Developer, Associate y DevOps Engineer, que es mi especialización. Esperemos esta plática sea de su agrado, les guste y les sea de beneficio para ustedes. Perfecto, muy bien, Para dar inicio, como ya había mencionado mi compañera Gio, que sepan que esta plática va a ir orientada a una comparativa entre lo que es una arquitectura monolito, que la va a defender mi compañero Marco Chávez, y una arquitectura basada en microservicios que la va a defender su servidor. Cabe aclarar que realmente no es como que uno esté peleado con el otro, no es que haya un pique extraño, sabemos que cada una de las arquitecturas tiene sus beneficios y sus contras, sus pros y sus negativas, pero lo interesante de esto es ver cómo se van desenvolviendo cada una, cómo están compuestas, qué servicios tiene, cómo va a resolver las necesidades de nuestro cliente, que como indicó mi compañera Gio, es para un cliente en específico, pero realmente son casos de uso que los vemos en el día a día y no solo está enfocado a resolver el tema de microservicios, sino que van a ver esa sinergia que hay entre distintos servicios de AWS que nos hacen tener una arquitectura completamente basada en el Well Architect de AWS y a sus seis pilares. ¿De acuerdo? Muy bien. Primero que nada hay que conocer de lo que vamos a hablar y voy a hablarles un poquito de lo que es el caso de estudio. ¿A qué me refiero con esto? Voy a dar algunas pautas para que sepan de qué va a ir esta arquitectura y qué solución estamos planteando ante qué problema. Primero es necesario conocer el problema profundidad para comenzar con la parte de las arquitecturas. Son ciertas afirmaciones bastante sencillas, intentando hacer los más generales posibles, que a pesar de que son sacadas de un cliente real, quisimos mantenernos en la escala de lo genérico y no hacerlo tan específico para no delimitar. ¿De acuerdo? La primera afirmación es que es una empresa dedicada al desarrollo de e commerce, la cual conoce aspectos básicos sobre la nube de AWS. Esto es importante ya que sobre todo en la arquitectura de microservicios vamos a ver el cómo. El que sea un e commerce viene bastante bien para el tema de microservicios. Sabemos que en el día a día bastantes de ustedes y bastantes empresas tienen su propio e commerce para vender sus productos en línea de la mejor manera. Pero ¿Qué buscamos con esto? Que sea de una forma eficiente y que se encuentre en producción la mayor cantidad de tiempo posible sin afectar a ninguna cantidad de usuarios. ¿De acuerdo? La siguiente afirmación sería que cuentan con una arquitectura tradicional monolítica, con algunas prácticas de resiliencia. Ahorita mi compañero Marco profundizará en lo que es una arquitectura monolítica y cuáles son sus ventajas. La tercera afirmación es que buscan cambiar por completo su arquitectura refactorizando su aplicativo a microservicios, prácticas de DevOps, seguridad e identidad. ¿De acuerdo? Es un cliente que sabe hacia dónde se quiere dirigir y es un cliente con el cual vamos a trabajar codo a codo para llegar a esa arquitectura modernizada con todos estos pilares que él nos comenta que para él son importantes. ¿De acuerdo? Lo siguiente es que están familiarizados con motores de bases de datos de código abierto y lenguajes de programación como Python. Hay otras cosas dentro de estas arquitecturas que vamos a platicar que vamos a tener que obviar mientras vayamos avanzando al momento de irlas explicando, pero va a quedar bastante claro conforme vaya avanzando el proceso de arquitectura. De momento es todo de mi lado, los voy a dejar con el ingeniero Marco para que empiece con la demostración de su arquitectura y a defender la misma. Adelante Marco.

Muchas gracias Inge, Carlos y bueno prácticamente a continuación veremos el esquema de la arquitectura monolitio, pero antes de ello me gustaría definir unos cuantos conceptos básicos de AWS, que prácticamente el primer paso para definir cualquier arquitectura es prácticamente seleccionar en qué región vamos a configurar todo nuestro ambiente. Prácticamente una región de AWS es una región física en cierta ubicación del mundo, la cual debe de contar con al menos tres zonas de disponibilidad, mientras que una zona de disponibilidad cuenta con uno o más centros de datos. Cabe mencionar que cada zona de disponibilidad tiene tanto alimentación, refrigeración y seguridad física independientes y todos estos centros de datos se encuentran conectados a través de redes redundantes de ultrabaja latencia. Actualmente AWS cuenta con 31 regiones en todo el mundo y 99 zonas de disponibilidad, siendo 4 regiones con las que cuenta AWS en Estados Unidos, siendo estas regiones las más utilizadas y las que tienen menor latencia para los clientes finales de México. Una vez que tenemos definido nuestra región en AWS, procedemos a realizar la creación de nuestro ambiente de red mediante el servicio de Virtual Private Cloud, el cual nos permite hacer toda esta tarea de virtualización y configuración de nuestro ambiente de red en donde van a estar nuestros servicios. Ahora veremos que prácticamente podemos definir que las subredes nos pueden seleccionar las zonas de disponibilidad que vamos a usar, aquí prácticamente en las subredes es donde vamos a colocar nuestro servidor de EC, como lo mencionaba Charly, el tema de la arquitectura, un tema de monolito, prácticamente aquí en este servidor tenemos lo que es nuestro front, nuestro back y además el tema de la base de datos. Posteriormente para poder hacer la exposición de nuestros servicios de un servidor privado, hacemos una integración con un servicio el cual es un balanceador de cargas en AWS, este servicio es conocido como Application Load Balancer, el cual nos permite hacer esa exposición de nuestro aplicativo hacia los usuarios finales y prácticamente nosotros hacemos esta integración de nuestro aplicativo con el Application Load Balancer, también con un servicio el cual es ruta 53, este servicio de ruta 53 nos permite tanto comprar dominios como configurar los propios dominios para poner nuestro dominio por ejemplo compucloud com mx, nuestro dominio y administrarlo y apuntarlo a nuestro servidor mediante la Application Load Balancer. Adicionalmente una de las bondades también de utilizar este tema de Application Load Balancer es que nos permite hacer la integración con otro servicio conocido como ACM o AWS Certification Manager el cual nos permite hacer ese offloading de los certificados SCL y TLS, ya no nos tenemos por que preocupar por los certificados a nivel de nuestro EC o ir con un tercero y comprar algunos certificados, sencillamente este servicio de ACM se integra directamente con Application Load Balancer y se renueva inclusive de manera automática el tema de los certificados y uno de los puntos más interesantes es que los certificados son gratuitos. Entonces prácticamente con esto vemos lo que es una arquitectura de monolito, prácticamente puede tener tanto ventajas como desventajas. Claro, una de las ventajas principales es de que el tema de la simpleza para aquellas personas que están acostumbradas a manejar todo en un mismo servidor que ingresan, que modifican el front, el back, la base de datos, todo desde un mismo lugar obviamente la principal desventaja es que si se cae este servidor pues abrió su aplicativo, entonces nuestro aplicativo prácticamente deja de fallar. Entonces este es un esquema de una arquitectura tradicional en monolito.

Muy bien, de acuerdo Marco, es bastante interesante la dinámica que nos pones aquí, la arquitectura que nos está reflejando, ¿Tú crees que cumple con todos los criterios necesarios para que funcione correctamente el e commerce?

Aquí Charly, prácticamente como te mencionaba la principal desventaja es de que si falla algo nuestro servidor pues prácticamente todo se colapsa. Entonces prácticamente una de las mejoras y aspectos que podemos comenzar a hacer y es necesario para poder desacoplar nuestro aplicativo es prácticamente comenzar con ese desacoplamiento de la base de datos. De hecho ya varios de nuestros clientes aquí en Copuclot hemos refactorizado lo que es el tema de la base de datos, sacarla del EC y mandarla a un servicio de base de datos relacionales como lo es Amazon RDS, el cual como les mencionaba es un servicio para administración de las bases de datos relacionales y aquí me gustaría comentar prácticamente de este servicio de RDS que de hecho lo podemos encontrar en sus varios sabores por así decirlo, prácticamente contamos con servicios administrados de motor de base de datos de MySQL, MariaDB, SQL Server, Oracle DB y PostgreSQL y hay otra variante más personalizada precisamente y desarrollada por AWS la cual es Aurora, a lo mejor algunos ya la han escuchado, prácticamente Aurora parte tanto de MySQL como Postgres, por lo tanto es compatible con estos dos motores de base de datos. Y algo que me gustaría mencionar es de que prácticamente este servicio fue creado y nacido para la nube. Entonces tenemos una cantidad inmensa de mejoras de este servicio, desde el tema del escalamiento de lecturas mediante el tema de las replicas, el cual prácticamente son bases de datos que únicamente van a atender peticiones de lectura, lo cual nos permite quitar esa carga de trabajo a nuestro nuevo maestro. Y adicionalmente también tenemos inclusive una opción todavía más interesante en cuanto a Amazon Aurora, que es el tema de mandarla al esquema de serverless, que prácticamente esto nos ayuda a que tenga un escalamiento vertical casi instantáneo. Y prácticamente ya una vez que tenemos este tema de desacoplamiento entre el aplicativo y la base de datos, ahora sí podemos proceder a hacer una integración para el tema de la resiliencia y de la alta disponibilidad, que prácticamente consiste en añadir un servicio de autoescalamiento, el cual nos va a permitir tanto atender el tema de la demanda, es decir, si en algún momento nuestro servidor ya no es suficiente para atender la carga, podemos implementar el auto scaling para poder agregar otra instancia de cómputo conforme a la demanda para atender el propio aplicativo. De hecho, inclusive más allá de la demanda, el tema del auto escalamiento se suele implementar para lo que es el tema de la resiliencia. En caso de que se caiga alguna de nuestras zonas de disponibilidad, prácticamente el auto scaling hace el relanzamiento de manera automática en otra zona de disponibilidad para estar atendiendo todo lo que es nuestro aplicativo. Entonces aquí podemos ver cómo está el flujo de nuestro aplicativo, prácticamente nuestro punto de entrada es el servicio de Ruta 53, posteriormente pasa por lo que es el Application Load Balancer, que al final de cuentas es un intermediario entre el cliente final y las instancias para reducir el tema de la exposición de las instancias y finalmente cada instancia se comunica con la base de datos para tener pues datos consistentes. Entonces prácticamente esta es una arquitectura de monolito que podemos mejorar en temas de disponibilidad y resiliencia, ya haciéndola en una arquitectura de dos capas, separando lo que es el tema del aplicativo y la base de datos. Entonces prácticamente por allí es referente al tema del monolito. Igual por aquí te cedo la palabra Inge Charlie, para que puedas por allí comentar lo que puede ser una arquitectura ya basada en microservicios y las bondades que nos pueden traer esto.

Perfecto, muchas gracias Marco. Bastante interesante esta arquitectura. Creo que abarcaste bastante bien todos los puntos relacionados a la necesidad del cliente de poder levantar un e commerce con infraestructura tradicional dentro de la nube de AWS. Me gustó que agregaras esa parte de la resiliencia, tanto en la base de datos como en el aplicativo dentro de Amazon EC. Aún así, considero que tiene algunas limitantes, las cuales expondré en el tema que vamos a pasar a continuación. También dejo abierto a que los participantes, si en algún punto quieren lanzar alguna pregunta ahí por el chat, con todo el gusto la podemos resolver conforme vaya avanzando esta plática. ¿De acuerdo? Ahora sí pasaremos al tema de microservicios, que es el tema central de nuestra plática, que a pesar de que como dije, es una comparativa de estos, ambos escenarios tienen sus ventajas y sus desventajas, pero los microservicios sí nos hemos ido encaminando en cuanto al TI que vamos hacia allá. ¿De acuerdo? Todo el tema relacionado a serverless y a modernizar nuestra infraestructura para dejar de utilizar servidores, pinta que va a ser realmente el futuro de todo el alojamiento web y de toda la creación y desarrollo de aplicativos. De acuerdo, como comentaba mi compañero Marco, es indispensable para desarrollar una arquitectura primero, obviamente estar dentro de la mejor nube que es AWS. En este caso, eso es un poquito obvio, estar dentro de una región que ya comentaba mi compañero Marco, que están esparcidas alrededor del mundo. Se podría decir que las cuatro regiones que están dentro de EEUU son las más cercanas a nosotros que estamos en territorio mexicano, pero aún así se puede hacer una resiliencia completamente global, la cual nos facilita toda la infra de AWS. De acuerdo, así como Marco empezó hablando un poquito del tema de la instancia, en este caso yo lo voy a manejar un poquito distinto debido a que la arquitectura va a cambiar bastante. Vamos a comenzar desde los usuarios finales. Los usuarios finales, como los vemos, están del lado izquierdo y son aquellas personas que se van a meter directamente a nuestra página web. ¿Cómo lo van a hacer? En esto no cambia mucho con la arquitectura tradicional de mi compañero Marco, ya que es el servicio por excelencia para esto. La administración de DNS dentro de la nube de AWS se hace con este servicio que es completamente global, que es el servicio de Amazon Road 53, en el cual vamos a poder administrar nuestros dominios en la nube de AWS. ¿Esto qué quiere decir? Que si yo como usuario final accedo al dominio W mitienda. COM, voy a poder acceder a la página que está desarrollada en este caso por el cliente, pero obviamente ese front de la página, ese frontend tiene que vivir alojada en un sitio. Como ya no vamos a depender tanto de una arquitectura tradicional monolítica, tenemos que empezar a desacoplar roles. Van a ver que al momento de llevar yo esta plática voy a utilizar mucho la palabra desacoplamiento. ¿Y a qué me refiero con esto? A que si tenemos una funcionalidad específica de nuestra arquitectura, como lo puede ser el frontend, el backend, las bases de datos, el manejo de los usuarios, entre otras funcionalidades básicas de nuestra página, tenemos que ir empezar a descomponerlo en distintos ámbitos. Entonces si yo accedo a mi tienda. COM tengo que acceder a un frontend que esté alojado en un sitio. Para eso vamos a utilizar el servicio de Amplify. Amplify es un servicio de hosting para aplicaciones estáticas, el cual nos va a ayudar a alojar nuestro frontend de nuestro aplicativo. Aquí estaremos obviando que va a ser un aplicativo, un e commerce desarrollado en un framework de JavaScript, como lo puede ser React por ejemplo, o Vue JS o cualquiera que esté basado en JavaScript. Si se preguntarán, oye Carlos, yo tengo mi página web estática, mi frontend de un aplicativo lo he almacenado en Amazon s y me ha funcionado bastante bien. Estoy de acuerdo, también es un buen servicio para almacenar páginas estáticas, pero hay que ir siempre a lo más novedoso y a lo que nos tenga más bondades. En este caso Amplify nos tiene más bondades que el servicio de Amazon s, ya que no solo nos sirve para hacer el hosting de nuestro aplicativo, sino que viene con un CDN ya incorporado para que todos los assets estáticos de nuestra página estén replicados con distintos puntos de presencia en el mundo, lo cual nos da un mucho mejor performance de la página web. Otra de las ventajas que nos tiene es la creación de flujos para no afectar directamente al productivo de nuestro ambiente, esto quiere decir que puedo poner a mis desarrolladores a que creen flujos personalizados para tener distintos ambientes. El manejar distintos ambientes como lo puede ser un ambiente de Kua, de desarrollo, de preproducción y de producción hace que generemos un ambiente completamente basado en las buenas prácticas de desarrollo. Esto va muy encaminado a las prácticas de DevOps, una práctica que estaré mencionando bastante a lo largo de esta plática, no sólo porque es mi especialización, sino porque verdaderamente recomiendo que todos los equipos de desarrollo vayamos hacia allá. Por último, la ventaja más grande es que tiene incorporada un CICD. ¿Con esto a qué me refiero? A que los desarrolladores de frontend, si tenemos desacoplados los roles de nuestra empresa con desarrolladores de frontend y desarrolladores de backend, los desarrolladores de Frontend van a estar completamente ajenos y cumpliendo su rol y centrándose únicamente en desarrollar el frontend de nuestra página web, en este caso de nuestro e commerce, con su propio CICD. Un CICD no es más que un ciclo de integración y despliegue continuo, el cual nos va a permitir que en cuanto se realice un push de nuestro código a lo que es un repositorio de código como lo es Git, se realice de forma automática. En cuanto un desarrollador mande un cambio a la rama de desarrollo, Amplify lo va a detectar de forma automática, va a realizar la construcción automática del código y lo va a desplegar de forma automática en lo que sería la URL. Así podríamos tener una URL que sea triple W, mitienda dev com o algo por el estilo, enfocado a los desarrolladores únicamente y otro dominio enfocado a los del área de producción. ¿De acuerdo? Así generamos estos flujos de aprobación para que en caso de que haya algo malo, algo que se tenga que corregir, no se lance directamente a la rama productiva. ¿De acuerdo? Entonces, la parte del frontend ya la tenemos cubierta, estamos haciendo un poco de desacoplamiento, estamos descomponiendo las funcionalidades de nuestro e commerce, sí, pero realmente todavía no se puede llamar microservicio esta arquitectura. Para eso vamos a hacer uso de lo que es un servicio por excelencia, de los más longevos dentro de la nube de AWS, que es el servicio de Amazon API Gateway. Amazon API Gateway, como su nombre lo indica, es un puente entre lo que va a ser el frontend de nuestro aplicativo y el backend. Es un intermediario entre los dos, el cual se encarga de crear, administrar, eliminar APIs, ya sea de tipo RESTful o de tipo WebSocket. ¿De acuerdo? Entonces, si ya tenemos un frontend que se basa en Amplify, pues vamos a tener nuestro backend en otros servicios. Para esto vamos a empezar ahora sí a hablar del tema de microservicios. Como ya les dije, lo primero que tenemos que pensar es en descomponerlo. Para descomponer nuestros servicios tenemos que basarnos en buenas prácticas de descomposición. Las prácticas de descomposición dentro de la nube de AWS son distintos patrones que podemos seguir para descomponer nuestros microservicios. ¿A qué me refiero con esto? Existen distintos frameworks, distintos caminos para tomar nuestro monolito y pasarlo a microservicios. Pero ¿Cómo hacemos esto posible? Pues por ejemplo, en un patrón de descomposición basado en equipos de negocio. Un patrón de descomposición basado en equipos de negocio se refiere a que, por ejemplo, tengamos un monolito que sea para toda nuestra área de marketing, un microservicio que sea para toda nuestra área de finanzas, un microservicio que sea para toda nuestra parte de desarrollo y así descomponemos por las áreas de negocio que tenemos. Realmente es de los patrones de descomposición más antiguos dentro de los microservicios, así que no lo recomendaría tanto. De hecho, en esta arquitectura que vamos a ver, vamos a ver un patrón de descomposición basado en subdominios y en funcionalidades. ¿A qué me refiero con esto? A un patrón basado en microservicios es aquel el cual, por ejemplo, vemos aquí la parte de cart y de orders, que son las funcionalidades directas de nuestro aplicativo. ¿Qué es esto? Que por ejemplo, la parte de un carro o de órdenes dentro de nuestro microservicio son funcionalidades directas de nuestro e commerce. ¿Esto qué quiere decir? Que el carro de compras de nuestro e commerce va a tener su propio microservicio y las órdenes que realicemos después de meterlas dentro de ese carrito de compras, van a tener su propio microservicio. ¿De acuerdo? Para esto tenemos que considerar algunas cuestiones como que los subdominios tienen que ser autónomos, especializados y esto nos hace que sean ágiles desde un escalado flexible, implementación sencilla, tengan una libertad tecnológica y utilicen un código reutilizable. Dentro de la presentación están viendo que se agregaron dentro del microservicio de carro tres funciones Lambda, Este es el icono de Lambda, ¿De acuerdo? El que vemos en la parte de arriba. Lo que vemos en la parte de abajo es un microservicio basado en órdenes y basado en contenedores. ¿Esto qué quiere decir? Estamos utilizando esa libertad tecnológica que nos dan los microservicios para no casarnos directamente con un servicio dentro de la nube de AWS, sino que descomponemos esas funcionalidades y las acoplamos al servicio que corresponda. ¿Esto qué quiere decir? Si tenemos, por ejemplo, APIs que sean de ejecución rápida y que no requieran de una alta complejidad al momento de estar utilizando el código, pues lo recomendable es utilizar funciones lambda. Mientras que si tenemos ejecuciones un poquito más complejas de nuestras APIs, lo recomendable es utilizar el servicio de Elastic Container Service y hacer uso de los contenedores. ¿De acuerdo? Entonces, cada uno de esos microservicios cumple con la característica de tener una libertad tecnológica para cada uno de nuestros equipos de desarrollo. Pero, ¿Cómo vamos a comunicar ese Amazon API Gateway con nuestros microservicios que tenemos en la parte derecha? Eso es bastante sencillo. Para la parte de Amazon API Gateway se puede poner el ejemplo de que la comunicación sea directa con las funciones lambda, con una integración que es bastante sencilla, mientras que el Application Load Balancer nos funciona como un intermediario para balancear las cargas dentro de nuestros contenedores. Hay que considerar que dentro de esto también viene bastante bien los temas de auto scaling dentro de nuestros containers, los cuales nos da una capa adicional de lo que es la resiliencia de nuestros aplicativos. Incorporamos un auto scaling dentro de nuestro contenedor, le agregamos un balanceador de cargas y así nos encargamos de que todas las cargas estén distribuidas entre los contenedores que estén arriba. Ahora, ¿Qué otra ventaja me puede presentar el tener microservicios? Ya hablamos de esa libertad tecnológica. Si por ejemplo tengo distintos grupos de desarrolladores, cada uno con una respectiva funcionalidad, pues puedo hacer que mi equipo de desarrollo, que se encarga de la parte del carrito de mi e commerce, trabaje con una base de datos no SQL, mientras que mi equipo de desarrollo, que se basa en las órdenes, que tiene que ver con todas las órdenes ejecutadas de nuestro e commerce, utilice la base de datos Aurora. ¿Esto qué quiere decir? Que tenemos esa libertad tecnológica de que cada uno de los microservicios puede ir con un motor de base de datos por completo distintos. Por ejemplo, para la parte del carrito estamos utilizando una base de datos no SQL, mientras que para la parte de órdenes estamos utilizando una base de datos que si es SQL. Esto también, como nos había indicado mi compañero Marco Chávez, nos viene bastante bien, ya que servicios como lo es Aurora van bastante bien con el tema serverless, Aparte de que tienen un performance acelerado tanto con Postgres como MySQL. Recordemos que el cliente nos había mencionado que está bastante familiarizado con motores de código abierto en cuanto a sus bases de datos. ¿De acuerdo? Ahora, ya que tenemos nuestros microservicios, nada más aquí hacemos mención de dos, porque realmente aplica para n cantidad de microservicios. ¿A qué me refiero con esto? A que podemos tener esta parte de carrito, esta parte de orden, podemos tener otra parte de catálogo, otra parte de usuarios, y así con n cantidad de microservicios, algunos basados en Lambda, algunos basados en containers, algunos basados en contenedores basados en EC y otros en contenedores basados en Fargate. Si no están familiarizados con Fargate, Fargate no es más que ejecutar contenedores completamente serverless dentro de la nube de AWS. ¿De acuerdo? Aquí ponemos nada más la mención de dos microservicios, pero por ejemplo, en las funciones Lambda, podemos ver directamente las funcionalidades de ese microservicio. Por lo cual podemos tener una función Lambda que sea añadir al carrito, actualizar al carrito o x funcionalidad. ¿De acuerdo? Ahora, ya que tenemos esta arquitectura basada en microservicios, ¿Cómo la mejoramos? Todavía podemos desacoplar los roles y agregar algunas capas tanto de identidad y seguridad, que era algo que nos mencionaba el cliente, como algunas prácticas de DevOps que son recomendados. Así que esta arquitectura todavía no está finalizada y todavía le podemos dar un plus. ¿Cómo le podemos dar ese primer plus? Agregando cuestiones de identidad de nuestros usuarios. Para eso estaremos utilizando el servicio de Cognitive Cognito. No es más que un federador de identidad, que es un servicio de AWS completamente serverless, el cual nos va a permitir que en cuanto nuestros usuarios se logueen a W mitienda. Com y le den en login de nuestra página, realmente nuestros usuarios no vivan en alguna base de datos, sino que vivan en una federación de identidad. En un servicio de AWS. Exactamente. ¿Para esto qué ventaja nos trae? Pues nuevamente, el desacoplamiento de roles, que es lo más importante al momento de hablar de microservicios. Descomponemos la funcionalidad de identidad en el servicio de Amazon Cognito. Esto también viene bastante bien, por ejemplo, si queremos tener, obviamente, nuestra base de datos de usuarios, pero también le queremos dar funcionalidades a nuestro cliente para que se puedan loguear por medio de Facebook, de Google, de Amazon, de Apple ID. Todos esos cuatro servicios se pueden incorporar dentro de Cognito de forma nativa, para que no solo se puedan loguear por medio del usuario de nuestro e commerce, sino también que se puedan incorporar simplemente dándole clic en el botón Loguearse con Facebook y ya no es necesario que hagan nada más. ¿De acuerdo? Viene bastante bien con ese tema de federación de identidades, así que agregamos una práctica de identidad y desacoplamos aún más los roles. Ahora, en cuestiones de seguridad, ¿Qué otras cosas podemos agregar? Vamos a incorporar algo más al microservicio de órdenes, que es este segundo de aquí, y vamos a incorporarlo dentro de una red privada. Marco ya profundizó un poquito en lo que es eso, así que ya no me voy a detener tanto, pero todos nuestros contenedores estarían dentro de su propia subnet privada, lo cual da una capa de seguridad adicional, ya que solo se van a agregar y se van a comunicar entre ellos y no van a tener como tal una entrada por medio de Internet. ¿De acuerdo? Así que estamos incorporando todavía más algunas cuestiones de seguridad dentro de nuestros containers. Cabe aclarar que, aunque no se ve dentro de esta arquitectura, también podemos incorporar lo que es una VPC dentro de nuestras funciones lambda para que sean completamente privadas. ¿De acuerdo? Ahora, el siguiente tema tiene que ver con mi coro, con la cosa que más me gusta, que tiene que ver con las canalizaciones y los ciclos de integración y despliegue continuo todas las prácticas de DevOps de forma automática. Tengo mis contenedores en el servicio Elastic Container Service, pero la verdad, Carlos, es una lata tener que estarlos actualizando constantemente. Entonces, ¿Cómo llevo esto a cabo? Mediante una canalización orquestada por este servicio que se ve aquí, aws code pipeline. ¿Esto cómo lo vamos a llevar a cabo? Obviamente, si ya hablamos de la parte de los microservicios, hablamos de que lo va a estar desarrollando otro equipo ajeno al equipo de Frontend, en este caso, el equipo de los desarrolladores de backend. ¿Y cómo lo vamos a llevar a cabo? Mediante cuatro AWS Code Commit, AWS CodeBuild, Elastic Container Service y afuera de la canalización, el elastic Container Registry. ¿Esto cómo se vería reflejado? Pues lo vemos aquí mediante algunas flechitas pero se los explico a detalle. Los desarrolladores de backend estarían subiendo el código como dije anteriormente, haciendo commits, haciendo push a nuestro repositorio de código. Nuestro desarrollo de código por ejemplo puede ser un contenedor basado en Python el cual tenga todos los archivos dependencias necesarios para construir esa imagen de docker en específico. Lo que más necesitamos es el archivo dockerfile y lo va a detectar de forma automática en cuanto se realice un push o un commit a nuestro repositorio. ¿De acuerdo? Esto también como se ve en el icono puedo manejar distintas ramas, una rama de producción y una rama de desarrollo. Aquellos equipos de desarrollo que estén familiarizados con herramientas git van a entender un poquito más a qué me refiero. Una vez se detecte el cambio de forma automática dentro de mi repositorio git, este código se va a empaquetar y se va a mandar a lo que es el servicio de CodeBuild. CodeBuild funciona gracias a que estaba un servidor por detrás ejecutando una serie de comandos que se los daremos mediante un archivo llamado build spec el cual irá ejecutando comandos antes de la construcción, durante la construcción y después de la construcción. En la construcción estaremos dándole comandos para que realice la construcción de nuestra imagen docker, la tagge y la mande directamente al SR. Si se fijan la flecha de acá abajo y está mandando el icono de docker que es una ballenita con su contenedor para que guarde directamente la imagen ya construida a un repositorio privado de imágenes dentro de de la nube de AWS. ¿De acuerdo? ¿Entonces si se fijan codebull tiene dos propósitos, construimos lo que es la imagen de contenedor y la mandamos al repositorio DSR y lo desplegamos directamente en el servicio de Amazon SS. De acuerdo? Entonces nuestros desarrolladores en cuanto suban un cambio de forma automática se ejecuta todo lo que está dentro de este cuadro rosa de forma completamente automatizada sin tener que realizar ningún comando, sin tener que hacer ninguna ejecución de por medio o alguna línea de comandos y se van a estar desplegando a nuestros contenedores que vemos en la parte de arriba de forma automática. Esta no es la única canalización que hay dentro de esta arquitectura, como vieron en la parte izquierda tenemos la canalización de frontend y tenemos la canalización de backend. Si se preguntan si hay alguna especie de canalización para los lambdas o alguna práctica de DevOps relacionadas a los lambdas. Esto sí existe y va dentro del Serverless Application Model de AWS, que tiene que ver también con la incorporación de ciclos de integración y despliegue continuo, pero solo a servicios serverless como lo puede ser Lambda. Pero eso es un tema bastante más extenso que sin duda revisaremos en algún Architecture Championship. ¿De acuerdo? Entonces, podrá parecer complejo esta arquitectura que vemos en pantalla, pero realmente no lo es. Nosotros somos especialistas en todas las herramientas aquí reflejadas, es nuestro pan de todos los días y conocemos más que nadie la ejecución de los mismos y los podemos ayudar a realizar la migración de monolito a microservicios. Pero nosotros no hacemos esa recomendación de pasar de monolito a microservicios a menos que realmente lo veamos necesario y que les va a traer beneficios a ustedes como clientes. ¿De acuerdo? Es un proceso, es todo un journey dentro de la nube de AWS, Así que es algo que se realiza también de forma paulatina, de forma paso por paso. Y no es como que propongamos una migración de monolito a microservicios saltándonos todos los pasos, sino que vamos descomponiendo ciertas funcionalidades y vamos realizando las pruebas pertinentes para llevar aquí. Muy bien. No sé aquí, Marco, si tengas alguna pregunta directa de esta arquitectura.

Realmente no, Charly, no hay ninguna duda. Realmente por allí me ha tocado parte de las implementaciones, llevar a cabo este tipo de implementaciones. La verdad es que son bastante interesantes y a pesar de que se ven un poco difíciles, realmente es un siguiente nivel para nuestros servicios.

Es correcto. Muy bien, muchas gracias, Marco. Y aquí abro, abro el chat, sobre todo a los asistentes. Tanto la práctica de marco de servicios tradicionales como la parte de servicios modernizados con microservicios, cada una tiene sus aspectos, sus pros y sus contras. Y si tienen alguna duda que quieren que contestemos en la sesión, cada uno es especialista en su área y por eso cada uno habló de su respectiva arquitectura. Así que con gusto, si quieren hacernos alguna pregunta por medio del chat, con gusto la podemos atender y también agradecerles por este medio que hayan prestado la atención necesaria. Esperemos estas dos arquitecturas les hayan sido de utilidad para darse una idea de cuáles son los servicios que se manejan dentro de la nube de AWS.

Perfecto, muchísimas gracias, Carlos. Marco, por aquí tenemos una pregunta, nos dicen. Si, nos dice el ingeniero Greco, si se pueden mezclar arquitecturas, monolitos y de.

Igual aquí en apoyo con Charly, realmente podemos tener a lo mejor cierta parte de nuestro servicio en un monolito y aparte en un tema de microservicios. Sin duda se puede realizar este tipo de esquemas, Greco. Igual no sé Charly, si gustas complementar con algo, pero yo como tal me ha tocado dos, tres clientes que sí, sí tienen como este tipo de mezclas de arquitectura.

Claro, claro, sí, sí, contestando brevemente sería la respuesta. Sí, sí se puede mantener una arquitectura basada en monolitos y en microservicios. Pero es que aquí hablamos de un todo de acuerdo, Hablamos de una carga de trabajo con completa, en la cual tenemos ciertas características de tu aplicativo que vienen bastante bien para el tema de arquitecturas monolíticas, mientras que otras funcionalidades no es necesario que compartan infraestructura con ese monolito. Por lo tanto, recomendamos hacer ese análisis detallado y ver cuál de esas funcionalidades vienen bastante bien para desacoplar. Así relajamos un poquito el monolito que tenemos, desacoplamos las cargas y esas funcionalidades específicas ahora sí empezamos a tocarlas en el tema de microservicios. Todo esto realmente tiene que ver con un tema de refactorización de código por completo, en el cual todo su equipo de desarrollo y su equipo de infra tiene que estar involucrado. Pero es posible tener un monolito y aparte microservicios para ciertas funcionalidades. Así que contestando tu pregunta Greco, que te agradezco que la hayas hecho, si es posible y tiene que ver bastante con ese análisis que tenemos que.

Perfecto, muchísimas gracias, ingenieros. No sé si alguien tenga alguna otra duda en cuanto a la infraestructura, ya sea la tradicional o la de microservicios. Al contrario, gracias a ti, Greco. Muy bien. Igual si tienen alguna otra duda la pueden ir escribiendo aquí. Y también los invitamos justamente este día jueves tenemos una sesión igual a las 11 de la mañana, en la cual el equipo comercial de CompuCloud les va a estar presentando ahora los beneficios que tienen los negocios al utilizar esta, estas infraestructuras a través de microservicios. Les vamos a presentar un caso de un cliente existente de compuclo que llegó con una preocupación en cuanto a lo que es su infraestructura on premise y se le presentó dos opciones como las que vimos el día de hoy, una opción con servicios tradicionales y otra con microservicios. Entonces los invitamos a que el jueves participen también en esta sesión para que tengan un poquito más de idea ahora de los beneficios que tiene el negocio y sus clientes finales al utilizar este tipo de arquitecturas, que conozcan cómo se ahorró costos tal vez al utilizar microservicios o tal vez la latencia este ahora ya es más baja, o todo lo que fueron sus servicios, este utilizó algunos para mejorar otros proyectos y ahora con los microservicios optimizó algunas cargas de trabajo para que conozcan más cuáles fueron también pues los beneficios finales que se tuvo ya que esta infraestructura está corriendo en la nube como microservicio. Entonces igual aquí en el chat les estamos colocando el link en donde se pueden registrar para que nos acompañen el jueves en esta sesión y de igual manera les estaremos enviando lo que fue la información que vimos el día de hoy en la sesión y también podrán encontrar más adelante el video de este evento virtual de Architecture Championship. Y bueno, ahora sí lo dejamos a su consideración, ¿Ustedes cuál creen que fue la arquitectura que mejor se adapta a este caso de uso que vimos de inicio? ¿Una tradicional o una basada en microservicios con nuevas tecnologías de AW? Pues nuevamente muchísimas gracias a todos por acompañarnos el día de hoy y si tienen alguna duda la pueden seguir escribiendo por aquí por el chat y de igual manera en pantalla podrán estar viendo todo lo que son nuestras redes sociales y también nuestro correo y número de teléfono para cualquier duda en específico que quieran que atendamos con ustedes ¿Va? Y pues nuevamente gracias y los esperamos el día jueves 11 de la mañana en la sesión que tendremos de continuación de este evento virtual. Gracias a todos y que tengan un excelente día.