Backend as a Service (BaaS)

Software as a Service o SaaS es ya un término común de la co­mpu­tación cloud. Describe el software que puede uti­li­zar­se a través de una conexión de Internet sin necesidad de una versión local. Los nuevos servicios en la nube están au­me­n­ta­n­do también en áreas como el de­sa­rro­llo web. En este artículo, exa­mi­na­re­mos más de cerca una de estas áreas: el Backend as a Service.

El Backend as a Service es un área de la co­mpu­tación en la nube. Se refiere a una in­frae­s­tru­c­tu­ra de backend alojada sobre la que los de­sa­rro­lla­do­res pueden co­n­fi­gu­rar rápida y fá­ci­l­me­n­te un backend. La ventaja es que estos no necesitan programar toda la in­frae­s­tru­c­tu­ra de una apli­ca­ción web y pueden centrarse en el diseño del frontend. Además, también les permite a los de­sa­rro­lla­do­res de frontend co­n­fi­gu­rar un servidor funcional en unos pocos pasos.

Las so­lu­cio­nes BaaS contienen una serie de funciones di­fe­re­n­tes, como ac­tua­li­za­cio­nes au­to­ma­ti­za­das del backend, bases de datos ge­s­tio­na­das, au­te­n­ti­ca­ción de usuarios e inicios de sesión en redes sociales.

Otro ejemplo de co­mpu­tación en la nube, además de BaaS y Saas, es Function as a Service (FaaS).

El fu­n­cio­na­mie­n­to de la versión backend es similar al del alo­ja­mie­n­to de una página web. El proveedor de BaaS entrega la apli­ca­ción con di­fe­re­n­tes funciones para que los de­sa­rro­lla­do­res puedan combinar los datos di­s­po­ni­bles para crear un backend in­di­vi­dual. A co­n­ti­nua­ción, los de­sa­rro­lla­do­res acceden a la co­n­fi­gu­ra­ción del backend a través de in­te­r­fa­ces fa­ci­li­ta­das por el proveedor de servicios mediante API o una interfaz REST y diseñan la ar­qui­te­c­tu­ra de la apli­ca­ción web deseada según sus ne­ce­si­da­des.

Para los pro­vee­do­res más grandes, el registro es su­fi­cie­n­te para empezar con un paquete inicial gratuito. De­pe­n­die­n­do del proveedor que elijas, podrás re­gi­s­trar­te uti­li­za­n­do tu cuenta de Facebook o Google. Los pasos ha­bi­tua­les para el registro incluyen la selección de la primera apli­ca­ción y la pla­ta­fo­r­ma de destino deseada, por ejemplo, HTML5, iOS o Android. A co­n­ti­nua­ción, la solución BaaS genera claves API y, según el proveedor, se crean bi­blio­te­cas Ja­va­S­cri­pt y se definen funciones estándar adi­cio­na­les.

Los de­sa­rro­lla­do­res avanzados no suelen necesitar ninguna formación para co­n­fi­gu­rar el backend. Co­n­fi­gu­rar el backend a través de BaaS es rápido y sencillo.

El Backend as a Service puede si­m­pli­fi­car y acelerar el de­sa­rro­llo de apli­ca­cio­nes. Pero el BaaS no es ne­ce­sa­ria­me­n­te la opción idónea para todos los es­ce­na­rios.

• La principal ventaja de la solución del proveedor es la sencilla co­n­fi­gu­ra­ción del backend. Con unos pocos clics, puedes crear, por ejemplo, pla­n­ti­llas para las tablas. También se encargan de las co­ne­xio­nes de la base de datos.
• Otra ventaja es el ma­n­te­ni­mie­n­to del backend, que es re­s­po­n­sa­bi­li­dad del proveedor de servicios.
• Las so­lu­cio­nes BaaS pueden estar basadas en la nube, lo que significa que las in­frae­s­tru­c­tu­ras pueden ge­s­tio­nar­se in­de­pe­n­die­n­te­me­n­te de tu ubicación o de la ubicación del servidor.
• Al mismo tiempo, ya no se necesitan de­sa­rro­lla­do­res es­pe­cia­li­za­dos en el backend, lo que hace que la co­mu­ni­ca­ción entre el frontend y el backend, que suele requerir mucho tiempo, sea cosa del pasado, ahorrando tiempo y dinero.
• Como los modelos BaaS son pre­do­mi­na­n­te­me­n­te de pago por uso, los usuarios solo pagan por los servicios que necesitan. Los pro­vee­do­res suelen ofrecer di­fe­re­n­tes niveles de paquetes (similares a los paquetes de alo­ja­mie­n­to) para que los usuarios tengan una visión general de los costes por ade­la­n­ta­do. Los servicios ge­s­tio­na­bles también hacen que las so­lu­cio­nes de Backend as a Service sean adecuadas para las empresas más pequeñas que no pueden im­ple­me­n­tar su propio de­sa­rro­llo de backend debido a sus recursos limitados.
• La es­ca­la­bi­li­dad es un factor decisivo cuando se trata de apli­ca­cio­nes web y puede tener un gran impacto en los costes. A primera vista, el Backend as a Service ofrece una ventaja, ya que el escalado y la gestión son re­s­po­n­sa­bi­li­dad del proveedor de BaaS o están es­pe­ci­fi­ca­dos por el proveedor y pueden llevarse a cabo au­to­má­ti­ca­me­n­te. Esto significa que no es necesario ac­tua­li­zar o migrar el servidor ma­nua­l­me­n­te. Según su tipo y alcance, los paquetes pueden incluir funciones estándar, como el envío de mensajes push, la cobertura de iOS y Android, y el acceso a las funciones de las redes sociales de Facebook o Twitter.

• Como co­n­se­cue­n­cia del punto anterior, pueden surgir costes im­pre­vi­s­tos debido al escalado au­to­má­ti­co si, por ejemplo, se desconoce el número de so­li­ci­tu­des entrantes y las ca­n­ti­da­des de al­ma­ce­na­mie­n­to de datos re­que­ri­das o se superan con creces los valores estimados. En cambio, las cuotas y los precios asociados se conocen de antemano con los se­r­vi­do­res dedicados. Los costes del BaaS más allá de un paquete básico son más difíciles de estimar por ade­la­n­ta­do, lo que dificulta la co­m­pa­ra­ción de los costes.
• Los aspectos de seguridad, por ejemplo, en forma de al­ma­ce­na­mie­n­to regular de los datos del servidor, varían de un proveedor a otro. Los usuarios deben in­fo­r­mar­se con su­fi­cie­n­te an­te­la­ción de cuáles son los ciclos de al­ma­ce­na­mie­n­to del proveedor de BaaS para ase­gu­rar­se de que se realizan copias de seguridad de los datos en los in­te­r­va­los ne­ce­sa­rios. Esto también incluye las copias de seguridad en caso de fallo del servidor. Comprueba de antemano con el proveedor cuánto tiempo después de un fallo se puede volver a utilizar un servidor y de qué datos se hace una copia de seguridad en caso de fallo. Cuando se recogen y procesan datos de los usuarios, la pro­te­c­ción de la in­fo­r­ma­ción sensible debe ser una prioridad absoluta.
• Otra de­s­ve­n­ta­ja surge cuando se cambia de un proveedor de Backend as a Service a un nuevo proveedor de servicios. Esto se debe a que los pro­vee­do­res utilizan su propia interfaz de servidor y kits de de­sa­rro­llo de software, por lo que almacenan la API, los co­n­tro­la­do­res o los pro­to­co­los de red en lugares distintos. En ese caso, no basta con cambiar la dirección de un servidor o redirigir las pe­ti­cio­nes entrantes. Además, hay di­fe­re­n­tes enfoques de im­ple­me­n­ta­ción que los de­sa­rro­lla­do­res pueden preferir. A menudo, hay que volver a im­ple­me­n­tar un backend cuando se cambia de proveedor.
• Las ubi­ca­cio­nes de los se­r­vi­do­res suelen variar según el proveedor. Esto puede ob­s­ta­cu­li­zar tus objetivos de BaaS o reducir tu elección de posibles pro­vee­do­res. Por ejemplo, si co­n­si­de­ras como criterio im­po­r­ta­n­te la ubicación de los se­r­vi­do­res en la UE.