Architecture Championship - Innovación y continuidad: Estrategias Clave de Resiliencia en la nube

El cual hablaremos sobre innovación y continuidad, específicamente sobre las estrategias clave de resiliencia en la nube. Y bueno, en la siguiente diapositiva les comparto justamente quiénes son el equipo experto que nos acompañan en esta sesión, que el día de hoy nos acompaña la ingeniera Sadia Olivares, consultora especializada de aquí del equipo CompuCloud y el ingeniero Carlos González, también uno de nuestros especialistas consultores de la nube de AWS. Y pues bueno, para dar una previa charla sobre quiénes somos, tal vez ustedes ya nos conocen, pero les platico rápidamente. Nosotros con Boucloud somos partner Advance de Amazon Web Services, tenemos presencia en México y Centroamérica y algunos otros países que acabamos de iniciar algunos proyectos. Y justamente desde el año 2012 somos especialistas en lo que es diseño y modernización de arquitecturas Cloud, obviamente pasando desde la planeación y migración hacia la nube de AWS, junto con otras tecnologías en nube que han estado surgiendo como serverless, DevOps, Inteligencia artificial, Machine Learning y todo esto que al día de hoy está siendo tendencia en la parte tecnológica y que bueno, vamos a ir conociendo más allá en conjunto con ustedes cómo podemos aprovechar estas tecnologías y utilizarlas en nuestras empresas. Y dando paso a la agenda, bueno, les platico un poco sobre qué es lo que vamos a platicar el día de hoy, sobre las estrategias de resiliencia empresarial. Y justamente me gustaría platicarles que estas estrategias de resiliencia son muy importantes, sobre todo en la nube, por razones clave. Tenemos la parte de escabilidad y flexibilidad, la opción de la reducción de costos, el poder tener accesos remotos y el trabajo colaborativo, obviamente la parte de seguridad y protección de los datos, así como la innovación continua que podemos recibir a través de la nube. Entonces, justo vamos a platicar sobre dos temas en específico, que el primero es Resiliencia empresarial en la nube, en donde la ingeniera Sadi por aquí nos va a estar platicando algunas estrategias de seguridad, de la creación de planes de recuperación ante algún incidente, el cómo las empresas pueden adaptarse a cambios en este entorno tecnológico y sobre todo lo más importante, la parte de monitoreo. Y por otro lado, tenemos un paso más allá, después de adaptar estas estrategias de resiliencia, lo que es la importancia de modernizar, el porqué estar modernizados continuamente nos ayuda a ser resilientes como empresa y obviamente todo lo que tiene que ver con la eficiencia operativa, la importancia de la redundancia de los datos y nuestros aplicativos y obviamente tener una arquitectura distribuida. Y muy bien, pues bueno, los dejo a continuación con la ingeniera Zadia Olivares, quien nos va a ayudar a dar inicio a estas estrategias que platicaremos el día de hoy justo sobre innovación y continuidad. Entonces, resiliencia empresarial en la nube. Pues bueno, muchas gracias ingeniera Sadi por acompañarnos y le dejo los micrófonos.

Muchas gracias Gio, gracias por nuestra introducción. Y pues nada, vamos a entrar ya en materia hablando justo como nos comentaba Gio por aquí sobre la resiliencia empresarial en la nube y cómo nosotros como CompuCloud ayudamos a nuestros clientes. En específico vamos a estar hablando sobre nuestro cliente que llegó con una arquitectura monolita. Para dar un poquito de contexto de cómo ha evolucionado nuestro cliente en compañía con CompuCloud a lo largo de este tiempo, hablar un poquito desde sus orígenes. Nuestro cliente llegó con una infraestructura monolita en donde tenía su aplicación basada en Windows y su base de datos, una SQL y todo estaba junto en una instancia, en este caso con el servicio de s. Esto pues exponía gravemente a nuestro cliente a temas de riesgo y también de sus datos en caso de alguna contingencia por el aplicativo o que tuviera como alguna intrusión a su aplicación, a su infraestructura, también se veía comprometida su base de datos. Algo que también hacía como entorpecer todo esto era el tema, el rendimiento de la instancia y que era muy pues tardado poder incrementar algún recurso y pues esto también se veía comprometido en cuanto a la base de datos, no se podía identificar de qué manera poder incrementar los recursos y si esto estaba siendo necesitado por no es por su base de datos o por el aplicativo como tal. Entonces eso hacía que se incrementara todo, toda la infraestructura y generaba costos más elevados. En lugar de poder enfatizarlo y enfocarlo en una de sus cargas, se tenía que hacer en un conjunto, en un todo. Y también por temas de que su aplicativo se encontraba en este mismo servidor al momento de hacer las actualizaciones y el despliegue de esta, de esta actualización lo tenían que hacer en ventanas de mantenimiento, pues fuera de horario laboral porque era su productividad, porque ahí estaba su base de datos y en caso de que sucediera algo, pues debían de tener el tiempo suficiente para poder remediar los errores que pudieran surgir. Esto pues también era un trabajo súper laborioso para su equipo, muy demandante y pues nada, era uno de los puntos como también de mucho foco para ellos. Al igual de temas de seguridad, ellos como les comentaba al inicio fueron vulnerados, tuvieron unos ataques de seguridad a su servidor y por ende a su base de datos en donde pues sí sufrieron algunas algunas consecuencias y dijeron pues no más combuccloud, necesito alguna alguna solución para esto y nosotros entramos en este sentido a apoyar a nuestro cliente y nos enfocamos y vamos a hablar un poquito acerca de esto, sobre empezando como con lo que terminé con las estrategias de seguridad, qué fue lo que nos tomamos como foco para poder crear esta nueva infraestructura, esta nueva arquitectura para nuestro cliente y tener una infraestructura ya desacoplada, totalmente separada, tu aplicativo va a estar por un lado y tu base de datos va a estar por otra. Nos encargamos mucho del tema de la seguridad y la encriptación de sus datos. En el caso de los datos del aplicativo del servidor, creamos una capa, un filtro de seguridad de encriptación de sus datos en reposo con el servicio de Key Management Service que ayuda justo a esto, a tener esta protección, esta capa adicional. Pero también para los temas de los accesos a su base de datos, hemos integrado el servicio de Secrets Manager para tener una integración en sus credenciales de acceso. En cuanto a la seguridad de la red, a verlo como de manera global por así decirlo, nos enfocamos en sus temas de VPC y poder proteger gracias a un firewall de aplicación virtual que por ahí tenemos gracias a los servicios de AWS, pues también tener estas detecciones gracias al servicio de Warduty. En conjunto trabajan y generan estas capas de seguridad a su infraestructura en donde se puede eliminar o denegar algún acceso de seguridad hacia toda la infraestructura. Todo lo que se encuentre dentro de la VPC, dentro de la arquitectura de nuestro cliente está resguardado gracias a estos servicios. De hecho para nuestro cliente un foco también muy importante fue sabes que yo no tengo clientes en China, yo no tengo nada que ver allá. Entonces dijimos OK, esa información es muy valiosa para nosotros y lo podemos utilizar para tener también ese filtro y lo que hicimos fue denegar todo locación para que no tuviéramos acceso alguno hacia la infraestructura desde este lugar. Y bueno, eso hablando de infraestructura, pero también hablando de esta herramienta que nos ayuda a poder administrar todos estos servicios, pues lo hemos también cubierto en cuanto a temas de seguridad con el servicio de Identity and Access Management, el cual nos ayuda a poder determinar qué permisos va a tener a cada uno de nuestros usuarios. Verán, por mejores prácticas que tenemos gracias al World Architect Framework que nosotros justo tenemos una especialización en ello, una de las mejores prácticas es que cada uno de nuestros usuarios así sea el que va a tener menor interactividad en la consola, que es esta herramienta de administración de los servicios o aquel usuario que se va a encargar de apagar, de encender, de eliminar recursos, bueno, tengan los permisos adecuados y sea cada quien tenga su propio usuario y así podamos tener un mejor control de los accesos de nuestros usuarios hacia la consola. Y eso es lo que se hizo con nuestro cliente. Si nuestro cliente tiene un usuario de finanzas que solamente necesita tener acceso al servicio de billing, en este caso, bueno, solamente se creó este usuario con ese permiso en específico, no puede ver, no puede utilizar, no puede puede crear, no puede eliminar ningún otro servicio ni otro recurso en ningún otro lugar. Y entonces esta es una de las grandes ventajas que también se tiene con AWS. Para hacerlo tan granular. Nos vamos al siguiente punto en donde nos enfocamos en la disponibilidad de los servicios de nuestro cliente. Aquí era un foco muy importante para nuestro cliente, ya que ellos tenían este miedo de oye, si se cae mi servidor, ¿Qué voy a hacer? Mi productividad está ahí, no puedo estar abajo de ni de chiste en cuanto a mis recursos porque pierdo dinero, en eso se traduce todo en este punto. Y pues nada, con esto ayudamos a la disponibilidad de nuestro cliente al implementar una infraestructura con un servicio de auto scaling, el cual nos permite determinar los mínimos y máximos en cuanto a servidores y servicios que se tienen en cuanto a nuestra infraestructura. En este caso nuestro cliente tiene una instancia base, ese es un mínimo, con eso se ha determinado que es más que suficiente para las peticiones que tiene de manera diaria, de manera constante este servidor nos abastece muy bien la necesidad, sin embargo, en días en donde tiene picos de peticiones hacia sus servidores, este servidor no es suficiente en cuanto a rendimiento. Entonces para evitar que este servidor se sature y tenga una caída por la falta de, hemos implementado un balanceador que le vemos aquí en nuestro diagramita de primer filtro, que nos evalúa las peticiones y en cuanto tenemos una petición, se va a este servidor. Pero si tenemos el triple de petición de peticiones, como lo vemos aquí en el diagramita, se activa el auto scaling y nos generan nuevas instancias que nos ayuda a poder satisfacer estas necesidades que nuestro cliente tiene. Y así podemos ayudarle con alta disponibilidad a que siempre esté arriba, a que sus usuarios tengan la mejor atención y rendimiento en cuanto a su experiencia y también los mejores costos para nuestros clientes. Porque en este caso nuestro cliente pues solamente va a pagar por tres instancias por el tiempo en el que se necesite. ¿Porque una vez que estas peticiones bajan en cuanto a el porcentaje de utilización de estos servidores, entra otra vez el AUT y dice sabes que? Estas tres instancias ya no las necesitas, las eliminamos, las elimina de manera automática y otra vez nos quedamos con esta instancia inicial que es nuestro centro y es la con la que tenemos la productividad diaria. Entonces, este es el punto en el que integramos este tipo de servicios con la experiencia que tiene CompuCloud para poder crear una infraestructura con alta disponibilidad. Lo que me lleva al siguiente punto, el cual nos vamos a enfocar ya hacia los respaldos. Cómo nuestro cliente ha sido ayudado con estos respaldos que se tienen hoy en día en cada uno de sus servicios, como ya lo tenemos también desacoplado, podemos hacer uso y explotar las herramientas que se están utilizando para cada uno de los servicios que hoy en día tienen. En el caso de nuestras instancias, se crean respaldos de manera automatizada. Y aquí es muy importante tomar en cuenta cuando se creen respaldos automatizados, tres puntos en específico. Cada cuánto ustedes tienen la modificación de los datos en su servidor, determinar si este servidor está en qué ambiente, si es productivo, si es de desarrollo, si es de QA, para ver con qué frecuencia se van a tener que estar haciendo estos respaldos. Dependiendo de cada cuánto tiempo necesitemos respaldar la información y actualizar nuestro backup, pues esta sería la frecuencia. Y también un punto muy importante es cuánto tiempo deseo mantenerlo ahí. Si por temas de alta disponibilidad o bueno, de recuperación necesitamos tenerlo una semana, un mes y eso es más que suficiente, lo podemos mantener así. Pero tal vez por temas de normatividad nos piden tener un respaldo un año o tres años. Entonces eso también es una de las grandes ventajas que el servicio de AWS Backups, el cual lo tiene todos los servicios disponibles para aquellos que tienen la interacción de datos e información que nos permite tener estas configuraciones personalizadas y hechas a la medida. Otro de los puntos muy importantes que se tiene con este servicio es que es muy económico ya que se cobra de manera incremental, es decir, nos cobran por la cantidad de gigas que se hayan respaldado al final del mes, entonces no importa si tenemos 50 o 100 copias de nuestra de. De nuestro respaldo, si eso en Suma nos hace cinco, 10 GB, solamente vamos a pagar por esos cinco o 10 GB que tenemos en almacenamiento. Entonces no tenerle miedo a este tema de respaldos porque nos ayuda mucho para también regresar a un punto inmediato en caso de necesitarlo o un punto hace un mes también en caso de necesitarlo y de tenerlo configurado de esa manera es posible regresar en el tiempo y recuperar aquellos datos que tal vez hoy en día estuvieron perdidos para nuestro cliente por su tema de productividad. Se hicieron respaldos cada 12 horas y se tiene una retención de un mes y ya por temas de normatividad se tiene otro respaldo de nuestro servidor cada mes y se tiene con retención de un año. Entonces esta es la versatilidad que se tiene en cuanto al servicio de s. Ahora bien, para la base de datos nos enfocamos en esto, la base de datos puede ser respaldada también con el servicio de AWS Backup, se puede hacer las configuraciones y se tendrá un respaldo adicional. ¿Por qué adicional? Una de las grandes ventajas que tiene RDS al ser un servicio administrado por AWS, ya nos da por default una retención de nuestros datos, en donde incluso si tú tienes alguna contingencia, perdiste tu dato, se crashó tu base de datos, tienes un punto de recuperación de tus datos de hace un minuto, así de eficiente es para poder evitar esta pérdida de datos masiva o la tenemos hasta 72 horas, puedes regresar hasta ese hasta ese tiempo sin ningún inconveniente, sin necesidad de crear alguna configuración, eso ya lo tiene por default. Si esto en conjunto con Compu Cloud también se determina cuáles son las necesidades para ustedes y si dicen no, sabes qué yo si tengo alguna contingencia necesito regresar una semana antes, OK, sin problemas se hace la configuración extra para este tipo de respaldos y poder tener siempre esa continuidad de negocio referente a tus necesidades. En el caso de nuestro cliente, fue más que suficiente el tema de las automatizaciones que se tiene ya por default con el servicio de RDS, así es que no fue necesario crear una configuración aparte de la que ya se tiene. Entonces, esto por una parte, tener los respaldos sí o sí, pero también para nuestro cliente hemos hecho una estrategia especializada y totalmente diseñada para ellos, en donde hicimos esta infraestructura y nos apoyamos con una tecnología para la automatización de estas plantillas con el servicio de Terraform para poder implementar nuestra y desplegar nuestra infraestructura en caso de alguna contingencia. Hoy nuestro cliente se encuentra en Virginia, ahí es donde está toda su infraestructura, su base de datos y demás, pero gracias a esta plantilla tenemos ahora sí que básicamente la facilidad de crear una réplica totalmente exacta de cómo se tiene en ese punto de recuperación para poder desplegar la infraestructura en caso de que caiga aquí en Virginia, ya sea por temas del cliente o por algún desastre natural que exista en Virginia, esta infraestructura se va a desplegar de manera automática en Ohio, así es como se tiene determinado el día de hoy y configurado. Y el tema de la recuperación del tiempo que se tiene en cuanto al despliegue de esta infraestructura es mínimo en comparación de que si se cayó Virginia. Bueno ¿Y ahora qué tienes que hacer? Ponte a migrar respaldos y crea desde cero toda la infraestructura. Bueno, sería un tema en el que nos llevaría un poco más de tiempo, pero gracias a este tipo de automatizaciones fueron posibles porque nuestro cliente ya pasó por esta fase de el desacoplamiento de su infraestructura, nos hizo más sencillo el poder dividir las tareas y crear este tipo de soluciones a nuestros clientes. Lo que me lleva al siguiente punto, una adaptación al entorno tecnológico de la infraestructura. Gracias, reitero, a que nuestro cliente ya tomó esta decisión de ir por un desacoplamiento, pudimos integrar plantillas de Terraform, pero también pudimos integrar servicios de analítica como lo es QuickSight, que por ahí más adelante estaremos hablando sobre estos temas más a detalle en otros capítulos, pero este servicio nos ayuda a tener una analítica de nuestros datos, de los datos de nuestro cliente en un dashboard, poderlos explotar, poder tener gráficos, datos duros que le ayudan a las tomas de decisiones empresarial de nuestro cliente, muchísimo más sencillo que estar viendo, que estar analizando en un Excel. Esta herramienta le ayuda a nuestro cliente a poder determinar ciertos temas y fue posible gracias a que toda su información, toda su data se encuentra en esta base de datos, en esta RDS que con la integración de distintos servicios de AWS se extrae esta información, se transforma. Y es así como quicksight tiene la capacidad de poder analizar y entregarnos esto, lo que vemos aquí en pantalla y verlo muchísimo más, tenerlo visualmente más sencillo, más digerible para todo el equipo, todo el equipo de nuestro cliente. Entonces, esto también nos lleva a la parte de monitoreo. Para CompuCloud es muy importante siempre estar presente en cuanto visualizar cómo se encuentra toda la infraestructura de nuestro cliente. Es uno de nuestros cores, siempre estar al pendiente 24 7 y gracias a servicios como lo es CloudWatch, Service Health, Dashboard, nos ayudan a tener esta visualización en un panorama, en un dashboard como lo vemos aquí en pantalla, en donde tenemos todo centralizado, podemos ver CPU, RAM, almacenamiento, conectividad, data transfer. Es decir, podemos ir analizando todos los datos que sean necesarios para cuidar infraestructura de nuestros clientes. Y posteriormente estas métricas, estos datos, nos dan toda la facultad necesaria y la información para poder hacer recomendaciones. Oye, ¿Sabes que? Estoy viendo que el auto scaling está funcionando de manera eficiente, pero también digo, ya es un momento para poder irnos hacia reservas de costos, porque se ha mantenido muy bien el uso de tu instancia es el adecuado, entonces listo, te recomendamos irnos a una reserva. ¿Y qué significa esto? Ahorro de costos. Y Así es como CompuCloud tiene un panorama, una visión más amplia para poder cuidar tu infraestructura y en este caso, el de nuestro cliente. También siempre estar de la mano con alarmas, alarmas de todas estas métricas que se pueden estar midiendo gracias al servicio de cloudwatch, de cada métrica se puede tener una alarma, una alarma totalmente configurable y administrada para poder también generar estas automatizaciones y tener ya procesos estipulados en caso de que se detecte alguna alarma de utilización de CPU, de utilización de RAM, de que ya estamos llegando al tope de nuestro almacenamiento y evitar futuros desperfectos y también evitarnos algún momento en donde digamos, ¿Sabes qué? Ni modos, me quedé sin almacenamiento, voy a tener que parar aquí la productividad, apagar el server y agregar mayor almacenamiento o mayor recurso. Entonces nos ayuda a poder prevenir esto. Y algo que también es muy importante para nuestro cliente y que también se ha adaptado son los servicios en cuanto a costos de Cost Explorer y de Budgets. Budgets nos ayuda también tener un panorama de la visualización de los gastos de nuestros clientes y tener, como lo dice su nombre, ¿No? Presupuestos de no solamente cuánto estamos gastando ahorita, cuánto estamos consumiendo, sino también en los próximos meses tener una proyección, cuánto voy a gastar. Y eso también ayuda a nuestros clientes a realizar presupuestos. Entonces, si lo ven, gracias a este desacomplamiento en conjunto con el cliente y CompuCloud, se hizo ya toda una infraestructura en donde hemos integrado diferentes servicios para tener un monitoreo más avanzado de nuestro cliente, para tener un cuidado de su infraestructura y sobre todo esta resiliencia en cuanto a su productividad, evitar que caigan y si caen, estar preparados, tener plan A, B y C en caso de alguna contingencia. Y dependiendo el escenario, pues tenemos también los planes de acciones y estamos listos. Eso es un punto muy importante que en conjunto con CompuCloud, estar listo. Paso a paso, CompuCloud sabe cuáles son los temas que les toca hacer. OK, listo, ya está de nuestro lado. Ahora te toca cliente, conectarte y ya verificar que todo se encuentre en orden y listo, continúa. Ese es el apoyo que damos aquí en CompuCloud para tener esta continuidad de negocio de nuestro cliente. Ahora bien, en el siguiente punto, ya en el siguiente, en el siguiente paso, pues mi compañero Carlos González nos va a estar apoyando en explicarnos un poquito sobre la importancia de la modernización para la resiliencia y como nuestro cliente va a poder ir avanzando y evolucionando en este tema en cuanto a la infraestructura. Entonces, nada, adelante, Charly. Muchas gracias.

Súper, Sadi. Ya pueden ver que hicimos un cambio de.

Sí, listo, súper.

Pues gracias. Sí, exactamente. Creo que aquí ahora yo voy a enfocarme un poco más hablando acerca de la modernización. Si bien Sadi ya habla de ella, yo contarles un poco cómo llegamos a ese punto final a través de un par de pasos que CompuCloud va a apoyarte a recorrer, que no lo recorras solo, porque se entiende que esta transformación y esta modernización de la cual yo voy a estar hablando, las empresas pueden ejecutarla y la pueden ejecutar por sí solos y no se pretende decir lo contrario, pero una empresa que se dedica a ello, que lo ha ejecutado muchas veces, creo que tiene mayor agilidad para apoyarte en ese sentido. Entonces llevarlos a platicar acerca de cómo es este proceso de pasar del monolito, de cómo pasó el cliente de un monolito a un tema de servicios desacoplados, de microservicios que son sinónimos y cómo fue este proceso y cómo CompuCloud apoyó para ello y cómo se hila esto con el tema de la modernización y por qué la modernización ayuda a la resiliencia o mejora la resiliencia. La razón principal es por lo cual conviene modernizar uno de los puntos, aumentar la resiliencia es un paso y uno de esos pasos es esta división que de pronto se propone, no sé si han escuchado de pronto hace miles de años, creo que un siglo I antes de Cristo, el imperio romano estaba expandiéndose, estaba creciendo y este Imperio Romano en crecimiento proponía para conquistar otros imperios y culturas y pueblos una estrategia muy específica con la cual quiero partir. Esta estrategia se llama, muy seguramente la han escuchado miles de veces divide y domina o divide y vencerás. Aplica también para la computación informática, porque cuando tenemos por ejemplo un monolito muy grande y comienza a crecer, está hablando de un pueblo al cual quieres conquistar, pues es como más complejo atacar cuando pues es un pueblo extremadamente grande. Pero cuando hacemos una división del problema en uno o varios subproblemas de la misma clase o de tipo, primero podemos atacar la problemática, identificar más rápido la problemática y por ende pues desarrollarla de una mejor manera y es donde comenzamos a acoplar este tipo de servicios de los que platicaba Sadi, ya desacoplamos la carga y empezar a utilizar otro tipo de servicio que era parte de lo que voy a estar hablando un poquito más adelante. La problemática principal es que la empresa tuvo este objetivo de entender mejor y mejorar la resiliencia en la nube, ya están en la nube, tenían este monolito, pero realmente no sabían si era lo más eficiente y seguían sufriendo algunos deadlines de recuperación, seguía siendo complejo la innovación, la agilidad, había cosas que seguían siendo compleja. Entonces la modernización como definición nos invita es un proceso socioeconómico, es un proceso socioeconómico de industrialización y tecnificación, acción y efecto de modernizar tal cual donde hacemos, nos vamos de un punto a que como dice la ley de Moore, hace dos años se quedó atrás, porque cada dos años hay cierta duplicación en el avance tecnológico. Bueno, Mohr dice, hay una duplicación en la cantidad de transistores que tiene un microprocesador. Pero esto por ende también nos lleva a escenarios tecnológicos que nos dice que va a haber un cambio cada dos años de igual forma, o sea, si hubo un cambio del 50% en los siguientes dos años va a haber un cambio de ese mismo 50%. Entonces hay que entender que cada ciertos periodos de tiempo, que no la invitación es que cambien cada dos años, pero es importante saber que existen cambios en la industria y muy seguramente la competencia ya está pensando en ellos. Entonces quizás si seguimos un poco en los esquemas que tenemos actualmente, pues ya estamos, ya hay que medir el tiempo, porque si ya han pasado 4 o 6 años, estamos quedando muy, muy atrás. Y luego por esto nos lleva a la resiliencia. Obviamente actualmente se cuenta con esquemas que nos llevan a la resiliencia, como los respaldos que comentaba Sadiq, replicar por ejemplo un esquema monolito, hacer una réplica exacta en otra zona de disponibilidad, que si bien funciona, pero hay formas actualmente más eficientes de regresar este estado estable cuando un mecanismo sistema es cesado o perturbado y hay que regresarlo a este estado de estabilidad. Entonces aquí lo inicio con estas dos definiciones porque son importancia a lo largo de lo que voy a estar platicando y luego voy a dejarles aquí un pequeño video para entender qué es la redundancia datos y aplicativos y cómo tenemos redundancia de datos y aplicativos en un sistema monolito. En un sistema monolito entenderemos que puede existir esta resiliencia, pero va a ser mucho más pesada, más robusta, porque como se ve en el video, empiezas con un esquema y este esquema crece y este esquema conforme va creciendo nos va impactando en la complejidad para trabajar con este monolito que se vuelve muy grande, es difícil escalar, es difícil administrar, no es que dejemos de tener escalabilidad o administración o resiliencia, sino que se vuelve mucho más complejo conforme este ambiente comienza a crecer. Entonces aquí CompuCloud ayuda a analizar el ambiente monolito de la empresa con sesiones enfocadas al entendimiento de estos ambientes, encontrar qué punto se puede o qué tanto se puede dividir estos ambientes para estar dando recomendaciones y aquí entendemos que está como que el monolito en dos escenarios, un monolito, monolito, un monolito ya estructurado en tres partes que habla el tema de del frontend, del backend y el tema de la data, pero no deja de ser un monolito. En este caso con Pocloud, en conjunto con un equipo especializado se pueden apoyar de nosotros para entender mejor el negocio, ayudarlos a entender cómo podemos dividir en funciones de negocio este monolito con un assessment que entiende los procesos, ayuda a identificar estos procesos y puede comenzar a entregar recomendaciones para ir a un esquema. Creo que ya me saltó a microservicios. Sí, ya me saltó microservicios, entró a un esquema de microservicios, entonces bueno, ya entendemos que es un monolito, que tenemos sus puntos de pronto débiles de este monolito. Ahora, entender las ventajas de un esquema de microservicios es una gran área de oportunidad. Una vez que conocemos una arquitectura monolita y sus limitantes, ahora podemos comenzar a entender un ambiente distribuido o de microservicios. Quizá en algún punto esto se vuelve un tema serverless también, porque aquí tocamos como que unos pequeños hilos y diferenciadores entre microservicios y serverless, que un microservicio puede tener servicios serverless, o sea, aquí se hilan mucho las definiciones y bueno, la idea principal de un microservicio es dividir o descomponer el monolito en partes más manejables, justo con la principal frase que iniciaba, divide y vencerás, o sea, literal dividir, romper en capas más pequeñas. ¿Por qué capas más pequeñas? Porque la regla de los microservicios es que tengamos funciones, una sola función por microservicio, este microservicio es autónomo y esté totalmente aislado, ¿Que significa? Que si hay una afectación en alguna unidad o en algún algún microservicio, alguna función, perdón, en específico, esta función no afecta a otra función. Entonces el tema de que sea aislado nos da lo que estamos buscando al inicio, una redundancia de datos y aplicativos y una mayor resiliencia. Aquí me está saltando solito esta, voy a platicar un poco de, Voy a regresarme y bueno, solamente qué beneficia, ya no más para dar los beneficios en qué benefició a la empresa conocer el tema de microservicios, que ya sabe que va a tener una mejor administración de su infraestructura, porque ya va a estar por unidades, estas unidades totalmente independientes, sabe que si hay alguna caída, estas caídas son parciales. Puedes usar diferentes tecnologías, que ese es un punto muy importante. Ahora, si quieres utilizar como el punto de enlace para la comunicación API Gateway o alguna API, o quieres utilizar algún balanceador de cargas, o en el tema del backend, quieres utilizar algún desarrollo de software en específico para esa función en específica, puedes hacerlo, porque no te tienes que casar ahora con un desarrollo o un lenguaje de desarrollo en específico, que era lo que hacías con tu monolito. Ahora, cada una de las funciones de negocio puede tener y estar customizado hasta donde te dé el desarrollo, hasta donde te dé tu equipo. Y en ese sentido, Computo con el equipo especializado en modernización te va a guiar a través de este proceso de modernización para saber cuáles son los servicios serverless o los servicios administrados que te conviene utilizar ahí. De pronto más adelante voy a hablar de Landas, voy a hablar de lo que platica un poco de la base de datos ADIC, que puede ser Steinham ODB, puede ser Amazon API Gateway, puede ser balanceador de cargas, que son servicios ya administrados y en conjunto con ellos puede ser un microservicio que no se casa con algún lenguaje de desarrollo en específico. Claro que es uno de los puntos específicos. Es necesario como puntos difíciles para una migración a microservicios o una modernización. La verdad es que es difícil comprender y es donde también entra CompuCloud para guiarte y nosotros que conocemos el lado de los servicios en general, AWS, poderte guiar a cómo estructurar microservicio. Es necesaria cierta experiencia y es donde también entra compuclo, porque ya tenemos experiencia para guiarlos a través de este camino de entendimiento del microservicio. ¿Y cómo los guiamos para que comiencen a fragmentar este monolito? Se necesita que se tenga, y esto es bueno tomarlo en cuenta, un equipo de DevOps, un equipo que nos apoye con los patrones de diseño, crear nuevas arquitecturas de software, o sea, todo esto va a tener que cambiar. Y en resumen, ¿Qué haremos, ¿Qué hicimos o qué haremos con este cliente? Le ayudaremos a tomar la aplicación entera, separarla en pequeños componentes o funciones, conectarlas entre ellos y el cliente se va a encargar de hacer estos nuevos desarrollos para que estos microservicios se puedan dar como lo estamos proponiendo, pero ya con la guía de compuclo. Entonces ahora sí esto me hace pasar a arquitectura distribuida. Este tema es muy interesante porque aquí es donde finalmente concluye un poco, hay cierta conclusión aquí donde ya estamos viendo por ejemplo los componentes aquí de un microservicio que iniciamos con el User Interface que podría ser un poco el Front Component Implementation, que estaremos hablando del back y la comunicación que aquí está el balanceador de cargas y terminamos por la base de datos, que lo interesante aquí es que la base de datos por ejemplo puede ser cualquiera, que es donde es la parte interesante, si para una función necesitaran utilizar elasticaché en la base de datos utilizas en esa función porque es más adecuada para el tipo de función. Otra función que requiere solamente almacenar data y no esta es una base de datos SQL sino que algo que sea NoSQL, puedes utilizar DynamoDB y aquí puede ser un mix, puedes hacer un mix de diferentes bases de datos que se acople mejor a tu función. Igual en el tema de cómputo puede ser aquí ECS pero puede ser también una función, puede ser una función creada con Lambda que son como funciones más cortas, entonces aquí podemos hacer un mix de ello. Entonces aquí CompuCloud ayudará a la empresa a recomendar esta mejor arquitectura, estos servicios que son adecuados a la función, buscando obviamente que sea ágil, que sea escalable, que admita una implementación rápida en comparación con una arquitectura monolita. Los servicios, los microservicios tienen que ser ligeros y es lo que vamos a nosotros ayudar, que sean ligeros con un acople suelto y que utilices servicios nativos de nube, todos estos que ven aquí son servicios nativos de nube y cuando tienes un monolito es muy difícil, muy muy muy difícil y créanme que lo es utilizarlos y entonces no le sacas realmente el provecho de la nube, termina por utilizarlo a media ser un estar subutilizado el potencial cloud, entonces sí, sí es bueno este punto. OK, cuando desacoplamos en pequeñas acciones, aquí voy a leerles un poco de los apuntes, la integración con servicios administrados se vuelve fácil, que era lo que les comentaba, cuando desacoplamos en pequeñas acciones la integración con servicios administrados se ve mucho más fácil ayudándonos a comenzar a integrar una gama muy amplia de servicios administrados para su arquitectura, que aquí hasta podría ser, y adelante voy a hablar de ello, otro, no solamente en AWS, que aquí podríamos hasta hacer un multicloud. Y no es como que, no es que los invite, la presentación es para hablar acerca de AWS un poco, pero cabe comentar que cuando estás en microservicios es mucho más fácil hacer un esquema de multinube y es de lo que voy a hablar más adelante. Entonces tendremos disponibles una gama más amplia de servicios que podemos agregar a nuestras arquitecturas. Estos servicios, tecnologías que se recomiendan serán en base a la función, que lo que les comentaba, pensando en cuál es la mejor alternativa para esa función. Esto puede ayudar a incorporar una gama altísima de tecnología de forma fácil y más eficiente. Y aquí cuando ven, termina por decirnos es un microservicio. En la imagen, luego voy a mostrarles otro esquema de microservicio, pero aquí utilizamos servicios diferentes. Aquí si observan es API Gateway, que será el que nos ayudará a llevar la solicitud al microservicio. Bueno, es el microservicio que transmitirá la solicitud y la va a transmitir a la lambda, que la lambda aquí tiene dos tareas y esta lambda de manera lógica consultará la base de datos, que en este caso estamos hablando de DynamoDB, para recuperar la información solicitada y estos datos se devuelven, se entregan los datos que pidió desde API Gateway y termina la función así. Entonces terminó, terminamos esa tarea y esto puede ser infinito las tareas que sean necesarios. Y otro de los puntos fuertes que voy a hablar más adelante, también conlleva un poco de ahorro en costos, porque utilizamos muy eficiente los servicios, no los tienes ahí, aunque no los utilices, que es el esquema monolito, pues mientras esté ahí tienes que pagarlo independientemente tengas o no solicitudes. Y esto es muy poco eficiente y la verdad es que sería ya muy arcaico. Entonces hay que entrar, si es buena razón el tema de costos, ir a microservicios. Entonces, ¿Cómo andamos de tiempo para extendernos un poco más en la siguiente, pero bueno, creo que estamos bien? Dejo un poco el video que aquí menciona, Cost, reducción, aumentar la eficiencia operativa y otro punto que comentaba, aquí llegamos ya literal, esto estamos hablando de un ambiente de microservicios. ¿Y por qué se llama eficiencia operativa? Porque ahorita podríamos hablar de que es el tope en la eficiencia operativa. Versus un monolito, que aunque tengas tu Disaster Recovery, que tengas tu plan de DRP, que tengas tu plan de respaldos, tengas lo que tengas, que son buenas alternativas, no estoy diciendo que no, esto actualmente ir a microservicios es la alternativa que nos va a dar mayor eficiencia operativa. Al dividir funciones de negocio, podemos gozar de hacer un deploy de diferentes microservicios en diferentes infraestructuras. Si observan al inicio del video están tres, que no voy a mencionarlos más que el primero, porque aquí me puedo meter en problemas, pero podemos utilizar hasta tres ambientes. Podemos tener en la misma nube, en este caso doble s, un deploy de diferentes microservicios, pero independientes en diferentes puntos de infraestructura o diferentes zonas de disponibilidad, por ejemplo. Podríamos también descubrir más rápido un ambiente caído, ya con herramientas terceras, podemos hacer este análisis rápido, atacar este ambiente, que finalmente, como pueden observar, hay diferentes ambientes que están con la carita triste, pero unos otros no. Entonces no es como en el monolito que se afecta todo, que ya lo comentaba. Entonces descubriríamos rápido que es parte de lo que obtendría la empresa con la que estamos trabajando, obtendría esta mayor eficiencia a la hora de recuperarse ante un evento. Esto no afecta otros ambientes, el trabajo, mejoras son independientes, además de crear prácticas de integración continua, que de pronto son puntos que más adelante, que en específico son temas que por sí solos son muy extensos, el tema de la integración continua, pero ya podríamos llevarlo a cabo, usar ahora sí diferentes tecnologías, integrar diferentes modelos de desarrollo, de lenguajes de desarrollo y generaríamos equipos mucho más ágiles, porque no estarían entrando a un a un almacén lleno de cosas, que de hecho dice Arthur Schopenhauer, es mejor una biblioteca con pocos libros, pero acomodada a una biblioteca con un montón de libros, pero sin un orden. Entonces esto nos da caos y ni siquiera terminamos por tener esa tranquilidad que queremos tener con la resiliencia, porque de eso se trata, la resiliencia nos va a entregar cierta tranquilidad operativa y buscar siempre esta eficiencia. Entonces creo que aquí por tiempo voy a pasar al siguiente. Ya creo que esto es todo de mi parte. Solamente comentarles que existe un assessment de modernización para los ambientes, que actualmente está en la nube, pero con un esquema quizá un poco monolito, quizá ya dividido, pero no en microservicios. Hay un assessment que en conjunto con el equipo de modernización podemos ejecutar. Hay cierta coinversión con AWS. Entonces, es un assessment que tiene un costo. En otras ocasiones tendría un costo muy elevado. Y ahora mismo aquí estamos colocándolo con esta consultoría totalmente gratis para que puedan aprovechar que es muy, muy nutritivo todo esto que podemos descubrir en sus arquitecturas. Pero.