88. ¿Qué es una aplicación serverless?

Transcripción

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 avanzados.

Una vez vistos estos 4 beneficios, ahora vamos a ver 4 desventajas, porque como todo en la vida, también hay desventajas.

El control del fabricante

Tener el control tú mismo de lo que estés utilizando, es siempre una buena idea. Sin embargo, si estás utilizando un servicio serverless, de cierta manera estás perdiendo el control porque estás alojando tu programación en la infraestructura de otra empresa.

Y, esa empresa, podría el día de mañana cerrar ese servicio. Esto ya pasó con Parce, que estaba bajo el amparo de Facebook. Naturalmente hubo un proceso largo de migración en el que no perdías nada (ya que te avisan con tiempo para que migres todo tu proyecto).

En fin, aquí el tema, es elegir un buen servicio que esté bajo el control de una empresa que no vaya a cerrar. Claro está que, no somos adivinos y no sabemos qué es lo que va a pasar, pero, yo creo que en el caso de Firebase-Google, no hay ningún problema de que lo vayan a cerrar. Quién sabe en 10-15 años, pero de momento tiene bastante fiabilidad.

Por otro lado, si se cayeran los servidores o surgiera algún problema con esos servicios, tu tendrías poco que hacer ahí. Lo único que puedes hacer es contactar con ellos. Mientras que, teniendo tu propio servidor, fácilmente lo puedes resetear y hacer que en unos segundos vuelva a funcionar.

De todas maneras, es lo mismo que digo sobre cerrar un servicio. Bajo el amparo de una empresa buena y con infraestructura de calidad, como Google, las probabilidades de que el servicio se caiga por mucho tiempo, son muy pocas.

Estás “encerrado” en su sistema

Esta desventaja, también va relacionada con el tema del control. Básicamente, estás encerrado en su sistema y no puedes migrar fácilmente de un servicio a otro.

Me explico. Si tú tienes un servidor y, por cualquier motivo no estás contento con la forma que está funcionado, puedes coger toda esa programación que has hecho y migrarla hacia otro servidor.

Sin embargo, si estás en un servicio serverless, como estás trabajando directamente con esa programación y servicios dados, es mucho más difícil migrar entre servicios serverless o a un servidor propio. Es posible, pero no es tan fácil como si tuvieras tu propio servidor.

Las limitaciones

Obviamente, un servicio serverless tiene ciertas limitaciones para según qué tipos de proyecto. Yo diría que la gran mayoría de proyectos, se pueden desarrollar sin ningún problema en estos servicios, pero sí que hay ciertos tipos de proyectos que no son adecuados para cierta tecnología.

Quizás, requieren ciertas especificaciones concretas que, con un servicio serverless, son más difíciles o caras de llevar a cabo. Es decir, hay que analizar si una arquitectura serverless, es apropiada para determinado proyecto, o no.

En resumen, no se puede hacer absolutamente todo en un servicio serverless porque existen ciertas limitaciones.

Coste a largo plazo

Esto depende del servicio, y de la forma en la que esté hecho el proyecto, pero, si al principio decía que el coste puede ser inicialmente bajo dado que la programación es menor, a la larga, si haces un uso muy intensivo del servicio y la aplicación está yendo bien, podría ser más caro que tener tu propio servidor.

Esto es algo que depende del proyecto, servicio y caso específico, pero sí sería normal que te saliera a cuenta el tener tu propio servidor si tu aplicación está funcionando muy bien y tienes mucho tráfico.

Si te ha resultado útil este artículo puedes hacer que también lo sea para otras personas compartiéndolo en , LinkedIn o .

Como siempre para cualquier duda o sugerencia puedes contactar conmigo y estaré encantado de poder ayudarte.

¡Suscríbete

a la newsletter!

Simple y llanamente te mantendré al día una vez al mes a través de un email con artículos o noticias de interés relacionadas con el mundo de las aplicaciones móviles. ¡Nada de spam!