Introducción a las tecnologías Serverless

Introducción a tecnologías Serverless

Las tecnologías y aplicaciones Serverless están de moda ¡y no es para menos! Permiten a los desarrolladores y equipos IT centrarse en las necesidades de Negocio. Además, nos prometen reducción de costes frente a arquitecturas tradicionales y con un respaldo implícito del proveedor de nube pública. Pero, ¿son todo ventajas?

Puedes seguir leyendo o puedes empezar por ver este video resumen de introducción a las tecnologías Serverless.

Qué es Serverless

La mejor forma de entender de verdad qué es Serverless es con el siguiente tweet de Kelsey Hightower, ingeniero en Google Cloud.

Como ya hemos mencionado, y como nos recuerda Kelsey, el punto fuerte de Serverless es el enfoque a “lo que nos interesa”, es decir, nuestra aplicación, servicio, producto o caso de Negocio.

Tradicionalmente, el concepto Serverless ha estado relacionado con ciertos servicios de computación que los proveedores de nube nos ofrecen y con los que únicamente debemos preocuparnos de subir el código a su plataforma. A partir de ese momento, la gestión de ese servicio en este entorno recae en el proveedor y permite que nuestra organización solo dedique esfuerzo en mejorar esa aplicación, servicio o producto.

Últimamente el concepto está evolucionando, y algunos servicios de nube pública gestionados (no necesariamente relacionados con computación) también están pasando a ser parte del mundo Serverless. Por ejemplo, ciertos servicios de bases de datos gestionadas, herramientas para desarrolladores, servicios de analítica de datos y otros…

Si nos centramos por el momento en servicios Serverless de computación como AWS Lambda o Google Cloud Functions, nos interesa entenderlos desde dos puntos de vista.

Modelo operacional

Algo esencial que debe cumplir cualquier servicio denominado Serverless es que no requiere una gestión de servidores por parte del usuario/cliente. El usuario se abstrae de la capa que aloja y corre su aplicación y se limita únicamente a desplegar su código.

Otra característica fundamental de estos servicios es el denominado pago por uso. Estos servicios escalan a cero las instancias o servidores que alojan nuestra aplicación cuando no se está haciendo uso de ella. De ese modo no se genera un coste cuando no se está usando.

Además nos proveen de una capa de seguridad completamente gestionada a nivel de acceso.

Modelo de programación

El uso de estas tecnologías Serverless se orienta a un enfoque basado en servicios. Servicios, a priori, independientes y que realizan tareas concretas y perfectamente acotadas.

Además, estos servicios tienden a estar dirigidos por eventos. Por ejemplo una llamada HTTP, un evento personalizado recurrente o la subida de un fichero a un repositorio de binarios que desencadena la puesta en marcha de nuestra aplicación (si no lo estaba) y ejecutará la tarea implementada en ese servicio.

Modelos Serverless

Niveles de servicio y responsabilidad compartida

Aunque últimamente hemos visto aparecer distintos niveles de servicios como FaaS (Function as a service) o CaaS (Container as a service), complementando y detallando a los tradicionales, vamos a mantener el enfoque de los tres niveles más importantes.

En el nivel de Infraestructura (IaaS) nos vamos al nivel más bajo que el proveedor de nube pública nos puede ofrecer. “Alquilamos” instancias de máquina virtual con recursos asignados y que viven cierto entorno customizable. A partir de ahí, todo lo que no tenga que ver con el propio hardware y los niveles más bajos de almacenamiento y red, será responsabilidad nuestra actualizarlos, securizarlos y tener unos procedimientos y/o metodologías de actuación.

En el nivel de Plataforma (PaaS) únicamente subimos nuestro código a un entorno controlado o hacemos uso de un servicio gestionado, y no deberíamos preocuparnos de nada más que de tener unos procedimientos de seguridad a nivel de aplicación y despliegue. Serverless estaría en este nivel.

En el nivel de Sofware (SaaS) estamos adquiriendo una solución completa. En este nivel nuestra responsabilidad únicamente recae en el uso del servicio, contenido o políticas de acceso.

Responsabilidad compartida Serverless

Este concepto es quizá el más importante a la hora de plantear alternativas de solución a un problema determinado. La responsabilidad adquirida según al nivel que vayamos puede variar enormemente y, por supuesto el no conocerlo, no implica en ningún caso que no estemos contrayendo dicha responsabilidad.

Desde que partimos de una fase de ideación a la puesta en marcha de una aplicación en un entorno productivo, es probable que los requerimientos cambien, sin embargo un factor que debemos tener muy claro desde el comienzo, es el alcance de la misma.

Puede ocurrir que, si esto no estuviese claro desde el comienzo del proyecto, sintamos la tentación de asumir que un enfoque o solución a nivel Infraestructura (IaaS) puede ser “más o menos” igual de costoso que una arquitectura Serverless dado que al fin y al cabo estamos usando servicios de nube pública de configuración similar. Si no analizamos esto con cuidado puede ocurrir que un posible éxito de nuestra aplicación sea la peor pesadilla del equipo.

Las soluciones Serverless nos garantizan que el proveedor de nube asume una alta responsabilidad que nosotros podemos exigir. De ese modo impactará, no sólo en la posible dificultad de nuestras soluciones, si no en los equipos de operaciones que deberíamos tener si fuésemos a arquitecturas IaaS.

Pero Serverless no es la respuesta a todo y, en cualquier caso, siempre podrán existir requerimientos de Negocio que nos hagan descartar estas soluciones desde el primer momento.

Pros y contras

El punto fuerte de las tecnologías serverless es la reducción de tiempo y coste para nuestro equipo o empresa. Por lo general, un enfoque serverless nos permitirá ahorrar en costes dado que los recursos “se apagarán” cuando no hagamos uso de ellos y por lo tanto no pagaremos por ese tiempo de inactividad.

Por otra parte, el hecho de no tener que realizar un gran esfuerzo en una fase de implantación de arquitectura provocará que nuestra solución esté lista en menor tiempo, por lo que nuestro time to market tenderá a ser menor.

Si bien vemos una mejora en costes y tiempos, hay que ser conscientes que el denominado “pago por uso” no debe considerarse una buena práctica por sí misma.

El escalado a cero es un “trade-off” o compromiso donde vamos a penalizar en algún aspecto a cambio de un beneficio. En este caso, el hecho de tener nuestras aplicaciones apagadas cuando no las usamos no es algo positivo por sí solo. De hecho, pueden existir multitud de casos de uso donde esto sea una pesadilla para el equipo y para la propia experiencia del usuario final.

Cabe recordar que, en muchas ocasiones, estos servicios vienen acompañados por entornos de trabajo o “frameworks” que debemos usar y que pueden llegar a ser difícilmente portables a otros proveedores y por tanto siempre asumiremos un riesgo implícito al hacer uso de ciertas tecnologías Serverless.

Pros y contras de tecnologías Serverless

No Ops fears

Sin duda, el principal mensaje que nos debería quedar es el de oportunidad y de no tener miedo a hacer usos de estas tecnologías. Es increíble el enorme portfolio de servicios y tecnologías que tenemos a nuestra disposición (desde bases de datos de entorno mundial a servicios de reconocimiento de voz) que estarán cubiertos por SLAs y que nos ahorran costosos equipos operacionales para ciertas aplicaciones.

Hemos de insistir en que hay que ser críticos con este tipo de “soluciones universales”. Los servicios serverless nos serán útiles, y mucho, y deberíamos prestarle una especial atención y pensar en ellos a la de idear cualquiera de nuestras soluciones.

—–

Las tecnologías Serverless no son sólo el futuro si no el presente de multitud de equipos de IT de todo el mundo que tienen siempre en cuenta estas tecnologías a la hora de construir sus productos y servicios.

Si quieres saber más sobre Serverless sigue atento/a, continuaremos contándote y analizando el día a día de las tendencias de este mundo en nuestro blog.

Imagen: pexels | djordje petrovic

Cloud Architect en Keepler. "Aprendiz de por vida e interesado en el cloud computing y las tecnologías públicas cloud. Ingeniero con amplia experiencia en desarrollo backend y habilidades en técnicas de machine learning. Apasionado por aprender y resolver problemas del mundo real. Disfruto del trabajo en equipo colaborativo, compartiendo conocimientos y creando productos increíbles."

Port Relacionados

¿Qué opinas?

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.