SaaS
•Télécharger en tant que ODP, PDF•
0 j'aime•519 vues
Slide relative ad una presentazione generale sul cloud, parte 2. Introduzione su come si realizza un servizio SaaS sfruttando le capacità del cloud, quali linguaggi e framework esistono ecc.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
SaaS
- 1. SaaS Alberto Zuin http://www.azns.it alberto@azns.it
- 2. Come si compone un SaaS Identità Monetizzazione Informazioni Presentazione Piattaforma Integrazione Resilienza Sviluppo Alberto Zuin Operazioni http://www.azns.it alberto@azns.it
- 3. Perchè scrivere codice cloud-ready? Una architettura solida che ha un suo valore intriseco. Alberto Zuin http://www.azns.it alberto@azns.it
- 4. Perchè scrivere codice cloud-ready? Una architettura solida che ha un suo valore intriseco. L'elasticità è d'obbligo nei business che crescono Alberto Zuin http://www.azns.it alberto@azns.it
- 5. Perchè scrivere codice cloud-ready? Una architettura solida che ha un suo valore intrinseco. L'elasticità è d'obbligo nei business che crescono La proprietà intellettuale di un codice vale di più se è flessibile Alberto Zuin http://www.azns.it alberto@azns.it
- 6. Linee guida di un bravo programmatore Ottimizzazione delle risorse Alberto Zuin http://www.azns.it alberto@azns.it
- 7. Linee guida di un bravo programmatore Ottimizzazione delle risorse Ottimizzazione delle operazioni Alberto Zuin http://www.azns.it alberto@azns.it
- 8. Linee guida di un bravo programmatore Ottimizzazione delle risorse Ottimizzazione delle operazioni Ottimizzazione degli obiettivi Alberto Zuin http://www.azns.it alberto@azns.it
- 9. Linee guida di un bravo programmatore di una webapp Ridurre le richieste di rete Alberto Zuin http://www.azns.it alberto@azns.it
- 10. Linee guida di un bravo programmatore di una webapp Ridurre le richieste di rete Minimizzare il download dei contenuti Alberto Zuin http://www.azns.it alberto@azns.it
- 11. Linee guida di un bravo programmatore di una webapp Ridurre le richieste di rete Minimizzare il download dei contenuti Distribuzione dei contenuti e cache Alberto Zuin http://www.azns.it alberto@azns.it
- 12. Linee guida di un bravo programmatore di una webapp Ridurre le richieste di rete Minimizzare il download dei contenuti Distribuzione dei contenuti e cache Ottimizzare la sequenza di download Alberto Zuin http://www.azns.it alberto@azns.it
- 13. Linee guida di un bravo programmatore di una webapp Ridurre le richieste di rete Minimizzare il download dei contenuti Distribuzione dei contenuti e cache Ottimizzare la sequenza di download Ottimizzare la logica dell'applicazione Alberto Zuin http://www.azns.it alberto@azns.it
- 14. Web 2.0 Cos'è Alberto Zuin http://www.azns.it alberto@azns.it
- 15. Web 2.0 Cos'è Perchè Alberto Zuin http://www.azns.it alberto@azns.it
- 16. Autenticazione E Autorizzazione OpenID Oauth Alberto Zuin http://www.azns.it alberto@azns.it
- 17. Aspetti critici della programmazione multiserver Programmazione tradizionale monoprocesso Alberto Zuin http://www.azns.it alberto@azns.it
- 18. Aspetti critici della programmazione multiserver Programmazione multiprocesso Alberto Zuin http://www.azns.it alberto@azns.it
- 19. Aspetti critici della programmazione multiserver Programmazione multiserver Alberto Zuin http://www.azns.it alberto@azns.it
- 20. Tutto deve essere condiviso Alberto Zuin http://www.azns.it alberto@azns.it
- 21. Scritture sul filesystem Alberto Zuin http://www.azns.it alberto@azns.it
- 22. Scritture sul filesystem Alberto Zuin http://www.azns.it alberto@azns.it
- 23. SRV01 SRV02 Appserver1 Appserver2 Rete W W R R DBserver1 DBserver2 (master) (slave) Scritture sul database Alberto Zuin http://www.azns.it alberto@azns.it
- 24. SRV01 SRV02 Appserver1 Appserver2 Rete W W R R DBserver1 DBserver2 (master) (slave) Scritture sul database Alberto Zuin http://www.azns.it alberto@azns.it
- 25. SRV01 SRV02 Appserver1 Appserver2 W W ? R R DBserver1 DBserver2 (master) (slave) Scritture sul database Alberto Zuin http://www.azns.it alberto@azns.it
- 26. SRV01 SRV02 Appserver1 Appserver2 W W ? R R DBserver1 DBserver2 (master) (slave) Scritture sul database Alberto Zuin http://www.azns.it alberto@azns.it
- 27. SRV01 SRV02 Appserver1 Appserver2 XMP Rete W XMP R R P P DBserver1 DBserver2 (master) (slave) Scritture sul database attraverso una coda in background Alberto Zuin http://www.azns.it alberto@azns.it
- 28. SRV01 SRV02 Appserver1 Appserver2 XMP XMP R R W P P DBserver1 DBserver2 (master) (slave) Scritture sul database attraverso una coda in background Alberto Zuin http://www.azns.it alberto@azns.it
- 29. SRV01 SRV02 Appserver1 Appserver2 XMP Rete W XMP R R P P DBserver1 DBserver2 (master) (slave) Scritture sul database attraverso una coda in background Alberto Zuin http://www.azns.it alberto@azns.it
- 30. SRV01 SRV02 Appserver1 Appserver2 XMP Rete W XMP R R P P DBserver1 DBserver2 (master) (slave) Scritture sul database attraverso una coda in background Alberto Zuin http://www.azns.it alberto@azns.it
- 31. Le Sessioni e i cookies Alberto Zuin http://www.azns.it alberto@azns.it
- 32. Le chiavi di criptaggio Alberto Zuin http://www.azns.it alberto@azns.it
- 33. Le basi dati Alberto Zuin http://www.azns.it alberto@azns.it
- 34. File System | DB relazionali | DB Documentali Alberto Zuin http://www.azns.it alberto@azns.it
- 35. File System | DB relazionali | DB Documentali Alberto Zuin http://www.azns.it alberto@azns.it
- 36. File System | DB relazionali | DB Documentali Alberto Zuin http://www.azns.it alberto@azns.it
- 37. File System | DB relazionali | DB Documentali Alberto Zuin http://www.azns.it alberto@azns.it
- 38. Database relazionali Pro: Contro: Numerose funzionalità Difficile scalabilità Linguaggio standard e Pesantezza in caso di query conosciuto complesse Possibilità di mettere in Non adatti a gestire oggetti di relazione diverse basi dati dimensione notevole (es. (Join, Union, ecc.) memorizzare una immagine di qualche MB) Alberto Zuin http://www.azns.it alberto@azns.it
- 39. Database relazionali: Scalabilità
- 40. Database relazionali: Scalabilità
- 41. Database relazionali: Scalabilità Lettura Scrittura
- 42. Database relazionali: velocità
- 43. Database documentali Pro: Contro: Elevata scalabilità di spazio Approccio al database non univoco Estrema velocità in lettura grazie (API, linguaggi proprietari) all'utilizzo della RAM Nessuna capacità relazionale Adatti a gestire oggetti di dimensione notevole (es. memorizzare una immagine di qualche MB) Sono “schemaless”, per cui non si deve definire uno schema di dati (tabella) a cui si rimane legati, ma lo schema Alberto Zuin cambia dinamicamente in base alle http://www.azns.it necessità alberto@azns.it
- 44. Database documentali: scalabilità Alberto Zuin http://www.azns.it alberto@azns.it
- 45. Database documentali: velocità Alberto Zuin http://www.azns.it alberto@azns.it
- 46. Usare MongoDB per i contenuti statici Alberto Zuin http://www.azns.it alberto@azns.it
- 47. Linguaggi di programmazione e framework Alberto Zuin http://www.azns.it alberto@azns.it
- 48. Microsoft asp e .net IIS IIS IIS IIS Alberto Zuin http://www.azns.it alberto@azns.it
- 49. Microsoft asp e .net MsSQL MsSQL MsSQL MsSQL } Federazione Alberto Zuin http://www.azns.it alberto@azns.it
- 50. Microsoft asp e .net IIS IIS IIS IIS IIS Alberto Zuin http://www.azns.it alberto@azns.it
- 51. Microsoft asp e .net ? http://msdn.microsoft.com/en-us/library/ff650667.aspx Alberto Zuin http://www.azns.it alberto@azns.it
- 52. PHP e Zend Alberto Zuin http://www.azns.it alberto@azns.it
- 53. PHP e Zend Alberto Zuin http://www.azns.it alberto@azns.it
- 54. PHP e Zend CORE PLATFORM Alberto Zuin http://www.azns.it alberto@azns.it
- 55. PHP e Zend Debug tools Alberto Zuin http://www.azns.it alberto@azns.it
- 56. PHP e Zend Cache e velocità Alberto Zuin http://www.azns.it alberto@azns.it
- 57. PHP e Zend Sessioni e code Alberto Zuin http://www.azns.it alberto@azns.it
- 58. PHP e Zend Sessioni e code Alberto Zuin http://www.azns.it alberto@azns.it
- 59. Python e Django Alberto Zuin http://www.azns.it alberto@azns.it
- 60. Python e Django Alberto Zuin http://www.azns.it alberto@azns.it
- 61. Ruby e Rails Alberto Zuin http://www.azns.it alberto@azns.it
- 62. Ruby e Rails Alberto Zuin http://www.azns.it alberto@azns.it
- 63. Ruby e Rails Alberto Zuin http://www.azns.it alberto@azns.it
- 64. Scala e Lift Alberto Zuin http://www.azns.it alberto@azns.it
- 65. Scala e Lift Alberto Zuin http://www.azns.it alberto@azns.it
Notes de l'éditeur
- SaaS
- Piattaforma: Piattaforma di sviluppo per il programmatore Presentazione: Interfaccia per l'utente finale Identità: Informazioni sull'utente che saranno usate per modificare l'interfaccia Integrazione: framwork per il trasferimento dei dati e gestione dei processi Informazioni: storage dei dati Resilienza: Tolleranza ai guasti dell'applicazione e dell'infrastruttura; scalabilità Monetizzazione: strumenti per la fatturazione e per l'incasso Sviluppo: processi che integrano anche il test e la messa in produzione Operazioni: tools di monitoraggio e supporto Come si compone un SaaS
- Una architettura orientata al servizio ha un maggior grado di flessibilità che permette di mantenere attuale l'applicazione nel tempo. Se il software è ingegnerizzato considerando fin dall'inizio la tolleranza ai guasti, la sicurezza e la scalabilità, sarà molto, più robusto, sarà più facile gestire situazioni non previste inizialmente e sarà più facile implementare nuove funzionalità Perchè scrivere codice cloud-ready?
- Non si tratta solo di un aumento di clienti o vendite a richiedere la scalabilità. Una architettura scalabile riesce a sostenere fusione o una acquisizione aziendale. Una architettura elastica permette di riutilizzare un applicativo anche per scopi diversi rispetto a quelli previsti inizialmente Perchè scrivere codice cloud-ready?
- Perchè rendere elastico un codice concepito per usi interni? Perchè un domani quel codice potrebbe essere rivenduto e se è strutturato per essere flessibile varrà di più Perchè scrivere codice cloud-ready?
- Srivere codice slegato il più possibile dagli aspetti hardware del sistema Facilitare la virtualizzazione Prevedere sistemi di accounting e possibilità di settare autorizzazioni in modo capillare Linee guida di un bravo programmatore
- Minimizzare gli intervanti umani Linee guida di un bravo programmatore
- Creare software riutilizzabile scomponendolo in pacchetti piccoli Linee guida di un bravo programmatore
- Ogni richiesta di rete comporta una query al DNS che rallenta la navigazione Linee guida di un bravo programmatore di una webapp
- Abilitare la compressione dei dati testuali (html, js, css) Minimizzare i javascript Linee guida di un bravo programmatore di una webapp
- Usare sistemi CDN (Content Delivery Network) per far servire i contenuti statici esternamente minimizzando la “distanza” con l'utente Ablilitare la cache del browser Linee guida di un bravo programmatore di una webapp
- Portare gli script alla fine della pagine Linee guida di un bravo programmatore di una webapp
- Usare memcache per memorizzare l'output delle query Ottimizzare gli script javascript perchè non saturino la capacità computazionale del client Ottimizzare il funzionalmento dell'HTML5 in caso di offline Linee guida di un bravo programmatore di una webapp
- Non più richiesta dal client, elaborazione del server e output, ma un canale aperto costantemente con il server per aggiornamenti in tempo reale. Ajax/Rest: generico funziona con tutti i browser tramite javascript ed è gestito direttamente dal codice applicativo Websockets: no Microsoft, impone un web server compatibile Web 2.0
- Aggregare informazioni esterne in tempo reale /Feed RSS e Social Networks) Esporre le informazioni all'esterno Considerazioni pratiche: - Abilitare Facebook e Twitter per portare connessioni alla propria applicazione - Rendere disponibili i feed attraverso PubSubHubbub (protocollo per la diffusione dei feed) - Abilitare i commenti sul proprio sito e replicarli sui Social Network - Aggregare i commenti multidirezionalmente attraverso il protocollo Salmon - Aggiungere contenuti alla propria Webapp sfruttando i servizi in realtime (Es. pubblicare gli ultimi tweet, le quotazioni di borsa...) - Controllare la presenza degli utenti e mostrarla sul sito - Seguire i principi del design in tempo reale e permettere all'utente di contribuire con commenti - Estendere il proprio servizio con componenti “embeddable” utilizzabili da altri siti Web 2.0
- OpenID: Protocollo aperto per integrare l'autenticazione di provider esterni (es. Google, Yahoo...) Oauth: Protocollo aperto per la gestione delle autorizzazione (chi fa cosa) Autenticazione E Autorizzazione
- Programmazione tradizionale: un unico processo parte e lavora “in esclusiva” fino a che non completa il suo lavoro (o viene fermato) Aspetti critici della programmazione multiserver
- Programmazione multiprocesso/multithreading: essendoci più processi contemporanei, devono essere gestiti “gli stati”. Quindi bisogna prestare attenzione agli accessi contemporanei (in scrittura) ai file e alla RAM, ecc. Aspetti critici della programmazione multiserver
- Programmazione multiserver: come la programmazione multiprocesso, ma abbiamo più server per cui non solo bisogna gestire la concorrenza all'interno di un server, ma bisogna gestirla tra più server: tutti i server devono comunicare tra loro ed essere sincronizzati. Aspetti critici della programmazione multiserver
- Scritture su disco: la gestione delle scritture su disco e la sincronizzazione delle stesse è estremamente complessa e causa di incongruenze tra i server: semplicemente, va evitata. Le scritture su disco devono essere limitate solo al codice dell'applicativo in caso di aggiornamento (ad es. Upload di file asp/php/rb/jsp/ecc.). Tutti i dati dinamici dell'applicativo compresi eventuali dati caricati dall'utente (ad es. Upload dell'immagine di profilo) devono essere gestiti da un datastore di livello più elevato (es. Database relazionale o documentale). Scritture sul filesystem
- Scritture su disco: la gestione delle scritture su disco e la sincronizzazione delle stesse è estremamente complessa e causa di incongruenze tra i server: semplicemente, va evitata. Le scritture su disco devono essere limitate solo al codice dell'applicativo in caso di aggiornamento (ad es. Upload di file asp/php/rb/jsp/ecc.). Tutti i dati dinamici dell'applicativo compresi eventuali dati caricati dall'utente (ad es. Upload dell'immagine di profilo) devono essere gestiti da un datastore di livello più elevato (es. Database relazionale o documentale). Scritture sul filesystem
- Le scritture su database devono essere gestite con attenzione perchè anch'esse possono essere causa di possibili incongruenze. Le architetture “multimaster” in cui tutti i nodi del database sono utilizzabili per lettura e scrittura, sono comode ma spesso causa di incongruenze in caso di “split-brain”. Meglio una architettura master/slave che è meno soggetta ad errori in caso di perdita di connettività tra i server Scritture sul database
- Le scritture su database devono essere gestite con attenzione perchè anch'esse possono essere causa di possibili incongruenze. Le architetture “multimaster” in cui tutti i nodi del database sono utilizzabili per lettura e scrittura, sono comode ma spesso causa di incongruenze in caso di “split-brain”. Meglio una architettura master/slave che è meno soggetta ad errori in caso di perdita di connettività tra i server Scritture sul database
- Le scritture su database devono essere gestite con attenzione perchè anch'esse possono essere causa di possibili incongruenze. Le architetture “multimaster” in cui tutti i nodi del database sono utilizzabili per lettura e scrittura, sono comode ma spesso causa di incongruenze in caso di “split-brain”. Meglio una architettura master/slave che è meno soggetta ad errori in caso di perdita di connettività tra i server Scritture sul database
- Le scritture su database devono essere gestite con attenzione perchè anch'esse possono essere causa di possibili incongruenze. Le architetture “multimaster” in cui tutti i nodi del database sono utilizzabili per lettura e scrittura, sono comode ma spesso causa di incongruenze in caso di “split-brain”. Meglio una architettura master/slave che è meno soggetta ad errori in caso di perdita di connettività tra i server Scritture sul database
- In caso di perdita di connettività tra SRV01 e SRV02, SRV02 può leggere dalla copia locale del database, ma non può scrivere. L'applicazione, in questo caso, rimane bloccata! La conseguenza è che per gestire le scritture correttamente è necessario un sistema asincrono di code come XMPP o AMQP (Advanced Message Queuing Protocol), unito ad un sistema di gestione in background dei processi (taskqueue su Python, delayed_job e resque su Ruby...). Scritture sul database attraverso una coda in background
- In caso di perdita di connettività tra SRV01 e SRV02, SRV02 può leggere dalla copia locale del database, ma non può scrivere. L'applicazione, in questo caso, rimane bloccata! La conseguenza è che per gestire le scritture correttamente è necessario un sistema asincrono di code come XMPP o AMQP (Advanced Message Queuing Protocol), unito ad un sistema di gestione in background dei processi (taskqueue su Python, delayed_job e resque su Ruby...). Scritture sul database attraverso una coda in background
- In caso di perdita di connettività tra SRV01 e SRV02, SRV02 può leggere dalla copia locale del database, ma non può scrivere. L'applicazione, in questo caso, rimane bloccata! La conseguenza è che per gestire le scritture correttamente è necessario un sistema asincrono di code come XMPP o AMQP (Advanced Message Queuing Protocol), unito ad un sistema di gestione in background dei processi (taskqueue su Python, delayed_job e resque su Ruby...). Scritture sul database attraverso una coda in background
- In caso di perdita di connettività tra SRV01 e SRV02, SRV02 può leggere dalla copia locale del database, ma non può scrivere. L'applicazione, in questo caso, rimane bloccata! La conseguenza è che per gestire le scritture correttamente è necessario un sistema asincrono di code come XMPP o AMQP (Advanced Message Queuing Protocol), unito ad un sistema di gestione in background dei processi (taskqueue su Python, delayed_job e resque su Ruby...). Scritture sul database attraverso una coda in background
- Le sessioni Nelle Web Application spesso si usano le sessioni per memorizzare informazioni sull'utente. Bisogna prestare attenzione a non memorizzare queste informazioni in un posto esclusivo dell'application server (ad es. La RAM o il filesystem locale) ma usare un posto comune (ad es. Un cookie sul browser dell'utente, il database, un demone per gestire la cache condivisa...) In alternativa è necessario usare un load balancer con le “sticky session”, cioè in grado di ricordarsi a quale server è stato precedentemente reindirizzato un client. Le Sessioni e i cookies
- Per i dati memorizzati in forma criptata, prestare attenzione a non usare chiavi di criptaggio specifice del server (ad es. Il mac address dell'ethernet), ma usare una chiave condivisa tra i server. Per maggiore sicurezza è possibile memorizzare la chiave condivisa in un luogo comune, ma mantenendola a sua volta criptata con una chiave di criptaggio specifica del server. Le chiavi di criptaggio
- Pro: Numerose funzionalità Linguaggio standard e conosciuto Possibilità di mettere in relazione diverse basi dati (Join, Union, ecc.) Contro: Difficile scalabilità Pesantezza in caso di query complesse Non adatti a gestire oggetti di dimensione notevole (es. Memorizzare una immagine di qualche MB) Database relazionali
- Scalare lo storage di un database relazionale: operazione impossibile. Non è gestita direttamente dal database per cui verrebbe demandata al filesystem. I filesystem cluster sono scalabili ma troppo lenti per essere usati alla base di un database relazionale Database relazionali: Scalabilità
- Scalare la capacità computazionale di un database relazionale e semplice: basta aggiungere slave server e bilanciare il carico con un proxy. Database relazionali: Scalabilità
- Normalmente il carico di lavoro di un database è dato al 90% da query in lettura e non da operazioni di insert/update/delete Database relazionali: Scalabilità
- Migliorare le prestazioni con la cache: la cache permette di migliorare le prestazioni di un database relazionale memorizzando I risultati delle query. In un cloud computer anche la cache deve essere condivisa, per cui esistono demoni dedicati a questo scopo come memcached Database relazionali: velocità
- Pro: Elevata scalabilità di spazio Estrema velocità in lettura grazie all'utilizzo della RAM Adatti a gestire oggetti di dimensione notevole (es. memorizzare una immagine di qualche MB) Sono “schemaless”, per cui non si deve definire una schema di dati (tabella) a cui si rimane legati, ma lo schema cambia dinamicamente in base alle necessità Contro: Approccio al database non univoco (API, linuguaggi proprietari) Nessuna capacità relazionale Database documentali
- I database documentali scalano semplicemente aggiungendo server che possono essere usati sia per espandere lo storage, sia in configurazione master/slave per per migliorare la contemporaneità di lettura e per la sicurezza. I database documentali sono in grado di leggere un dato o una serie di dati che rispondono a determinati criteri, ma non hanno alcuna capacità computazionale e relazionale. Le “operazioni complesse” sono demandate quindi agli application server che, in caso, dovranno simulare operazioni come Join e Union. E' per questo che spesso vengono definiti con il termine NoSQL. Database documentali: scalabilità
- La velocità di lettura di un database documentale è condizionata esclusivamente dalla velocità dello storage sottostante. Nel caso di utilizzo di storage lenti, è possibile mantenere una copia dell'intero database in RAM che da “tramite” per le operazioni di I/O. Questa feature è stata introdotta da FourSquare su MongoDB a causa della lentezza dell'I/O su disco di Amazon. Database documentali: velocità
- Il webserver più usato sul cloud è nginx che ha un plugin per accedere direttamente a MongoDB. Con una simile configurazione è possibile servire i contenuti statici del sito (immagini, css, js, ecc.) presenti su MongoDB direttamente da web server, senza appesantire l'application server Quindi, tutti i contenuti del sito (file statici dati dinamici) possono risiedere in un cluster di server MongoDB che scala nello storage ed è replicabile in maniera consistente. Gli application server conterranno al loro interno solo gli script con il codice dell'applicativo Usare MongoDB per i contenuti statici
- E' possibile scalare orizzontalmente una applicazione in .net su più server IIS Microsoft asp e .net
- Il datastore su MS SQL deve essere di tipo federato e quindi distribuito tra i server Microsoft asp e .net
- Per gestire il “map reduce”, è necessario scrivere del codice specifico, oppure ospitare la propria applicazione su Microsoft Azure Microsoft asp e .net
- Valgono le considerazioni precedenti per lo sviluppo degli applicativi Per maggiori informazioni: http://msdn.microsoft.com/en-us/library/ff650667.aspx Microsoft asp e .net
- PHP è un linguaggio che non è nativamente orientato agli oggetti, ma e stata aggiunta questa funzionalità solo in seguito. PHP è molto usato e conosciuto per via della sua facilità di apprendimento in quanto lascia “le mani libere” su come scrivere il codice, senza imporre regole ferree. PHP e Zend
- Zend è più di un framework: è un PaaS commerciale per lo sviluppo di applicazioni PHP installabile sulla propria infrastruttura. Si compone di: Zend Core: versione di PHP certificata e supportata da Zend Zend Platform: la piattaforma di runtime per le applicazioni Zend PHP e Zend
- Zend è più di un framework: è un PaaS commerciale per lo sviluppo di applicazioni PHP installabile sulla propria infrastruttura. Si compone di: Zend Core: versione di PHP certificata e supportata da Zend Zend Platform: la piattaforma di runtime per le applicazioni Zend PHP e Zend
- Zend Platform esegue il monitoraggio dell'applicazione PHP attraverso un plugin del webserver. Eventuali anomalie (rallentamenti, errori, memoria, ecc.) vengono inoltrati al sistema di controllo che le rende disponibili tramite una interfaccia ed è in grado di eseguire operazioni preconfigurate Con l'anomalia vengono memorizzate tutte le informazioni utili per il debug (variabili, cookie, sessioni, ecc.) PHP e Zend
- Attraverso Zend è possibile “precompilare” uno script PHP per aumentare la velocità di esecuizione Zend ha delle API specifiche per gestire la cache: può essere usata sia per memorizzare il “precompilato” degli script PHP, sia per memorizzare i risultati delle query al database PHP e Zend
- Si occupa direttamente di gestire le sessioni condividendole tra tutti gli application server Incorpora un gestore di code e di processi in background multiserver a cui è possibile accedere tramite API PHP e Zend
- Si occupa direttamente di gestire le sessioni condividendole tra tutti gli application server Incorpora un gestore di code e di processi in background multiserver a cui è possibile accedere tramite API PHP e Zend
- Python è un linguaggio di scripting caratterizzato per il supporto di più paradigmi di programmazione tra cui OOP, strutturato, funzionale e orientato all'aspetto. Tutti gli script di configurazione di RedHat sono scritti in Python. Python impone una sintassi meno libera rispetto a PHP per cui a prima vista sembrerebbe di più difficile apprendimento Python è usato in molti siti ad elevato traffico come Disqus.com e instagram Python è il linguaggio principe per Google App Engine e per il suo clone OpenSource Appscale Python e Django
- Django è un framework costruito su Python per la realizzazione di web application Valgono le medesime raccomandazioni generali degli altri linguaggi, in quanto tutte le “funzionalità cloud” non sono contenute nel linguaggio o nel framework, ma sono compito del PaaS Python e Django
- Ruby è il linguaggio che sta soppiantando PHP oltre oceano. Twitter è stato scritto inizialmente in Ruby e ancora oggi è usato soprattutto per il frontend. Ruby, al contrario di PHP e in maniera ancora più accentuata rispetto a Python, impone una sua modalità di programmazione molto spinta agli oggetti che lo rendono a prima vista il linguaggio più ostico. Ruby e Rails
- Rails è un framework basato su ruby estensibile attraverso pacchetti aggiuntivi chiamati “gemme”. Tra le gemme disponibili, citiamo delayed_jobs e resque per la gestione di code e processi in background Rails gestisce direttamente le routing del sito in modo da realizzare “friendly URL”. Non è più necessario programmare complesse transcodifiche sul Web Server Anche in questo caso valgono le medesime raccomandazioni generali degli altri linguaggi, in quanto tutte le “funzionalità cloud” non sono contenute nel linguaggio o nel framework, ma sono compito del PaaS Ruby e Rails
- Rails impone la modalità MVC (Model View Controller) rendendo il codice dell'applicazione ordinato. Grazie a questa visione, nel controller posso scegliere la vista da inviare in base a numerosi criteri. In particolare si può avere un unico “motore” per il sito e differenziare l'output in base al dispositivo di navigazione (Pc/Smartphone) o al tipo di richiesta. Con rails si implementano nativamente le REST API senza aggiungere una riga di codice Ruby e Rails
- Scala è un “dialetto” di Java, quindi di facile apprendimento per chi conosce questo linguaggio Scala è “l'ultimo arrivato” e per questo non diffusissimo. Solo Foursquare lo sta utilizzando fin dall'inizio per ogni sua parte; nel 2009 Twitter ha annunciato la riscrittura di buona parte del suo backend in Scala. Anche il guardian sta seguendo le orme di twitter portando il sito a Scala. E' senza dubbio il futuro. Scala e Lift
- Scala eredita da Java le API per la programmazione concorrente, aggiungendo l'actor model ( http://en.wikipedia.org/wiki/Actor_model ) Scala utilizza un suo CSP (Communicating Sequential Processes) Communicating Scala Processes per la comunicazione tra gli oggetti Tutte queste caratteristiche rendono Scala il linguaggio più efficiente, al momento, per la realizzazione di web application. Scala, come Ruby e Python, non mette a disposizone alcun tool per la gestione multiserver, quindi valgono le solite considerazioni generali per scalare orizzontalmente. Scala e Lift