Svi­lup­pa­re un back end per­so­na­liz­za­to con il Backend as a Service

Il Software as a Service o SaaS è un elemento già comune nel cloud computing. Il Saas indica un software che può essere uti­liz­za­to tramite una con­nes­sio­ne Internet senza la necessità di una versione locale. I nuovi servizi nel cloud sono in aumento anche in settori come lo sviluppo web. In questo articolo, diamo uno sguardo più da vicino a uno di questi ambiti: il Backend as a Service.

Il Backend as a Service è un’area del cloud computing che fa ri­fe­ri­men­to a un’in­fra­strut­tu­ra ospitata di back end sulla base della quale gli svi­lup­pa­to­ri possono impostare ra­pi­da­men­te e fa­cil­men­te un back end. Il vantaggio è che, grazie al BaaS, gli svi­lup­pa­to­ri non hanno bisogno di pro­gram­ma­re l’intera in­fra­strut­tu­ra per un’ap­pli­ca­zio­ne web e possono con­cen­trar­si invece sulla pro­get­ta­zio­ne del front end. Gli svi­lup­pa­to­ri del front end possono anche impostare un server fun­zio­na­le in pochi passi.

Le soluzioni BaaS con­ten­go­no una serie di funzioni diverse come gli ag­gior­na­men­ti au­to­ma­ti­ci del back end, i database gestiti, l’au­ten­ti­ca­zio­ne degli utenti e i login dei social.

Un altro esempio di cloud computing, oltre al BaaS e al Saas, è il Function as a Service (FaaS).

Il modo in cui questa versione di back end funziona è simile all’hosting di un sito web. Il fornitore BaaS fornisce l’ap­pli­ca­zio­ne con diverse funzioni in modo che gli svi­lup­pa­to­ri possano combinare i dati di­spo­ni­bi­li per creare un back end in­di­vi­dua­le. Gli svi­lup­pa­to­ri accedono quindi alla con­fi­gu­ra­zio­ne del back end tramite in­ter­fac­ce ri­la­scia­te dal fornitore di servizi tramite API o un’in­ter­fac­cia REST e pro­get­ta­no l’ar­chi­tet­tu­ra dell’ap­pli­ca­zio­ne web de­si­de­ra­ta come richiesto.

Per i provider più grandi, basta sem­pli­ce­men­te re­gi­strar­si per poter iniziare con un pacchetto iniziale gratuito. A seconda del provider scelto, potreste essere in grado di re­gi­strar­vi usando il vostro account Facebook o Google. I passaggi di re­gi­stra­zio­ne generici includono la selezione della prima ap­pli­ca­zio­ne e la piat­ta­for­ma di de­sti­na­zio­ne de­si­de­ra­ta, ad esempio, HTML5, iOS o Android. La soluzione BaaS genera poi le chiavi API e, a seconda del provider, vengono create delle librerie Ja­va­Script e vengono definite ulteriori funzioni standard.

Ge­ne­ral­men­te gli svi­lup­pa­to­ri più esperti non avranno bisogno di alcuna for­ma­zio­ne per con­fi­gu­ra­re il back end. Impostare il back end tramite BaaS è facile e veloce.

Il Backend as a Service può sem­pli­fi­ca­re e ac­ce­le­ra­re lo sviluppo delle app, ma non è ne­ces­sa­ria­men­te la scelta giusta per tutti gli scenari.

• Il vantaggio prin­ci­pa­le della soluzione offerta dal BaaS è dato dalla con­fi­gu­ra­zio­ne semplice del back end. In pochi clic, è possibile creare, ad esempio, modelli di tabelle. Qui ci si occupa anche delle con­nes­sio­ni al database.
• Un altro vantaggio è la ma­nu­ten­zio­ne del back end che è re­spon­sa­bi­li­tà del fornitore di servizi.
• Le soluzioni BaaS possono essere basate sul cloud, il che significa che le in­fra­strut­tu­re possono essere gestite in­di­pen­den­te­men­te dalla vostra ubi­ca­zio­ne o dalla posizione geo­gra­fi­ca del server.
• Allo stesso tempo, gli svi­lup­pa­to­ri designati per il back end non sono più necessari, il che rende obsoleta la co­mu­ni­ca­zio­ne, spesso di­spen­dio­sa in termini di tempo, tra front end e back end, riuscendo a ri­spar­mia­re sia tempo che denaro.
• Poiché i modelli BaaS sono pre­va­len­te­men­te basati sul credito, gli utenti pagano solo per i con­tin­gen­ti di cui hanno bisogno. I fornitori tendono ad offrire diversi livelli di pacchetti (simili ai pacchetti di hosting) in modo che gli utenti abbiano una pa­no­ra­mi­ca dei costi in anticipo. La pos­si­bi­li­tà di gestire i diversi con­tin­gen­ti rende le soluzioni Backend as a Service adatte anche alle piccole aziende che non sono in grado di im­ple­men­ta­re lo sviluppo di un proprio back end a causa delle risorse limitate.
• La sca­la­bi­li­tà è un fattore decisivo quando si tratta di ap­pli­ca­zio­ni web e può incidere no­te­vol­men­te sui costi. A prima vista, il Backend as a Service offre un vantaggio, poiché la sca­la­bi­li­tà e la gestione sono re­spon­sa­bi­li­tà del fornitore BaaS o sono spe­ci­fi­ca­te dal fornitore e possono essere eseguite au­to­ma­ti­ca­men­te. Questo significa che il server non ha bisogno di essere ag­gior­na­to o migrato ma­nual­men­te. A seconda del tipo e delle di­men­sio­ni, i pacchetti possono includere funzioni standard, come l’invio di messaggi push, la copertura di iOS e Android e l’accesso alle funzioni dei social media di Facebook o Twitter.

• Come con­se­guen­za di quanto an­ti­ci­pa­to nel paragrafo pre­ce­den­te, a causa della sca­la­bi­li­tà au­to­ma­ti­ca possono sorgere costi im­pre­vi­sti se, ad esempio, il numero di richieste in arrivo e le quantità di im­ma­gaz­zi­na­men­to dati ne­ces­sa­rie sono sco­no­sciu­te o superano di molto i valori stimati. Al contrario, le capacità e i prezzi associati sono noti in anticipo con i server dedicati. I costi del BaaS al di là del pacchetto di base sono più difficili da an­ti­ci­pa­re, rendendo difficile un confronto tra costi.
• Gli aspetti di sicurezza, ad esempio sot­to­for­ma di ar­chi­via­zio­ne regolare dei dati del server, variano da un fornitore all’altro. Gli utenti do­vreb­be­ro capire bene in anticipo quali sono i cicli di ar­chi­via­zio­ne del fornitore BaaS per as­si­cu­rar­si che i dati vengano salvati negli in­ter­val­li richiesti. Questo include anche i backup nel caso di un guasto al server. Conviene dunque ve­ri­fi­ca­re in anticipo con il fornitore quanto tempo dopo un guasto un server è di nuovo uti­liz­za­bi­le e quali dati vengono salvati in caso di guasto. Quando i dati degli utenti vengono raccolti ed elaborati, la pro­te­zio­ne dei dati sensibili deve essere una priorità assoluta.
• Un altro svan­tag­gio si presenta quando si passa da un fornitore di Backend as a Service a un nuovo fornitore del servizio. Questo perché i provider uti­liz­za­no la propria in­ter­fac­cia server e i propri kit di sviluppo software, me­mo­riz­zan­do così le API, i driver o i pro­to­col­li di rete in luoghi separati. In questo caso, non è suf­fi­cien­te cambiare un indirizzo del server o rein­di­riz­za­re le richieste in entrata. Inoltre, gli svi­lup­pa­to­ri possono preferire diversi approcci di im­ple­men­ta­zio­ne. Di con­se­guen­za, spesso un back end deve essere re-im­ple­men­ta­to quando si cambia fornitore.
• Le ubi­ca­zio­ni dei server tendono a differire a seconda del provider. Questo può osta­co­la­re le vostre ambizioni nei confronti del BaaS o ridurre la vostra scelta di po­ten­zia­li provider se, ad esempio, l’ubi­ca­zio­ne dei server nell’UE è un criterio im­por­tan­te per voi.