azns.it

In questo articolo valuteremo alcuni servizi PaaS per ospitare web application.

Questo perchè non tutte le applicazioni sono uguali e, innanzi tutto, bisogna capire cosa dovrà fare l’applicazione per scegliere il linguaggio e il framework di sviluppo più opportuno e quindi, di conseguenza, il servizio PaaS adeguato. Non bisogna essere “talebani” focalizzandosi su un solo sistema per tutta la vita, bensi conoscere e saper valutare le differenze in modo da scegliere di volta in volta quello più adatto alle necessità dell’applicazione.

Premettiamo una cosa: se, come nel 99% dei casi, la nostra applicazione non è altro che un sito web con qualche feature 2.0, con collegamenti a database e vi aspettate che generi un traffico relativamente poco impegnativo, scegliere PHP non è sbagliato. Se invece si tratta di quell’1% dei casi in prevedete che l’applicazione verrà utilizzata intensamente (indendiamoci… voglio dire milioni di contatti giornalieri, non qualche centinaio o qalche migliaio), PHP probabilmente non è la scelta più adatta.

Difatti, se prendiamo in esame l’utilizzo delle risorse hardware, salta subito all’occhio che la maggior parte dei siti web passano il loro tempo “in idle”, cioè non sono costantemente visitati. In una simile situazione, che è la più comune e quindi anche la più semplice da affrontare, l’utilizzo di un linguaggio come PHP su una piattaforma di tipo PaaS tradizionale basata su una installazione LAMP condivisa è una scelta economicamente e tecnicamente poco impegnativa e che permette uno sviluppo dell’applicazione che è tutto sommato abbastanza facile.

LAMP, per chi non lo sapesse, è l’acronimo di Linux Apache MySQL PHP, cioè i quattro componenti che formano questo tipo di servizio PaaS. Risulta evidente che avere solo quattro componenti da gestire rende il sistema estremamente facile (e quindi economico), però impone dei limiti tali per cui in quel restante 1% dei casi si rende necessario un sistema molto più complesso.

Difatti, nel restante 1% dei casi concepiremo la nostra applicazione per non essere usata “spot” ma per essere un qualcosa che una volta lanciato continua ad operare; già da subito capiamo che scegliere una piattaforma LAMP per lo sviluppo non è la scelta migliore in quanto riusciremmo in pochi secondi a prendere possesso di tutte le risorse hardware della macchina facendola “sedere”. Per applicazioni di questo tipo Rails, Python e Java/Scala (e perchè no C++) sono linguaggi molto più adatti perchè permettono di lavorare a più stretto contatto con il sistema… anche se magari sembrano molto più impegnativi .

Inoltre, in una situazione di questo tipo, è importante prevedere che la nostra applicazione sia “scalabile” e che quindi non sia un unico grosso processo che gira su una macchina, ma che sia formata da più processi ed elementi che possono girare indipendentemente su più macchine. Così facendo la nostra applicazione potrà beneficiare delle potenzialità delle piattaforme cloud che permettono di istanziare nuovo hardware virtuale “on demand” permettendo alla nostra applicazione di scalare virtualmente all’infinito senza però dissanguarci per creare una infrastruttura hardware adeguata… oltre ad aggiungere una importantissima tolleranza ai guasti.

Oltre ai servizi PaaS su piattaforma LAMP dei “soliti noti” e di parecchi piccoli ma efficienti ISP, esistono già in commercio alcuni servizi PaaS “non LAMP” che sono in grado di scalare facilmente, anche se non sono proprio a buon mercato. I più conosciuti sono:

• Microsoft Azure per programmare in .net
• Heroku ed Engine Yard per programmare in Ruby on Rails
• Google App Engine che supporta Python, Java e Go

Se, invece, volete avere il massimo controllo di ogni componente e crearvi la vostra piattaforma “non LAMP” sopra una infrastruttura IaaS, vedremo in un prossimo articolo quali sono i componenti essenziali che la compongono.