La tecnología avanza rápidamente. O tal vez simplemente parece que avanza rápidamente porque están apareciendo nuevos movimientos, enfoques y arquitecturas por todas partes. Este mes, el repentino ascenso de las arquitecturas “sin servidor” ha cobrado protagonismo en el flujo de Twitter y en la conciencia de todos. Al menos si estás en el mundo Dev/Ops.
Para aquellos de ustedes que se preocupan por la infraestructura, la arquitectura de red y las operaciones y no han sido inundados con esta nueva arquitectura, es una progresión lógica que precede de monolito -> microservicios -> arquitecturas sin servidor. Es un desglose adicional de las aplicaciones desde uso comercial -> servicio -> función.
Literalmente, se trata de funciones. Funciones de grano fino controladas por eventos.
Y cada uno se centra en un alcance de lógica de aplicação aún más pequeño que un microservicio. Mientras que un microservicio puede contener toda la lógica de aplicação necesaria para implementar un “servicio de perfil”, la arquitectura sin servidor lo desglosa en funciones individuales. Uno para iniciar sesión, uno para cerrar sesión, uno para cambiar su contraseña, uno para restablecerla. Básicamente, es como crear un servicio pequeño y específico para cada acción que puedas realizar dentro de una aplicación.
La razón por la que se denomina “sin servidor” es porque es básicamente una forma muy evolucionada de PaaS. Lo cual es bueno para PaaS, porque como mercado, PaaS nunca llegó a convertirse en el gigante que esperaba ser. Simplemente se queda ahí, recibe elogios de los fanboys que lo aman, pero en general se lo ha ignorado y crece a un ritmo que no es tan emocionante como el de la nube privada o pública, y ciertamente no como el de SaaS. En una arquitectura sin servidor, el proveedor de nube es responsable de todo excepto del código necesario para hacer algo cuando un usuario presiona un botón, una casilla de verificación o hace clic en un enlace. Esa es la parte del evento “controlado por eventos”: cuando el usuario presiona el botón, se ejecuta function_in_the_cloud . Esa función generalmente es parte de una API más grande que es administrada por otro servicio en la nube.
Lo importante aquí es que la persona que escribe la función no aprovisiona, configura ni inicia una máquina virtual o un contenedor. No se preocupan por detalles operativos como la escala. Simplemente escriben un poco de código y con solo hacer clic en un botón, ¡voilá! Funcionalidad instantánea.
Esto es la nube llevada a su extremo máximo, ya que los desarrolladores ahora son responsables de reducir la pila a una sola capa: la capa de aplicação . Nada más importa, como diría Metallica. La plataforma subyacente proporciona todos los detalles operativos. Es NoOps, o al menos desde la perspectiva del desarrollador.
Porque sabes que hay servidores, servicios, infraestructura y una red bajo la plataforma que proporciona esta capacidad mágica. Simplemente no es algo de lo que el desarrollador deba preocuparse. Pero usted, como profesional de operaciones de infraestructura o de red, sí lo hace.
Es por eso que es poco probable que las empresas se sumen a esta tendencia por un tiempo. Una hazaña de este tipo requiere un entorno de computación en la nube completamente operativo que incorpore no solo capacidades de aprovisionamiento de máquina virtual o contenedores, sino también escalabilidad automática . En otras palabras, escalar sin parámetros ni aportaciones de los desarrolladores. Debería suceder, maldito seas, y eso es todo. No es autoservicio, es autoservicio . No es sólo escala, también es aprovisionamiento automático. Y seguimiento, y elaboración de informes, y prácticamente todo lo relacionado con las operaciones actuales. Es por esto que lo estamos viendo principalmente en entornos de proveedor de nube bien establecidos; solo ellos tienen la infraestructura subyacente, la automatización y la orquestación necesarias para respaldar un modelo operativo en gran medida de no intervención.
Por lo tanto, actualmente la mayor parte de la atención en el ámbito sin servidor se centra en probarlo y descubrir cómo trabajar con las encarnaciones actuales disponibles en la nube: Amazon Lambda , Google Cloud Functions , Microsoft Azure Functions y IBM OpenWhisk . No es que no existan ofertas para ayudar a las implementaciones locales, como Serverless y Iron.io. Pero por ahora, estamos en las primeras etapas de la tecnología sin servidor.
Aún así, probablemente comenzarás a escuchar rumores sobre la tecnología sin servidor. Por el momento, son en gran medida solo los motores de una nueva arquitectura que se están poniendo en marcha. Es poco probable que afecte a la mayoría de las organizaciones en el corto plazo (durante los próximos 12 a 15 meses), pero es bueno comprender de qué se trata antes de que llegue a las instalaciones locales.
NewStack ofrece una excelente descripción general si desea obtener más información sobre servidores sin servidor y los beneficios y desafíos actuales.