Phenquestions
Computadoras físicas
Hemos recorrido un largo camino desde los servidores masivos de la era de las puntocom. En aquellos días, la infraestructura del servidor era principalmente local. Una empresa ejecutó sus soluciones en un servidor físico. Las personas usaban servidores completamente separados para diferentes propósitos (copias de seguridad, servidor de correo, servidor web, etc.). Cuando un determinado servidor no pudo mantenerse al día con las crecientes necesidades de la empresa, fue reemplazado por un servidor más nuevo y más rápido. Escalaste obteniendo un mejor hardware. Escalaste verticalmente.
Hipervisores
Luego vino la era de los hipervisores. Cobró impulso con el auge de VMWare y la gente se dio cuenta de que pueden conseguir un bastidor para gobernarlos a todos. Un bastidor para ejecutar todos los casos de uso y proporcionar a cada uno de ellos su propia máquina virtual separada. Esto también dio lugar a la computación en la nube y las empresas dejaron de invertir en hardware de servidor, directamente, y optaron por 'alquilar' servidores virtuales.
Los centros de datos enormes y costosos fueron administrados por proveedores de la nube en todo el mundo. Las empresas aprovecharon esto al brindar sus servicios a nivel mundial, utilizando la mayor variedad posible de centros de datos. Esto se hizo principalmente para reducir las latencias, mejorar la experiencia del cliente y apuntar a un mercado más grande.
Esto también hizo que los autores de software pensaran en términos de sistemas distribuidos. Escribieron software para que no se ejecutara en una sola computadora gigante, sino en muchas mediocres de manera consistente y confiable. Escalaste horizontalmente.
Todavía puedes escalar verticalmente. De hecho, gracias a la virtualización, el aprovisionamiento de más recursos se volvió más fácil. Apagó la máquina virtual, ajustó sus recursos y pagó un poco más a su proveedor de nube. Pedazo de pastel.
Los servidores físicos subyacentes no han desaparecido. Los proveedores de la nube ahora son responsables de administrar las complejidades de las interfaces de red, la compatibilidad del sistema operativo y otras patologías aterradoras.
Contenedores
Luego vinieron los contenedores. Los contenedores eran esta asombrosa abstracción ligera. Un entorno virtual con un sistema operativo que permitía empaquetar e implementar el software como una sola unidad. Al igual que las máquinas virtuales, cada contenedor no se dio cuenta de otros contenedores, pero compartieron el mismo kernel del sistema operativo.
Esto permitió a las personas implementar software en servidores (físicos o virtuales, no importa) con un nivel de abstracción aún mayor. No te importaba el sistema operativo de producción. Siempre que sea compatible con su tecnología de contenedorización, ejecutará su software. Además, los contenedores son más fáciles de poner en marcha, lo que hizo que los servicios fueran más escalables que nunca.
Esto aumentó aún más la flexibilidad de los sistemas distribuidos. Con tecnologías como Kubernetes, puede tener legiones de contenedores que ejecutan una gama compleja de servicios. Los sistemas distribuidos ofrecen una gran cantidad de beneficios: alta disponibilidad, solidez y la capacidad de recuperarse de una falla en el nodo.
Al mismo tiempo, debido a su complejidad, también son más difíciles de diseñar, implementar, mantener, monitorear y depurar. Esto va en contra de la tendencia original de abstraer la complejidad de su software y delegar esa responsabilidad a su proveedor de nube. Aquí es donde entra en juego la arquitectura sin servidor.
Sin servidor o función como servicio (FaaS)
La idea de la tecnología sin servidor ha ganado fuerza principalmente gracias a AWS Lambda, y aquí la usaré como modelo para hablar de la tecnología sin servidor. Los principios en los que se basa FaaS son:
- Pagas por lo que usas
- No tienes que preocuparte por escalar
- Usted se concentra en su código, deja la administración de la infraestructura a AWS
Cuando nadie accede a sus servicios, los servicios no están activos. Este no era el caso en las soluciones de alojamiento tradicionales en las que paga por un VPS que siempre está en funcionamiento, incluso si está inactivo sin hacer nada más útil que escuchar una nueva solicitud.
En la arquitectura sin servidor, su servicio no se está ejecutando a menos que alguien realmente quiera usarlo. Cuando llega una solicitud, se crea un servicio sobre la marcha para manejarla.
Como funciona?
Su función (por ejemplo, un programa Python, Go o Java) se encuentra como un archivo en AWS Lambda. Con esta función, asocia ciertos eventos desencadenantes, como una puerta de enlace de API o un nuevo objeto que ingresa a su depósito de S3. Y ciertos recursos como una base de datos u otro almacén de objetos o una instancia EC2.
En respuesta a cualquiera de los eventos desencadenantes asociados, AWS Lambda crea un contenedor con su función dentro. La función se ejecuta y da una respuesta. Por ejemplo, si entra una nueva imagen en su bucket de S3, AWS Lambda puede tener un código de aprendizaje automático dentro, que analizaría esta imagen y escribiría su salida en un DynamoDB (uno de los servicios de almacén de datos de AWS).
No tiene que pagar por un servidor completo, sino solo por la cantidad de memoria que asignó a su función, la cantidad de solicitudes que recibe y por cuánto tiempo se ejecuta su función.
Además, no tiene que preocuparse por escalar contenedores en respuesta a una gran carga de trabajo entrante. Si se producen muchos eventos desencadenantes simultáneamente, AWS se encargará de poner en marcha nuevos contenedores y programar las cargas de trabajo entre ellos y todas las demás complejidades.
No es una solución completa
Cuando aparecieron las máquinas virtuales, los servidores físicos no dejaron de existir. Cuando llegaron los contenedores, todavía usábamos máquinas virtuales. FaaS es una abstracción de nivel superior y encaja muy bien con el diseño moderno de API RESTful, servicios sin estado y lenguajes ligeros como Node.js o Python.
Sin embargo, aún se ejecuta en un servidor físico (administrado por AWS, por ejemplo), aún escucha las solicitudes entrantes (simplemente no paga por eso directamente) y aún necesita almacenar datos de manera persistente, por lo que ha integraciones para S3, EC2 y otros servicios. No obstante, es una abstracción útil.
