Infraestructura como Código para Aplicaciones React en AWS Escritas en TypeScript

Genial. Sí, como dije, ahora vamos a hablar de infraestructura como código. Pero antes, permítanme presentarme y darles un poco de contexto sobre por qué lo necesitamos. ¿Qué está pasando? Genial. Mi nombre es Denys Artyukhovic. Soy el líder del equipo en The Zone. Originalmente, soy de Bielorrusia, pero ahora estoy basado en Londres. Y en The Zone, estamos cambiando todos los aspectos de cómo los fanáticos se involucran con los deportes, desde la distribución de contenido hasta una experiencia verdaderamente inmersiva en tiempo real donde puedes ver datos aumentados para las transmisiones de video. Estamos disponibles en más de 200 países y en varios tipos de dispositivos, incluidos televisores inteligentes, tabletas, computadoras portátiles y, por supuesto, Xbox, PS5 y otras consolas de juegos. Y creo que puedes imaginar la cantidad de infraestructura que tenemos. Y mi equipo ha construido características que son multiplataforma. Están disponibles en la web y en los televisores. Entonces, la respuesta ahora, probablemente sea obvia, pero consideremos el flujo normal de desarrollo de sus aplicaciones. Comenzamos con una característica, o digamos un servicio, luego una nueva y brillante idea llega al escenario y tenemos una característica más, y luego boom, cientos de ellas. Y en nuestro caso, podemos esperar cambios en nuestra infraestructura incluso varias veces al día, y creo que puedes imaginar lo estresante que podría ser si todo fuera manual, porque necesitas replicar algunos cambios manuales, ¿y qué pasa si algunos de los desarrolladores olvidan actualizar la documentación? ¿O qué pasa si la interfaz de usuario misma ha cambiado en nuestro proveedor de la nube, como AWS, y hacemos clic en la casilla de verificación incorrecta y Facebook no está disponible durante unas horas? Así que puede ser realmente estresante, ¿verdad? Para evitar esta situación y solucionar este problema y nunca tener un problema así, nuevamente, necesitamos aprovechar la infraestructura como código. Pero antes de comenzar a hablar sobre la infraestructura en sí, consideremos estos dos paradigmas de programación, ya que son bastante relevantes cuando hablamos de codificación para la infraestructura. Por un lado, tenemos el enfoque imperativo, que se basa en instrucciones explícitas para todo literalmente. Por lo general, nos referimos a algunos scripts de shell, y de hecho, la instrucción explícita es la mayor ventaja de este enfoque. Pero al mismo tiempo, es la mayor preocupación, porque debes mantener todo tú mismo y no es realmente escalable a lo largo del tiempo. Por otro lado, tenemos el enfoque declarativo, que se basa en describir el resultado y dejar que el proveedor haga el resto del trabajo, lo cual es mucho más fácil y mejor para escalar. Entonces, sí, nuevamente, con el enfoque imperativo, eres inteligente y siempre culpas al sistema de que no funciona como esperas, porque escribiste tantas líneas de código. Cuando con el enfoque declarativo, simplemente no te importa hasta que los proveedores inteligentes se encarguen de todo por ti. Y la buena noticia es que Terraform, en realidad, es un software de código abierto. ¿Quién ha trabajado con Terraform antes? Permítanme hacer esta pregunta primero. Sí. Ok. Algunas personas. Increíble. Entonces, Terraform es un software de código abierto que fue desarrollado originalmente por HashiCorp, y admite miles de proveedores diferentes, y nos permite administrar nuestra infraestructura con código, y lo que es más importante para hoy es que también admite TypeScript. O mejor dicho, CDK, que significa

Y lo primero que podemos necesitar es almacenamiento, ¿verdad? Necesitamos almacenar nuestra aplicación en algún lugar. No sé cuántos de ustedes han trabajado con buckets de S3 en AWS, pero es solo un simple servicio de almacenamiento que tiene una gran disponibilidad, 99.99%, lo cual es genial, pero para nosotros, lo importante es que lo vamos a usar para almacenar nuestros activos estáticos, ¿de acuerdo? Entonces, para esto, podemos importar el proveedor de AWS y el bucket de S3. Esa va a ser una infraestructura simple que puedes imaginar, y es muy sencilla. Como va a estar lista para producción, más adelante planeo conectar un dominio real y por eso creo que podemos llamar al bucket con el nombre del dominio solo porque es más explícito. Vamos a crear un proveedor. Puedes usar cualquier región que prefieras. Yo voy a usar US-East-1. Solo un dato, para tu bucket, por ejemplo, puedes usar una región europea y EU Central-1, lo que sea. Eso está perfectamente bien, pero ACM, que vamos a usar para los certificados SSL más adelante, requiere la región US-East-1. No tiene nada que ver con cómo codificamos la infraestructura, solo está relacionado con cómo AWS opera. Ellos lo necesitan en sus requisitos. Si vas a crear otra región, simplemente crea la segunda más adelante para ACM. Genial. Estamos creando el bucket de S3, pasando solo el nombre del bucket, pasando el proveedor. Estamos diciendo que será un sitio web con index.html como documento raíz. También estamos especificando la lista de control de acceso como lectura pública, porque ¿a quién le importa la seguridad? Estoy bromeando, lo arreglaremos más adelante. Por ahora, déjalo como público. Tan pronto como hagas estos cambios, solo necesitas construirlos y ejecutar el comando YARN syns

Entonces, ¿todo lo que nos mostraste son cosas que también usas en Dazone? Sí, claro, en realidad, la mayoría de nuestras infraestructuras se crean por supuesto con Terraform, pero usamos Azure Corp Configuration Language en lugar de TypeScript, estamos comenzando a adoptar TypeScript, pero como dije, todavía está en fase beta, por lo que debes tener cuidado con esto y debes tener en cuenta las preocupaciones relacionadas con la mantenibilidad si hay cambios significativos relacionados con ello, así que debería ser una llamada de atención.

Eres una empresa global y cualquier cambio es un gran cambio, supongo que es realmente difícil probar cosas a tu escala. Sí, absolutamente, quiero decir, estamos disponibles para millones de clientes en todo el mundo, por lo que para nosotros es cada vez más crucial automatizar todo lo que podamos y documentarlo bien con código, así que pongámoslo así.

Bien, como no tenemos más preguntas en este momento, creo que terminaremos la sesión de preguntas y respuestas o actualizaré si ha habido alguna pregunta en el ínterin. Si recibo algún data. Disculpen a todos los que estaban en línea y tuvieron problemas de audio, no fue desde mi computadora portátil, algo sucedió. Sí, se solucionó en los primeros minutos. Mi data es realmente mala aquí en Londres. Y necesito moderar las preguntas antes de que aparezcan allí y allá. Oh, no te preocupes. Y no tengo data. Pero, sí, Deniz, muchas gracias. Y pasaremos al siguiente ponente entonces. Sí, muchas gracias. Así que todos, un aplauso más para Deniz.