Link copiato negli appunti
Quando vogliamo sviluppare applicazioni su Jelastic, è bene seguire una serie di passaggi: alcuni tipici del processo di sviluppo, altri più inerenti alla piattaforma. L'aspetto su cui si noterà una grande differenza è la velocità con cui sarà possibile configurare l'architettura su Cloud grazie ai pannelli accessibili mediante il proprio account. Jelastic offre alcuni strumenti che la rendono ideale a realizzare applicazioni con un impianto estremamente moderno: la ricchezza di linguaggi e strumenti a disposizione, il forte orientamento ai container, la possibilità di sfruttare immagini Docker in ogni punto dell'applicazione.
Le aree di azione saranno le seguenti:
- Progettazione: per prima cosa è necessario pianificare cosa la nostra applicazione deve fare, quali saranno i suoi obiettivi e le modalità con cui raggiungerli. Un aspetto da considerare, in vista dell'esecuzione su Jelastic, è la possibilità di strutturarne l'architettura come una rete di container. Questo è in linea con l'organizzazione degli environment in Jelastic, ma anche con le moderne modalità progettuali. Soprattutto se abbiamo intenzione di far crescere la nostra applicazione e non vogliamo porre limiti ai suoi orizzonti, è necessario iniziare a pensarla con la filosofia dei microservizi. Da un punto di vista pratico, Jelastic fornisce già il necessario a livello infrastrutturale, starà a noi decidere quanto segmentarla in più nodi e come sviluppare il dialogo tra di essi. In questa fase, vale inoltre la pena considerare cosa è disponibile nel Marketplace e se un'applicazione in esso presente possa o meno trovare posto all'interno dell'architettura.
- Strumenti: in base a come abbiamo scelto di progettare la nostra applicazione, potremo scegliere gli strumenti, in primis linguaggi di programmazione e database. Questi andranno selezionati con cura anche perché spesso determinano a cascata ulteriori scelte. Ad esempio, il linguaggio di programmazione adottato spesso pone qualche limitazione sulla scelta dell'Application Server. Per quanto riguarda i database, si potrà optare liberamente per l'approccio che si preferisce. Un po’ perché i linguaggi dispongono un po’ tutti di driver per ogni DBMS, po’ per il superamento di determinati preconcetti sui confini tra paradigma relazionale e NoSQL: ormai è chiaro che qualsiasi tipo di strato di persistenza può essere realizzato altrettanto bene con MariaDB, con MongoDB o Redis. A questo punto vale comunque la pena riflettere ancora su quanto sottolineato al punto precedente: Jelastic permette con grande facilità di strutturare il proprio lavoro su container e dato che questi dialogano tra loro attraverso protocolli di rete neutri perché non diversificare l'architettura su vari linguaggi a seconda dei casi? Si potrebbero pensare, ad esempio, interfacce web con framework Javascript che dialogano con strati di API sviluppati in Python, Node.js o perfino in linguaggio Go. Tali API proteggerebbero database che potrebbero essere, a seconda delle strutture dati, diversificati tra relazionali e NoSQL.
- Sviluppo: dopo la scelta degli strumenti arriva il momento dello sviluppo dell'applicativo vero e proprio. Jelastic favorisce quanto più possibile anche la collaborazione e la condivisione del codice mediante repository Git/SVN. Pertanto conviene organizzare il lavoro su uno o più team e diversificare le linee di sviluppo nella maniera più opportuna, lasciandole confluire sulla piattaforma Cloud per i test che via via si svolgeranno.
- Deployment: questo è l'approdo finale alla piattaforma. Con Jelastic possiamo seguire varie strade: upload diretto delle componenti sviluppate in locale (si fa un archivio e lo si carica); passaggio per repository di codice basati su Git e SVN; incapsulamento delle componenti in immagini Docker e successiva importazione direttamente nei container dell'architettura Jelastic.
- Test: aspetto importante è la verifica delle funzionalità dell'applicazione. Intendiamo in questo caso, come si può immaginare, testing automatico da effettuare mediante specifici framework. Parte del codice può essere sottoposta a test, anche prima del caricamento sulla piattaforma: pensiamo ad esempio agli unit test su librerie e codice interno alle componenti. Per i test di integrazione, si deve necessariamente caricare il componente insieme ad altre parti e ciò può richiedere coordinamento con altri team di sviluppo. Inoltre, sui test influisce la visibilità delle componenti: se una componente è pubblica, può essere sottoposta a test anche dall'esterno con appositi tool, mentre ciò non è possibile per container con visibilità privata (e questo non capita di rado). In tali casi, può essere molto utile caricare ulteriori container che non fanno parte dell'architettura di produzione, ma che siano finalizzati solo a svolgere il testing di altri container non visibili dall'esterno. Anche in questo caso le possibilità sono molte, ed è particolarmente importante definire bene i tempi dei test. Andrebbero eseguiti per le varie componenti appena possibile, poiché in caso di loro fallimento sarebbe necessario tornare indietro alla fase di sviluppo - se non addirittura di progettazione.
