...

Context

Serverless es una tendencia en Arquitectura Software que reduce la noción de infraestructura permitiendo que los desarrolladores no tengan que preocuparse por el balanceo de carga, el multihilo y otros temas de infraestructura y centrarse únicamente en su código ya que la propia plataforma Serverless gestiona los recursos.

A Serverless aun le queda camino para ser una tecnología usada de forma generalizada, pero a su vez, como hemos avanzado, ofrece numerosas ventajas para las organizaciones al proporcionar un modelo de programación simplificado para crear aplicaciones en la nube abstrayendo la mayoría de las preocupaciones operativas por lo que no es aventurado decir que acabará definiendo la forma en que las organizaciones desarrollan, despliegan e integran sus aplicaciones.

Ventajas e inconvenientes de una Arquitectura Serverless

A Serverless aun le queda camino para ser una tecnología usada de forma generalizada, pero a su vez, como hemos avanzado, ofrece numerosas ventajas para las organizaciones al proporcionar un modelo de programación simplificado para crear aplicaciones en la nube abstrayendo la mayoría de las preocupaciones operativas por lo que no es aventurado decir que acabará definiendo la forma en que las organizaciones desarrollan, despliegan e integran sus aplicaciones.

Ventajas Modelo Serverless

• No más gestión de servidores: Aunque la computación "Serverless" se hace en servidores, los desarrolladores no tienen que preocuparse por su existencia en el momento del despliegue de la aplicación ya que el proveedor lo gestiona de forma automática, lo que disminuye la inversión requerida en DevOps y el tiempo que los desarrolladores se toman para construir y ampliar sus aplicaciones. Las aplicaciones ya no estarían limitadas por la capacidad del servidor o la potencia de cálculo.

• Backend de pago por uso: Al igual que con un plan de datos de "pago por uso" en el que sólo se factura por la cantidad de datos consumidos, en la computación Serverless, sólo se factura cuando se ejecuta el código de la aplicación. El código de la aplicación sólo se ejecuta cuando las funciones del backend se ejecutan en respuesta a un evento y este se autoescala según la demanda y el aprovisionamiento sigue siendo dinámico, preciso e instantáneo.

• Computación Serverless = Escalabilidad: Las aplicaciones sin servidor aumentan y reducen su tamaño según la demanda, esto permite a las aplicaciones pasar de cientos de instancias de computación a una sola y viceversa en cuestión de segundos para adaptarse a curvas de demanda complejas. Los proveedores de la computación Serverless emplean algoritmos para iniciar, ejecutar y finalizar esas instancias según sea necesario (en muchos casos utilizando contenedores). En consecuencia, las aplicaciones Serverless pueden manejar millones de solicitudes concurrentes o una sola solicitud con el mismo rendimiento.

• Despliegues y actualizaciones más rápidas: La infraestructura sin servidor no necesita complicadas configuraciones de backend para que una aplicación funcione. Una aplicación Serverless es una colección de funciones gestionadas por el proveedor en lugar de un gran bloque monolítico inmanejable de código. A la hora de lanzar actualizaciones, parches y correcciones, los desarrolladores sólo tienen que alterar las funciones afectadas. Asimismo, se pueden añadir nuevas funciones para reflejar una nueva característica de la aplicación.

• Las localizaciones permiten reducir la latencia: Las aplicaciones Serverless no se alojan en el servidor de origen, sino en varias ubicaciones de la infraestructura del proveedor, de modo que en respuesta a la demanda, la ubicación más cercana activa el evento y la función, esto reduce la latencia porque ahora las solicitudes no tienen que ir hasta un servidor de origen.

• La computación sin servidor permite reducir el coste para la mayoría de los casos de uso: Las arquitecturas Serverless son más eficientes para reducir los costes de las aplicaciones con un uso desigual. Si la aplicación alterna periodos de gran actividad con instancias de poco o ningún tráfico, el alquiler de espacio en el servidor por un periodo de tiempo fijo no tendrá sentido. Pagar por un espacio de servidor disponible y siempre en funcionamiento no es rentable cuando sólo se va a utilizar durante una fracción del periodo de alquiler.

Desventajas del modelo Serverless

Pero “nadie es perfecto” y como sucede con el modelo de microservicios, la computación Serverless no es adecuada para todos los casos de uso y además su uso genera otras complejidades.

• Cargas de trabajo prolongadas: si tus aplicaciones necesitan ejecutar cargas de trabajo prolongadas (como procesos Batch que ocupan 12 horas diarias, vídeo bajo demanda o entrenamiento de modelos) en los que las aplicaciones estarían funcionando la mayor parte del tiempo la computación Serverless no será práctica y su coste será mayor en el proveedor Cloud que provisionando infraestructura.

• Dependencia de la red: construir una aplicación sobre una Arquitectura Serverless implicará en muchas ocasiones flujos de eventos que llaman a funciones que se comunican exclusivamente a través de protocolos de red estándar, lo que significa que un corte de red o una interrupción de cualquier tipo (a menudo fuera del control) interferirá con las operaciones de negocio. Y, a medida que aumenta el número de funciones desplegados, también lo hace el riesgo de una interrupción de la red, poniendo en peligro uno de estos servicios.

• Latencia: Por otro lado, la red también implica que se introduce latencia en el sistema, y eso hay que tenerlo en cuenta.

• Sobrecarga en la gestión: Con una Arquitectura Serverless, se divide un producto en una red de funciones más pequeñas. Como resultado, hay una sobrecarga que se crea en la gestión de estas funciones, que es un motivo por el que muchas organizaciones no están preparadas para adoptar plenamente los microservicios y menos las funciones.

• Dependencias: Imaginemos cientos de componentes de aplicaciones que dependen de una función con un contrato establecido (especificación de la API). Y ahora imaginemos que el equipo de microservicios quiere rediseñar (o incluso modificar ligeramente) su especificación. La organización no sólo debe coordinar este cambio entre equipos, sino que también debe hacer un seguimiento de quién depende de quién en todo momento.

• Contratos estrictos: en relación con el punto anterior, los desarrolladores deben tener cuidado de definir una especificación de API de la función lo suficientemente robusta como para proporcionar valor de negocio mucho después del lanzamiento inicial. Este tipo de previsión es poco frecuente, si no imposible en algunas organizaciones.

• Orquestación: en muchos escenarios será necesario orquestar diversas funciones para componer un servicio de negocio. No todos los proveedores lo soportan y entre los que lo soportan cada proveedor ha optado por una solución para esto.

• Transaccionalidad: el proceso de negocio que orqueste las funciones tendrá que gestionar las compensaciones antes un problema en la ejecución de una función.

• Demasiado fácil crear una función: Esto podemos catalogarlo como una fortaleza pero también como una debilidad. La capacidad de desplegar e incorporar funciones de forma tan sencilla puede llevar a un exceso de funciones.

Offering Serverless

Los principales proveedores de la nube ya tienen ofertas sobre este paradigmaServerless. Además de las ofertas de Amazon Web Service y Microsoft Azure, la computación Serverless es un mercado prometedor para todos los proveedores de computación en la nube y las principales tecnologías de desarrollo de aplicaciones (como Spring) le dan soporte.

...

Offering Serverless

...

Diferenciación

...

AWS Lambda

...

is a trend in Software Architecture that reduces the notion of infrastructure allowing developers to not have to worry about load balancing, multithreading and other infrastructure issues, so that they focus only on their code, since the Serverless platform itself manages the resources.

Advantages and disadvantages of a Serverless Architecture

Serverless still has some way to go to be a widely used technology, but at the same time, as progress has been made, it offers many advantages for organizations by providing a simplified programming model to create applications in the cloud, abstracting most of the operational concerns. so it is safe to say that it will eventually define the way in which organizations develop, deploy and integrate their applications.

Advantages of the Serverless Model

• No more server management: Although "serverless" computing is done on servers, developers do not have to worry even about their existence at the time of application deployment, since the provider manages that automatically, thus reducing the investment required in DevOps and the time developers require to build and extend their applications. Applications would no longer be limited by server capacity or computing power.

• Pay-as-you-go backend: As with a "pay-as-you-go" data plan where you are only billed for the amount of data consumed, in serverless computing, you are only billed when the application code is executed. Application code is only executed when backend functions are executed in response to an event, and the event autoscales on demand, and provisioning remains dynamic, accurate, and instantaneous.

• Serverless Computing = Scalability: Serverless applications scale up and down on demand, allowing applications to go from hundreds of compute instances to one, and back again, in seconds, to accommodate complex demand curves. Serverless computing vendors employ algorithms to start, run, and terminate those instances as needed (in many cases using containers). Consequently, serverless applications can handle millions of concurrent requests, or one single request, with the same throughput.

• Faster deployments and updates: Serverless infrastructure does not require complicated backend configurations for an application to work. A serverless application is a collection of vendor-managed functions rather than one large, unmanageable, monolithic block of code. When releasing updates, patches, and fixes, developers only have to alter the affected features. Besides, new functions can be added to reflect a new feature of the application.

• Locations help reduce latency: Serverless applications are not hosted on the origin server, but rather in multiple locations on the provider's infrastructure, so that, in response to demand, the closest location triggers the event and function. This reduces latency because requests now don't have to go all the way to an origin server.

• Serverless computing helps reduce cost for most use cases: Serverless architectures are more efficient at reducing costs for applications with uneven usage. If the application alternates periods of high activity with instances of little or no traffic, renting space on the server for a fixed period of time makes no sense. Paying for always-on, available server space, is not profitable when it will only be used for a fraction of the rental period.

Disadvantages of the Serverless model

And yet, “no one is perfect” and as with the microservices model, serverless computing is not suitable for all use cases, and besides, its use also creates other complexities.

• Long workloads: If your applications need to run long workloads (such as batch processes that take twelve hours per day, video on demand, or model training) where the applications would be running most of the time, serverless computing will not be practical and its cost will be higher in the Cloud provider than it would be provisioning infrastructure.

• Network Dependency: Building an application on a Serverless Architecture will often involve event streams calling functions that communicate exclusively over standard network protocols, meaning that a network outage or interruption of any kind (often out of our control) will interfere with business operations – and, as the number of deployed features increases, so does the risk of a network outage, jeopardizing any of these services.

• Latency: On the other hand, the network also implies that latency is introduced into the system, and that must be taken into account.

• Management overload: With a Serverless Architecture, a product is divided into a network of smaller functions. As a result, there is an overload that is created in managing these functions, which is the reason why many organizations are not ready to fully embrace microservices, let alone functions.

• Dependencies: Let's imagine hundreds of application components that depend on one single function with an established contract (API specification) – and now let's imagine that the microservices team wants to redesign (or even slightly modify) their specification. The organization must not only coordinate this change across teams, but also keep track of who reports to whom at all times.

• Strict contracts: Related to the previous point, developers should be careful to define a function API specification that is robust enough to provide business value long after the initial release. This kind of forecasting is rare, if not impossible, in some organizations.

• Orchestration: In many scenarios, it will be necessary to orchestrate various functions to compose a business service. Not all providers support it and, among those that do support it, each provider has opted for a solution for this.

• Transactionality: the business process orchestrating the functions will have to manage compensations to a problem in the execution of a function.

• Too easy to create a function: We can classify this as a strength, but also as a weakness. The ability to deploy and incorporate features so easily can lead to an excess of features.

Serverless Offering

The main cloud providers already have offers on this serverless paradigm. In addition to offerings from Amazon Web Service and Microsoft Azure, serverless computing is a promising market for all cloud computing providers, and is supported by leading application development technologies (such as Spring).

Actualmente, Amazon es líder en esta computación capturando más del 80% de la cuota de mercado en 2020 y Microsoft está en segundo lugar.

Análisis elección tecnología Serverless en Onesait Platform

A continuación, se recoge un resumen del análisis que se ha realizado en Plataforma para la elección de la tecnología Serverless más adecuada a incorporar/soportar en Plataforma.

...

Independencia Cloud: Como se puede ver en la imagen uno de los mantras de Onesait Platform es poder trabajar con las diversas nubes, además de hacer compatibles las arquitecturas en Cloud y On Premise. Estas consideraciones arquitecturales no recomendaban el uso de tecnologías propietarias como AWS Lambda, Azure Functions o Google Functions que salvo en escenarios muy concretos implican la ejecución en la Cloud del proveedor.

...

Despliegue sencillo/nativo en los proveedores Cloud: Por otro lado, aunque se busque la independencia de las Cloud está clara la apuesta de Plataforma por el Cloud, incluyendo el ofrecimiento en modo SaaS de la plataforma. Por tanto, la tecnología Serverless seleccionada debería poder desplegarse de forma sencilla, incluso nativa en los principales proveedores Clouds.

...

Soportar Despliegue On Premise: y aunque nuestra apuesta por el Cloud es clara, no podemos olvidar que aún seguimos teniendo muchos proyectos y productos en Plataforma desplegados en los CPDs de los clientes (y que muchos de estos grandes clientes tienen su propia estrategia de Cloud privada) lo que nos obliga a asegurar que esta tecnología pudiera desplegarse On Premise.

...

Tecnología Open-Source: Onesait Platform es un software open-source publicado en github bajo licencia Apache2 y al que el equipo de producto da el soporte empresarial. Idealmente además la tecnología debería tener licencia Apache2 para poderla integrar y comercializar sin restricciones.

...

Soporte multilenguaje: de los puntos anteriores salía un claro ganador, Spring Cloud Functions, ya que por un lado forma parte del ecosistema Spring que es la tecnología base de Plataforma (y de Onesait Technology), y por otro lado ofrece soporte para el despliegue en los principales Clouds. Sin embargo, carecía de un soporte de primer nivel para el desarrollo de funciones en diversos lenguajes como Python, Go, Node.js o C#. Y Plataforma tiene numerosos casos de uso en los que se usan tecnologías como estas para el desarrollo, por ejemplo para el desarrollo de modelos IA sobre base Python, que además encajan muy bien para una vez entrenados ejecutar como funciones.

...

Currently, Amazon is the leader in this computing, capturing more than 80% of the market share in 2020, and Microsoft is in the second place.

Analysis of the Choice of Serverless Technology for Onesait Platform

Below is a summary of the analysis that has been carried out on the Platform for choosing the most appropriate Serverless technology to incorporate/support on the Platform.

• Cloud Independence: One of Onesait Platform's mantras is to be able to work with the different clouds, in addition to making Cloud and On Premise architectures compatible. These architectural considerations did not recommend the use of proprietary technologies such as AWS Lambda, Azure Functions or Google Functions, which, except in very specific scenarios, involve execution in the provider's Cloud.

• Simple/Native Deployment in Cloud Providers: On the other hand, although independence from the Cloud is sought, the Platform's commitment to the Cloud is clear, including offering the platform in SaaS mode. Therefore, the selected serverless technology should be able to be deployed easily, even natively, in the main Cloud providers.

• Support On Premise Deployment: Although our commitment to the Cloud is clear, we cannot forget that we still have many Platform projects and products deployed in customers' CPDs (and that many of these large customers have their own private Cloud strategy), which forces us to ensure that this technology can be deployed on premise.

• Open-Source Technology: Onesait Platform is open-source software published on GitHub under the Apache2 license, and the product team supports it. Ideally, the technology should also have an Apache2 license, so that it can be integrated and marketed without restrictions.

• Multilanguage Support: a clear winner emerged from the previous points: Spring Cloud Functions, since, on the one hand, it is part of the Spring ecosystem, which is the base technology of the Platform (and Onesait Technology); and on the other hand, it offers support for deployment in the main Clouds. However, it lacked first-level support for feature development in several languages ​​such asPython, Go, Node.js, or C#, and Platform has many use cases in which technologies like these are used for development, for example for the development of AI models based on Python, which also fit very well to execute as functions once trained.

• Compatible Deployment Strategy: the platform deployment strategy is based on containers orchestrated by Kubernetes and managed by a CaaS, with the ability to integrate with Cloud services (/wiki/spaces/PT/pages/492109995) por lo que para evitar gestión de múltiples tecnologías era muy recomendable que las funciones FaaS se pudieran desplegar como contenedores dentro de un cluster Kubernetes (incluidos los de los proveedores Clouds).

• Sencillez y extensibilidad de la tecnología: no podemos ni queremos olvidar que uno de los objetivos de la plataforma es simplificar el uso de las tecnologías, por tanto el desarrollador de Funciones debería ser capaz de hacerlo de forma sencilla y el equipo de plataforma debería poder extender esta tecnología para integrarla en plataforma y extenderla cuando sea necesario.

• Madurez, Comunidad, popularidad, extensibilidad, documentación y soporte: en este último punto del análisis hemos agregado diversas consideraciones (en la fase de análisis se estudiaron por separado( como eran la madurez de la tecnología, la comunidad que existía alrededor de la tecnología, la popularidad de esta tecnología, la documentación existente (calidad y cantidad) y el soporte de un gran player que garantice la evolución y mantenimiento de la tecnología.

De este análisis quedaron 3 tecnologías finalistas:

• Apache OpenWhisk: sobre la que IBM es el principal contribuidor y lo ofrece como servicio en su Cloud

• Spring Cloud Functions que además de ser parte del ecosistema Spring puede ser usada como fachada para AWS Lambda o , so to avoid managing multiple technologies, it was highly recommended that FaaS functions could be deployed as containers within a Kubernetes cluster (including those of Cloud providers).

• Simplicity and Extensibility of the Technology: we cannot and do not want to forget that one of the objectives of the platform is to simplify the use of technologies, therefore the Functions developer should be able to do it easily, and the platform team should be able to extend this technology to integrate it into the Platform and extend it when necessary.

• Maturity, Community, Popularity, Extensibility, Documentation and Support: in this last point of the analysis, we have added several considerations (in the analysis phase they were studied separately), such as the maturity of the technology, the community that existed around the technology, the popularity of this technology, the existing documentation (quality and quantity), and the support of a great player that guarantees the evolution and maintenance of the technology.

From this analysis, three finalist technologies remain:

• Apache OpenWhisk for which IBM is the main contributor and offers it as a service in its Cloud.

• Spring Cloud Functions that, in addition to being part of the Spring ecosystem, can be used as a facade for AWS Lambda or Azure Functions, …

• Fn Project  soportado por Oracle y ofrecido como servicio en su Cloud.

El primero que descartamos fue Spring Cloud Functions porque carecía de una característica que resultaba fundamental que era el soporte multi-tecnología y que las otras 2 si soportaban.

En el análisis final entre OpenWhisk y Fn Project finalmente nos decantamos por Fn Project, porque, aunque OpenWhisk es algo más popular y tiene buena documentación es bastante más complejo en cuanto a su uso que Fn Project (por ejemplo arrastra diversas tecnologías. Además, Fn Project ofrece integraciones con tecnologías como Spring Cloud Functions (lo que permite crear funciones Spring Cloud Functions que ejecuten en el Engine Fn) y GraalVM.

Tecnología seleccionada para incorporar en Plataforma: Fn Project

¿Cómo funciona?

Fn está construido en Go y su arquitectura se basa en Docker. Está compuesto por 2 componentes principales:

• La línea de comandos de Fn, que permite controlar todos los aspectos del framework (como creación de funciones, despliegue,…) e interactuar con el servidor de Fn:

  Image Removed

• El servidor Fn, que es una aplicación Docker simple

  Image Removed

Crear un función con Fn es tan sencillo como:

• Crear la función con la CLI de Fn: Fn genera el archivo de configuración de Fn y un proyecto simple basado en la plantilla de la tecnología seleccionada.

...

• Desplegar la función con la CLI de Fn: con esto se hace el Push de la imagen Docker de la función al repositorio Docker elegido (local o remoto) y notifica al servidor sobre la existencia y la ubicación de esta última versión.

...

 Las funciones desplegadas en Fn se ejecutan en contenedores aislados, lo que permite el soporte de muchos lenguajes, en sus ejemplos incluso explican como generar una función desde una imagen Docker existente (ver). Además, para mayor comodidad, Fn ofrece un conjunto de plantillas de tiempo de ejecución incorporadas, facilitando el arranque en una gran variedad de lenguajes y versiones (Go, múltiples versiones de Java, múltiples versiones de Python, etc.).

En Fn los argumentos de las funciones se pasan vía STDIN, y su valor de retorno se escribe en STDOUT. Si los argumentos y valores de retorno no son valores simples (por ejemplo, un objeto JSON), entonces son serializados por una capa de abstracción proporcionada por el propio Fn en forma de un Kit de Desarrollo de Funciones o FDK.

...

En Java

...

• supported by Oracle and offered as a service in its Cloud.

The first one thta we discarded was Spring Cloud Functions, because it lacked a fundamental feature, which was multi-technology support, while the other two do support it.

In the final analysis between OpenWhisk and Fn Project, we finally opted for Fn Project, because, although OpenWhisk is somewhat more popular and has good documentation, it is much more complex to be used than Fn Project (for example, it drags various technologies). Besides, Fn Project offers integrations with technologies like Spring Cloud Functions (allowing you to create Spring Cloud Functions that run on the Fn Engine) and GraalVM.

Technology Selected to Incorporate in Platform: Fn Project

How Does it Work?

Fn is built on Go and its architecture is based on Docker. It is made up of two main components:

• The Fn command line, which allows you to control all aspects of the framework (such as function creation, deployment ,…) and to interact with the Fn server:

  Image Added

• The Fn server, which is a simple Docker application

  Image Added

Creating a function with Fn is as simple as:

• Create the role with the Fn CLI: Fn generates the Fn configuration file and a simple project based on the selected technology template.

...

• Deploy the function with the Fn CLI: This Pushes the function's Docker image to the chosen Docker repository (either local or remote) and notifies the server of the existence and location of this latest version.

...

The functions deployed in Fn are executed in isolated containers, which allows the support of many languages. In their examples, they even explain how to generate a function from an existing Docker image (see). Also, for added convenience, Fn offers a set of built-in runtime templates, making it easy to boot into a wide variety of languages ​​and versions (Go, multiple Java versions, multiple Python versions, etc.).

In Fn, function arguments are passed via STDIN, and their return value is written to STDOUT. If the arguments and return values ​​are not simple values ​​(for example, a JSON object), then they are serialized by an abstraction layer provided by Fn itself, in the form of a Function Development Kit or FDK.

In Java	In Python

Arquitectura

En ejecución la arquitectura de Fn es esta:

...

...

Architecture

In execution, the architecture of Fn is this:

...

Where a load balancer provides a frontend to multiple Fn servers and each server manages and executes the function code as needed. Servers can be scaled as needed.

Fn UI

Fn tiene una UI que permite gestionar e interactuar con el servidor Fn, permitiendo ver métricas sobre las funciones desplegadas:

...

Así como invocarlas:

...

has a UI that allows you to manage and interact with the Fn server, allowing you to see metrics about the deployed functions:

...

As well as invoke them:

...