La nube de AWS un perfecto aliado para desarrolladores

Muchas gracias por acompañarnos el día de hoy en el webinar La Nube de AWS, un perfecto aliado para desarrolladores. Esta presentación será grabada y será compartida con ustedes a través de nuestro canal de YouTube. Les pedimos de favor poner en mute sus micrófonos y cualquier duda o sugerencia favor de hacérnoslo saber a través del chat. Al final de la presentación tendremos una sesión de preguntas y respuestas, favor de realizarla de igual manera a través de nuestro chat. Les comparto los nombres de mis compañeros que me apoyarán a impartir este webinar, es el ingeniero Pedro Serrano, el ingeniero Jared Hernández y su servidor David Martínez. Bien, comencemos con la agenda del día de hoy. El día de hoy tocaremos 5 puntos importantes para los desarrolladores, en el cual comprende la importancia de la innovación en el ámbito del desarrollo. Segundo punto los microservicios, que de ahí nos pasamos al tema de contenedores. En el cuarto punto estaremos hablando de serverless y de DevOps. En el tema de contenedores y en el tema de DevOps vamos a hacer una pequeña demo que nos apoyarán mi compañero Jared y mi compañero Pedro respectivamente. Les comento, CompuCloud es un partner especializado únicamente en Amazon Web Services, inició sus operaciones en el año de 2012 y a lo largo de estos ocho años ha conseguido una amplia experiencia en la implementación de los servicios de AWS y formar departamentos con ingenieros certificados y calificados. Con las certificaciones que contamos actualmente son las que pueden ver aquí en pantalla, como es Sysop Administrator Cloud Practitioner, Solution Architect Developer. El año pasado AWS nos otorgó el reconocimiento Advanced Consulting Partner Mejor, como su nombre lo indica, somos el partner que mejor ha asesorado a sus clientes a lo largo del 2019 basándonos en las mejores prácticas de AWS y como consecuencia somos uno de los pocos partners avalados por AWS para hacer este estudio que se llama Well Architected y está basado en los cinco pilares que es excelencia operacional, seguridad, fiabilidad, eficiencia de desempeño y optimización de costos. Con este estudio ustedes como clientes hasta 5 dólares aplicar a su consola ahondando más en comp en busca de la excelencia y seguir ofreciendo el mejor servicio a nuestros clientes. En este año se consiguió la certificación ISO 20000, con esta norma lograremos las mejores prácticas que nos ayudarán a mejorar la prestación de servicios que le ofrecemos a todos nuestros clientes. Adicional, contamos con pólizas de servicio para que esto les permita a ustedes dedicarse a la innovación y no preocuparse por el tema operativo de la infraestructura, ya que como bien sabemos, esto es lo que más consume el tiempo de los recursos valiosos con lo que cuenta cada con los que cuenta cada empresa. Bien, comencemos con la importancia de la innovación en el ámbito del desarrollo. El día de hoy estaremos desglosando los servicios que nos pueden apoyar en la innovación y en el ámbito del desarrollo. Y vamos a ahondar en cuatro temas principales para lograrlo, que es el de microservicios, el de contenedores serverless y DevOps. Como lo comenté en cada uno de estos dos puntos, haremos una demo breve para que les pueda ayudar a comprender un poco más estos servicios en la nube de AWS. En conjunto, estos servicios enfocados en el desarrollo nos ayudarán a tener un despliegue de software más rápido. ¿Esto en qué nos va a beneficiar? En la rapidez de aprovisionamiento, pues no necesitamos contratar servidores, instalar software, base de datos, configurar máquinas, etcétera. Rapidez de desarrollo, porque no tenemos que programar muchos de los sistemas que se necesitan para una aplicación web y eliminar la necesidad de programar todas las capas. Centrarse en otras partes del desarrollo, gracias a que muchas tareas no se necesitan desarrollar. También se puede integrar fácilmente con AWS, ya que contamos con la seguridad que ofrecen las soluciones para autenticar usuarios y herramientas para que estos tengan su información privada. Pero además, confiar en un servicio de terceros creado por personas altamente especializadas suele ser más confiable que el software que nosotros podamos realizar manualmente. Y por último, la escalabilidad, dado que la nube es perfectamente escalable en función de la demanda y las empresas que ofrecen Cloud Services suelen tener muy presente esta necesidad. A continuación, les cedo la palabra a mi compañero, el ingeniero Jaret.

¿Qué tal a todos? Muy buenos días y gracias por seguir aquí con nosotros en el webinar. Yo les voy a hablar acerca de qué son los microservicios. Siguiente, por favor. OK, para empezar, hay que tener claro que los microservicios no es más que otra forma de ingeniería de software. Es decir, el arquitecto de software debe de pensar en microservicios como una solución a un problema Actualmente estamos acostumbrados a pensar de manera monolítica, es decir, que todo nuestro código, todas las funcionalidades, todo el business logic se mantenga en un servidor. Inclusive a veces hasta la mismísima base de datos está corriendo en el mismo servidor. Esto tiene una serie de desventajas, como es que es muy difícil escalar, ya que si se requiere de más recursos, se tiene que ver un escalamiento vertical u horizontal dependiendo de la situación. Tiene un único punto de fallo, es decir, si algo le pasa al servidor, se cae todo el aplicativo y es muy difícil trabajar en lo que vendría siendo las actualizaciones, porque como todo tiene unas cadenas firmemente establecidas, una lógica y otra, o una usabilidad y otra, pues obviamente si se cambia algo en una parte se tiene que hacer pruebas, hacer pruebas de integración para que se vea que en realidad sí están funcionando todas las partes y toda la comunicación. Entonces, pues que nos quede claro que los microservicios es una arquitectura de software que reduce y más bien eliminación todas estas fallas que tenían los sistemas monolíticos. Siguiente, por favor. Ahora, también cabe aclarar que utilizar microservicios no es una tarea sencilla, de hecho es una tarea compleja que se tiene que estudiar, que los ingenieros de software y los arquitectos tienen que trabajar en conjunto, ¿Para qué? Para desacoplar todas las funcionalidades. Ahora sí que sin fallas. Tenemos esta parte de que sobre todo lo más difícil que se tiene que hacer cuando se incorporan los microservicios es el data binding, es decir, la comunicación entre una data y otra entre los microservicios, porque por definición un microservicio tiene que ser independiente de toda la funcionalidad. Entonces, lo que se recomienda es tener una base de datos aislada y que no dependa de otra base de datos. Pero entonces, ¿Cómo le vamos a hacer para tener esta comunicación? Bueno, ahí entra, podría ser, ahora sí que existen dos formas, la sincronización o las funcionalidades síncronas y asíncronas. Lo más recomendable es usar ambas y para eso están los servicios de cola. En esta parte vamos a hablar acerca de los servicios de AWS que les pueden ayudar a hacer una arquitectura de software basada en microservicios. Supongamos que tenemos una aplicación que tiene tres funcionalidades, usuarios, productos y órdenes. La parte de usuarios, el arquitecto de software le dice a sus ingenieros desarrolladores que está checando y le parece genial lo que es AWS Lambda y que ellos quieren. Esos ingenieros de software están especializados en en C Sharp como programación, entonces ellos se enteran de que Lambda les provee del runtime de Net Core, entonces lo van a utilizar para esta etapa de usuarios, se van a conectar a través de API Gateway, van a hacer un API REST que van a hacer la comunicación entre los usuarios, también van a tener la autenticación de los usuarios a través de JWT que vendría siendo la autenticación vía tokens con el servicio incógnito que también es serverless, entonces esta solución de usuarios es un microservicio totalmente serverless, inclusive va a tener la comunicación y el almacenamiento de la base de datos en un DynamoDB que es una base de datos no relacional nativa de AWS. En la parte de productos nosotros lo que va a hacer el arquitecto de software más bien es que se entera que que sus ingenieros tienen experiencia trabajando con contenedores, entonces van a utilizar el servicio de Fargate AWS Fargate junto con ECS que vendría siendo el orquestador de los clústeres de los contenedores, más adelante vamos a hablar acerca de los contenedores y estos ingenieros de desarrollo tienen especialidad utilizando Node JS, entonces van a elegir este runtime o este lenguaje de programación y van a guardar toda la data en una base de datos no relacional que es MongoDB para para eso utilizan el servicio de AWS llamado DocumentDB que no es más que MongoDB en AWS. Y por último el servicio tal vez más complejo porque es el que va a requerir de la data de usuarios y productos va a ser el de órdenes, aquí los ingenieros de software están especializados utilizando el lenguaje de programación Golang, igual le gustó al arquitecto de software cómo funcionó el servicio anterior con los contenedores con Fargate, entonces se van a quedar utilizando Fargate y van a guardar la base de datos en una estructura muy bien establecida en una base de datos relacional. Entonces voy a utilizar Amazonar 10. ¿Ahora cómo hacemos esta comunicación que les dije al inicio? ¿Cómo evitamos esta dificultad? Utilizando EventListeners que vendrían siendo, ahora sí que van a esperar que por ejemplo usuarios, se agregue un usuario y van a sincronizar las tres bases de datos a través de estos EventListeners, inclusive esto lo puedes hacer con uno de los mejores servicios de AWS en el mercado que se llama Amazon SQS que es una cola de servicios asíncrona, entonces con esto podemos nosotros tener la data bien sincronizada entre los tres servicios sin ningún problema. Siguiente, por favor. Ahora hablaremos acerca de lo que son los contenedores. Bueno, los contenedores no son más que empaquetar todo el código junto con las dependencias del mismo para tu aplicación o para tu funcionalidad. Ahora sí que esto va a incluir todo lo necesario para ejecutarse e implementarse en cualquier entorno. Esto es súper importante. Los contenedores son portables y y se van a ejecutar bien tanto en la máquina del desarrollador, como en la máquina on stakeholder, como en la máquina de producción o el servidor de producción. Cabe aclarar que el 80% de los contenedores de la nube se ejecutan actualmente en AWS y clientes como Samsung, Expedia, KPMG y Snap eligen ejecutar sus contenedores en Amazon Web Services. Siguiente, por favor. Ahora, ¿Cuál es la diferencia? Antes de entrar en las ventajas de contenedores, les voy a hablar de la diferencia entre una Virtual Machine, que vendrá siendo un servidor y unos contenedores. La principal diferencia es que las máquinas virtuales, como lo vienen siendo EC o cualquier ahora sí que máquina o software que ustedes utilicen para virtualizar máquinas virtuales, valga la redundancia, van a virtualizar hardware. Es decir, es un software que va a emular, que está corriendo un hardware, va a emular un sistema operativo, lo va a instalar dentro de este hardware emulado y después va a correr la máquina o los servicios y se tiene que hacer la configuración completa de todo el servidor. Es una tarea tediosa para el procesador y para la RAM, inclusive si se tiene una máquina con prestaciones potentes, va a tardar en arrancar. Y esta es la principal desventaja entre las máquinas virtuales, además de que son 100% configurables por el usuario, es decir, no están administradas. Esta es la diferencia. Las Virtual Machines utilizan el hypervisor, que vendría siendo este software capaz de emular hardware. En cambio los contenedores no necesitan emular ningún tipo de hardware, es simplemente un proceso, un daemon en Linux, un proceso en Windows, que se ejecuta donde está ese empaquetado de tu software o de tu solución o funcion que ustedes implementaron y se está ejecutando en un sistema operativo y ya es mucho más ligero y por lo tanto es mucho más fácil escalar. Y aquí vemos que también lo que les comentaba, es súper fácil de hacer la portabilidad de una imagen creada en Docker en un contenedor, tanto en la máquina de cualquier programador como en la máquina de cualquier supervisor como el productivo, debe de correr exactamente igual la imagen de Docker y es fácil de adaptar a un ciclo de bobs. Teniendo ahora este nuevo tipo de programación mucho más ágil, nosotros queremos ver cambios inmediatos, queremos hacer pruebas automatizadas, todo este tipo de despliegues automatizados, todo este tipo de configuraciones ya se unieron en lo que vendría siendo un ciclo de box, que más adelante hablaremos de él. Y cabe recalcar que los contenedores es muy fácil de adaptar a un ciclo de bops. Siguiente, por favor. Ahora, también es importante señalar que los contenedores obviamente tienen que correr sobre un clúster, es decir, un paquete de esos mismos procesos y a su vez tienen que estar orquestados, es decir, tener la infraestructura bien establecida tanto de redes, como de cómputo, como de almacenamiento. Todo este orquestamiento o administración se hace a través de los orquestadores. En el mercado existe el más popular por muchos, Kubernetes. Kubernetes también lo tenemos en AWS con el servicio EKS. EKS es Kubernetes en Amazon Web Services. Entonces, si sus desarrolladores o equipo de operaciones ya tiene experiencia utilizando la administración tipo Kubernetes, no se preocupen, AWS pensó en ustedes y ya tiene este servicio de Kubernetes. También es importante señalar que AWS tiene su propio administrador de contenedores u orquestador llamado SS, que vendría siendo la competencia directa a Kubernetes. Siguiente por favor. Ahora vamos a ver un ejemplo de cómo sería este proceso de registro y de despliegue de contenedores. Para empezar, esos programadores crearían la imagen de Docker a través de un Dockerfile, después la crearían con el comando docker build en el CLI. Posteriormente se tendrían que hacer el registro de esta imagen a la nube de AWS, porque la imagen está en local. Para eso tenemos el servicio de AWS SR que vendría siendo el registro de imágenes de la nube, para así pasar tu imagen de local a AWS. Una vez que ya está este servicio, esta imagen arriba, tenemos que elegir qué orquestador vamos a utilizar para administrar los clústeres de esta imagen. Podemos utilizar EKS como les mencionaba, o podemos utilizar SS. Y después tenemos dos opciones, ahora sí que ponernos la parte del hardware porque así sea. Ahora sí los servicios sean serverless, no sean serverless, todo va a correr al final de cuentas sobre fierros, o sea sobre hardware físico. Y hay dos opciones, tener que administrar tú en dónde van a correr tus clústeres con una Amazon EC, que vendría siendo una máquina virtual. Aquí vemos que en realidad las máquinas virtuales y los contenedores se complementan aquí en esta parte, porque están utilizando Amazon EC y dentro de ese Amazon EC van a correr los clústeres de los contenedores. Pero obviamente se tiene que hacer toda la configuración manual, se tiene que elegir familia, se tiene que ver todo este tipo de requerimientos o existe una forma serverless que le llama AWS también más adelante hablaremos acerca de serverless, que vendría siendo Fargate, Fargate. Tú únicamente le dices, OK, tengo Task Definition. Task Definition vendrá siendo este contenedor o este servicio que va a ocupar 1 GB de RAM y punto 5 de vCPU. Y ya AWS Fargate se encarga de toda la que esté corriendo perfecto dentro los clústeres, o más bien el clúster de esta imagen que esté arriba, si se cae por algún motivo va a levantar otra de manera automática. Toda esta magia de administrar el cluster lo va a hacer Fargate de una manera totalmente administrada por AWS. Siguiente, por favor. OK, después hablando más acerca de los contenedores, vamos a tener una demo práctica acerca de cómo está configurado este servicio de contenedores en AWS. Pero primero hay que ver esta parte del diagrama de qué es lo que se logró con esta demo. Para empezar, pensando siempre en la seguridad de los usuarios, dividimos que los contenedores van a estar corriendo en una subnet privada y vamos a tener un balanceador de carga en la subnet pública. ¿Para qué nos funciona un balanceador de carga con contenedores? Bueno, como pudimos ver anteriormente, los contenedores son muy fáciles de escalar, pero obviamente necesitamos algo, un software que le indique a qué contenedor se va a ir el request del usuario. Entonces para eso necesitamos un balanceador de carga. Este balanceador de carga igual es un servicio de AWS, se llama Load Balancer y este va a estar en la parte pública porque va a tener acceso a Internet, al final de cuentas es un API restaurante y va a tener acceso a los contenedores. Este balanceador de carga a través de un Security Group, voy a compartir pantalla para presentarles lo que vendría siendo lo que realizamos, me confirman cuando lo puedan observar. Aquí estamos dentro de la consola de AWS. Si pueden ver, tenemos tres servicios, porque inclusive vamos a ver que es muy fácil hacer un Code Pipeline de contenedores. Un codepipeline es un ciclo de bots. Para empezar tenemos lo que vendría siendo los repositorios, las imágenes registradas, es decir, la funcionalidad de usuarios. OK, mis programadores ya crearon la imagen, está corriendo perfecto en local, ahora hay que subirla. Y esto es, Sr, subes las imágenes que creaste local. Después tenemos algo que se llama Task Definitions. Las Task Definition son los servicios o un blueprint de qué se va a hacer con esa imagen. Es decir, aquí ponemos variables de ambiente, hacemos un port mapping, es decir, decimos, OK, esta imagen va a correr o tiene la finalidad de correr sobre el puerto 3000, entonces hacemos el mapping de ese puerto. Toda la configuración de cómo queremos que corra este servicio lo haremos en un Task Definition. Por último, tenemos un clúster. En el clúster, dentro vamos a tener los Task Definition corriendo. Para empezar los servicios y entre los servicios, las tareas que son copias tangibles de un Task Definition. Tenemos en EC un balanceador de carga, que es el que les comentaba, para hacer la carga de, OK, Si mi máquina 1 está saturada, vámonos a la máquina 2, o más bien al servicio de contenedores 2. Y así, para que nunca tengamos alguna caída de sistema. Después creamos inclusive una imagen, o más bien un ciclo de bops, perdón, con tres fases. La primera, la source, es decir, de dónde tomamos el código con GitHub VIR, cómo hacemos este sistema de subir la imagen automáticamente y bajarla, Eliminar los servicios que tienen una versión desactualizada, poner solo los actualizados. Todo eso lo hacemos en la fase Build y Deploy es subir simplemente la imagen. Si podemos ver aquí, este es el API REST, lo actualizamos y dice Webinar de AWS para Developers. El código es este, lo podemos ver acá. Y simplemente es un API REST con un GET, ahora sí que la parte principal del DNS, donde mandamos un pequeño mensaje. Utilizamos también la Ruta Health. ¿Para qué? Para que Load Balancer se mantenga feliz. Esta ruta siempre va a mandar un código 200 de HTTP que le indica que todo está funcionando perfecto y va a escuchar en el puerto 3000 la docker image de cómo se creó esta imagen de Docker. Simplemente elegimos que runtime vamos a utilizar, en este caso no es En su versión 12, el Working Directory donde lo vamos a correr o qué directorio va a ejecutar este servicio. Hacemos un npm install para instalar las dependencias del API REST, creamos el empaquetamiento en producción, copiamos, exponemos el puerto 8080 y por último ejecutamos la aplicación. Todo esto es lo que hace los pasos a seguir de Dockerfile y cómo hacemos el ciclo DevOps. La parte de build, bueno esto lo vamos a ver un poquito más adelante a detalle, pero solo se ponen las fases y dentro de esas fases igual se pone qué comandos se van a realizar, por ejemplo aquí decimos OK, en el CI de AWS loguéate a mi cuenta en la región US East 2, después create la imagen de donde estoy y ponle un tag llamado prueba compucloud el último, después taggeamos, ahora sí que la parte que vamos a subir, posteriormente subimos la imagen a través del servicio de SR. Por último creamos un archivo JSON llamado image definition, donde le pasamos el nombre del task definition y le pasamos la imagen, el URI de la imagen y por último qué guardamos como artifact. De todo este proceso qué es lo que nos va a importar que salga el output, el archivo JSON creado anteriormente. Estos son los pasos para crear contenedores de una manera sencilla en AWS, como pueden ver la administración como es Fargate lo hace automáticamente AWS SS es un servicio muy fácil de administrar contenedores, entonces todo este proceso se lleva de una manera práctica y de una manera rápida y a los desarrolladores les va a dar más tiempo de pensar en soluciones para su negocio y no tanto el administrar todo este tipo de servicios. Muchas gracias.

Excelente Jared, muchísimas gracias. Continúo yo. Mucho gusto Pedro Serrano, gracias por continuar con nosotros. Vamos a hablar un poquito acerca de lo que es serverless. Si bien mi compañero Jared ya nos dio un review muy rápido, pudimos ver lo que es este Fargate, uno de los servicios serverless, vamos a verlo un poquito más a detalle. ¿Qué es serverless? Bueno, tenemos que entender que serverless es una arquitectura nativa de la nube, con lo cual nos permite trasladar las responsabilidades operativas, en este caso a AWS, que nos aumenta la agilidad y la innovación, dado que obviamente está optimizado para soportar todas estas cargas de trabajo. Lo que nos ayuda es a tener, a poder olvidarnos de aprovisionar servidores o algo físico, o puede ser también en este caso una instancia con sistema operativo y todas estas cuestiones, entonces nos vamos a eliminar esa administración, el tener esos ahora sí que cosas físicas como tal, administrar el sistema operativo, hacer las configuraciones necesarias, configurar paqueterías, librerías, todo ese tipo de cuestiones que siempre necesitamos, lo vamos a olvidar en este caso con serverless y le trasladamos toda esa responsabilidad operativa a AWS, lo que permite eliminar las tareas de administración de infraestructura y nos permite enfocar a nuestros desarrolladores, a nuestro personal de ingeniería en actividades que netamente son benéficas para la empresa y eliminar estas otras actividades. Los beneficios de serverless, pues obviamente bajo mantenimiento, ya hablamos por qué no necesitas aprovisionar ni mantener ningún servidor, todo se lo delegas AWS. Pago por uso, esto es muy importante, si no lo estás usando no se paga, solo pagas lo que estás usando por el tiempo de ejecución, por la duración y por las capacidades de cómputo que se hayan aprovisionado para hacerlo. La escalabilidad, este tipo de tecnología permite ser escalable de una forma muy fácil y prácticamente automatizada, lo que obviamente estos servicios como son totalmente administrados, obviamente detectan como tal estos picos de rendimiento que estamos teniendo y se escalan como tal, lo que nos permite tener un performance más eficiente. Alta disponibilidad, bueno este tipo de servicios, esta tecnología cuenta con alta disponibilidad, ya que por default está diseñada para soportar errores, para tener una mayor resiliencia, para que todas estas cuestiones, todas estas cargas de trabajo que tenemos en estos servicios sean más resilientes. Estas fallas por default se replica en varias zonas de disponibilidad, lo que nos da que eliminemos un único punto de falla como tal. Esta tablita que pueden ver aquí es muy interesante, ya que obviamente nos representa el modelo de responsabilidad operacional, hacia la izquierda vemos más on premise, podríamos decir que es menos serverless y hacia la derecha podemos ver lo que es más serverless, de on premise hacia la nube totalmente serverless. Obviamente hay en medio diferentes servicios, como por ejemplo obviamente si empezamos en la primera capa de on premise, pues son nuestros datacenters, podemos hacer Virtual Machines con Hypervisors y otras cuestiones, nuestras bases de datos tenemos que tenerlas en algún servidor, el almacenamiento, el EBS y todas estas cuestiones que tenemos que tener on premise. Si nos vamos un poquito más a la derecha, entonces encontramos nube que es por ejemplo, ya tenemos lo que son las instancias EC y en estas instancias EC no es nada, no es otra cosa más que un servidor en la nube por así decirlo, con nuestro sistema operativo Windows, Linux, de la distribución que queramos, diferentes versiones de sistema operativo Windows y obviamente vamos a acceder a ellas a través de escritorio remoto, VPN, etcétera, etcétera y una base de datos MySQL en s, también puede ser SQL Server, pero es totalmente administrado por nosotros. En el modelo de responsabilidad compartido de AWS nos queda muy claro que AWS se encarga de la infraestructura y nosotros nos encargamos de lo que está en esa infraestructura, la administración del sistema operativo y todas estas cuestiones. Si nos vamos un poquito más a la derecha empezamos a tener instancias administradas por AWS, que si bien si son instancias que ocupan un espacio, tienen rendimiento y nosotros decimos qué características va a tener, son administradas por AWS, nosotros no tenemos la injerencia en el sistema operativo, lo único que hacemos por ejemplo en Elastic Beanstal le pasamos el código, el servicio lo que hace lo aprovisiona con un simple archivo que nosotros le vamos a crear de tipo YAM, le vamos a decir aquí las características que queremos que configure, ya se hace librerías, paqueterías, comandos a correr, todo este tipo de cuestiones y se va a provisionar automáticamente. Sirve para cuestiones de Apache, cuestiones de NET y otros tipos de tecnologías que maneja. RDS también es una instancia especialista en base de datos totalmente administrada por AWS, lo único que hace nos retorna un endpoint y este endpoint lo que va a hacer nosotros lo vamos a configurar ya sea en un manejador de bases de datos visual o en una línea de comando como tal y vamos a poder entrar a la base de datos como tal sin necesidad de tener esta administración del sistema operativo ni administrar el motor de base de datos y todas estas cuestiones nos las vamos a liberar como tal. Un poquito más a la derecha está el mismo concepto RDS, pero ahora es Aurora. Aurora es el motor de base de datos diseñado por AWS que nos sirve para bases de datos compatibles con MySQL y PostgreSQL y obviamente está automatizado está totalmente administrado y por default ya trae réplicas en diferentes zonas de disponibilidad, una opción de un endpoint para Writer, una opción para un endpoint de Reader y esto nos va a ayudar a que obviamente el performance sea muchísimo más elevado. Un poquito más a la derecha hablamos de Fargate, lo que ya mi compañero Jared nos hizo el favor de comentarnos un poquito, obviamente es contenedores serverless, ya lo vimos como tal está Aurora serverless, mismo caso del motor de base de datos de Aurora, pero totalmente serverless, no vamos a provisionar ningún servidor, solo se va a consumir lo que nosotros las consultas que hagamos, las escrituras y no nos tenemos que preocupar por nada más porque es totalmente pago por uso y bajo demanda. Y ya en lo totalmente serverless pues tenemos AWS Lambda, el core de las funciones serverless de AWS. AWS Lambda es un servicio de cómputo en el que nosotros podemos aprovisionar funciones de código, pedazos de código en el que queramos que haga una función específica y no más, nos va a cobrar cuando lo mandemos llamar, el tiempo que dure y la capacidad que se tenga que aprovisionar para ejecutar esta función como tal nos sirve para diversos lenguajes tales como Go, Ruby, net, Node, js, Python, entre otros. Entonces esto es como tal el corazón como ya lo mencioné de las funciones de los servicios serverless de AWS. Tenemos DynamoDB, una base de datos no relacional totalmente serverless, obviamente pues con las mismas características de Aurora serverless, pero obviamente es una base de datos no relacionada, no SQL. Tenemos s para almacenamiento, en este caso en la demo que vamos a hacer lo vamos a usar para montar una página web estática que también nos sirve para eso, le aprovisionamos alguna página web estática que hayamos diseñado, puede ser en React, en Vue, en otros tipos de tecnologías que usemos y entre otros servicios como tal. Bueno, como les decía el stack de serverless AWS es muy variado, pero el corazón lo podemos ver en estos servicios que es Lambda, como ya les había dicho, obviamente podemos hacer por ejemplo a través de estas funciones convertirlas en API, las podemos llamar a través de API Gateway, que no es otra cosa que un ad servicio que nos va a dar un API endpoint para poder consumirlo a través de Cals, entonces obviamente va a estar aprovisionado nuestro nuestro código en Lambda y vamos a llamarlo a través de API Gateway. DynamoDB, pues ya dijimos, nos puede servir como una base de datos no relacional para hacer operaciones entre Lambda y Amazon DynamoDB, entonces podemos hacer aquí algo muy interesante y podemos utilizar el framework nativo de AWS, que es AWS SAM, que nos permite desplegar de forma totalmente nativa servicios serverless a través de CloudFormation, con comandos muy sencillos que maneja WS, Nosotros a través de línea de comando vamos a poder desplegar ambientes completos serverless de forma muy ágil. Lambda, como ya dijimos, ya fuimos un poquito claros en lo que es Lambda, como dijimos, maneja lenguajes como lo son Node, JS, Net, Python, Java, Ruby, Go, entre otros. Y esto nos va a permitir obviamente, todas estas funciones que tenemos, poderlas migrar o poderlas aprovisionar desde un inicio en Lambda, y ya sea que se llamen de forma nativa entre los mismos servicios de AWS, que obviamente la integración entre los servicios de AWS es nativa, es muy fácil, o ya sea que necesitemos llamarla desde fuera a través de una API, ¿No? Y esto para esto nos va a ayudar. API Gateway. Fargate, bueno pues ya Jared nos hizo el favor de comentarnos acerca de Fargate como tal, contenedores totalmente serverless, lo que nos va a ayudar a olvidarnos de aprovisionar hardware o una instancia como tal. Y ya tuvimos una demo. Herramientas para desarrolladores, Ya hablamos un poquito de XAMPP, que dijimos es un modelo que define una aplicación serverless, es totalmente nativo a CloudFormation, o sea AWS, y le permite montar una aplicación serverless de una manera muy sencilla. Es una tecnología desarrollada por AWS, totalmente nativa y nos va a apoyar en todas estas cuestiones de desplegar ambientes serverless. Claudia JS, un framework similar a XAMPP, obviamente triparty como lo es Claudia JS, pero también nos va a ayudar a hacer estas cuestiones de despliegue con sus propios comandos. De una forma muy ágil y muy sencilla. Podemos desplegar ambientes serverless, ya sea que queramos usar SAM, que es nativo de AWS, o Claudia Gies, que es obviamente Tripart. Vamos a hablar un poquito de DevOps. Bueno, DevOps, ¿Qué es y cómo se conforma? Si podemos ver aquí el símbolo de DevOps, pues obviamente es una cadena infinita de operaciones, una amalgama entre desarrollo y operaciones, y lo que nos va a permitir conjuntar estos dos mundos. ¿AWS tiene un stack de servicios que nos van a ayudar a lo que es esta cuestión de DevOps para aplicaciones, en este caso web, que es la demo que vamos a hacer, obviamente tenemos nosotros nuestro ambiente y quién lo va a consumir? Nuestro ambiente un usuario final y DevOps lo que nos va a ayudar es, nos va a ayudar a automatizar lo que es el despliegue del código, el build, el testing y todas estas cuestiones que tengan que ver con el código y obviamente el lanzamiento final hacia un frontend que nosotros le hayamos definido como tal. ¿Qué opciones de backend? Ya hablamos de lo que es serverless, obviamente serverless lo podemos implementar a lo que es backend, hacer un ciclo automatizado con nuestros desarrolladores en donde tengamos nuestro repositorio de código fuente, obviamente en cuestiones de backend y en cuestiones de frontend también puede ser en estas cuestiones de backend podemos crear un ciclo DevOps que nos automatice como Jared nos mostró hace un momento, despliegues hacia contenedores, hacia contenedores dockers o si lo queremos hacer en Fargate que sea serverless o otro tipo de cuestiones, podemos poner ciclos automatizados a lo que es Elastic. VStalk nos va a ayudar a hacer este despliegue automatizado, obviamente nuestro código tiene que estar el archivo que les mencioné, igual mismo caso que el Docker, tiene que estar el Dockerfile y todas estas cuestiones para que el despliegue sea eficiente y nos ayude y ahora sí que sepa el motor que nos va a ayudar a hacer el despliegue, cómo se tiene que hacer este debug, este empaquetado como tal y otras cuestiones, aunque no es serverless, pero también podemos usar debug end, obviamente una EC que es lo más común en AWS y nos puede servir sin problemas. Frontends en AWS, pues ya mencionamos sí nos sirve para montar una página web estática, en este caso en la demo es lo que vamos a usar, esto lo que nos va a dar es, nos ayuda a procesar esta simple web application y nos retorna un endpoint, a través de este endpoint podemos ligarlo a un content delivery network y este content delivery network nos va a ayudar, aparte del caché y la entrega de forma ágil nos va a ayudar a las certificaciones SSL necesaria para que lo podamos aprovisionar en nuestro DNS, podemos montar nuestro frontend en otro contenedor. Hablando un poquito en referencia de microservicios, podemos pensar en que un contenedor sea nuestro backend y otro contenedor sea nuestro frontend. Obviamente cada uno con su ciclo DevOps y bien identificados. Y obviamente podemos montar un frontend en una EC, que es ahora sí que algo totalmente genérico de AWS. Bueno, vamos a continuar con la presentación, pero antes de eso vamos a hacer una demo de una web con un ciclo de bots. Muy bien, digo, para efectos de verlo muy rápido, esta es nuestra web, nuestra página web, y vamos a hacerle unos cambios en lo que es el código fuente. Entonces, por ejemplo, aquí podemos ver el mensaje principal que tenemos Todos podemos ser héroes aunque sea un día en este webinar para desarrolladores. Entonces guardamos los cambios y obviamente yo lo que estoy utilizando es tecnología Git de AWS, que es el servicio de code commit. Entonces, si nuestros desarrolladores están familiarizados con lo que es la tecnología Git, sin problemas utiliza los mismos comandos que si utilizáramos por ejemplo GitHub o GitLab u otras de estas cuestiones. Pero obviamente estos ciclos DevOps se vuelven un poquito más nativos, aunque podemos usar GitHub como en el ejemplo que nos dio Jared, Pero obviamente si usamos CodeCommit, lo que es el servicio de AWS se vuelve totalmente nativo. Vamos a hacer un commit, y aquí al hacer el commit falta una parte, hacemos nuestro push, y al hacer nuestro push, obviamente lo que nos va a detectar a través de un diagrama que les voy a mostrar más adelante, pero igual lo podemos platicar poquito, nos va a detectar a través de lo que es un servicio de monitoreo que nuestro push fue realizado. Y obviamente lo va a detectar y va a iniciar, si se fijan, ya hace un momento lo detectó lo que es el code commit, detecta el source, lo empaqueta y se lo pasa al build. El build lo que va a hacer es construirnos nuestra aplicación y ya posteriormente lo va a pasar al deploy, al code deploy. Y seguimos en la presentación. En un momento más vamos a volver a lo que fue nuestra demo, Vamos a permitirle que termine el despliegue total, ya que es una página completa, nos va a tardar unos cuantos minutos en desplegar. Mientras vamos a analizar un poquito lo que es el stack de servicios que utilizamos. Aquí podemos ver los servicios DevOps en AWS. Bien, utilizamos Code Pipeline para hacer toda esta automatización de este ciclo a tres fases. Si se fijaron la primera fase es el código que es el source. Utilizamos code commit para centralizar nuestro código fuente, obviamente en este caso utilicé la rama master, pero obviamente nuestros desarrolladores pueden crear n cantidad de ramas y dividir en ambientes, llámese dev, llámese QA, pruebas o lo que nosotros queramos productivo, obviamente a la rama que le hagamos el commit es la rama que es el ambiente que se va a desplegar por medio de este ciclo DevOps automatizado. Después viene el build, lo realizamos con codebuild, en este caso es necesario crear un archivo build spec para aquí le vamos a decir las características que queremos que tenga nuestro empaquetado, vamos a decirle de qué tecnología va el proyecto, tal vez configuraciones adicionales que queramos, todo esto que ya hemos platicado. Aquí me va a hacer el build, el testing y el empaquetado. Nos va a arrojar el artifact, muy interesante es que este servicio nos ayuda por si nuestro nuestro proyecto tiene algún error, obviamente aquí lo vamos a detectar y podemos automatizar alertas a través de cloudwatch. Podemos usar un tripty también con quad build, como por ejemplo Jenkins, en este caso no lo utilizamos, pero se puede integrar sin problemas. Y codeploy, que no es otra cosa más que el despliegue de nuestras aplicaciones en un frontend o en un backend donde nosotros le digamos y el monitoreo que nos va a decir si se desplegó bien, si no se desplegó bien, nos va a dar logs y todas estas cuestiones que necesitamos como tal. Entonces aquí tenemos un ciclo DevOps completo, vamos a nuestra aplicación a ver si ya como tal pudo desplegarse, igual les platico un poco, sigue desplegándose, Estos son los archivos en el bucket DS, así los podemos ver una vez ya desplegados, si nos vamos a propiedades, sin problemas podemos configurar este bucket para que sea una página estática, una página web estática. Entonces ya con las características que le digamos se va a desplegar como tal. Nos va a arrojar un endpoint, que es este endpoint y nos va a ayudar como tal a todo lo que es mostrarnos la página que nosotros diseñamos o la página productiva o todas estas cuestiones que nosotros hicimos como tal. Sigue sin desplegarse en este caso, si se fijan en la parte del deploy, yo lo dirigí a un bucket DC, que es este que ya les mencioné y obviamente ya tenemos la página y CodeBuild, que es nuestro motor de compilación y debug y testeo como tal. Aquí podemos ver los diferentes fases que hemos. Las ejecuciones de compilación que hemos realizado y si hubiera alguna errónea o alguna que no se hubiera desplegado bien, porque nuestro código tiene algún error, le falta alguna configuración, que es algo muy común, nos va a ayudar a evitar lanzar versiones inestables. Entonces, aquí diría un mensaje de error, el mensaje de error del por qué. Y obviamente entrando a él podríamos ver a detalle los logs del por qué falló como tal. Excelente. Bueno, mientras se ejecuta nuestro código, completo nuestro ciclo DevOps, le cedo la palabra a mi compañero David. Muchas gracias.

Gracias Pedro. Bien, muchas gracias por continuar aquí con nosotros. Como podrán ver, hay muchas ventajas en tener todos los servicios y herramientas que proporciona AWS para los desarrolladores. Entonces, ¿Por qué elegir AWS para las operaciones de desarrollo? Vamos a enfocarnos en las ventajas que ya nos platicaron tanto el ingeniero Pedro como el ingeniero Jared, que es comenzar con rapidez, servicios completamente administrados, diseñado para el escalado programable, automatización, seguridad y sobre todo, lo que más nos importa en este momento es pagar por lo que se está usando, no tener recursos utilizados. Entonces, estas son las ventajas de estar en AWS con todos los servicios que les acabamos de presentar. Por favor, quiero comentarles que cuentan con el apoyo total de los ingenieros de CompCloud para ayudarlos en su viaje a la nube. Si ahí ustedes tienen por ahí un proyecto, tienen pensado migrarse a la nube, no duden en contactarnos y pueden recibir una consultoría sin costo en conjunto con el equipo de ingenieros de CompuCloud y más adelante podemos involucrar a un arquitecto de AWS. Bien, no me queda nada más que agradecerles por su atención y en lo que se ejecuta el código que hizo el ingeniero Pedro, podemos a la sesión de preguntas y respuestas. Que tengan un excelente jueves y muchas gracias de nueva cuenta por su atención. ¿Cómo vamos ahí Pedro con tu? ¿Con tu código? ¿Ya quedó? Para que se pueda mostrar.

Sí, listo, ya quedó. Ya quedó. Si vemos aquí en el pipeline, ya se realizó por completo todas nuestras tres fases. Si podemos ver, obviamente ya habíamos visto que el source ya se había realizado correctamente, aquí podemos ver que el build ya se realizó correctamente también y en efecto el deploy se hizo de forma correcta. Entonces actualizamos nuestra página, como todavía falta que la despliegue, tal vez que la reconozca, denos un segundo.

Perfecto Pedro, entonces mientras esperamos a que se despliegue completamente la página, reitero, si tienen alguna pregunta o alguna duda por ahí. María Elena Reyes nos está preguntando dónde puede consultar la ruta de aprendizaje de las herramientas.

Claro, en esta parte hay diferentes fuentes de información de cómo utilizar los servicios de AWS. Las dos principales son, o más bien oficiales, son AWS Educate, que es una página donde vienen distintos tutoriales de cómo se y con ejemplos inclusive técnicos y prácticos de cómo puedes levantar por ejemplo una aplicación web, cómo puedes levantar una API REST, como puedes configurar una base de datos en AWS, toda esta parte la maneja AWS Educate, que es lo oficial. También existe la otra alternativa, es la documentación oficial de AWS, que se encuentra disponible también en la página de Amazon Web Services, donde también te dan ejemplos, claro, estos escritos y AWS Educate son tanto escritos como videos, demostraciones y talleres. Esas son las dos fuentes principales.

Gracias Jared, ya podemos ver como tal aquí cómo se desplegó nuestra página, digo tarda estos servicios, aunque son totalmente automatizados y en tiempo real, tenemos que esperar un momento ya que obviamente tarda en replicarse. Entonces ya podemos ver cómo se completó el ciclo DevOps con nuestros cambios que hicimos de forma efectiva.

Perfecto Pedro, muchas gracias. ¿Alguna otra duda o pregunta que tengan? Aquí les comparto los datos de los consultores comerciales que estamos divididos por zona. En la zona occidente y Bajío está Jorge Montión, en la zona de CDMX y sur está Bianca Grullón y en la parte norte su servidor David Martínez.