Infraestructura como Código con enfoque en Node

¡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

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

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

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í.

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.

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.

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.

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í.

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í.

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.