24

¿Qué es Serverless? Breve historia del inicio de una revolución

7624Puntos

hace un año

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.

¿Qué es Serverless?

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

Breve historia sobre Servidores y Web Apps

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 😻)

1.png

Algunas de las preguntas o problemas a resolver fueron las siguientes:

  • ¿Cómo puedo evitar fallos en mis sistemas cada que hago actualizaciones?
    • Respuesta: diseñar componentes pequeños e independientes de fácil actualización.
  • ¿Cómo asegurar la escalabilidad de mi plataforma?
    • Respuesta: componentes pequeños y que se puedan replicar en muchos servidores a la vez y de forma redundante.
  • ¿Cómo mejoro el rendimiento de la plataforma y que mis usuarios no perciban altos tiempos de carga?
    • Respuesta: componentes pequeños que me ayuden a descentralizar la carga, las estrategias de caché se logran fácilmente sobre componentes pequeños. Claramente la velocidad de internet de cada usuario impacta de forma significativa, pero eso es tema de otro blog.

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 🤔

2.png

Interesante. Pero, ¿cómo entra Serverless en todo esto? Bueno sigamos en la historia (acelero un poco para hablar de lo importante).

1. REST: “La revolución”

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.

3.png

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 🧑🏽‍💻

2. ¿Cómo se relacionan los servidores en la nube y Serverless?

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.

4.png

¡Bueno, basta de memes! ¿Cómo podría desplegar estos pequeños bloques de código en la nube?

Existen múltiples opciones como:

  • Configurar un servidor virtual, instalar las herramientas necesarias y ejecutar mi app.
  • Usar servicios de contenedores auto-gestionados por el Cloud Provider.
  • O mejor aun, solo subiendo tu código y que la nube se encargue de todo 🚀🪄🔮🎩.

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!

5.png

Hablemos de Serverless en AWS

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:

  • Persistencia/Almacenamiento: DynamoDB, Aurora Serverless, S3.
  • Backend: ECS Fargate, Lambda Functions, Step Functions.
  • Frontend: S3, CloudFront, Amplify.

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.

6.png

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.

7.png

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.

Conoce más de Serverless en Platzi

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:

Yor
Yor
yorjaggy

7624Puntos

hace un año

Todas sus entradas
Escribe tu comentario
+ 2
Ordenar por:
4
7414Puntos

Excelente publicación, me aclaró algunos conceptos que tenía incompletos

2

Excelente blog, muy claro, divertido incluso! 👌
En este entorno tecnológico tenemos muchísimo potencial, infinidad de opciones de aprendizaje.