TL,DR: Vas a encontrar un walkthrough sobre la historia que nos llevó a construir apps cada vez más pequeñas, pasando desde SOAP en grandes servidores, hasta funciones lambda en la nube.
Para empezar debemos entender que es Serverless. En este blog te damos una definición corta y precisa del concepto, sin embargo hay mucho más por aclarar.
Serverless es un término en inglés que significa ‘sin servidores’, lo cual implica que no necesitas configurar servidores. No tenemos que preocuparnos por el disco duro, la memoria, la CPU, el sistema operativo, ni nada asociado a servidores. Nos concentramos únicamente en el código, la funcionalidad y los triggers de esta.
Aunque, claramente, esta lógica se ejecuta en un servidor, no somos responsables de configurarlo, gestionarlo o actualizarlo. El Cloud Provider lo hace por nosotros. 🚀
Comencemos con un poco de historia. Hace unos años, la mayoría de las aplicaciones eran monolitos: robustas, grandes y centralizadas. Solían configurarse en servidores On-Premise. En su momento, esto no representaba ningún problema para los negocios, e incluso en la actualidad, algunas empresas, como StackOverflow, aseguran tener un monolito totalmente funcional 😮.
Sin embargo, algunas empresas o celebridades de la escena Tech comenzaron a cuestionarse si esa era la mejor forma de construir tecnología. Fue entonces que llegaron a nosotros más recursos, dudas y problemas por resolver (eso es lo que siempre tenemos en Tech, problemas por resolver 😻)
Algunas de las preguntas o problemas a resolver fueron las siguientes:
En algunas de esas preguntas y respuestas teníamos indicios de que las cosas apuntaban a componentes pequeños y desacoplables que nos permiten actualizar, crecer, escalar, mantener y mejorar el rendimiento de cualquier plataforma casi sin dolor 🤔
Interesante. Pero, ¿cómo entra Serverless en todo esto? Bueno sigamos en la historia (acelero un poco para hablar de lo importante).
Después logramos descentralizar aplicaciones y podíamos tener múltiples componentes en diferentes servidores. Aquí usábamos SOAP y apenas estábamos conociendo de Rest, ¡y este último lo cambió todo! 😮
Con Rest teníamos forma de estandarizar muchos aspectos, ya que internamente usamos métodos de un protocolo bien conocido como HTTP, y así mismo otras bondades de este. Incluso logramos tener una sintaxis para intercambiar objetos de forma más fácil y legible con JSON (XML también se usa, pero 😣…), entre otras bondades.
Pero, ¿y cómo entra Serverless en todo este tema? Paciencia, paciencia. Hay que entender la historia para no repetirla, o al menos no repetirla totalmente. ¡Aceleremos!
Luego, teníamos otros problemas como el famoso “funciona en mi local” que rompió muchos ambientes productivos y ahí surgieron nuevas herramientas como lo son Docker, ContainerD, DockerSwarm, K8s, entre otros.
Todo esto no es resultado de la invención de algún niño gurú en tecnología, es simplemente iteración sobre lo que ya conocíamos, como los Linux Containers (LXC), pero de contenedores y orquestadores podemos hablar luego. Lo interesante de los contenedores es que nos dieron más alas para construir apps más pequeñas, distribuibles y asi mismo compatibles para múltiples ambientes.
Hasta este punto muchos de los problemas que teníamos de escalabilidad, rendimiento, agilidad de desarrollo pueden ser solucionados construyendo pequeños bloques de código y desplegando a nuestros servidores On-Premise en contenedores 🧑🏽💻
Y tu pregunta sería, ¿y si mejor los desplegamos a la nube?
¡Excelente que lo mencionas! Hablemos del maravilloso mundo del cómputo en la nube o Cloud Computing.
¡Bueno, basta de memes! ¿Cómo podría desplegar estos pequeños bloques de código en la nube?
Existen múltiples opciones como:
Esta última suena a magia, pero no lo es. Aquí es donde entra Serverless, que es una de las nuevas (no tan nuevas) estrategias para construir aplicaciones desacopladas, granulares, asíncronas, mediante pequeños bloques de código o aplicaciones de única responsabilidad (Single Responsability).
Prácticamente con Serverless logramos articular los diferentes componentes de una aplicación haciendo uso de los servicios autogestionados por nuestro Cloud Provider, sea AWS, GCP, Azure, etc.
Es decir, ¿podría construir y lanzar el frontend, el backend y mis bases de datos solo con un par de clicks; y el proveedor escala, gestiona y mantiene todos los recursos por mi?
Ding Ding Ding! 🛎️ ¡Correcto!
AWS como Cloud Provider tiene múltiples servicios netamente Serverless. En otras palabras, no tenemos que configurar ninguna capa de servidor, solo de parámetros de alto nivel como nombres, regiones, disponibilidad y dependiendo del recurso algún parámetro especial para agregar mayor resiliencia y escalabilidad a nuestro sistema.
Por ejemplo:
No logro entender cómo sería una plataforma completa en Serverless 😳👉🏽👈🏽
No hay problema, en Platzi estamos para compartir lo que sabemos, y lo que estamos aprendiendo 💚. En el siguiente diagrama puedes ver un ejemplo de las tres capas mencionadas anteriormente y cómo podrían interactuar entre ellas.
Ejemplo de aplicación usando Servicios Serverless en AWS (Frontend, Backend, Persistencia y almacenamiento)
El caso de uso podría ser una aplicación web estática la cual se puede alojar en S3 y servir mediante CloudFront como capa de CDN, esta se comunicaría con nuestro backend, el cual dispone un API Gateway para validar lógica de negocio, seguridad y demás aspectos en cada request. Finalmente, este nos permite exponer nuestras funciones Lambda para ser consumidas como cualquier otra Rest API.
Nuestra capa de persistencia y almacenamiento estaría compuesta de servicios como DynamoDB, una DB NoSQL para servicios de alta transaccionalidad y de uno o múltiples Buckets de S3, los cuales nos permiten almacenar archivos de cualquier tipo (jpeg, mp4, mp3, json, etc).
Notarás que tenemos otros servicios de AWS, estos serán de gran ayuda para comunicación asíncrona entre lambdas (SQS, SNS) evitando así cuellos de botella y dependencias entre componentes, CloudWatch para gestión de nuestros logs y alertas. Finalmente System Manager y Secret Manager para gestión de variables de entorno y secretos o información sensible para nuestra aplicación.
Pero esto puede costar mucha plata, mi empresa/startup no tiene tanto presupuesto ☹️
Calma, guardamos lo mejor para lo último. AWS tiene una capa de servicios gratis (AWS Free Tier) hasta cierta cantidad de consumo, es decir, solo si sobrepasan ciertos límites AWS genera cobro, en caso contrario no deberías preocuparte por tu app o plataforma ya que podría ser hosteada totalmente gratis o al menos con un bajo costo.
AWS Free Tier: capa de servicios gratuitos durante 12 meses.
Es decir AWS solo generara cobro, cuando de verdad tengas un alto tráfico o alto consumo. Y si ya tienes un alto tráfico o multiples usuarios accediendo a tu plataforma es por que tu producto o aplicación se está consumiendo/vendiendo y generando ingresos o flujo de caja, en caso contrario 😳😊 te invitamos a plantear una estrategia de monetización atractiva para tus usuarios e inversores que te permitan inyectar capital a ese proyecto tan increíble que tienes en mente.
Suena excelente pero, ¿cómo comienzo? 🤓💚
Lo primero es conocer el ecosistema de AWS y sus herramientas Serverless, luego puedes aprender de funciones lambda y bases de datos como DynamoDB.
Puedes comenzar con el blog de Introducción a Serverless Framework y los diferentes cursos de Serverless que Platzi tiene para ti:
Déjanos saber en el Discord → #cloud si tienes alguna duda y lo más importante:
¡Sé como una lambda Function y nunca pares de crecer!
Links:
Excelente publicación, me aclaró algunos conceptos que tenía incompletos
Excelente blog, muy claro, divertido incluso! 👌
En este entorno tecnológico tenemos muchísimo potencial, infinidad de opciones de aprendizaje.
AMAZING
Que buen post!
Muy bueno el blog 🔥