Esta charla explora el poder de la infraestructura tecnológica como código, permitiendo a las organizaciones construir, escalar y desmantelar infraestructuras del mundo real de manera rápida, confiable y reproducible, con un enfoque en pilas de NodeJS.
Video Summary and Transcription
La charla de hoy discutió la infraestructura como código utilizando Node.js sin servidor con un enfoque en AWS Lambda y Terraform. El orador enfatizó los beneficios de la infraestructura como código, como la colaboración, la versionización y la reproducibilidad. La charla proporcionó una demostración paso a paso de cómo implementar una aplicación Node.js en AWS Lambda utilizando Terraform. Los puntos clave incluyen las ventajas de los procesos mecanizados y automatizados, el estado efímero, los procesos repetibles y la transparencia. El orador también mencionó la importancia de tener expertos en DevOps en el equipo y destacó la rentabilidad de las funciones sin servidor.
Available in English
1. Introducción a la Infraestructura como Código
Short description:
Hoy estamos discutiendo la infraestructura como código con un enfoque en Node.js sin servidor. La infraestructura abarca todos los componentes tecnológicos, desde servidores y bases de datos hasta pasarelas y nodos CDN. Utilizaremos una función lambda como ejemplo, explorando la necesidad de un proxy o una puerta de enlace de API para garantizar un acceso seguro. Las operaciones de lectura y escritura en disco también son consideraciones importantes.
¡Hola a todos! Es genial verlos aquí en el Congreso de Node. Mi nombre es Tejas. Ese soy yo. Trabajo para G2I, que significa buenas noticias para Internet. Y realmente, lo que hacemos es ayudar a los ingenieros de JavaScript o TypeScript a encontrar buen trabajo, especializándonos en React, React Native y Node. Pero también ayudamos a las empresas a encontrar ingenieros de JavaScript o TypeScript especializados en React, React Native y Node. Así que es como Tinder pero para Java. De todos modos, eso no es por lo que estamos aquí. Estamos aquí hoy para hablar sobre la infraestructura como código con un enfoque en Node.js sin servidor. Y saben, este es un tema candente. Hay un montón de charlas sobre esto, como mañana Slobodin hablará sobre lambdas en la arquitectura sin servidor. Y también Colin hablará sobre las charlas de AWS CDK2, las recomiendo mucho. Creo que van a ser increíbles. Estaré atento a ellas. Y te animo a que si te gusta esta charla, te quedes para esas. Pero empecemos esta charla definiendo el término infraestructura. ¿Qué queremos decir con infraestructura? Porque significa cosas diferentes para diferentes personas. Lo que quiero decir en esta charla es todo tu material tecnológico, tus servidores, tus discos, tus bases de datos, tus API, tus enrutadores, tus puertas de enlace, tus equilibradores de carga hasta tus nodos CDN, que sirven probablemente tus interfaces front-end estáticas. Así que todo. Y tal vez usemos un ejemplo. Digamos que tienes una función lambda. Y es solo una función que hace algo, te da una entrada, te da una salida. Y en algún momento, alguien querrá interactuar con esta función. Y probablemente querrán conectarse de alguna manera. Pero permitir el acceso directo a una función probablemente no es la idea más segura. Entonces es posible que necesites algún tipo de proxy o puerta de enlace de API delante de ella. Entonces si el usuario se comunica con esa cosa, esa cosa podría comunicarse con un equilibrador de carga o podría comunicarse con tu función. Y es un poco más seguro. Y tal vez tu función necesite leer
2. Introducción a la Infraestructura como Código (continuación)
Short description:
Pero la puerta de enlace de la API no debería comunicarse con el disco, porque el usuario no debería comunicarse directamente con el disco. Tradicionalmente, la gestión de la infraestructura se realizaba a través de una interfaz gráfica de usuario o una interfaz de línea de comandos, lo cual puede ser desalentador y carece de capacidades de colaboración y versionado. La infraestructura como código ofrece una mejor manera, permitiéndote describir tu infraestructura en un archivo de texto que se puede versionar e implementar como instantáneas.
o escribir en un disco. Pero la puerta de enlace de la API no debería comunicarse con el disco, porque el usuario no debería comunicarse directamente con el disco. Entonces tu arquitectura, tu infraestructura puede volverse un poco complicada. Eso es normal. Las cosas que están vivas generalmente crecen.
Y tradicionalmente, estas cosas eran gestionadas por una persona de cloud o una persona de DevOps, o tal vez muchas personas. Tal vez incluso un equipo. Pero generalmente usarían una interfaz de usuario gráfica en la web de AWS o Azure o Google Cloud o Heroku o cualquier otra. O tal vez una interfaz de línea de comandos, pero generalmente es un proceso en gran medida manual. Y si somos honestos, esta interfaz de usuario gráfica puede ser un poco aterradora a veces.
Y además de eso, creo que el método tradicional tiene algunos puntos débiles. Por ejemplo, no es colaborativo. Si alguien en el equipo de DevOps cambia el tamaño del disco de 8 gigas a 16 gigas en una instancia EC2, no sé que sucedió a menos que les pregunte. Y por supuesto, con suficiente manipulación y creación de registros de auditoría, tal vez, pero por naturaleza, como fuera de la caja, no está orientado a la colaboración. No se puede versionar. ¿Qué tal sería si pudiera tener una infraestructura con un montón de componentes y equilibradores de carga, y luego lo verifico en Git y luego puedo viajar en el tiempo para verlo. Incluso puedo revertir o comprometer una nueva versión. No puedes hacer eso tradicionalmente. Es en gran medida manual. Como acabamos de ver, las personas generalmente entrarían y cambiarían componentes o agregarían nuevos componentes o eliminarían componentes a mano. Es en última instancia opaco. He sido parte de equipos donde no tenía idea de cómo se veía la infraestructura. Simplemente no lo sabía. Empujé algo y luego se implementó, pero ¿cómo? No tengo idea. Creo que al saber esto, podríamos facilitar un software de mayor velocidad y así creo que hay una mejor manera. Creo que no solo hay una mejor manera, hay una manera sexy. Y eso es la infraestructura como código. Entonces podrías preguntarte, ¿cómo es esto más sexy que lo tradicional? Bueno, es una versión. Así que imagina un archivo, un archivo de texto, donde describe todo lo que tienes, desde tus equilibradores de carga hasta tus bases de datos, hasta todo. Es un archivo de texto, es un archivo de texto, se puede verificar en versiones de Git. En segundo lugar, cuando implementas cosas, crea una instantánea del estado de tu infraestructura, y así que si quieres cambiar tu disco de 8 gigas a 16, puede diferenciarlo de manera inteligente y encontrar
3. Introducción a la Infraestructura como Código (Demo)
Short description:
La infraestructura como código es como el DOM virtual de React para tu infraestructura en la nube. Es reproducible, transparente y actúa como un plano. Hay varias herramientas disponibles, incluyendo Chef, Puppet, SaltStack, Ansible y Terraform. Personalmente, prefiero Terraform de HashiCorp debido a su versatilidad y naturaleza idiomática. Cambiemos a una demostración con un navegador, un editor de código y documentación.
cambia y actualiza ese componente. Es como el DOM virtual de React, pero para tu infraestructura en la nube. Es increíble. Es reproducible, lo que significa que puedes destruirlo, crear una nueva cuenta de AWS e implementar toda tu infraestructura en ella. Y por último, es transparente. Todos pueden verlo. Es literalmente como un gran plano de toda tu infraestructura. Entonces, si hay un desarrollador al comienzo de su carrera en tu equipo que quiere saber dónde está todo, puedes mostrárselo. Este es el plano. Y así, es realmente genial. Y es realmente interesante. Ya puedo ver a algunos de ustedes en esta llamada de Zoom diciendo, bien, pero ¿cómo? Quiero esto. ¿Cómo lo obtengo? La respuesta es, tenemos herramientas. Hay herramientas. Está Chef. Está Puppet. Está SaltStack. Está Ansible. Está Terraform. Hay muchas de ellas. Y todas son buenas a su manera. Personalmente, me encanta Terraform de HashiCorp. Lo encuentro el más idiomático. Y también funciona. Es muy versátil. Puede funcionar prácticamente en cualquier lugar. Pero en lugar de hablar más sobre eso, déjame mostrarte. Cambiemos a una demostración. Entonces, tenemos a la izquierda, un navegador. A la derecha tenemos un editor de código. Y aquí tenemos algunos documentos de los que hablaremos en un segundo.
4. Desplegando la aplicación NodeJS en AWS Lambda
Short description:
Tenemos una aplicación NodeJS escrita en TypeScript que crea una instancia de puppeteer, un Chrome sin interfaz. Visita una página, toma una captura de pantalla y la devuelve. Necesitamos desplegarla en AWS Lambda construyendo un archivo zip. Escribiremos código de infraestructura usando HCL y Terraform, especificando AWS como proveedor.
Pero, ¿qué estamos desplegando? Bueno, tenemos una aplicación NodeJS escrita en TypeScript que, ya sabes, es bastante básica. Crea una instancia de puppeteer. Puppeteer, para aquellos que no lo saben, es simplemente headless Chrome. Es Chrome sin interfaz de usuario. Visita una página, va a una URL proporcionada a la función, toma una captura de pantalla y luego la devuelve. Así de simple. Esto está envuelto en un controlador AWS Lambda. Simplemente llama literalmente a una función con una URL de los parámetros de consulta y la devuelve. Solo una captura de pantalla. Nada especial. Pero, por supuesto, no está desplegado. Es solo una cosa. Entonces, ¿cómo desplegamos esto? Bueno, para empezar, vamos al proyecto y lo construimos. Esto nos dará un archivo zip que luego podemos desplegar en AWS Lambda. Va a crear un bonito archivo zip para nosotros. Y en un par de segundos, ahí lo tenemos. Tenemos un paquete. Creemos un archivo llamado main.tf. Ahí es donde vamos a estar la mayor parte de esto. Comencemos a escribir esto. Estamos escribiendo un lenguaje llamado HCL. Así es como se describe toda tu infraestructura. Comienzas con un bloque llamado Terraform. Y mencionas qué proveedores quieres. Solo quiero AWS. Y su origen es HashiCorp slash AWS. Y puedes estar pensando, ¿qué es eso en el mundo? Llegaremos a eso en un segundo. Además, solo voy a escribir una regla para este proveedor. Y es que estaré en la región EU central uno. Porque estoy en
5. Trabajando con Proveedores y Función Lambda
Short description:
HashiCorp, la compañía detrás de Terraform, tiene un registro similar a NPM. Este registro proporciona módulos que te permiten interactuar con varios proveedores de la nube, incluyendo AWS. Puedes describir de forma declarativa tu infraestructura utilizando estos módulos. Para nuestra función Lambda, buscaremos en la documentación y utilizaremos un ejemplo básico. Realizaremos algunos cambios en los valores, como el nombre del archivo, el nombre de la función y el rol de IAM. El controlador se establecerá en index.handler.
Berlín. Voy a guardar esto. Ahora, ¿qué es este proveedor? Bueno, HashiCorp, la compañía que desarrolla Terraform, tiene un registro. Esto es literalmente como un registro de NPM. Y así que estoy diciendo, ve a ese registro y obténme este módulo. Es como un módulo de nodo. Y este módulo te permite comunicarte con AWS. Ahora, estos proveedores literalmente pueden comunicarse con cualquier backend, Azure, Google Cloud, o lo que sea. Conectan Terraform a la API de algúncloud proveedor y te permiten describir de forma declarativa tu infraestructura. Así que estamos trabajando con Lambda. Así que busquemos en la documentación la función Lambda. Eso es lo que quiero. Y esto es realmente solo desarrollo basado en copiar y pegar. Así que voy a copiar todo este ejemplo básico aquí. ¡Vaya! Tengo problemas con los trackpads. Vale. Así que voy a copiar todo esto y pegarlo aquí. Esta es una regla que nos permite trabajar en AWS con Lambda. Así que la dejaré tal cual. Y voy a cambiar algunos de estos valores aquí. El nombre de mi archivo de mi paquete de implementación es bundle.zip como puedes ver. No me importa el nombre de la función. Y este rol lo estoy accediendo desde aquí. Así que puedes ver que el nombre del recurso es AWS IAM role. Y el nombre del recurso que le doy, o el ID, es IAM4Lambda. Así que es awsiamrole.iam4lambda.arn, los roles son un identificador. El controlador es index.handler, porque el controlador es el exportado
6. Configurando Lambda y API Gateway con Terraform
Short description:
Necesitamos agregar memoria y un tiempo de espera más largo a nuestra función Lambda. Además, requerimos una capa para la versión de Chrome que estamos utilizando. Al copiar el ARN de esta capa, podemos importarla sin enviar todo el código y los módulos de nodo. Con Terraform, podemos hacer que nuestra función Lambda y nuestra API Gateway existan. Terraform descargará las dependencias necesarias y creará la infraestructura. La API Gateway es esencial para la comunicación segura con la función Lambda. Terraform apply creará un plan y generará los recursos necesarios.
const. Entonces index.handler. Y, sí, no necesitamos esto. Pero lo que sí necesitamos, ni siquiera necesitamos el entorno. Lo que sí necesitamos es más memoria. Vamos a agregar eso. Vamos a darle un tiempo de espera más largo. Y por último, necesitamos una capa. En Lambda, las capas son como módulos de NPM. Y hay una para la versión de Chrome que estamos utilizando. Así que voy a copiar el ARN de esta capa. Y eso nos permitirá importarla sin enviar realmente todo ese código, todos esos módulos de nodo con nosotros. Ok, así que tenemos una Lambda. Vamos a intentar hacer que exista con Terraform. Así que haré terraform init. Y esto... es como NPM install, básicamente. Va a ir al registro y va a descargar eso. Y una vez que descargue eso, podemos hacer que la infraestructura real de AWS suceda. Mientras se descarga eso, como vimos en la presentación, no es suficiente con que alguien se comunique directamente con una Lambda. Necesitamos una API Gateway. Así que mapeémosla rápidamente. Así que necesitamos una API Gateway. Si conoces la API Gateway de AWS, hay algunos conceptos aquí. No tengo tiempo para entrar en ellos, pero están todos en la documentación, lo prometo. Así que solo npm install. Eso es genial. Hagámoslo existir. Haremos terraform apply, y eso mapeará nuestro archivo declarativo aquí a cosas reales de AWS. Creará un rol y una Lambda. Entonces lo que ha hecho aquí es crear un plan. Esto
7. Creando API y Componentes Requeridos
Short description:
Vamos a hacer que la infraestructura exista y crear los componentes necesarios para nuestra API. Comenzaremos con el recurso de la API y le daremos un nombre. Luego pasaremos a los otros componentes requeridos, como el recurso, el método, la integración y las implementaciones. Por último, solucionaremos el problema de no poder llamar a la API configurando la configuración necesaria.
El plan va a crear cosas. Va a crear un rol. Puedes verlo con un signo más y algunas cosas solo se conocerán después de que existan. Y va a crear una función. Sabes, esto se ve bien para mí. Voy a decir sí, cualquier otra cosa que no sea sí, será rechazada. Y va a ir y hacer que la infraestructura exista. Muy, muy emocionante. Y puedes ver que se está creando aquí. De todos modos, volvamos a planificar. Necesitamos una API. Necesitamos un recurso. Necesitamos un método. Necesitamos una integración. Y luego necesitamos métodos raíz e integraciones raíz. Sí, es un poco complicado jugar con las APIs. Y luego necesitamos implementaciones. Necesitamos un permiso de invocación para tener la API, como invocar la Lambda. Y por último, estos son los componentes que necesitamos. Puedo acelerarlos, pero están en la caja. Es solo copiar y pegar. Así que podemos decir que se crearon nuestras cosas. Solo que aún no podemos llamarlo porque no tenemos una API. Vamos a solucionar eso. Así que empecemos con la API. Lo que voy a hacer es, voy a crear un recurso, AWS API Gateway REST API. Ese es el nombre del recurso. Y puedo darle el nombre que quiera. Así que simplemente lo llamaré API y el nombre es el que yo quiera. Entonces
8. Creando Recurso en AWS API Gateway
Short description:
Necesitamos crear un recurso en la puerta de enlace de la API de AWS para nuestra devolución de imágenes. El recurso tendrá un ID de API REST, un ID de recurso y una parte de la ruta. La parte de la ruta va a redirigir todo, desde la barra diagonal hasta la integración. Este es un script especial para AWS.
simplemente llámalo API. Es una descripción, que no me importa realmente. Y esto es importante porque vamos a devolver una imagen. Por lo tanto, los tipos de medios binarios son un comodín para todo. También necesitamos un recurso. Y el recurso es solo una cosa en un paquete. Entonces AWS API Gateway recurso. Boom. Y lo llamaremos RES, supongo. Y, ya sabes, necesita un ID de API REST, que es el ID de nuestra API REST recién creada. Necesita un ID de recurso, lo siento, necesita un ID de padre por ese ID de padre y pondremos el ID de recurso raíz aquí. Y necesita una parte de la ruta. Y esto es lo que vamos a hacer aquí, esto simplemente dice redirigir todo, desde la barra diagonal hasta cualquier integración.
9. Creando Método e Integración para API Gateway
Short description:
Necesitamos un método para la puerta de enlace de la API de AWS. Requiere un ID de API REST, un ID de recurso, un método HTTP y autorización. A continuación, configuramos la integración, lo cual implica especificar el ID de API REST, el ID de recurso, el método HTTP y los detalles internos para la comunicación con la función Lambda. Por último, copiamos y pegamos los comandos de integración, reemplazando los ID de recurso por el ID de recurso raíz. Luego creamos una implementación para nuestra API y le otorgamos permisos.
lo tienes. Es solo un script especial para AWS, pero eso es todo lo que necesitamos. Y luego necesitamos un componente. Así que puerta de enlace de la API, perdón, no componente, método. AWS API Gateway. Necesitamos un método. Podemos llamarlo met. Y ya sabes, nuevamente, necesita un ID de API REST, necesita un ID de recurso, que es el ID de nuestros nuevos recursos. Entonces, dot res dot ID. Necesita un método HTTP en el que trabajar, y necesita saber si tiene alguna autorización, que en nuestro caso no la tiene. Bien, es hora de la integración. Entonces puedes ver, son solo un montón de comandos. Llamaremos a esto int. Y lo mismo, necesita un ID de API REST. Necesita un ID de recurso. Necesita un método HTTP, pero usaremos el método HTTP de nuestro método. Bien, y luego necesita algunas cosas internas para cuando se comunique con la Lambda internamente. Entonces necesita un método HTTP de integración, y va a comunicarse con la Lambda en post, aunque reciba un get. Será un proxy interno de AWS a otro componente de AWS, que es Lambda. Y la URI de esto es nuestra función Lambda llamada test Lambda. Es su URI. Entonces test Lambda dot invoke ARN. Bien. Y básicamente vamos a copiar y pegar estas dos cosas aquí abajo y reemplazar los ID de recurso por los ID de recurso raíz. Entonces el ID de recurso aquí va a ser el ID de recurso raíz. Eso se mantendrá igual. Y este ID de recurso también va a ser eso. Bien. Eso es prácticamente todo. Ahora solo tenemos que crear una implementación de nuestra API, darle permisos y listo. Así que haremos resource AWS API deploy,
10. Configurando Integración y Permisos
Short description:
Esta sección se centra en configurar la integración y otorgar permisos. Se asignan nombres únicos a las integraciones y se establece un nombre de etapa como 'dev'. Se obtiene el ID de la API REST de la API REST creada previamente. Los permisos se otorgan utilizando el recurso permiso de lambda. Las cadenas codificadas en duro de la documentación de Amazon se pueden copiar y pegar. Se especifica el nombre de la función, el principio y el ARN de origen. Se obtiene el ARN de ejecución de la API REST y se agregan comodines de subruta. Se crea una salida llamada 'endpoints' con el valor del ARN de invocación de la implementación.
Implementación de la puerta de enlace de la API de AWS. Lo llamaremos DEP. Y esto va a ser realmente interesante porque depende de nuestras integraciones. Y hablando de eso, vamos a darles nombres únicos aquí. Así que tenemos la integración int y la integración int root. Entonces int y luego .introot. De acuerdo. Necesita un nombre de etapa, que llamaremos dev. Y hay una barra diagonal cuando accedemos a ella. Y por último, necesita el ID de la API REST, que, si volvemos a donde creamos la API REST, podemos hacerlo, .api.id. De acuerdo. Por último, necesitamos otorgarle permisos. Así que haremos recurso permiso de lambda. Exactamente. Lo llamaremos perm. Mira, tenemos autocompletado. Esto se escribe solo. Sin embargo, hay un montón de cadenas codificadas en duro aquí, que provienen de la documentación de Amazon. Así que sí, simplemente puedes copiar y pegarlas. El nombre de la función es el nombre de nuestra función de arriba, que es this.testlambda.function.name. El principio es apigateway.amazon.aws.com. Y por último, nuestro ARN de origen. Entonces, quién va a llamar a esto? Así que iremos a la implementación aquí. Y obtendremos, lo siento, no la implementación, iremos a la API REST, mi error. La API REST. Exactamente. Y obtendremos el API.executionARN. Pero quiero agregar algunos comodines de subruta a esto. Así que voy a interpolar esta cadena con eso. Y por último, hagamos una salida, llamémosla endpoints. Y su valor será
11. Despliegue de Infraestructura y Verificación del Despliegue
Short description:
Ahora, aplicaremos esta infraestructura y veremos qué sucede. Ya hemos creado la lambda, así que solo creará todo lo adicional. El plan es desplegar y, con suerte, obtener una URL con una captura de pantalla de la ruta predeterminada. Podemos probar diferentes URL y funcionará. Eso es todo. Acabamos de desplegar una gran cantidad de infraestructura de AWS Lambda con un archivo de texto. Y si queremos, también podemos desactivarlo fácilmente.
será nuestro ARN de invocación de las implementaciones. Entonces, el nombre de la implementación es deck.invokeURL. De acuerdo. Así que eso no es mucho. Ahora, aplicaremos esta infraestructura y veremos qué sucede. Ya hemos creado la lambda. Así que no va a crear eso. Solo creará todo lo adicional. Por lo tanto, mostrará en tiempo real las diferencias. Y como puedes ver, tiene 8 cosas que agregar. Y es solo un montón de esto. Entonces, este es el plan. Si lo veo y se ve bien, diré que sí. Y literalmente lo desplegará por nosotros. Y al final, con suerte, obtendremos una URL aquí arriba. Si abro esta URL, ¿qué tenemos? Con suerte, tenemos una captura de pantalla de la ruta predeterminada de My Screen Shotter, que es Google. Genial. Y luego, si hacemos una URL, probemos con nodecongress.com. Deberíamos tener un puesto de trabajo, por favor. De acuerdo, lo tenemos. Podemos volvernos locos, podemos hacer esto todo el día. Tenemos g2i.co. Podemos hacer mi sitio web personal. Así que funciona. Eso es todo. Acabamos de desplegar una gran cantidad de infraestructura de AWS Lambda con un archivo de texto. Y si queremos, también podemos desactivarlo fácilmente. Solo hago esto. Digo que sí. Este sí es muy importante, porque puede fallar en cualquier lugar.
12. Conclusiones y Debate del Sándwich
Short description:
Acabamos de desplegar infraestructura de Node.js sin salir de nuestro editor, lo que permite la colaboración, escalabilidad y fácil destrucción y recreación. Cuatro conclusiones clave: los procesos mecanizados y automatizados son mejores que los manuales, el estado efímero es preferible al estado duradero, los procesos repetibles son superiores a los raros y la transparencia es mejor que una caja negra. Gracias por su tiempo. Discutamos el debate del sándwich en el canal de Discord de la comunidad.
Pero hago eso, y boom. Ya no existe, pero podría aplicarlo de nuevo, y luego vuelve a existir. Así que volvamos a la presentación. Acabamos de desplegar infraestructura de Node.js sin salir de nuestro editor de una manera en la que nuestro equipo pueda colaborar, escalar, destruir y recrear según sea necesario. Esto es el poder de la infraestructura es buena. Hablemos de las conclusiones. Realmente, tengo cuatro conclusiones para ustedes. Quiero que recuerden cuando salgan de esta charla, quiero que recuerden MERT. Específicamente, los procesos mecanizados, los procesos automatizados, tienden a ser siempre mejores que los procesos manuales, porque son cosas que se pueden repetir, iterar y mejorar, y no hay que adivinar. El estado efímero tiende a ser mejor que el estado interno o el estado duradero, porque el estado duradero puede corromperse, puede acumular obsolescencia, mientras que algo que se borra y se actualiza, y sigue siendo lo mismo, tiende a ser más puro. Los procesos repetibles tienden a ser mejores que los procesos raros, porque, nuevamente, son procesos que se pueden automatizar, iterar y probar, lo más importante. Por último, la transparencia es mejor que la turbidez, es decir, el software abierto, el software de código abierto, las implementaciones abiertas, la infraestructura abierta, tienden a funcionar mejor que una caja negra de la que no tienes idea de cómo funciona, para la escala y para los equipos. Así que con eso, solo quiero agradecerles mucho por su tiempo. Sí, hola, ¿cómo va? Estoy decepcionado. Entonces, ¿cuál es tu opinión al respecto? ¿Por qué es un sándwich? Sabes, es pan. Es una cosa en el pan. Como, sabes, si pongo tofu en el pan, es un sándwich de tofu. No lo entiendo. Sí, no entiendo esto. Sí, es importante discutirlo, pero es realmente extraño que la gente diga que no lo es. Así que, si tienes otra opinión, explícanosla en el canal de Discord de la comunidad. Pero sí, lo siento, acordamos en no estar de acuerdo.
QnA
Desarrolladores versión 2.0 y la necesidad de DevOps
Short description:
Los desarrolladores versión 2.0 pueden tener algo de experiencia en la nube, pero pueden no tener la profundidad de un experto a tiempo completo en DevOps. Siempre es útil tener expertos en tu equipo para manejar los detalles específicos.
Pero ahora, pasemos a las preguntas de nuestra audiencia. Y la primera pregunta que me gustaría que respondas es de Java Task. Entonces, cuando tenemos desarrolladores versión 2.0, ¿todavía necesitamos DevOps? Sí, ¿puedes repetir eso? ¿Desarrolladores 2.0? Tenemos desarrolladores versión 2.0, ¿necesitamos DevOps? No lo creo. Suponiendo que los desarrolladores versión 2.0 significa, como, una versión mejorada del desarrollador que hace cosas en la nube, creo que sí, definitivamente. Porque, quiero decir, no hace daño tener a alguien... Siento, sabes, Spotify como empresa hace un trabajo realmente bueno con este tipo de diagrama en forma de T de experiencia. Entonces, puedes tener una experiencia amplia o puedes tener una experiencia profunda, pero a menudo no puedes tener toda la experiencia. Y así, si me considero tal vez un desarrollador 2.0, hago algunas cosas en la nube. También hago algo de front y algo debackend, pero no creo que tenga la profundidad de un experto a tiempo completo en DevOps hardcore. Ni siquiera lo afirmaría. Y así, podría arruinar fácilmente las cosas si no tengo cuidado. Por lo tanto, sería útil, definitivamente, tener a alguien que tenga la profundidad que yo no tengo. Sí, siempre es útil tener expertos en tu equipo y conocer los detalles específicos. Y es bueno si puedes ayudar un poco y tal vez dar como, no puedo encontrar la palabra en inglés para start. Sí. Eso es, eso es básicamente. Sí.
Terraform y Cambios Incrementales
Short description:
Terraform es para tu infraestructura, literalmente como React es para tu interfaz de usuario. Es simplemente esta cosa declarativa que es capaz de detectar cambios y luego solo cambiar lo que describiste que debería cambiar. Es como recargar en caliente tu infraestructura. Eso es bastante hardcore.
Estoy de acuerdo. Así que estamos de acuerdo nuevamente, dos puntos. La siguiente pregunta es de cyberFox 909, ¿puedo invitarte a una bebida? Lo siento, creo que estamos haciendo una broma. La siguiente pregunta es de cyberFox 909. Si hago algún cambio en el archivo de Terraform, que generalmente cambiará la infraestructura, ¿se vuelve a realizar todo el proceso de construcción, o solo cambia el componente que se está modificando? Sí, esa es una buena pregunta. Así que hablé de esto brevemente en mi charla, pero tiendo a balbucear, así que tal vez se perdió. En realidad, sé que hay algunos desarrolladores frontend en la sala. Es bastante genial porque Terraform es para tu infraestructura, literalmente como React es para tu interfaz de usuario. Y lo que eso significa es que es simplemente esta cosa declarativa que es capaz de detectar cambios y luego solo cambiar lo que describiste que debería cambiar. Por ejemplo, si creas un disco de dos gigas a ocho gigas en AWS, nada más en mi infraestructura cambiará. No reconstruirá todo. Solo hará un cambio incremental acumulativo. Es como recargar en caliente. Sí, exactamente. Es como recargar en caliente tu infraestructura. Eso es bastante hardcore. Eso es, para un desarrollador frontend, suena bastante genial.
Costo de las Funciones Serverless
Short description:
El costo de implementar una función serverless como esta depende de la demanda. Con Lambda, solo pagas cuando se invoca y por el tiempo y la memoria que utiliza. Los precios son mínimos y si nadie lo usa, no pagas nada. Por lo tanto, el costo variará según el uso. Si bien no es costoso, un aumento repentino en el uso puede generar una factura más alta.
Otra pregunta de Bruce. ¿Cuánto costaría al mes esta demostración en particular que has dado? Esa es una excelente pregunta, y sabes, me alegra que Bruce haya preguntado. Creo que esto se cubrirá en la charla de mañana sobre las funciones serverless. En este caso, implementamos una función serverless, y creo que son la mejor manera y la más económica, y simplemente la forma más inteligente económicamente de implementar cosas. Porque no pagas nada si no se usa. Por ejemplo, normalmente, si trabajas con una VM o una instancia EC2 en la cloud, o incluso si haces un clúster de Kubernetes, estarás pagando por esas máquinas solo por estar encendidas. Ya sea que las personas las usen o no. Pero con una Lambda, con una función como esta, si nadie la usa, no pagas nada. Pagas cada vez que se invoca y pagas por el tiempo que tarda en hacer su trabajo, y pagas por la cantidad de memoria que utiliza para hacer su trabajo. Y esos precios son mínimos. Por lo tanto, realmente depende de - para responder a la pregunta, ¿cuánto costaría esto? Depende de la demanda. Por ejemplo, si ahora, después de esta charla, todo el mundo va y usa esta Lambda, podría tener una factura razonable, pero en general, no es tan caro. Bueno, tenemos 12,000 personas viendo, así que podríamos arruinarte. Oh, no. Todos ahora.
Infraestructura multiinquilino utilizando Terraform
Short description:
El orador no puede responder la pregunta sobre la infraestructura multiinquilino utilizando Terraform y sugiere aclarar la pregunta o continuar la discusión en el chat espacial.
La siguiente pregunta es de Ghost1m. ¿Qué nos recomienda tener una infraestructura multiinquilino utilizando Terraform? ¿Recomendaría una infraestructura multiinquilino? ¿Qué nos recomienda? No sé cómo responder esa pregunta. ¿Qué les recomendaría tener multiinquilino? Lo siento, no entiendo la pregunta. Bueno, Ghost1m, si puedes aclarar un poco mejor tu pregunta, entonces podríamos tener tiempo para volver a ella. O estaré en el chat espacial. Hay una sala completa donde podemos pasar el rato y hablar todo el día.
Terraform Registry y Módulos Reutilizables
Short description:
Existe un equivalente a los paquetes NPM de los módulos de Terraform llamado el Terraform Registry. Proporciona conexiones a servicios externos y tiene adaptadores para casi todos los proveedores de la nube. Sin embargo, personalmente no he explorado los módulos reutilizables ya que no he tenido la necesidad de utilizarlos.
La siguiente pregunta es de bkankal. ¿Hay una biblioteca de código abierto de módulos reutilizables de Terraform que recomendarías? Esa es una buena pregunta. En mi charla, mostré el Terraform Registry, que es básicamente el registro de NPM, pero para cosas de la nube. Entonces, existe un equivalente a los paquetes NPM de los módulos de Terraform. En realidad, no son realmente módulos. Son más bien conexiones a servicios externos. En cuanto a un registro de módulos, no estoy seguro. Realmente no uso nada predefinido porque, como acabamos de ver en la charla, me siento bastante cómodo copiando y pegando desde el registro. Pero el registro en sí tiene adaptadores para casi todos los proveedores de la nube que puedo encontrar. Incluso tienen cosas para Heroku. Y creo que también para Digital... Es simplemente, es completo. Pero en cuanto a los módulos reutilizables, no los he investigado porque no he tenido la necesidad personalmente. Esa también es una respuesta que no sé si es una respuesta.
Thoughts on CloudFormation, CDK, and Terraform
Short description:
He utilizado CloudFormation pero no me gustó. Terraform es TypeScript primero, lo cual es genial para mí como ingeniero de TypeScript. No está bloqueado por proveedor a AWS, por lo que puedo usarlo para Azure, Google Cloud, etc. La mejor manera de comenzar con Terraform es ver mi charla y implementar una cosa de nodo como una Lambda.
La siguiente pregunta es de Tom. ¿Qué opinas sobre CloudFormation de AWS versus CDK de AWS versus Terraform? Esa es una excelente pregunta. He utilizado CloudFormation. Y quiero ser respetuoso y amable, pero no me gustó para nada. Lo encontré tedioso. Lo encontré excesivamente verboso. Y lo encontré... Hay muchas formas diferentes de escribir un archivo de CloudFormation, según mi experiencia. Lo escribiría y luego alguien me diría que hiciera algo diferente. No parecía muy sólido. No he trabajado específicamente con CDK de AWS, pero Terraform está creando... Creo que se llama CDKTS, algo así. Lo cual es... Estoy muy emocionado por esto. Porque sigue en principio los mismos principios de CDK de AWS. Pero Terraform es TypeScript primero. Y para mí, como ingeniero de TypeScript, esto es oro. Porque no tengo que aprender este otro lenguaje, HCL, para escribir mis archivos de Terraform. Literalmente puedo escribir TypeScript y obtener autocompletado perfecto en todo. Y luego simplemente genera una configuración de Terraform. Entonces, si CDK de AWS tiene TypeScript de serie, también lo utilizaría. Pero para mí, el valor de Terraform es que no está bloqueado por proveedor a AWS. Podría escribir un archivo de Terraform para Azure, para Google Cloud, para lo que quiera. Y eso es para mí el valor ahí.
De acuerdo, gracias. La siguiente pregunta es de Dan G. ¿Cuál es la mejor manera de comenzar con Terraform? Mira mi charla. Creo que honestamente podrías escribir algo de nodo y desplegarlo como Lambda. Esa es una excelente manera de comenzar. Y luego realmente seguir desde ahí.
Getting Started and Converting Infrastructure
Short description:
Para comenzar, es mejor leer detenidamente la documentación. Convertir la infraestructura existente a código puede ser complicado y aún no he encontrado una forma de hacerlo. Podríamos clonar todo y cambiar a Terraform. En cuanto a escribir lambdas sin Babel y con tree shaking, depende del tiempo de ejecución. AWS Lambda admite hasta Node 14 y requiere empaquetar con herramientas como Webpack o Rollup.
Creo honestamente que esa es la mejor manera de comenzar. Si no tienes acceso a mi charla, por cualquier motivo, la forma en que aprendí la mayoría de las cosas, Terraform, Kubernetes, Docker, lo que sea, React, simplemente abro la documentación y leo cada palabra de principio a fin. Y luego pienso, está bien, más o menos entiendo la idea principal. Así que esa también es una opción. Lo cual lleva mucho tiempo. Sí, pero vale la pena. Es una inversión, ¿verdad? Sí, sí, sí, claro.
De acuerdo, la siguiente pregunta es de Tazi. ¿Podemos convertir una infraestructura existente a código o necesitamos configurar una infraestructura completamente nueva y migrar? Sí, eso es complicado. Así que, sabes, espero no estar violando ningún acuerdo de confidencialidad o algo así, pero en el lugar donde trabajo, no tenemos una gran infraestructura en forma de código. En su mayoría ha sido manual, pero es algo hacia lo que nos estamos moviendo. Algo que nos gustaría hacer y aún no he encontrado, he estado pensando si podemos, ya sabes, tomar nuestro flujo manual existente y usar los servicios existentes pero mapearlos a los recursos de Terraform. Aún no he encontrado una forma de hacerlo. Me gustaría hacerlo, pero creo que lo que vamos a hacer es clonar todo lo que tenemos en un archivo de Terraform y luego simplemente cambiar si llega a eso. Pero sí, la respuesta es que aún no he encontrado una forma de hacerlo, aunque me gustaría tenerla. Así que si sabes algo, avísame en el chat especial. Genial.
Tenemos otra pregunta de Java task. ¿Podemos usar Node 14 y ES6 modules para escribir lambdas sin Babel y con tree shaking? Esta es una gran pregunta, porque se trata de definir una lambda, ¿verdad? Y si una lambda es solo una función, entonces sí, puedes escribirla como quieras. Puedes escribirla en Python. Claro, pero las funciones que se ejecutan, se ejecutan en un runtime. Y siento que la respuesta a esta pregunta es depende, depende del runtime. ¿Puede tu runtime manejar ES 2018 nativo o cualquier versión de ES que quieras escribir? Y AWS Lambda, hasta donde puedo decir, no puede. Admite hasta Node 14, creo, como máximo que tiene algunas características modernas. Pero los verdaderos desafíos, ya sabes, la carga de empaquetar tu lambda recae en ti. Así que no puedes simplemente importar lo que quieras con npm. Y enviar un archivo JavaScript plano a Lambda. Tendrías que usar Webpack o Rollup o algo así. Sí.
Maintaining CICD Pipelines and Version Control
Short description:
En cuanto al control de versiones de los archivos fuente de la infraestructura, como los archivos de Terraform, se pueden incluir en el control de versiones para la colaboración. Sin embargo, el archivo de estado, que contiene valores sensibles, no debe incluirse. En su lugar, se recomienda utilizar una herramienta como Terraform Cloud. Es gratuita para hasta cinco usuarios y se puede conectar a un repositorio de GitHub para facilitar la gestión.
De acuerdo. Es algo que debes tener. Oh, olvidé la palabra. Empaquetado, sí.
Tenemos tiempo para una pregunta más. Es una pregunta de Novorf. Hablando de infraestructura como código, ¿cuáles son tus experiencias hasta ahora con el mantenimiento de los pipelines de CI/CD como archivos fuente bajo control de versiones? ¿Tienes alguna solución favorita? ¿Puedes hacer la pregunta de nuevo? Hablando de infraestructura como código, ¿cuáles son tus experiencias hasta ahora con el mantenimiento de los pipelines de CI/CD como archivos fuente bajo control de versiones? ¿Tienes alguna solución favorita? Me cuesta entender la pregunta, pero la responderé lo mejor que pueda. Si se trata del control de versiones de los archivos fuente de la infraestructura, como estos archivos de Terraform. Puedes, quiero decir, obviamente el punto de un archivo de Terraform es que puedes incluirlo en el control de versiones y colaborar en él. Pero en cuanto a incluir y versionar específicamente el archivo de estado, porque lo que hará Terraform es gestionar el estado de tu infraestructura y hacer un seguimiento de eso. Lo mejor es no incluirlo en el control de versiones porque contiene valores sensibles, contraseñas y cosas así. Así que mi solución para incluir y versionar eso es no hacerlo, sino usar algo como Terraform Cloud, que es generosamente gratuito para hasta cinco usuarios. Y para nosotros, no tenemos más de cinco personas que trabajen con Terraform. Así que simplemente lo conectamos a un repositorio de GitHub y todo está solucionado.
De acuerdo, genial. Así que tenemos más preguntas que han llegado al canal de preguntas y respuestas, pero no tenemos más tiempo. Así que para las personas que han estado haciendo preguntas, pueden unirse a Dajez en su sala de chat espacial de oradores, ¿a dónde vas ahora, verdad? Sí, eso es correcto. Muy bien, Dajez. Quiero agradecerte mucho por esta increíble sesión de preguntas y respuestas y espero verte de nuevo en algún lugar de la vida real, tal vez algún día. ¡Genial! Gracias por tu buen trabajo como maestro de ceremonias.
