Mejores prácticas para tener una infraestructura segura, de alto rendimiento y con ahorro de costos

Nuestro webinar se llama Mejores prácticas para tener una infraestructura segura, de alto rendimiento y con ahorro de costos. Esto basado en los cinco pilares del vuelo Architected, el cual es el tema fundamental que vamos a revisar el día de hoy. A continuación siguiente les voy a compartir al equipo que va a estar presentando nuestro webinar. Una bienvenida a nuestro compañero Francisco Javier Huerta, quien es especialista en soluciones de arquitectura de parte de AWS y de igual forma estará Osvaldo Luna, quien de igual manera es arquitecto de soluciones pero de la parte de CompuCloud en nuestro equipo. Y bueno, como ya les comenté, mi nombre es Jorge Monteón, yo soy consultor comercial de CompuCloud y estaremos a sus órdenes durante el webinar para cualquier necesidad que tengan ustedes. A continuación veremos la agenda, los puntos que vamos a revisar durante nuestro webinar. Les recuerdo por favor que se mantengan durante todo el webinar para que no se pierdan la promoción que tendremos al final. En primer lugar vamos a revisar de una forma muy rápida lo que es CompuCloud. Vamos a ver también por medio, bueno Javier nos va a apoyar y nos va a dar una introducción de lo que es AWS y algunas historias de éxito. Vamos a ver también en el punto 3 lo que es el Well Architected Framework, lo que son la definición general que es los cinco pilares. Vamos a revisarlos cada uno de ellos para que los conozcan a detalle. Vamos a revisar las aplicaciones que tiene lo que es la herramienta de Well Architected, los recursos de Well Architected y la metodología que utilizamos en CompuCloud para realizar esta herramienta. A continuación vamos a revisar en la siguiente diapositiva lo que es CompuCloud. Nosotros CompuCloud somos la empresa líder en servicios administrados en la nube, en específico de AWS. Nosotros tenemos presencia en México y en Centroamérica. CompuCloud cuenta con las certificaciones necesarias para para ser un partner Advance, lo cual nos permite estar apoyando a las organizaciones en temas de las arquitecturas de cloud, en temas de planeación, migración y la implementación. Y no solamente les entregamos la implementación, sino que nosotros acompañamos al cliente después de esta administrando, respaldando y apoyándolos con el monitoreo continuo de su infraestructura en la nube. Les comento de igual manera que el año pasado recibimos el reconocimiento por parte de AWS como el mejor partner. Este es un dato muy importante para que por ahí lo tengan en mente. Una de las certificaciones más importantes que tenemos es el ISO 20000 y de igual manera nosotros somos uno de los únicos partners que tenemos la autorización para realizar el AWS Well architected, el cual es el tema que nos tiene aquí y del cual a continuación nuestro compañero de AWS, Javier Huerta, nos va a platicar y nos va a dar una introducción también de lo que es AWS y un poquito por ahí de casos de éxito. Adelante Javier.

Muchísimas gracias, Jorge. ¿Me escuchan bien todos?

Excelente Javier.

Mil, mil gracias, Jorge. Pues comenzamos. Buenos días a todos. Mi nombre, gracias Jorge por presentarme. Mi nombre es Javier Huerta. Yo soy Senior Partner Solutions Architect de Amazon Web Services. Yo trabajo con CompuCloud, en este caso, viendo las mejores prácticas, estudiando los nuevos servicios, viendo soluciones y apoyándolos en todo momento. Soy una extensión de CompuCloud dentro de Amazon Web Services y como tal, a veces un poco de equipo extendido. Muchas gracias por su invitación, Es un gusto estar con ustedes. Gracias por su tiempo. El día de hoy, como bien comentó Jorge, vamos a platicarles acerca del Well architected Framework. Vamos a ver qué qué significan las mejores metodologías para la carga de información, para la carga de aplicaciones dentro de la nube, cómo se aplica y algunos ejemplos prácticos. Nuestra intención es aterrizarlo lo más posible y que ustedes se den cuenta de la propuesta de valor que tiene una metodología de esta naturaleza para sus cargas de trabajo. Pues sin más, comenzamos. Siguiente, por favor. Me gustaría comenzar platicándoles un poco acerca de algunas historias de éxito de Amazon Web Services y aquí hacer una ¿Qué tienen en común todas estas compañías? La primera respuesta obviamente podría pensarse, pues todas están corriendo de manera general en Amazon Web Services, tienen sus cargas. Pero vamos a entrar un poquito más a detalle. Vamos a estudiar, por ejemplo, qué tiene en común un Expedia Group que acaba de migrar sus servidores Amazon Web Services, un Pinterest o Netflix, que son empresas de media que nacieron dentro de la nube y siguen dentro de de Amazon Web Services o la NFL y la Fórmula 1, que están haciendo trabajo de Machine Learning y de Inteligencia Artificial para mejorar el desempeño de los equipos, para mejorar el desempeño de los coches. Un Coca Cola Company que tiene toda la parte de retail, su backend corren Amazon Web Services, McDonald's, que la parte de retail corre en Amazon Web Services, Epic Games, que si ustedes conocen Fortnite, sabrán qué si no sus hijos seguramente lo conocen. Cientos de millones de jugadores simultáneamente conectados a la red de Amazon Web Services o nuestro cliente de casa, Amazon. Com, el segmento de retail. ¿Qué tienen en común además de ejecutarse dentro de Amazon Web Services? Es bien interesante. Lo que tienen en común es que en algún momento ellos tuvieron que salir a la nube, tuvieron que comenzar a operar en la nube. Y la pregunta que todos tuvieron fue ¿Cómo puedo operar de la mejor manera posible? ¿Cómo me aseguro que estas cargas de trabajo tan disimilares, tan fuertes, por ejemplo, en el caso de Epic Games, tan globales como en el caso de Netflix, ¿Cómo se aseguraron que funcionaran bien? Esta es la pregunta que vamos a contestarles el día de hoy. Siguiente, por favor. Cuando ustedes están construyendo una aplicación, tienen el ciclo de desarrollo de software, en este caso un ciclo tipo Waterfall, que empieza con planeación, análisis, diseño, implementación, pruebas y mantenimiento, o si están muy acostumbrados al tema de Agile, bueno, estarán pensando en función de Sprint, en función de Retrospectivas, en función de Review Meetings, tal vez historias. Sin embargo, en el mundo de software ya hay una metodología y una forma de asegurarnos que las aplicaciones que estamos construyendo siempre van a tener el grado de desempeño que estamos esperando. Entonces, la pregunta ¿Cómo pudiéramos pensar en un tipo de ciclo de desarrollo de esta naturaleza, pero para la nube? Siguiente, por favor. La respuesta sería el AWS, Well Architected Framework. ¿Qué es el Well Architected Framework? ¿Qué es lo que contesta? Siguiente, por favor. Lo que contesta el Well Architected Framework es la pregunta ¿Está bien diseñado? ¿A qué nos referimos? ¿Mi arquitectura está bien diseñada? ¿Puede soportar las cargas de trabajo que estoy poniéndole? ¿Tiene la seguridad que requiere? ¿Está optimizada en desempeño? ¿Tiene una confiabilidad? Todas esas preguntas, de alguna forma la respuesta positiva nos va a decir si un sistema está bien diseñado o no. Entonces, lo que vamos a estudiar el día de hoy es de qué manera nosotros podemos hacer estas preguntas, contestarlas de la mejor manera posible y llegar a poder contestar esta pregunta. ¿Mi sistema está bien diseñado? Sí, sí lo está. ¿Cómo podemos ver entonces si tenemos una arquitectura adecuada de manera general? Ya lo estuvimos comentando un poco, primero tendríamos que ver cuáles son las características de una buena arquitectura. Nosotros, como vemos, hay cinco características principales que son Excelencia operacional, ¿Qué se refiere esto? ¿Estoy monitoreando lo que debo de monitorear? ¿Las cosas las tengo bajo control? ¿Mis procesos están bien establecidos? Seguridad, ya determiné cuál es la información más valuable para mí, la que más tengo que proteger y la infraestructura que la ejecuta. ¿Fiabilidad, en caso de que exista algún problema, puedo recuperarme? ¿Mis sistemas están diseñados para autocurarse y para levantarse de manera automatizada? Eficiencia de desempeño, ¿Estoy utilizando los recursos correctos? ¿No estoy, no tengo un exceso de equipamiento? ¿Tengo el equipamiento que requiero para la carga que requiero? Y por último, optimización de costos. ¿A qué nos referimos? ¿Todo esto que estoy haciendo, lo estoy haciendo desde un punto de vista que optimice lo que estoy gastando dentro de la nube? ¿Estoy gastando de más? ¿Estoy gastando DE MENOS? ¿Cómo puedo corregir esto? Ahora, una vez que tenemos cinco características, la forma en la que nosotros abordamos el diseño de una mejor arquitectura es a través de un proceso de revisión, el cual es consistente, siempre se aplica de la misma manera y se aplica a todo el portafolio tecnológico. ¿Para qué? Para que en todo momento tengamos el control de todas las cosas que tenemos cargadas dentro de la nube. Siguiente, por favor. La suma de todos estos componentes, ¿Qué es lo que nos da la metodología de AWS Well Architected? Es una metodología, es un conjunto de preguntas las cuales nos hacemos con respecto a la arquitectura que nosotros tenemos en la nube, con respecto a la carga de trabajo que estamos montando en la nube y las respuestas que nos van a dar un marco de referencia sobre el cual podemos desarrollar nuestras aplicaciones. ¿Cómo nace el Well Architected Framework? ¿Por qué? ¿Cómo podemos hablar de que los clientes que vimos en un principio pueden estar trabajando con una mejor práctica? Pudiéramos pensar, por ejemplo, que no tenemos un marco de referencia para que esos clientes tuvieran una mejor carga cómo lo hicieron en su momento. Vamos a platicarles un poco de historia. Nosotros comenzamos el Well Architected Framework hace ocho años, en 2012. ¿Qué es lo que hicimos? Empezamos a ver qué era lo que hacían bien nuestros clientes, empezamos a platicar con ellos, ellos nos empezaron a comentar también dudas que tenían, inquietudes, empezaron a experimentar, empezamos a experimentar de manera conjunta y empezamos a generar un conjunto de mejores prácticas, las cuales empezamos a revisar en 2013 en conjunto con nuestros clientes y al final decidimos que habían cuatro grandes áreas de experiencia, cuatro pilares como las que ya vimos. Dos años después nos damos cuenta de que la excelencia operacional también es un pilar que añadimos y con el paso del tiempo empezamos a involucrar a partners para empezar a hacer esta revisión. El Well architected Framework es el conjunto de experiencias que tenemos de todos nuestros clientes, en todas las verticales que se puedan imaginar, en todos los tamaños que se puedan imaginar. Todas estas experiencias las juntamos en un conjunto de preguntas y estas preguntas las exponemos como una metodología. Aquí me gustaría hacer un comentario si ustedes han escuchado el término Well architected Framework, por alguna razón, algunas otras compañías, algunos competidores están utilizando a partir de, me parece, este año el nombre de Well architected Framework. Nos sorprende un poco, los pilares son iguales, también nos sorprende un poco. Sin embargo, lo que nosotros les puedo decir es que nosotros empezamos hace ocho años y tenemos esa experiencia de trabajo. Iniciamos con esta práctica y ahora podemos darles esta metodología con toda la experiencia de los clientes que vimos anteriormente. Siguiente, por favor. Me gustaría platicarles un poco ahora de cuáles son los beneficios que tiene el Well Architected Framework. ¿Por qué tendríamos que estar aplicando el Well Architected Framework? De qué manera se beneficiarían sus cargas de trabajo y ustedes al utilizar la primera van a construir e implementar más rápido. ¿Por qué razón? Ustedes en el momento en que empiezan a hacerse las preguntas sobre los pilares que vimos de excelencia operativa, confiabilidad, seguridad, optimización de costos, desempeño, ustedes lo que van a empezar a descubrir son cosas de su arquitectura que probablemente no conocían o habían pasado por alto y de AWS van a empezar a conocer la forma en la cual nosotros trabajamos de la mejor manera. En conjunto con esta información van a poder construir e implementar más rápido sus cargas de trabajo dentro de su arquitectura. Con este conocimiento, de la misma forma van a reducir o mitigar riesgos, van a conocer de su arquitectura cuáles son los puntos, las áreas de oportunidad, de qué manera se pueden corregir con los ofrecimientos de Amazon Web Services y de esta forma lograr tener menos riesgos en el menor tiempo posible. De la misma forma como habíamos platicado, ustedes van a tener información y esta información les va a permitir hacer la toma de decisiones. Un ejemplo muy sencillo, si yo incremento la seguridad de mi plataforma, de qué manera va a impactar, por ejemplo, la optimización de costos o qué es lo que voy a tener que empezar a monitorear si subo el número de servidores. Anteriormente ustedes sin esta metodología podría darse el caso de que pudieran empezar a asumir cosas. El Well Architected Framework lo que les permite es no asumir, empezar a medir y tomar decisiones conforme a métricas y datos. Y por último, en el momento en que ustedes hacen una revisión de Well Architected Framework, van a empezar a recibir información sobre las mejores prácticas de Amazon Web services en los cinco pilares. ¿Qué es lo que les va a ayudar? Nos va a ayudar a conocer mejor la infraestructura de Amazon Web Services y utilizar los mejores servicios adecuados a lo que ustedes están buscando. Siguiente por favor. El Well Architected Framework básicamente nosotros lo vemos como un mecanismo para apoyarlos en su viaje a la nube. ¿A qué nos referimos? El primer paso siempre es aprender de toda la arquitectura que ustedes tienen, aprender de los ofrecimientos de Amazon Web Services. Después empezar a tomar métricas. Nosotros lo más importante del Web Architected Framework es que todo lo que queramos cambiar, todo lo que queramos mejorar, debe tener una métrica asociada. Si no existe una métrica que nos permite decir si mejoramos o no, muy difícilmente podremos tomar una decisión. Well Architected Framework se enfoca a tener esas métricas y que ustedes sepan cuáles son los beneficios tangibles dentro de su carga de trabajo, cuál es el resultado que nosotros esperamos en todo momento mejorar. ¿A qué nos referimos? Mejorar el pilar que ustedes deseen y ver los resultados de manera tangible. ¿Qué es el Well Architected Framework? Ya lo platicamos un poco, son los pilares. En un momento vamos a entrar un poco más de detalle para platicarles exactamente qué hace cada pilar. Estos pilares se basan en criterios de diseño. ¿A qué nos referimos? Cada uno de estos pilares tiene ciertas mejores prácticas asociadas y de manera general, todos los pilares tienen un conjunto de mejores prácticas que aplican de manera general. Los vamos a ver un poco más a detalle a continuación y cómo funciona de la manera más sencilla nosotros hacemos preguntas sobre su arquitectura. Estas preguntas que nosotros hacemos, las respuestas van a estar asociadas con un criterio de diseño, con un cambio, con una modificación, con una mejora que se recomienda aplicar en el momento en que ustedes aplican esta mejora. Posteriormente se toma una métrica y se analiza realmente cuál fue el beneficio que obtuvieron. Vamos a ver cómo estos cambios se hacen de manera puntual, se hacen de manera gradual, se hacen poco a poco para empezar a evaluar el impacto de cada uno de los cambios dentro de su arquitectura. Ahora vamos a platicarles un poco más a detalle qué son los pilares del Well architected Framework. Hemos hablado mucho de los pilares, los hemos visto de alguna manera, vamos a verlos a profundidad para que ustedes entiendan del impacto de cada uno de ellos y la forma en que se relacionan. Excelencia operacional, hemos platicado un poco, se refiere a que sus operaciones estén optimizadas de la mejor manera posible. ¿Cómo lo logramos? El tipo de preguntas serán ¿Como la ¿Estamos monitoreando lo correcto nuestros procesos y operaciones para operación en la nube? Una atrás, por favor. Una atrás, por favor. Esa, por favor. Gracias. Excelencia operacional tiene mucho que ver con el monitoreo de los servicios en la nube y que nuestros procesos estén correctamente. ¿Estamos operando nuestros servicios de la manera correcta? Seguridad tiene dos vertientes. La primera es empezar a analizar cuáles son nuestros datos, determinar cuáles son los datos que más debemos de cuidar, porque sea información confidencial, privilegiada, protegida por alguna ley, y ver si estamos aplicando los controles de acceso correctos y si está asegurada dentro de la nube de manera adecuada. ¿La segunda, nuestra infraestructura, la parte de procesamiento, tiene los controles de acceso y de seguridad correctos? ¿El pilar de fiabilidad, a qué se refiere? Toda la parte de resiliencia, de recuperación en caso de desastre, ¿Cómo se comporta nuestra arquitectura? ¿Si hay una falla, cómo se comporta, cómo se recupera y cómo nos notifica que se ha recuperado? ¿La eficiencia en el desempeño de qué nos habla es nuestras instancias, nuestros servicios, nuestros balanceadores de cargas, nuestros repositorios de información, están dimensionados correctamente para la carga de trabajo? ¿Y no necesariamente es si están dimensionados para operar correctamente, sino también si nos excedimos dentro del diseño, de qué manera podemos regresar? Un punto correcto es dimensionar correctamente, no sobredimensionar ni subdimensionar y la optimización de costos es dentro de todas las actividades que estamos haciendo nosotros estamos gastando lo correcto dentro de la nube o estamos gastando de más o estamos gastando de menos. Lo interesante de los pilares, que me gustaría que lo que lo consideran así es, los pilares soportan nuestra arquitectura, la arquitectura corre en un nivel superior a los pilares. Si ustedes modifican algún pilar, por ejemplo, vamos a hablar que incrementan la seguridad de manera necesaria tendrían que la metodología lo que les va a decir es de qué manera se incrementan el resto de pilares o cómo se afectan. Un ejemplo, si yo incremento los controles de seguridad, por ejemplo si pongo Security Groups o si pongo Network Access Control List que bloquean la entrada a ciertos recursos dentro de mi red, la excelencia operacional se ve afectada, ¿Por qué? Porque porque ahora voy a tener que monitorear ciertos parámetros distintos o voy a tener que monitorear de manera distinta mi plataforma. Si nosotros monitoreamos el parámetro de seguridad, el pilar de seguridad, las preguntas automáticamente nos van a revisar que estés monitoreando estos puertos, revisa que está haciendo estas actividades de manera correcta. Existe una relación entre todos los pilares, Si nosotros incrementamos un pilar o si nosotros modificamos un pilar, la metodología nos va a decir de qué manera se modifican el resto de los pilares. Esto es a lo que nos referíamos cuando hablábamos con tomar decisiones con información. La idea es que en todo momento nosotros sepamos cómo está nuestra arquitectura y de qué manera se afecta si hacemos alguna modificación dentro de estos pilares. Raciela, ¿Que sigue por favor? Vamos a entrar ahora a platicarles un poco acerca de los criterios de diseño para cada uno de los pilares y de los criterios de diseño que afectan de forma general todos los pilares. Ahora sí vamos a ver cuáles son un ejemplo de preguntas, cuáles son los ejemplos de los temas que estamos viendo y creo que en esta parte vamos a poder empezar a entender el impacto de una metodología de este tipo y por qué nos va a permitir hacer las mejores arquitecturas posibles. Los criterios de diseño, como ya platicamos, son de dos tipos. Existen criterios generales de diseño, los cuales afectan a todos los pilares y existen criterios específicos para cada uno de los pilares. Cuando hablemos de cada uno de estos, lo que tenemos que pensar siempre la respuesta a esta pregunta de un pilar en específico se apega a los principios generales de diseño y la respuesta a esta pregunta se apega al diseño, al pilar específico del que estamos hablando. Vamos a entenderlo un poco más cuando veamos las preguntas. La siguiente, por favor. Primero vamos a comenzar con los criterios generales de diseño. OK, vamos a empezar con el criterio de diseño para la excelencia operacional. Primero vamos a ver que todas las operaciones deben de realizarse como código. ¿A qué nos referimos aquí? Nosotros estamos muy acostumbrados a trabajar dentro de la consola de Amazon Web Services. Es un lugar muy amigable para trabajar, muy cómodo. Sin embargo, el gran problema de la consola es que si nosotros queremos repetir alguna actividad en particular con la consola es muy difícil. Existen muchos parámetros que modificarse, existe la posibilidad de no replicar de manera exacta a lo mejor la creación de un elemento, qué es lo que nosotros sugerimos. Tenemos herramientas como CloudFormation, la cual nos permite generar nuestra infraestructura como código y tratar la infraestructura como código, incluso manejarla dentro de un repositorio de versiones, tratarla como si fuera básicamente una aplicación. Nuestra recomendación es siempre tratar la arquitectura, la infraestructura como código y realizar todas las operaciones. ¿Por qué? Porque nos vamos a evitar muchos problemas, nos vamos a evitar errores, equivocaciones. Si nosotros utilizamos la infraestructura como código, podemos desplegarla siempre de la misma forma y podemos asegurarnos de los mismos resultados de manera consistente. Ahora, una vez que tenemos la infraestructura como código, podemos anotarla como si fuera software. Aquí el comentario es todo lo que hagamos que quede bien anotado dentro del código. Si estamos generando servidores, clústeres, anotar por qué se están generando las características, si tienen alguna característica en particular, anotarla. Esto es para saber por qué se hicieron las cosas y en caso de que exista un problema, poder tener una referencia más consistente. ¿Siguiente, que ya hemos hacer? Cambios frecuentes, pequeños, irreversibles. ¿De qué estamos hablando aquí? Cuando nosotros hacemos un cambio o una mejora, siempre tenemos que medirla. Si nosotros hacemos cambios grandes o hacemos múltiples cambios a la vez, lo más probable es que aunque tengamos una mejora, nunca vamos a saber exactamente cuál fue el cambio que le ocasionó y en qué magnitud. La recomendación si nosotros ya tenemos la infraestructura como código, vamos a hacer los cambios constantes, vamos a hacer los cambios pequeños, vamos a medir esos cambios de manera continua y vamos a aprender cuáles son los cambios que mayor impacto tienen. Anticipar fallas y aprender de todas las fallas operacionales. Esto es un concepto muy interesante. Dentro de Amazon Web Services nosotros manejamos un concepto que se llama Game Days. ¿Qué son los Game Days? Son eventos en los cuales nosotros juntamos al equipo de desarrollo de soporte de infraestructura de un cliente o de un partner y levantamos una infraestructura exactamente igual a producción. ¿Cómo lo hacemos? Como tenemos ya la infraestructura como código, podemos levantar la infraestructura nuevamente en un ambiente de prueba y una vez que está corriendo, hay una persona tras bambalinas, por decirlo de esta forma, que tiene el control de de la operación y de repente empieza a introducir variables. Por ejemplo, sobrecarga la base de datos, cierra un security group, a lo mejor desconecta alguna interfaz, mueve algún endpoint. ¿Qué es lo que nosotros pretendemos con esto? Que los equipos detecten la falla y la corrijan. Y se les dan puntos en función al número de correcciones que hayan logrado. En este momento nosotros aprendemos de la infraestructura y cuando un evento sucede en la vida real, con la experiencia del Game Day, podemos saber de manera mucho más rápida cuál puede ser el problema potencial. Los Game Days son una herramienta que tenemos para que toda la organización conozca cómo funciona la infraestructura y de qué manera se pueden suscitar fallos y cómo corregirlos de la manera más rápida posible. Vamos a pasar ahora a el pilar de la seguridad. ¿Cuáles son los principios de diseño de seguridad? La primera y más importante es implementar una sólida base de identidad. ¿A qué nos referimos? A identificar todos los recursos y todas las personas que entren a nuestra plataforma y darles los menores privilegios de acceso posible. La idea de la seguridad en primera instancia, el menor número de personas que puedan entrar con el menor número de privilegios, es una de las mejores prácticas que podemos tomar para una buena arquitectura siguiente es habilitar la trazabilidad. Tenemos herramientas como CloudTrail, la cual nos va a permitir ver en todo momento qué cambios se hacen en la infraestructura y quién lo hizo. Aplicar seguridad en todas las capas. ¿A qué nos referimos? La seguridad debe venir desde el firewall perimetral hasta los Network Access Control List, Security Groups, las mismas instancias, los sistemas operativos de la instancia y las aplicaciones que corren en la instancia. Es cierto que se pueden tener uno o dos elementos de seguridad. Sin embargo, la mejor práctica que dice protege todas las capas en todo momento y aplica toda la seguridad, aunque sea redundante. Proteger los datos en tránsito y reposo es analizar qué datos están saliendo, qué datos están entrando a nuestra red, encriptar todo lo que entre, encriptar todo lo que sale y de la misma manera encriptar todo lo que se encuentra en reposo con las herramientas y servicios de Amazon Web Services. Siguiente es mantener a las personas alejadas de los datos. ¿A qué nos referimos? Los sistemas son los que acceden a los datos, las personas no necesariamente tienen que tener acceso y eso es solamente bajo ciertas condiciones muy particulares. Mejor práctica, no dejes que las personas se acerquen a los datos, solamente permite que los sistemas se conecten a través de los endpoints, a través de las rutas y a través de los permisos correctos. Y la última, la seguridad ante eventos de desastre. ¿Esto cómo lo podemos hacer? De la misma forma con un Game Day. En un Game Day podemos introducir también variables de seguridad en los cuales simulemos una intrusión, simulemos un ataque, simulemos tal vez el cambio de Security Group, un intruso dentro de la plataforma. Esto es a lo que nos referimos con prepárate ante un evento en particular. Siguiente, por favor. Vamos a. Siguiente. Ah, ya, ahí está. El siguiente punto es Principios de diseño para la fiabilidad. ¿Qué tan confiables son nuestros sistemas? ¿Qué tanto sabemos que se pueden recuperar ante el caso de una eventualidad? ¿Cómo se van a recuperar ante el caso de una eventualidad? ¿A qué nos referimos en este punto? Primero vamos a probar nuestros procedimientos de recuperación. Todos sabemos de entrada que los respaldos se tienen que hacer, cada uno de nosotros define la frecuencia con lo que se hace. ¿Sin embargo, la siguiente pregunta en el caso de un desastre, me puedo recuperar? ¿Cuál es mi RTO? ¿Cuál es MI RPO? Probar los procedimientos de recuperación nos da la tranquilidad de que estamos respaldando los elementos correctos que necesitamos para recuperarnos y de que podemos recuperarnos en el tiempo que nosotros habíamos pactado en primera instancia y que el tiempo de pérdida de datos es aceptable para la organización, expresado obviamente en RTO y RPO. Siguiente es Recuperarse automáticamente de la falla. ¿Qué nos referimos con esto? Existen maneras, obviamente, de tal vez que existe un problema dentro de nuestro servicio y de que se notifique una persona que esa persona entre tal vez a la consola, seguramente encuentre la falla entre la aplicación, haga una modificación y se levante y que pasen dos o tres horas en lo que esto sucede. El principio de diseño de fiabilidades, no lo hagas así, recupérate automáticamente, utiliza auto scaling groups, utiliza elastic load balancers, utiliza arquitecturas desacopladas, recupérate automáticamente, que ese debe ser tu primer objetivo, y una vez que lo hagas, notifica a la gente para que pueda entrar y ver la causa raíz del problema. En el mismo tenor existe el concepto de escalar horizontalmente, porque si nosotros escalamos verticalmente, obviamente podemos aumentar la capacidad de nuestros equipos, dar un mejor servicio, operar de la manera correcta, sin embargo, esto no nos aumenta la fiabilidad. Aquí lo que decimos, aprovecha los beneficios de un balanceador de carga elástico, aprovecha el beneficio de un auto scaling group, escala horizontalmente. Si existe alguna degradación en alguno de tus servicios que escalaste horizontalmente, el resto de los equipos pueden seguir funcionando con normalidad y a través de herramientas automatizadas puedes recuperar la operación al 100%. Deja de adivinar la capacidad. Nosotros tenemos muchas herramientas para permitirte ayudarte, para permitirte que tú puedas saber exactamente en todo momento cuál es la capacidad que requieres dentro de tu infraestructura. No operar de manera sobrada, no operar con faltantes. En el momento en que dejas de adivinar la capacidad, operas de la mejor manera posible, de la manera más óptima posible y estableces los parámetros para saber cuál es tu base para operar de manera confiable y dar el servicio a todos tus usuarios que lo requieran. Y por último, muy relacionado con infraestructura como código, gestiona los cambios automáticos. ¿A qué nos referimos? Nuevamente, no entres a la consola, permite que las herramientas automatizadas de Amazon Web Services generen los cambios en ventanas de tiempo que tú definas y en caso de que exista algún problema con esos cambios, te permitan hacer un rollback ordenado por medio de código, el cual regrese tu infraestructura al punto original de la manera más fácil y confiable. Siguiente por favor. Vamos a hablar ahora de la eficiencia en el desempeño. La eficiencia en el desempeño, como ya platicamos, es tener la infraestructura correcta en el momento correcto, no sobredimensionar equipos, ni tener equipos demasiado pequeños. Primer principio, democratiza las tecnologías avanzadas. ¿A qué nos referimos? Da a conocer a tu organización. ¿Cuáles son los servicios y herramientas que Amazon Web Services te puede dar para mejorar tu desempeño, para mejorar tu capacidad y para mejorar todo lo que le puedes ofrecer a tu cliente? ¿Qué nos referimos? Por ejemplo, si tú estás actualmente utilizando un ejemplo, transcodificadores de video que están corriendo dentro de instancias, EC democratiza la tecnología avanzada. Conoce la parte de transcodificadores con el servicio de Elemental que nosotros tenemos y comienza a trabajar con elemental. ¿Por qué? Es un servicio más eficiente, es un servicio que tú no tienes que administrar, es un servicio que va a bajar costos. Operar con equipos, por ejemplo, con instancias y tú está bien. Sin embargo, hay que ver cada uno de los casos para ver si existe un servicio que te pueda ayudar a disminuir ese trabajo no diferenciado que estás haciendo actualmente. Haciendo respaldos, operando servidores. Vuélvete global en minutos. ¿Que nos referimos? Si de repente uno de tus contenidos se volvió viral o una aplicación se volvió muy famosa, despliegala a través de múltiples zonas de disponibilidad o múltiples regiones. Ayuda a que tus clientes finales tengan un menor tiempo de latencia y una mejor experiencia. Utiliza arquitectura serverless como Lambda, como API Gateway, como DynamoDB. Estas arquitecturas pueden escalar de manera muy rápida, te pueden dar un servicio de manera adecuada. Puedes utilizarlo para aquellos servicios en los cuales no conozcas la carga o que sepas que se utilizan de repente, que no tengan una operación continua. Experimenta más seguido. Regreso al tema de infraestructura como código. Si tienes la infraestructura como código, puedes desplegarla dentro de nuevos ambientes de prueba y puedes. Puedes evaluar nuevas capacidades. Por ejemplo, puedes traer tu sitio web completo, aplicar un nuevo diseño, aplicar nueva funcionalidad, hacer pruebas A B junto con un DNS como Route, evaluar si tus resultados son positivos, si son positivos, migrar a la nueva plataforma, si ves áreas de oportunidad, dar de baja tu plataforma de pruebas y seguir operando como lo venía haciendo continuamente. La idea es experimenta más seguido, ve qué es lo que mejor funciona para ti y haz cambios pequeños. Haz cambios pequeños, innova, mejora y mide. Y por último, aplica la simpatía mecánica. Hemos hablado mucho, por ejemplo, de tecnologías avanzadas. Utiliza arquitectura serverless como Lambda. Sin embargo, hay algún tipo de cargas que son constantes y consistentes en el tiempo que pueden estar operando, por ejemplo, en un ambiente 24 por 7 o que tú conoces que la carga es continua y constante y que sabes que no va a pasar de esos niveles, en ese caso utiliza una instancia EC, probablemente te dé un mejor desempeño y a un mejor costo que una arquitectura serverless. Si tú tienes cargas que se incrementan continuamente en el tiempo o que no conoces la carga, o que de repente tienes cargas muy fuertes y de repente estas cargas decrecen, muy probablemente una arquitectura serverless es para ti. La idea utiliza la simpatía mecánica, ve cuáles son tus tipos de cargas y adopta la arquitectura que más se acerca a tus necesidades. La parte de optimización de costos, esto es, adopta un modelo consumo, si tu organización lo permite, divide los costos dentro de cada una de las unidades organizacionales que tiene para que todos estén conscientes de la cantidad de recursos que están gastando de servicios en la nube y que cada una de las áreas busque la mejor manera de optimizar su su consumo. Mide la eficiencia general, utiliza las herramientas que tenemos en Amazon Web Services para ver cuáles son los servicios que más costo tienen y que puedas empezar a enfocarte a esos servicios optimizándolos, viendo si realmente los estás utilizando por completo o sustituyéndolos por otros servicios que probablemente tengan un menor costo. Deja de gastar dinero en operaciones centro de datos Bueno, esto es muy obvio, si actualmente tienes un centro de datos y estás operando también con Amazon Web Services, empieza a estudiar la forma en que estos gastos te están impactando, tener una persona realizando backups, una persona cableando, manteniendo servidores, energía, aire acondicionado, todos son gastos no diferenciados que a menos de que tu función sea operar un centro de datos, no es tu competencia central, entonces deja de gastar en operaciones centro de datos y empieza a ver cómo puedes migrarte a la nube para disminuir estos costos. Analiza y atribuye gastos, divide cada uno de los servicios, enfócate las áreas que están utilizándolos, plática con ellos y empieza a disminuir estos gastos. ¿Y por último lo que hemos visto, utiliza servicios administrados para reducir el costo de propiedad, A qué nos referimos? Nuevamente, servicios como DynamoDB, Elemental para la transcodificación de video, te pueden ahorrar costos ya que son administrados por Amazon Web services y son pago por uso. ¿Ahora podrías preguntarte cómo es este análisis? ¿Cómo son las preguntas? Ya vimos los pilares, ahora podría estarte preguntando cómo es cada una de estas preguntas, cómo funcionan los pilares, cómo se ven en este ejemplo. Vamos a ver un ejemplo de una pregunta del pilar de fiabilidad. ¿Tenemos gestión de fallos como el área del pilar, la pregunta cómo tu sistema soporta fallas de los componentes? El contexto, si tus cargas de trabajo tienen requerimiento para disponibilidad alta y bajo tiempo de recuperación, entonces arquitecta tus cargas para la resiliencia y distribuye tu tus cargas de trabajo para soportar problemas. Ese es el contexto y las mejores prácticas, lo que habíamos platicado de las recomendaciones muy particulares para este tipo de problemas. Monitorea todas las capas, despliega en múltiples zonas de disponibilidad o múltiples regiones, empieza a diseñar tus sistemas con dependencias con un bajo nivel de acoplamiento, implementa degradación paulatina, automatiza la curación de todas tus capas y envía las notificaciones en el momento en que existe un evento que te impacte tu operación. Como pueden ver, además de que son recomendaciones muy particulares, por ejemplo, en el caso de despliegue en múltiples zonas de disponibilidad, dicen distribuye tu carga de trabajo a través de múltiples zonas de disponibilidad y múltiples regiones utilizando DNS, Elastic Load Balancer, Application Load Balancer, API Gateway, son recomendaciones muy particulares que incluso te dicen qué servicios puedes usar y de qué manera se pueden implementar. Estos son el tipo de preguntas que se hacen, el tipo de contexto que se da y el tipo de respuesta que ustedes pueden esperar de nosotros. La que sigue por favor, Esto es bueno. La que sigue ahorita, por favor. Gracias. Estos son los pilares, las preguntas, los conceptos, ahora vamos a ver de qué manera se aplica esta, aplicamos este marco de mejores prácticas. Esto es algo, es un tema muy importante que quisiera platicarles. El Well Architected Framework, pese a que son preguntas que se tienen respuestas y que existen recomendaciones, no es una auditoría, es un trabajo en conjunto para mejorar el Well Architected Framework. No existe un culpable, un inocente, un se hizo bien o un se hizo mal. El Well Architected Framework es una revisión la cual está hecha para aprender, la cual está hecha, está hecha para mejorar, para obtener métricas y para tener la mejor arquitectura posible. Entonces no hay culpables, no hay inocentes, hay simplemente mejores prácticas y recomendaciones. Como vimos en el ejemplo pasado, no son comentarios que dicen mejora tu arquitectura o acelera tu performance. Son comentarios que dicen utiliza DNS, ELB, utiliza múltiples zonas disponibles. Son consejos muy pragmáticos y probados en todos los clientes que hemos visto anteriormente. Y no es una única revisión. Esto es importante. ¿Por qué lo vemos así? Porque Amazon Web Services está introduciendo muchos servicios de manera continua y seguramente su plataforma sufre muchas modificaciones por requerimientos de los usuarios. La idea del Well architected Framework es que su arquitectura dentro de Amazon Web Services funcione tan bien como lo hace desde el primer día. Entonces, una revisión continua en la cual ustedes siempre se van a ver beneficiados de saber cuáles son nuestros ofrecimientos, de qué manera podemos implementarlos dentro de su solución y cómo se van a ver beneficiados con la introducción de todos estos nuevos servicios dentro de su arquitectura. Siguiente, por favor. ¿Cómo se realiza el proceso de revisión de un Well Architected Review? Bueno, ustedes, su equipo, con líderes técnicos y comerciales, trabajan en conjunto con el partner, en este caso CompuCloud, utilizando una herramienta que se llama el Well Architected Tool. Esta herramienta tiene todas las preguntas, todas las respuestas que hemos visto. Es un trabajo en conjunto en el cual, como ya hemos visto, se hacen las preguntas, se contestan de la forma que ustedes mejor vean, que se adapta a sus necesidades y la herramienta al final, en conjunto con el partner les va a dar las recomendaciones de cómo mejorar su arquitectura para que se adapte a las mejores prácticas de los clientes que hemos tenido, de las verticales que hemos tenido y de las mejores soluciones que hemos tenido a lo largo de estos ocho años. Siguiente, por favor. ¿Cuáles son los casos de uso en los cuales podemos utilizar el Well architected Framework? El primero es para aprender las mejores prácticas de la nube. El Well architected Tool es la mejor herramienta que pueden usar para aprender de cómo hacer la mejor arquitectura dentro de Amazon Web Services. Contestan las preguntas y dentro de las respuestas van a encontrar cuál es la forma en la cual las cargas más exitosas que tenemos trabajando han sido diseñadas para trabajar dentro de nuestra infraestructura. La parte de gobernanza tecnológica, que ustedes tengan un control de todas sus aplicaciones, de todas sus arquitecturas, que sigan las mejores prácticas y que tengan el conocimiento de que estas mejores prácticas que están siguiendo están de acuerdo a sus normas, regulaciones que tienen establecidas dentro de su gobernanza. Y por último, la gestión de la cartera de proyectos. Ustedes en el momento en que estudian el Well architected Tool lo hacen a través de todas sus herramientas y de esta forma pueden conocer conceptos como elementos reutilizables, servicios que ya aplicaron, servicios con los que ya trabajaron y de esta manera conocer de mejor manera cómo se armaron sus plataformas y qué se puede reutilizar o que proyectos pueden tener funcionando. En esta lámina, la siguiente por favor. Tenemos varios recursos que pueden ustedes leer para aprender más del Well architected Framework. Nuestro sitio es WA AWS, Amazon. Com, van a ver lo que hemos platicado a más detalle, ejemplos de nuestra arquitectura global, nuestra infraestructura global, ejemplos particulares de compañías que han hecho el well architected review y los resultados que han tenido. Siguiente por favor. En esa página van a ver también la liga para los Well architected Labs, en el cual van a ver ejemplos de nuestras mejores prácticas aplicadas ya a ejemplos muy en particular. Siguiente lámina por favor. Y bueno, con esto me despido, muchas gracias por su tiempo, espero que hayan aprendido algo más del Well architected Framework. Puede estar aquí para preguntas. Y ahora los dejo con Osvaldo que va a seguir con cómo Compuclo aplica la metodología de manera particular. Muchas gracias.

Excelente Javier, muchas gracias y buenas tardes nuevamente a todos por asistir a este webinar. Y precisamente me corresponde a mí hablar un poco sobre la metodología que Compuclo sigue para esta parte. Como bien mi compañero Javier ya mencionó de qué se trata detall toda la cuestión del well architected, la finalidad es también poder cerrar esta presentación en cómo nosotros podemos llevarlo, como nosotros ayudamos a nuestros clientes a aplicar el well architected con una metodología que utilizamos propiamente aquí en Compu Cloud, que en este caso lo dividimos en siete fases, que va desde la primera donde se hace la explicación hasta tema ya de cierre, ya cuando se hacen remediaciones. Por ejemplo, nosotros siempre comenzamos con la fase 1, donde podamos generar en conjunto con el cliente la explicación de cuál es el workload que vamos a analizar, definir un tema de una fecha, este horario donde podamos cuadrar agenda y hacer la programación y sobre todo para generar los lineamientos de personal técnico necesario, el well architected, una buena práctica es enfocarnos en los workloads. ¿A qué se refiere? Que por ejemplo, si ustedes en Amazon utilizan, por poner un ejemplo, tienen un e commerce, tienen un sitio web y aparte tienen su ERP en la nube. La intención de un well architected es enfocarnos en el assessment, en un workload específico, porque cada uno puede tener diferentes procedimientos, diferentes personas involucradas. Entonces se define, por ejemplo, es decir, vamos a enfocarnos en el workload de e commerce y para ello definimos los lineamientos del personal técnico necesario, tanto del lado del cliente como de compucad. ¿Por qué? Porque precisamente como todo el assessment que realizamos tiene que ver también con operaciones como generan, es importante tener al equipo involucrado que esté en ese proyecto, desde la parte de desarrollo, la parte de infraestructura. Entonces, así es como comenzamos la fase 1 y posteriormente iniciamos con el tema del Well Architected. Esto hacemos, como bien lo mencionó Javier, hacemos uso del Well architected Tool, donde nos permite tener preguntas basadas bajo esta herramienta. Y reiteramos, es muy importante lo que mencionaba Javier, no es un tema de quién hizo mal que toda esta parte, no, para nada, siempre tiene la intención de recabar información de cómo están trabajando hoy en día y para poder tener un resultado de cómo pudieran operar mejor en cualquiera de los cinco pilares. Además de ello, ¿Como lo llevamos nosotros con una plática más allá de tener, nosotros registramos aquella información adicional, es decir, no sólo nos apegamos a contestar la pregunta, sino que recabamos información adicional que pudiera llevar tal cual todo este tipo de situaciones para poder hacer un análisis y un entendimiento mayor y hacer recomendaciones más asertivas de mejoras como tal? Una vez que generamos todo este assessment, que pudimos platicar un poquito con nuestros clientes sobre la operación de ese workload, generamos un reporte basado en well architecture, donde prácticamente lo divide en riesgos altos y riesgos medianos, donde se muestra un esquema, una tabla, donde en base a los pilares donde se encuentran mayores riesgos en base a la información recabada. Con esto en mente, con pucloud, nosotros generamos un reporte específico, es decir, ya con accionarias concretas, porque la parte de well architected nos genera el tool, nos genera un reporte bastante amplio, nosotros lo agarramos, lo transformamos y lo presentamos hacia el cliente. Bueno, enviamos el reporte ya con acciones muy concretas, oye, saliste, podemos mejorar en el tema de la protección de datos, muy bien, hay que encriptar y hay que utilizar este servicio como tal. Y en base a ello, después de que enviamos dicho reporte, generamos una sesión con nuestros clientes para la explicación de lo que nos arrojó reporte y así definir primero contestar las preguntas que puedan surgir, presentar todo este tema y definir los siguientes pasos que pudieran llegar a ser una remediación. Es importante que el well architected nos dará assessment, nos dará una información y en base a esa información podemos detonar mejores mejoras accionables que puedan impactar de manera positiva a su infraestructura, ya sea de una manera inmediata o a un corto plazo. Al final de cuentas tiene la finalidad de tener una información inicial, es decir, si el cliente decide de momento decir sabes que me parece súper interesante pero tengo que hacer una ingeniería o estamos haciendo algo, no hay ningún problema, al final de cuentas el assessment ya tenemos una información inicial, pero también lo interesante ellos poder hacer una mejor. Estas mejoras nos llevan a la metodología 4 que es donde dice sabes que ya de todas las recomendaciones que me hiciste pues podemos aceptar total o parcialmente estas remediaciones en el cual generamos un plan de trabajo específico a una a una escala del tiempo que hayamos definido, sabes que nos vamos a en un mes vamos a hacer estas mejoras o en una escala de dos meses y en base eso vamos programando con el equipo técnico de compuclo hacer estas mejoras aceptadas, ¿Sale? Al tener esta parte de toda esta cuestión podemos hacer y es donde también se vuelve interesante también nada más para aclarar la parte, nosotros podemos llegar a inclusive a bajar hasta 5.000 créditos para poder generar estas remediaciones, es decir, donde podemos llegar identificar cada workload y si vas a necesitar un servicio para mejorar esto que les va a salir por un ejemplo 100 dólares y luego otro de 200 y que al final de cuentas haga una suma mensual, nosotros podemos tramitar los créditos para hacer estas remediaciones y que no les generen ningún costo estas remediaciones por un tiempo determinado y así les da oportunidad de generar, operar a través de estas mejoras y posteriormente poder continuar ya de manera recurrente con este servicio. Entonces para hacer este trámite no todos los partners de AWS pueden generar, solamente partners certificados de Google arquitecta que compuclo es un partner certificado para generar esta gestión. Entonces es lo importante y esto nos va a llevar para poder generar estos, obtener estos créditos necesitaríamos por lo menos hacer una remediación del 25% de los riesgos altos que nos sale de tal manera que vamos a enfocar, demandar inicial esta parte y una vez que tengamos la remediación pasamos a la fase 6 que es lo que viene siendo una encuesta de satisfacción y aplicando los créditos cuando hacemos los cambios directamente Amazon les estará enviando una encuesta de satisfacción para poder de cómo fue, cómo se sintieron y cómo fue todo el proceso y en base a ello ya se aplican los créditos y posteriormente pasamos a una fase 7 de cierre del Wall Architect donde entregamos como una sesión de cierre de proyecto, veámoslo de esta manera porque al final de cuentas es como un proyecto de mejora y lo podemos estar haciendo, entregamos un reporte, entregamos un plan de trabajo donde cómo ya firmado y cómo se completaron todas las fases y para posteriormente si es de su interés después poder generar, enfocar esta parte a otro workload. Es importante aclarar dos temas los créditos son por world load, es decir, si en un momento llegamos a hacer su web architected de su e commerce como tal y obtenemos las mejores los créditos, ya no podríamos volver a obtener los créditos para volver a hacer un assessment de Well architected para su mismo e commerce. Well Architected los podemos estar haciendo tan tan recurrente como sea necesario cada tres meses, cada seis meses, cada año, dependiendo de las necesidades de cada cliente, eso sin problema podemos identificar mejoras tantas veces sea necesario, pero la aplicación o este apoyo de créditos solamente es una vez en la vida del workload.