Architecture Championship - FinOps en AWS

En la cual hablaremos sobre FinOps en AWS en este Architecture Championship, pues bueno, ahí podrán conocer algunas de las estrategias que se utilizan para la cuestión de finops. Igual vamos a platicar sobre lo que es su definición. Más adelante les presento la agenda y aquí aprovecho para compartirles quiénes van a ser las personas que nos estarán acompañando el día de hoy. Aquí primeramente tenemos a Oswaldo Luna, nuestro Director de Negocio de aquí de CompuCloud. También nos acompaña la Ingeniera Paulina Martínez, ella está justamente aquí en CompuCloud en el área de Customer Success, apoyando a todo lo que es el seguimiento a clientes en cuanto a lo que son sus consolas dentro de AWS, compartiéndoles igual mejores prácticas, justamente algunas prácticas de FinOps que vamos a ver el día de hoy y también el Ingeniero Axel Loredo, que está justamente en este mismo departamento de Customer Success. Entonces, pues básicamente aquí tenemos a los expertos de estas prácticas de FinOps en AWS. Y pues bueno, pasando a la siguiente diapositiva, les platico rápidamente quién es CompuCloud. Seguramente algunos de ustedes ya nos conocen, pero para los que no, pues nosotros somos una empresa líder en servicios administrados de Amazon Web services. Somos partner advanced de AWS desde el año 2012 y tenemos diferentes especializaciones de lo que es la nube, desde la parte de migración, el diseño de las arquitecturas, hasta lo que es una modernización constante dentro de AWS a través de los diferentes servicios que van saliendo año con año aquí en AWS. Y obviamente tenemos diferentes certificaciones y reconocimiento que nos avalan como un Partner Experto de Servicios de Amazon Web Services. Entonces, pasando a la siguiente diapositiva, les platico rápidamente cómo irá la agenda y comenzaremos justamente con Osvaldo, en donde platicaremos cómo es el panorama general de FinOps, algunos beneficios de implementar esta estrategia de FinOps, sus mejores prácticas y también las automatizaciones para la reducción de costos a través de estas estrategias de Finance. Y pues bueno, justamente los dejo con Osvaldo Luna, quien nos estará platicando más a detalle sobre lo que es finops. Adelante Osvaldo.

Gracias. Muy bien, perfecto. Muchas gracias Giovanna, nuevamente, muy buenos días, bienvenidos sean todos ustedes. Y pues bueno, como punto clave o como me toca abrir ya desde la parte más allá de la presentación, y pues bueno, vamos a comenzar con los temas de finops y vamos de repente entrar a un tema de lo que es la definición, más sin embargo, antes de avanzar ello, me gustaría comentarles sobre algunos datos de impacto, algunos datos que se vuelven muchas veces, donde entre ellos algunos costos asociados a temas de seguridad y toda esta parte vienen a afectar a las organizaciones. Y quiero mostrarle algunos datos clave, algunos datos clave en temas que tiene que ver con el tema de los costos o toda esta cuestión. Por ejemplo, a través de una encuesta que hizo forest Research con HashiCorp, hizo una encuesta a 1000 tomadores de decisiones de TI, donde el 94 % comentó justo en esa encuesta que actualmente pagaban gastos que posiblemente eran evitables. Es como dicen impresionante que sabes que la gran mayoría, si estamos hablando de mil tomadores de decisión, 240 personas tomadores de decisiones aceptaron o comentaron que muy probablemente estaban teniendo gastos que eran inevitables. Y esa como cuestión. Y también la parte de IDC, la directora de investigación y gestión de datos en la nube de IDC en Europa, comenta algo muy interesante que dice que la adopción de la nube se ha acelerado, eso creo que todos concordamos, es correcto. Cada vez en los últimos años se ha ido acelerando, cada vez las empresas adoptan más la estrategia nube, ya sea de manera nativa, de manera híbrida, como parte estrategia de TI, algunas organizaciones se mide hasta 100 % a la nube. Entonces eso es claramente correcto y es algo que estamos viendo que la adopción ha ido creciendo en los últimos años, pero no al mismo ritmo como lo menciona, pero no los mecanismos de control de gobernanza, eso es súper importante. Y a qué se refiere con los mecanismos de control gobernanza de cómo vamos a controlar, literal, cómo vamos a controlar y quiénes van a ser los responsables de llevar y que no se conviertan en gastos innecesarios. Y pues bueno, esto al final de cuentas, esto que se comenta se cl clasifica que más o menos hasta un 30 por ciento de los gastos de la nube, según también esta investigación de esta persona de IDC, comenta que los resultados hasta el 30 % de gastos como innecesario. Entonces es un dato importante de impacto que como dicen, quise abrir con estos dos datos, seguro hay muchos más relacionados, pero definitivamente creo que este es el que más hemos visto también nosotros cuando clientes de cualquier nube de repente tienen estos temas y pues bueno, parte de ello, ¿A qué se debe estas dos analogías por decirlo anteriormente o estos más estas investigaciones previas que mostré? Pues bueno, hay tres ejemplos típicos y clásicos que podemos esperar. Primero de ellos es ejemplos de cursos de recursos no utilizados. ¿Qué quiere decir con estos recursos no utilizados? Precisamente que de repente pueden llegar a tener estos costos inesperados por tener de entrada no tener ese control o gobernanza, no sabemos o más bien no ponemos atención o detalle a si los recursos, tengo recursos de más recursos que están a la mitad de su capacidad trabajando todo el tiempo o inclusive literal como lo dicen, no utilizados, que ni siquiera, no es que no estén sobrados y ni siquiera de repente tiene levantado una instancia, un disco duro que es información y todo eso cuesta y pues obviamente impacta esta parte y obviamente esto a medida que la nube crece, esto a medida que la nube crece vamos metiendo más bases de datos, toda esta parte, si no utilizamos esta cuestión de recursos, pues bueno se empieza a ver comprometido esta cuestión. Otro de ellos es un tema resistencia a la modernización. ¿Por qué dices, oye, por qué si no me modernizo puedo incurrir gastos? Efectivamente, porque muchas veces al no tener las empresas una cultura, voy a decirlo de esta manera, de innovación, de actualización constante o adaptar nuevas tecnologías, están perdiendo y muchas hasta una eficiencia de un 20% o hasta más en diferentes casos, por no migrar a instancias más nuevas, agua, servicios, de repente quizás en lugar de tener un servidor para cierta cuestión, a lo mejor es candidato a trabajar bajo una infraestructura serverless. Y también el tema de anomalías, el tema también de anomalías nos lleva al siguiente punto que es la mayor sorpresa que pueda llegar a tenerse, de repente es como uno de los más inesperados de estos tres y anomalías puede ir desde un tipo, una demanda que puede llegar a tener nuestra aplicación y toda esta parte no existe un control, un ciberataque, algún tema relacionado con la parte de la gobernanza. Entonces estos son los tres ejemplos que reitero, recursos no utilizados, resistencia a la modernización, es un punto muy importante que entre manos se enfoquemos a movilizar y utilizar tecnologías más nuevas y otro tipo de tecnologías también van de la mano con ahorro de costo y todo este tipo de anomalías a cuestiones no esperados. Entonces esos son como partiendo de los datos anteriormente y algunos ejemplos de costos inesperados. Pues bueno, existe una metodología, un framework en el cual es la parte central de este Architecture Championship que se llama FINOPS y vamos a entrar una pequeña definición. ¿Que significa Finops? Podremos encontrar muchos significados en Google, si lo googleamos en cualquier buscador de Internet. ¿Sin embargo este me pareció el más concreto y más directo donde dice qué es FINOPS? FINOPS combina principios o más bien problemas de Finance Operation y combina los principios financieros con prácticas operativas. ¿Esto qué quiere decir? Para que puedan asegurar las organizaciones utilicen los recursos de la nube de manera eficiencia y y rentable. Entonces nace un concepto y se vuelve un framework donde de repente empieza a cambiar el mindset o debe cambiar el mindset de cómo trabajan las organizaciones. De entrada muchas veces trabajan por separado los departamentos de tecnología con los departamentos de finanzas. Muchas veces lo ven como un gasto al área de sistemas, sino como un área operativa que aporta. Entonces esto empieza a cambiar la mentalidad de las organizaciones para poder generar un tema de fino y donde voy a mencionar algunos de los principios básicos que existen dentro de la metodología de FINOPS. Entonces dentro de estos principios básicos, seis principios fundamentales. Hay sitios donde demuestran, hablan de diez, otros de nueve, pero en realidad estos son los principios fundamentales, por eso lo pusimos como fundamentales para integrar la parte de FINOPS en las organizaciones. ¿Primero la colaboración es el principio básico no? La colaboración como bien mencioné y como les adelanté un poquito en la anterior diapositiva, los equipos de ingeniería y de finanzas y desarrollos y negocios deben de colaborar en conjunto. Ya no es aquel que de repente un área tiene un área de desarrollo y que simplemente diga oye necesito un servidor de tal características para generar un aplicativo. ¿Entonces cambia donde dice sabes que? La parte de finanzas de ingeniería dice saben que vamos a requerir una aplicación para el área de marketing, finanzas entre un tema más o menos generar costeos, la parte desarrollo busca las opciones que mejor se adapten, el tipo de código y sobre todo la parte de negocios también el frente de negocios de esa parte debe colaborar. Entonces se vuelve ya un tema donde las organizaciones colaboran y no trabajan en silos cada área como dicen por separado. Y así cada parte que está involucrado en el proyecto, voy a ponerlo de esta manera, tiene una responsabilidad, asumir la responsabilidad de uso en la nube, donde siempre van a buscar que la utilización sea lo adecuado. Porque hablamos de optimización de costos, pero también muchas veces hablamos de optimización de recursos. ¿Esto también puede ser la cuestión contraria donde dices, oye, sabes que? Es que mi aplicación no está funcionando correctamente porque está al tope de los recursos. Entonces algo también que es un cambio MINDC, porque muchas de las áreas de finanzas dicen tienes un presupuesto de X cantidad de dólares y no te debes de pasar de ahí sí o sí, yo en la pa. Entonces hace que de repente se puedan hacer ajustes y muchas veces los equipos dicen no, ya sabes que ya optimicé el código, ya optimicé todo. Si logramos reducir el consumo de recursos un poco, pero aún así no es suficiente, entonces llega a fracasar el proyecto. Entonces es algo que ya se evalúa y por eso vuelvo a parte también la responsabilidad y parte del punto donde está la parte negocio se involucra en esta parte y que puedan llevar a tener esta flexibilidad. Esto la centralización quiere decir con la centralización, pues a pesar de que haya la colaboración, la responsabilidad, pues bueno, un equipo centralizado respalda un modelo común del uso de la nube paralelo, al final de cuentas todo se puede llegar a centralizar la colaboración, pero centralizado con unos responsables que van a poder llevar a un buen punto, un buen puerto toda esta estrategia de finance. La parte de informe se vuelve importante estar generando los informes sobre cómo va todo el tema y literal como lo dice Proxy y compartir informes de manera rutinaria entre los equipos de finops, toda la parte de involucrados es empezar a compartir estos informes y los informes. No es solo un tema de mira, este mes gastamos tanto, sino más bien este mes se gastó tanto, se optimizaron tales recursos o estos estaban sobrados, los bajamos, nuestro aplicativo ha tenido una mejor eficiencia, es un tema 360, no solo puro financiero, porque muchas podemos caer en ese tema de puro financiero o solamente cuál es el consumo de usabilidad de la infraestructura, como bien lo dice Finances on Operations, generar informes completos, obviamente tan seguido lo requiera la organización. Esto puede ser tan flexible o tan cambiante o tan dinámico como cada organización. Puede haber organizaciones que por su tipo de aplicaciones o por un periodo inicial que se libera una primera aplicación, a lo mejor necesario semanalmente generar este reporte, posteriormente 15 días, luego mensual, luego trimestral, ya conforme vaya evolucionando, como se vaya estabilizando, las distancias entre un informe y otro pudiera ir siendo mayor conforme vayan madurando en esta parte. Y obviamente cada parte interesa y asume la responsabilidad del uso de la nube. Tiene que ver arriba con la usabilidad, pero abajo también con el costo, es muy parecido. Y obviamente generar aquellas oportunidades donde podamos buscar costos variables, de repente que oye, si genero este modelo de consumo me voy a ahorrar ciertos costos y si lo cambio a toda esta parte aparte si hago un escenario de reservas que más tarde, más adelante van a hablar, me ahorro tanto, vale la pena. Entonces es una manera de cómo esta parte. Entonces estos son los seis principios fundamentales que me llevan a aplicarlos a un framework. Este framework de hecho como dice, no es un framework desarrollado por CompuCloud, es un framework que se obtuvo por la cuestión de Foundation FinOps y pueden verificar la URL y donde podrán encontrar más información referente a temas de FINOPS, pero como lo dice y voy a leer textualmente, FINOPS es una disciplina en evolución de gestión financiera en la nube y una práctica cultural que permite las organizaciones obtener el máximo valor comercial, ayudar a los equipos de ingeniería, finanzas y negocios para la colaboración de la toma de decisiones. Y es aquí donde aterrizo lo que les mencionaba hace rato de cómo la colaboración de los equipos necesitan generar esta colaboración adicional, donde parte de ello se vuelve clave aquellos recursos donde los equipos equipos necesitan estar colaborando y formados todo el tiempo. Reitero, es muy importante y por eso hacemos doble cheque en esta parte, todos asumen las responsabilidades, el equipo centralizado impulsa FinOps. Los informes deben ser accesibles y oportunos como se los mencioné, simplemente esto es una parte de lo que ya mencioné, accesibles y oportunos, si, a Eso me refería. ¿Qué tan oportuno es? Pues bueno, tan oportuno como cada organización o cada aplicativo, vuelvo a lo mismo, a lo mejor todos los tienen ya muchos aplicativos, muchos wordload corriendo en la nube que podrán tener necesidades diferentes de informes, entonces son tan oportunos como cada informe, cada aplicativo lo requiera. Y así que las decisiones deben estar impulsados por el valor comercial de la nube y aprovechar el modelo de costo variable que era la parte lo que comentaba y una sugerencia también de personas que deben de estar involucradas pues es tener por lo menos personas con conocimientos básicos en finops algunos, algún ejecutivo que se encargue también de parte, no necesariamente tiene que ser, pero que pueda ser parte de sus labores. El propietario del negocio y de productos es súper importante porque muchas veces, reitero, si hablamos de una empresa pequeña, pues pudiera ser propietario de negocio, por si hablamos de una empresa con múltiples productos, múltiples soluciones, múltiples aplicaciones, pues bueno, es donde los product owners se involucran en esta parte. Y definitivamente la parte de finanzas, pero más bien como un socio, un colaborador, que el CFO por ejemplo, se vuelva el mejor amigo del CTO, que muchas veces van por cambios separados, donde dice, chin, este me va a restringir el dinero y el CFO dice, me va a gastar mucho, vamos viendo, ¿No? Es donde se empiezan a generar y sobre todo las áreas de ingeniería y operaciones. Y pues bueno, ¿Cuáles son las tres fases, o más bien el círculo permanente como lo podemos ver? ¿El círculo permanente, como lo podemos ver? ¿Cuáles son las tres fases que podemos tener? El primero es informar, la parte de informar nos permite generar esta visualización y asignación en las diferentes tareas. Vuelvo a lo mismo, se vuelve a informar a través de los informes, pues obviamente, como dicen, de nada nos sirve la información que obtenemos si no generamos ciertas ejecuciones, ciertas acciones. Entonces si dentro de la información, la visibilidad y la asignación, pues bueno, puedes encontrar, ¿Sabes que? Pues encontramos a través de los informes que tal instancia o tal workload está demasiado sobrado, los recursos vamos a reducirlos o identificamos que este workload puede ser sujeto a modernización, que nos va a ayudar a tener una mejor eficiencia si lo mandamos a temas de serverless y además de tener mejor eficiencia, voy a tener ahorro de costos, eso se trata. Y una vez que se optimiza, pues se continúa operando y aquí la mejora continua, se opera y vuelves a entrar. Entonces es un ciclo que se repite, voy a ponerlo de esta manera, como un loop, donde se generan todas estas cuestiones, perdón, muy bien, sale y obviamente todo empieza con un nivel de madurez, hay que ir adoptando, hay que ir adoptando como una fase natural, empezar con lo más básico, muchas cuestiones. Lo más básico puede ser tener primero esa colaboración inicial con un workload, generar un monitoreo como tal, posteriormente pues ya empiezas a caminar y adoptar el modelo hasta que puedas llegar a correr, decir, ¿Sabes que? Ya es una práctica cimentada a nivel organización, que inclusive nos ha ayudado a aumentar el ritmo de innovación, nos ha ayudado a aumentar nuestro valor competitivo y obviamente conforme vas avanzando vas teniendo diferentes dominios que es necesario ir teniendo. Primero, la comprensión del uso de la nube y el costo, cómo se cobra, cuesta que no, porque así como hay muchas cosas, hay costos fijos en la nube, como hay costos variables, como en muchas nubes hay servicios que ni siquiera generan un costo. Entonces es importante esta parte y definitivamente un seguimiento del rendimiento y benchmarking que te deja todo este tema. Toma decisiones en tiempo real. Esos dominios que nos va también vamos a obtener basado en los informes y todo lo que va a estar podemos estar teniendo. Toma de decisiones, optimizaciones de tarifa, son dominios que se deben de encontrar, o sea, ¿Cómo puedo optimizar? Ya sé que este es el recurso que tengo, ya sé que es el recurso que necesito, voy a tener una operación estable por uno o dos años de toda esta parte, ¿Qué optimización de tarifas puedo hacer? Y es donde van a hablar más adelante mis compañeros para ciertos escenarios y para la parte de la optimización de casos de uso en la nube, pues bueno, también eso es lo que nos lleva y así hasta tener una alineación organizacional, eso es como dice la magia de este framework que pudiéramos llegar a tener. Y pues bueno, como dicen en el siguiente slide, ¿Qué beneficios van a obtener las empresas al implementar FINOPS? Aquí voy a ser muy breve porque tiene que ver con los beneficios y la parte que podríamos llegar a tener en cada uno de los costos. Obviamente el control de costos y optimización financiera como punto número uno. Al implementar un framework de finance, vamos a mejorar esta parte de control de costos y optimización financiera. Visibilidad y transparencia en todo momento, es decir, saber en qué se gastó, cómo se gastó y de qué manera se puede mejorar. Y obviamente esto me lleva al siguiente punto, la mejora en la toma de las decisiones. Puede existir una responsabilidad financiera o una corresponsabilidad cuando hablamos de un tema de colaboración. ¿Escalabilidad y felicidad financiera, que es lo que mencionaba hace unos slides, donde ya no necesariamente se tiene que ver como algo rígido que diga, sabes que? Necesitamos ir incrementando nomás este presupuesto de aquí no te pasa, pero si llegan nuevos negocios, cómo podemos generar esta escalabilidad financiera y obviamente encontrar una viabilidad y retorno de inversión de una manera más controlada y más certera. Cuando generamos inversiones en estos temas van a tener una mejor automatización y eficiencia operativa, así como un cumplimiento y gobernanza. Ya cuando tengamos estén las partes, los stakeholders involucrado y centralizado lo que mencionaba en ciertas personas, bueno se mejorará el cumplimiento de la gobernanza y definitivamente fomentar la innovación. Ese es algo que nos va a dar, porque al conocer todo el tema de los costos, toda esta parte puedes generar y costear periodo de pruebas de ciertos pilotos, de ciertos proyectos que puede ser que no sabes si va a funcionar, pero parte de saber o no funcionar dices ¿Cómo puedo saber? Y si no funciona que nos cueste lo menos posible. Entonces esto es algo que va potencializar el tener una cultura de fin ups a las empresas que es la fundación de innovación. Y por supuesto esto nos lleva al último pero no menos importante, pues reduc los riesgos en esta cuestión. ¿Y como dicen para aterrizar e ir terminando con mi parte, pues bueno, como comparar a tener una práctica de finops? Bueno existen diferentes puntos, pero algunos de los que están aquí reflejados, pues bueno, tiene que ver con, primero que yo los ayuda el tema de nuestros clientes en la búsqueda constante de recursos no utilizados, ver qué está sobrado, ver que no se está utilizando, ver cómo lo podemos estar generando una detección temprana de anomalías a través de las propias herramientas que nos ofrece AWS, que ahorita entrarán en detalle, así como otro tipo de herramientas que nosotros utilizamos para garantizar esta detección de anomalías. Optimización continua y permanente es algo, el buen uso de la nube no quiere decir que hoy optimicé, ya me olvido y hasta dentro de un año, dos años veo, le vuelvo a dar otra pasada, No, esto es algo continuo y pues bueno, es como ayudamos a nuestros clientes en co colaboración para poder generar esta parte y sobre todo cuando se temas de mejora, presupuesto y previsiones. Esto por decir algunos temas de fino, hay más temas, nos apoyamos, entre otras cosas. Pero bueno, muy bien. Entonces dado este tema, pues bueno, yo estaría cediendo la palabra para continuar con la presentación a mi compañero Axel y pues bueno, muchas gracias.

Listo, excelente. Muchas gracias Osvaldo por comentarnos acerca de los finops, ahora sí que veremos cuáles son las mejores prácticas dentro de AWS para aplicar esta disciplina y cómo es que AWS mismo ya cuenta con apoyos directos para facilitarnos esta tarea ajustándose a cualquier necesidad. En primera parte tenemos estrategias para optimizar nuestros recursos dentro de la nube de AWS, prácticamente iniciamos con un tema por ejemplo de monitoreo y análisis, utilizando servicios por ejemplo como lo son cloudwatch para monitorear el uso de los recursos, por ejemplo hablemos de monitorear CPU, RAM, disco, monitorear otros temas, podemos almacenar incluso logs, entonces es una oportunidad muy buena de optimización porque nos podemos dar cuenta de puntos muy específicos, incluso de nuestros servidores, de nuestras instancias, cómo las estamos utilizando e incluso si podemos mejorar algo en ellas, podemos configurar alertas incluso para que todos estos por ejemplo picos inesperados de utilización o incluso subutilización de recursos nos lleguen de manera automática, haciéndolo todo muchísimo más constante y facilitándonos la tarea. ¿Otro punto muy importante es el tipo de instancia, cómo que el tipo de instancia? Prácticamente en cuanto a EC que son nuestros servidores principales dentro de la nube, son los más usados comúnmente. ¿Qué importancia tiene escoger un tipo de instancia? Prácticamente al decir tipo de instancia nos referimos por ejemplo un tipo de familia, las familias prácticamente nos indican cuántos recursos de cómputo van a tener, mencionando un ejemplo por ejemplo 4 de CPU, 16 de RAM, entonces es muy importante definir bien o adecuadamente los requisitos para nuestra carga de trabajo, puesto que podemos ver que la utilización sea la que necesitamos, no estar con una instancia mucho más grande y que la utilización sea demasiado baja, puesto que ahí habría un costo muchísimo mayor. Entonces para este tema incluso para analizarlo existen recursos como Compute Optimizer, que eso ya se ahondará un poquito más adelante, pero ahora sí que esa sería una recomendación, incluso una estrategia muy buena para este tema. Análisis a futuro Aquí utilizaremos por ejemplo varios recursos, varios servicios, uno de ellos es Forecast, Forecast prácticamente es un servicio de pronóstico, el cual nos ayuda con este tema de Machine Learning a analizar nuestras métricas, organizaciones, así como lo dice prácticamente cómo va a ser nuestro futuro y esto combinándolo con QuickSight, que QuickSight es prácticamente un BI que nos ayuda a potenciar nuestros datos prácticamente unificándonos a hiperescala, podemos tener todo de manera muchísimo más visual, podemos crear ahora sí que tableros con toda la información, por ejemplo hablemos de costos, podemos hacerlo de manera incluso más granular, cuánto se ha gastado por mes, con porcentajes, con gráficas, podemos hacerlo muchísimo más centralizado y que ahora sí toda esa información esté en un mismo punto. Bajo este mismo punto podemos estar ahora sí que simplemente entrando, viendo cómo vamos, si hay algo fuera de lugar y podemos ahora sí que tomar una decisión a futuro, por ejemplo puntos donde podemos mejorar temas de arquitectura serverless. Las arquitecturas serverless son muchísimo más recomendadas que por ejemplo arquitecturas normales o monolito, puesto que prácticamente utilizamos recursos o servicios que simplemente aprovisionan lo que necesitan, no utilizan más ni menos. Y dado el caso de que necesiten por ejemplo que la carga de trabajo al momento sea mayor, estos mismos aumentan esa carga durante ese lapso de tiempo y luego disminuyen a la carga normal, simplemente utilizan lo que necesitan o como dicen bajo demanda. Uno de ellos por ejemplo es Lambda, que Lambda es un servicio para ejecutar código sin necesidad de un servidor, es muy útil y es muy usado en general, puesto que nos ayuda incluso para temas por ejemplo de alarmas, de mensajes, todo de manera más automática. Utilizar servicios por ejemplo como API Gateway, Step Functions o Fargate, que Fargate también nos ayuda a construir aplicaciones sin necesidad de preocuparnos por la infraestructura, todo es de manera prácticamente automática. Y un servicio o prácticamente algo que va en conjunto casi siempre es el uso de las bases de datos. En este caso ¿Cómo tener un uso eficiente en nuestra base de datos? Utilizando por ejemplo bases de datos gestionadas por AWS como RDS o Aurora, puesto que prácticamente nos ayudan a reducir la carga operativa y podemos incluso optimizar temas de costos de licencias. Pasando a temas por ejemplo de MySQL o Postgres, podemos obtener estos ahorros en general, puesto que también estas bases de datos utilizan estrategias de particionamiento y optimización de consultas, así mejoramos rendimiento y mejoramos costos, ahora sí que vamos en un X. Seguridad y cumplimiento ¿Cómo esta parte nos puede apoyar? Prácticamente implementando prácticas de seguridad recomendadas podemos reducir ahora sí que todos los riesgos a futuro que pueden afectar nuestra infraestructura y como prácticamente en base a un ataque podría entrar alguien y aumentar, por ejemplo abrir una instancia con un mayor uso, pues eso prácticamente nos va a pegar tanto en costos y en la estrategia, Entonces siempre, siempre hay que tener políticas de seguridad, políticas de cumplimiento que se apliquen para todos esos temas y así poder evitar costos adicionales o incluso penalizaciones que pueda haber dentro de la infraestructura. Temas de gestión de costos, prácticamente podemos configurar presupuestos con temas por ejemplo AWS Budget, que ahorita entraré en tema en ello, pero prácticamente con esto podemos incluso monitorear y ayudarnos a controlar un poco los costos, ya en casos por ejemplo donde veamos un presupuesto, establezcamos un presupuesto, es decir, tengo por ejemplo 500 dólares para el mes, podemos establecer ese presupuesto y en conjunto incluso por ejemplo como mencionaba con Lambda, pues recibir alertas en el caso de que nos estemos llegando o acercando a este presupuesto que nosotros establecimos y junto a otros servicios u otros análisis por ejemplo de costos, podemos tomar decisiones en este caso por ejemplo en base a las instancias DC, aquí hay un tema muy importante que no solo escogiendo bien la instancia podemos ahorrar o podemos tener un uso por así decirlo de mejor manera, sino que hay estas tres opciones extras, o sea, esto es aparte, una instancia reservada, instancias en Spot o saving plans. ¿Estas tres prácticamente nos apoyan ahora sí que de manera más puntual al tema de costos, al tema de ahorro de costos, pero también tienen sus puntos no? De utilización, por ejemplo las Spot Instances nos automatizan el uso para prácticamente las cargas de trabajo, pueden tolerar interrupciones y son significativamente más baratas que las instancias bajo demanda. ¿En qué casos podemos utilizar instancias de Spot? Pues prácticamente en temas de procesamiento de Big Data, ejecución de trabajos, de análisis de datos con herramientas como Apache Hadoop o Apache Spark, podemos hacer temas de tareas de batch, procesamiento de trabajos por lotes, renderización de imágenes y videos, temas de pruebas y desarrollo, donde estemos, donde la interrupción ocasional es aceptable y aplicaciones de CD, entornos de integración y entrega continua. Podemos incluso utilizar este tipo de instancias o otras que son las más utilizadas y unas que también son muy recomendadas que tienen dos variantes, en este caso las instancias en reserva que nos ayudan para obtener descuentos significativos, prácticamente todas son en comparación por ejemplo con demanda, podemos tener dos tipos, en el primer tema serían las reservas estándar, estas reservas estándar nos comprometemos a un plazo de uno o tres años prácticamente a pagarla por ese lapso de tiempo, pero, el pero está en que nosotros nos vamos a quedar con esa capacidad que nosotros hayamos ahora sí que colocado puede ser 416 y con esos 416 nos vamos a quedar todo ese año o esos tres años, pero vamos a tener un descuento, prácticamente es la desventaja, no podemos modificar, digamos aumentar los recursos o disminuirlos, nos quedamos con esas y prácticamente nos ofrecen un mayor descuento. Y las otras serían las reservas convertibles, estas reservas convertibles prácticamente en diferencia con los estándar si podemos incrementar y si podemos decrementar, no en caso de que sea necesario, el descuento es menor pero sigue habiendo un descuento bastante importante a la hora de tener nuestra instancia. Y por último los Saving Plans nos ofrece un 72 % de descuento en comparación con precios bajo demanda, pero pues prácticamente nosotros nos comprometemos por ejemplo a cumplir con una cuota por así decirlo de utilización al mes o de utilización en general, nosotros establecemos incluso cuántas instancias vamos a meter dentro de este plan y pues prácticamente tenemos esa flexibilidad y ese ahorro de costos que siempre va a venir muy bien. En siguiente, hablando un poco de temas, como mencionaba las primeras diapositivas, tenemos a Cost Explorer o el tema de Cost Reporting, que son prácticamente generación de reportes de consumo, prácticamente el objetivo principal es tener un control efectivo y tener decisiones estratégicas basadas en datos precisos, datos de costos, análisis de por ejemplo incluso granularmente por servicio. Los objetivos prácticamente es tener un control, optimización financiera, la transparencia y visibilidad, puesto que podemos proporcionar claridad sobre cuánto es el uso y cuánto es el gasto de cada uno de los servicios, así incluso con esto podemos planificar como les digo presupuestos o incluso previsionar hacia futuro incluso con un crecimiento, atribución de costo, cumplimiento de gobernanza, cumplir con las políticas y auditorías, mejora de toma de decisiones como comentaba y la automatización de informes, así reducimos el esfuerzo manual de estar viniendo por servidor, por instancia, por almacenamiento, por cantidades, sino que lo tenemos todo de manera general y granular con tablas y una información muy precisa y hasta de manera muchísimo mejor. Nos apoya en gran parte con esto AWS Budgets, que como lo comentaba anteriormente nos apoya ahora sí que a generar alertas en caso de por ejemplo que estemos llegando a un umbral de costos, como lo comentaba anteriormente, este nos va a avisar cuando estemos llegando a ese umbral, incluso podemos establecer de manera más específica los presupuestos en cada uno, prácticamente nos ayuda a gestionar mejor las finanzas, optimizar los recursos, claro, porque estamos viendo qué tanto gasto estamos teniendo por los recursos y nos ayuda a mantener un control de los gastos y en general en combinación por ejemplo con el cost reporting, prácticamente estos dos van de la mano y siempre, siempre nos van a dar un apoyo muy grande. ¿Con estos límites podemos plantear por ejemplo monitoreo en tiempo real, claro, porque prácticamente nos va a avisar al momento cuando estemos llegando a los umbrales, las alertas, notificaciones que son automáticas, podemos claro optimizar recursos gracias a también esto y mejorar la toma de decisiones, claro, porque estamos viendo cuánto estamos gastando, en qué estamos gastando, nos está avisando al momento para nosotros pues ahora sí que estar al pendiente, por ejemplo si estamos a mediados de mes y ya estamos llegando al presupuesto, qué podemos hacer? Y en conjunto con las estrategias anteriores pues aplicarlas para que el costo no se sobresalga de nuestras manos. Por último tenemos un tema de Trusted Advisor. Trusted Advisor en conjunto pues nos ayuda a temas de mantener ahora sí que los entornos en AWS más seguros y eficientes, prácticamente con un objetivo de optimizar costos, optimizar el performance, la seguridad, como lo comentaba, puesto que tenemos por así decirlo varios checks que podemos pasar o nos manda una advertencia o incluso un error, decir aquí mira aquí hay un punto de mejora y podemos tomar esos puntos de mejora para aplicarlos y ahora sí que tener no sólo una infraestructura más resiliente, sino que incluso con puntos de mejora en gastos, mejoras de rendimiento, obviamente una mejora de seguridad, que eso siempre, siempre viene muy bien y nos ayuda incluso con la gestión de límites de servicio, evitar interrupciones al monitorear estos límites de servicio, todos estos en conjunto, estos tres, sobre todo estos tres servicios nos apoyan a tener esta infraestructura más resiliente, más optimizada, mucho mejor a operar a escala en nube y pues ahora sí que de manera general viene muy bien todos estos apoyos. Entonces ahora sí que de mi parte esto sería todo, pasamos ahora sí que con la ingeniera Paulina, te cedo el micrófono Pau.

Claro que sí, muchas gracias Axel, te robó pantallas, necesitas dejar de compartir. Vale, gracias. Excelente. ¿Bueno pues estábamos haciendo mención hace unos momentos sobre todas aquellas estrategias que podemos tener pues básicamente con todo esto que nos estaban comentando los ingenieros y nuestro director verdad? Pero qué mejor si podemos llevar como todas estas estrategias que se estaban comentando de una manera más automatizada para así pues nosotros tener como por así decirlo el menor trabajo posible. Bueno si nos vamos un poco con todos estos aspectos pues podemos hacer mención sobre la primer apartado que es más que nada encargarnos o ver la manera de poder tener un escalado automático, justamente ese escalado automático ¿Cuál sería el objetivo del mismo? ¿Pues más que nada ajustarnos hacia la demanda, podríamos hacer uso de un auto scaling group el cual justamente se va a encargar de esto, va como tener como ese monitoreo de toda nuestra carga de trabajo y justamente cuando nosotros sabemos que tenemos ciertos picos de cargas de trabajo pero que realmente no sabemos qué tanto pueda llegar a subir pues ocupamos el mejor rendimiento posible, este servicio como tal se encarga de ello, lanzar los servidores necesarios para que nuestro aplicativo tenga el mejor rendimiento posible y caso contrario si obviamente ya pasó nuestra demanda fuerte ya sabemos que nuestras cargas van a bajar pues obviamente no nos sirve de nada tener infra de sobra entonces justamente ese servicio se encarga de hacer la reducción de la misma, todo esto con el objetivo de poder asegurarnos de que realmente estamos pagando por aquellos recursos que están siendo utilizados verdad? Bueno si nos vamos en aspectos como más infraestructura como código hace un momento el ingeniero Axel hacía mención de todas aquellas arquitecturas serverless que realmente eran como la mejor opción en algunos aspectos pero en este caso no es la excepción, también podemos hacer uso de lo que es AWS Lambda, todo esto con el objetivo de poder generar scripts que detecten todos aquellos recursos que no han sido utilizados, el director Oswaldo se ha mencionado en un inicio muchas de las veces esto nos genera como un cargo adicional porque en X momento se lanzaron los recursos por algún objetivo en específico pero en determinado momento se dejaron de utilizar y esos recursos quedan aprovisionados y quizás no nos hemos dado cuenta pero al final de la factura lo tenemos ahí y se está consumiendo, entonces justamente de este lado se pueden crear justamente estos scripts que se encargan de encontrar todos estos recursos y pues saber a su vez terminar con ellos, igualmente todo esto con el objetivo de pues nosotros tener la certeza de que todos los recursos que tenemos pues están siendo utilizados y tienen un objetivo en específico, este beneficio pues obviamente nos ayuda bastante con la reducción de los costos, elimina infraestructura basura o no utilizada pues para tener el mejor rendimiento posible. Si nos vamos a aspectos más como tipo todos aquellos análisis o todos aquellos recursos que nos pueden ayudar más que nada como a tener una mejor arquitectura posible nos estaríamos apoyando yéndonos de la mano con AWS Compute Optimizer básicamente que se encarga justamente de apoyarnos con un resize, a qué me refiero con esto, básicamente es el análisis de todos los recursos que tenemos y a su vez nos brinda con recomendaciones de ajustes de tamaño, obviamente necesitamos que la infras tenga básicamente los recursos exactos para que tenga un funcionamiento óptimo obviamente estos recursos deben coincidir lo mejor posible con estas cargas de trabajo evitando de esta manera pues lo que son pagar por recursos no utilizados. ¿Si nos vamos a aspectos por la parte de lo que es optimizaciones de almacenamiento pues son aspectos también muy importantes pero en este apartado en específico me gustaría ampliar un poquito más y entrar un poco más a detalle sobre esta parte ya que pues bien se sabe existen pues una gran variedad de servicios que nos apoyan justamente con esto almacenar toda esta nuestra información pero en este caso me gustaría hablar de dos en específico como lo son los buckets de s y los mismos EBS que son servicios de almacenamiento de s, pero bueno qué es lo que nos apoya a nosotros como para optimizar el almacenamiento y la gestión de nuestras capacidades? Hablando específicamente de los bucket de s tenemos varias alternativas que nos pueden ayudar con este objetivo, podemos empezar hablando como implementar políticas de ciclo de vida que también son por ejemplo las lifecycle policies, esto para lo que son los objetos que se encuentran almacenados en s, esto con el objetivo básicamente de mover de manera automática los datos que tenemos en nuestros buckets de s, quizás en un apartado estándar pero que esta información o estos datos se puedan mover de manera automática o un almacenamiento más económico justamente del s, Se sabe que tenemos como varias etapas del mismo servicio y quizá podamos moverlas a más económicas puede hacerse mención no sé como puede ser el mismo s, infrequent access o hasta el mismo glacier ¿Verdad? Pero todas estas reglas deben ser definidas por nosotros. Y esto con el objetivo de que nosotros realmente conocemos con certeza pues qué datos usamos con mucha frecuencia y cuáles son los datos que los generamos, más que nada como un tipo histórico, ¿Verdad? Pero bueno, si nosotros queremos algo más automatizado, por así decirlo, y no tenemos como a ciencia cierta qué tan frecuente e infrecuentemente usamos los datos, pues sería mejor optimizar.