Serverless en la nube: Introducción

Últimamente, ha habido un revuelo en el mundo IT sobre tecnologías "Serverless". El término puede ser un poco confuso, porque sigue habiendo una computadora haciendo procesamiento del lado del servidor; la diferencia clave es que cuando hablamos de un entorno "serverless", toda la infraestructura del lado del servidor es manejada por terceros. En un entorno así, un desarrollador sólo necesita proveer su código a ejecutar del lado del servidor, y la plataforma de la nube se encargará de desplegarlo y ejecutarlo de manera conveniente y escalable. Esto lleva el concepto de cloud computing de delegar cosas a la nube un poco más allá. Recordemos los distintos tipos de servicios de cloud e intentemos meter a Serverless en esa lista:

  • IaaS: Infastructure as a Service. El proveedor de cloud ofrece una interfaz para que sus usuarios manejen la infraestructura: servidores, bases de datos, redes y otros recursos. De esta manera, el usuario puede definir y asignar recursos computacionales usando un modelo de facturación donde paga proporcionalmente a lo que usa (pay-as-you-go). Este es el modelo donde el usuario tiene más control: puede configurar aplicaciones, sus datos, runtime, middleware y sistemas operativos; algunos proveedores cloud también ofrecen bases de datos, colas de mensajes y otros servicios. Aquellos que agregan esto a veces son denominados IaaS+. El caso usual de uso de este tipo de soluciones es delegar el manejo de la infraestructura del datacenter a terceros a fin de concentrarse en el desarrollo de la aplicación. Ejemplos: AWS (Amazon Web Services), Microsoft Azure, Google Compute Engine, Joyent.
  • PaaS: Platform as a Service. El proveedor cloud ofrece un framework de desarrollo para los programadores. El proveedor se encarga de mantener el framework y su infraestructura, y los desarrolladores se encargan de desarrollar sus aplicaciones usando el framework. El escenario usual de uso de este tipo de solución involucra usar el framework existente para reducir tiempos de desarrollo y salida al mercado. Ejemplo: Apprenda.
  • Baas/FaaS/Serverless: Backend as a Service/Function as a Service. En este caso, lo único que el usuario controla es el código que se ejecuta en el servidor. Todo lo demás es manejado por el proveedor cloud. Por eso se coloca esta modalidad entre PaaS y SaaS. Sin embargo, debe marcarse una distinción entre BaaS y FaaS (ver próximo párrafo).
  • SaaS: Software as a Service. El proveedor cloud ofrece un conjunto de aplicaciones pre-fabricadas que pueden ser usadas directamente. El cliente sólo tiene acceso a la interfaz de usuario de dichas aplicaciones, no tiene injerencia en su desarrollo o mantenimiento; eso es responsabilidad del proveedor. El caso de uso usual de este tipo de soluciones es reemplazar software de escritorio tradicional, lo cual evita al usuario final las molestias de instalar y actualizar. Ejemplo: Google Apps, Salesforce, Citrix GTM, Cisco WebEx.

Mike Roberts, de martinfowler.com, marca una diferencia entre dos tipos de arquitecturas Serverless:

  • BaaS: Backend as a Service. Una aplicación construida sobre BaaS delega casi toda la lógica y estado del lado del servidor al proveedor cloud, usualmente vía aplicaciones de tipo "rich client".
  • FaaS: En un entorno FaaS, el usuario aún escribe la mayoría del código a ejecutar del lado del servidor, pero a diferencia de los entornos tradicionales, ese código es ejecutado por el proveedor cloud en "contenedores efímeros", rompiendo el paradigma "always on" de los servidores tradicionales. Básicamente, FaaS se trata de correr código del lado del servidor sin administrar servidores ni aplicaciones en servidores. Esto da al proveedor cloud mayor flexibilidad a la hora de asignar sus recursos computacionales.

Las tecnologías FaaS más populares son Amazon Lambda (de AWS) y las Microsoft Azure functions (de Azure).

Para profundizar en el tema (incluyendo ejemplos de arquitectura):

Comments

Post a Comment

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce
Keep reading