Lo primero que tenemos que hacer para hablar del tema de las serverless aplicaciones, es situarnos un poco en el mundo de los servidores y las aplicaciones.

A la hora de desarrollar una aplicación, el 99% de las veces, tenemos dos componentes que crean lo que viene a llamarse “app”.

En primer lugar, tenemos lo que viene a ser la aplicación móvil, ya sea para Android, iOS o ambos; ya sea desarrollándola de forma híbrida, en un proyecto que funciona para los dos; ya sea desarrollándola a través de una tecnología nativa, da igual.

La función principal de esta aplicación móvil, es ser la interfaz de usuario o mecanismo a través del cual los usuarios, se pueden comunicar con la app.

En segundo lugar, tenemos el servidor, el cual es aquel ente que no vemos o por lo menos, los usuarios finales no ven, que está alojado en algún lugar del mundo y que no es más que un ordenador con una programación dentro.

Tiene varias cosas, como una base de datos que implica también validar los datos que entran; le dice a la aplicación los datos que tiene que mostrar y los que no. Es decir, es el corazón real de la aplicación.

SI hiciéramos una analogía entre la app móvil y el servidor, con el cuerpo humano, podríamos decir que aquellas partes del cuerpo visibles: manos, pies, cabeza, etc., representan la aplicación móvil/interfaz de usuario.

Por otro lado, los órganos que tenemos internamente y que hacen realmente la función de mantenernos vivos y de que hagamos cosas, los que son el “corazón” del cuerpo humano (aunque el corazón es un órgano en sí), serían el servidor. Por tanto, el servidor es el que decide todo y donde está toda la “chicha” del proyecto.

Cómo se desarrolla un servidor

Después de esta introducción al mundo aplicación-servidor, vamos a ver en qué consiste el proceso de desarrollar un servidor; de tener un servidor listo para nuestra aplicación, ya que, el desarrollo de una aplicación en sí, ya lo hemos visto bastantes veces.

Lo primero que tenemos que hacer es contratar un servidor, lo cual implica contratar a una empresa de hosting para que te dé un sitio en donde alojar tu programación. El segundo paso, sería programar la aplicación, diseñar la base de datos, etc. Finalmente, el tercer paso, sería mantener y escalar el servidor.

Este último paso, en realidad, es algo que se tendría que hacer mes tras mes. Tendríamos que ir viendo si necesitamos más recursos en el servidor, si necesitamos contratar más cosas, si necesitamos reparar alguna contingencia como una caída en el servidor, etc.; lo que viene a ser la tarea del día a día.

Esto sería lo que podríamos llamarle “la forma normal de hacer las cosas”. Es decir, si quieres programar una aplicación y necesitas un servidor, seguramente vas a tener que seguir estos tres pasos.

Las serverless apps

Sin embargo, en los últimos años, ha surgido una nueva moda: las serverless applications que, básicamente se trata de utilizar un servidor o back-end, a través de un software as a service.

Esto quiere decir que no vas a contratar directamente un servidor para luego poner la programación ahí, darle mantenimiento y escalarlo. Lo que vas a hacer, es comprar un servidor con los extras: programación y ciertos componentes; y, que se va a escalar automáticamente.

En otras palabras, elegir una solución serverless, se basa en que primero vas a contratar un servidor y muchos componentes de programación más, que ya vendrán dados. Por ejemplo, una base de datos que ya vendrá preconfigurada; no solo contratas lo que viene a ser el propio servidor.

En segundo lugar, como digo, muchas funcionalidades van a venir dadas y no vas a necesitar programarlas desde cero, como, por ejemplo, la autenticación.

En tercer lugar, no tienes que preocuparte por escalar o mantener ese servidor. Es decir, no necesitas que haya una persona preocupada de ver si el número de usuarios que tienes, se corresponde con las especificaciones que tienes en tu servidor; si te vienen más usuarios y los tienes que escalar o no; si se va a caer el servidor o no.

Todo esto, a través de una aplicación serverless, se hace automáticamente. Ya depende de la aplicación que utilices, pero en la mayoría de los casos esto ya va totalmente automatizado.

Si vienen más servicios, el servidor que utilizas automáticamente va a dedicar más recursos para que no tengas ningún problema a la hora de dar una respuesta.

Por otro lado, si hay una bajada de usuarios, el propio servicio también se va a encargar de utilizar menos recursos para que te cueste menos.

En cuarto lugar, la programación es más fácil y simple, ya que ellos mismos implementan muchas cosas.

Por ejemplo, en el caso de FireBase, el tema de la seguridad está muy implementado por ellos. Es decir, tienen unos mecanismos para implementar la seguridad de la base de datos y, por lo tanto, no te tienes que preocupar mucho por ello.

Simplemente tienes que seguir sus pasos y hacer lo que te dicen, así como implementar las reglas de seguridad que a ti te convengan.

Así que, en mi opinión, la programación es más sencilla cuando estás en una aplicación serverless que cuanto tienes un servidor entero porque éste debes programarlo totalmente desde cero.

Ahora, vamos a ver tanto los beneficios como las desventajas de tener un servicio serverless. Empecemos con los beneficios.

Reducción del tiempo de desarrollo

Esto, para mi es lo más importante. Cuanto estas empezando a desarrollar algo, lo que especialmente quieres es reducir el coste y el tiempo de desarrollo, sin sacrificar la calidad de lo que estás desarrollando.

A través de un servicio serverless, aparte de contratar un servidor, te van a venir muchas de esas cosas dadas. Por ejemplo, en Firebase, el tema de autenticación viene hecho y, únicamente tienes que configurar unas cuantas cosas.

Por poner un ejemplo práctico: para montar un log-in con redes sociales y mail, si lo haces a través de Firebase, en 1-3 dias, lo puedes tener listo. Aquí también se incluyen las interfaces de usuario de las posibles aplicaciones.

Por otro lado, si tienes un servidor propio y tienes que hacer todo ese sistema de autenticación desde cero, implementando OAuth2.0 u otro método de autenticación, vas a tardar mucho más. Quizás te lleve una semana y luego vas a tener que integrar los log-in de redes sociales.

Es cierto que, a través de ciertos frameworks, puedes acelerar el desarrollo, pero te va a llevar mucho tiempo más que si tuvieras una aplicación serverless.

Y, lo mejor, es que el resultado va a ser el mismo. Vas a tener usuarios que se registran y se logean a través de redes sociales, así que ellos no notarán si tienes un servicio serverless o un servidor propio; no van a notar absolutamente nada. Solo tu lo vas a notar en términos del coste y tiempo de desarrollo.

Coste inicial más bajo

Este beneficio va a ligado al anterior. Al tener que desarrollar menos cosas (ya que mucho de lo que vas a utilizar ya te van a venir dadas), vas a conseguir reducir el coste de desarrollo. Es similar a lo que comentaba sobre Flutter/desarrollo de aplicaciones nativas.

Si con Flutter vas a desarrollar menos, básicamente el resultado final es que vas a pagar mucho menos por ello. Lo mismo pasa con el mantenimiento de la aplicación: si tienes menos cosas desarrolladas tienes menos cosas tendrás que mantener y, por ende, menos coste de mantenimiento.

Si, por el otro lado, has programado muchísimas más cosas, hay más posibilidades de que tengas un error y de que tengas que dedicarle más tiempo a mantener esos errores.

El coste en función del uso

Este es bastante interesante. Normalmente, cuando contratas un servicio serverless, lo que haces, es contratarlo por uso. Es decir, si vas a tener cierta cantidad de usuarios y harás cierto número de peticiones al servidor, vas a pagar X. Mientras que, por la razón que sea, al día siguiente tienes el doble de usuarios, el servicio automáticamente se va a escalar para usar los recursos de este día.

Y, si al día siguiente, los usuarios se reducen a la mitad, el sistema automáticamente vuelve a reducir el uso de los recursos. El resultado es que, generalmente (una vez, depende del servicio serverless que estés utilizando), vas a pagar exactamente por lo que uso.

Mientras que, por otro lado, la mayoría de veces que contratas un servidor desde cero para programarlo tú, lo que haces es contratar una serie de especificaciones concretas. Es decir, contratas X memoria, X espacio y unas especificaciones técnicas concretas.

Lo que pasa con esto, es que da igual el tráfico que tengas, tú vas a pagar por lo que has contratado. Claro que, cada día puedes estar cambiando componentes, pero no es ni mucho menos una solución ideal.

Simplemente contratas algo que crees utilizar y, a lo largo de los meses, si ves que necesitas más o menos, varias las especificaciones en función de esto. Así que, no estás pagando por el uso, sino que estás pagando por las especificaciones que contratas.

Escalabilidad

La escalabilidad es algo muy importante en programación. Tu proyecto, tiene que estar preparado para recibir tantos usuarios como pueda ser posible. Idealmente, en tu aplicación te tendría que dar igual si vienen 100 usuarios o 1 millón de usuarios.

Tendría que estar preparado para soportar ese millón de usuarios. Y, mediante ese servicio serverless, básicamente te olvidas de este problema, de lado del servidor porque como ya comentaba, el servidor escala sus recursos en función del uso que esté recibiendo.

Además, si elegimos un servicio serverless bajo el amparo de una empresa como Firebase o Google, tenemos la seguridad de que estamos usando su infraestructura que es quizás una de las más avanza