Per creare la propria applicazione web al giorno d'oggi, non è sufficiente saperla sviluppare. Un aspetto importante è la configurazione degli strumenti per il deploy dell'applicazione, il monitoraggio, così come la gestione e l'amministrazione dell'ambiente in cui essa opera. L'era del deploy manuale sta scomparendo, anche per i piccoli progetti, gli strumenti di automazione possono apportare benefici tangibili. Durante un deploy "manuale", spesso possiamo dimenticare di trasferire qualcosa, prendere in considerazione un dettaglio, eseguire un test dimenticato; questa lista potrebbe continuare per molto tempo.
Questo articolo può essere utile a coloro che stanno appena iniziando a comprendere i fondamenti della creazione di applicazioni web e vogliono fare un po' di chiarezza sui termini e le convenzioni di base.
Pertanto, la costruzione di applicazioni può essere suddivisa in 2 parti: tutto ciò che riguarda il codice dell'applicazione e tutto ciò che riguarda l'ambiente in cui questo codice viene eseguito. Il codice dell'applicazione è a sua volta suddiviso in codice server (quello che viene eseguito sul server, come: logica di business, autorizzazione, archiviazione dei dati, ecc.) e codice client (quello che viene eseguito sulla macchina dell'utente: spesso l'interfaccia e la logica ad essa associata).
Iniziamo, dunque, con l'ambiente.
La base per il funzionamento di qualsiasi codice, sistema o software è il sistema operativo, quindi di seguito esamineremo i sistemi più popolari presenti sul mercato dell'hosting e daremo una breve caratterizzazione di ciascuno:
Windows Server – la famigerata Windows, ma nella sua versione server. Alcune funzionalità disponibili nella versione client (normale) di Windows non sono presenti qui, ad esempio, alcuni servizi per la raccolta delle statistiche e software simile, ma è presente un insieme di utilità per l'amministrazione della rete e software di base per il deploy server (web, ftp, ...). In generale, Windows Server appare come una normale Windows, emette suoni come una normale Windows, tuttavia, costa il doppio del suo corrispondente normale. Tuttavia, considerando che il deploy dell'applicazione sarà molto probabilmente effettuato su server dedicati/virtuali, il costo finale per te potrebbe aumentare, ma non in modo critico. Poiché la piattaforma Windows occupa una posizione predominante nel mercato dei sistemi operativi per utenti, la sua edizione server sarà la più familiare per la maggior parte degli utenti.
Unix-un sistema simile. Il lavoro tradizionale in questi sistemi non prevede la presenza di un'interfaccia grafica familiare, offrendo all'utente come elemento di controllo solo una console. Per un utente inesperto, lavorare in questo formato può rappresentare una difficoltà, come dimostra l'uscita di un editor di testo piuttosto popolare. Vim, la questione relativa a questo ha già accumulato oltre 1,8 milioni di visualizzazioni in 6 anni. I principali distribuzioni (versioni) di questa famiglia sono: Debian - una distribuzione popolare, le versioni dei pacchetti in essa sono principalmente orientate su LTS (Long Term Support – supporto a lungo termine), il che si traduce in un'affidabilità e stabilità piuttosto elevate del sistema e dei pacchetti; Ubuntu – contiene distribuzioni di tutti i pacchetti nelle loro ultime versioni, il che può influire sulla stabilità, tuttavia consente di utilizzare la funzionalità fornita con le nuove versioni; Red Hat Enterprise Linux – un sistema operativo, posizionato per un uso commerciale, è a pagamento, ma include supporto da parte dei fornitori di software, alcuni pacchetti proprietari e pacchetti di driver; CentOS – una variazione opensource di Red Hat Enterprise Linux, si distingue per l'assenza di pacchetti proprietari e supporto.
Per coloro che stanno appena iniziando a esplorare questo campo, la mia raccomandazione sarà utilizzare sistemi Windows Server, oppure Ubuntu. Se consideriamo Windows, la prima cosa è la familiarità del sistema, Ubuntu – maggiore tolleranza agli aggiornamenti e, ad esempio, meno problemi nell'avviare progetti su tecnologie che richiedono nuove versioni.
Quindi, una volta scelta l'OS, passiamo alla scelta degli strumenti che consentono di distribuire (installare), aggiornare e monitorare lo stato dell'applicazione o delle sue parti sul server.
La prossima decisione importante sarà - l'hosting della tua applicazione e del server per essa. Al momento, le tre strade più comuni sono:
- Ospitare (mantenere) il server autonomamente - è l'opzione più economica, ma dovrai ordinare un IP statico dal provider, per evitare che il tuo sito cambi indirizzo nel tempo.
- Affittare un Server Dedicato (VDS) - e gestirne autonomamente l'amministrazione e la scalabilità dei carichi.
- Pagare (spesso offrono la possibilità di provare gratuitamente le funzionalità della piattaforma) un abbonamento a un servizio di cloud hosting, dove è piuttosto diffuso il modello di pagamento per le risorse utilizzate. I rappresentanti più noti di questo settore sono: Amazon AWS (offre un anno gratuito di servizi, ma con un limite mensile), Google Cloud (offre 300$ di credito, spendibili in un anno per i servizi cloud hosting), Yandex.Облако (offre 4000 rubli per 2 mesi), Microsoft Azure (offre accesso gratuito a servizi popolari per un anno, + 12.500 rubli per qualsiasi servizio in un mese). In questo modo, puoi provare uno qualsiasi di questi provider senza spendere un centesimo, ma ricevendo un'idea del livello e della qualità dei servizi erogati.
A seconda del percorso scelto, in seguito cambierà solo il fatto che, in gran parte, la responsabilità per un'area specifica di gestione ricade su di te. Se gestisci il servizio da solo, devi capire che eventuali interruzioni di corrente, di connessione a Internet, del server stesso e del software installato su di esso – tutto questo ricade interamente sulle tue spalle. Tuttavia, per scopi di formazione e test, questo è più che sufficiente.
Se non hai una macchina in più in grado di fungere da server, allora potresti voler considerare il secondo o terzo percorso. Il secondo caso è simile al primo, con l'eccezione che trasferisci la responsabilità per la disponibilità del server e la sua potenza sulle spalle del fornitore di hosting. L'amministrazione del server e del software è ancora sotto il tuo controllo.
E infine, l'opzione di affittare capacità dai provider cloud. Qui puoi impostare una gestione automatizzata praticamente di qualsiasi cosa, senza dover scendere troppo nei dettagli tecnici. Inoltre, invece di una sola macchina, puoi avere più istanze (esemplari) eseguite in parallelo, che possono, ad esempio, occuparsi di diverse parti dell'applicazione, senza differire molto nel costo rispetto all'acquisto di un server dedicato. Inoltre, qui sono disponibili strumenti di orchestrazione, containerizzazione, deploy automatico, integrazione continua e molto altro! Alcune di queste cose le esamineremo di seguito.
In generale, l'infrastruttura del server appare così: abbiamo quello che viene chiamato «orchestratore» (l'«orchestrazione» è il processo di gestione di più istanze di server), che gestisce le modifiche all'ambiente su un'istanza del server, un contenitore di virtualizzazione (opzionale, ma molto frequentemente utilizzato), che consente di suddividere l'applicazione in strati logici isolati, e un software per l'Integrazione Continua – che permette di aggiornare il codice distribuito tramite «script».
Quindi, l'orchestrazione ti consente di visualizzare gli stati dei server, di eseguire il «rolling out» o il «rollback» degli aggiornamenti dell'ambiente del server, e così via. In un primo momento, questo aspetto difficilmente ti riguarderà, poiché per orchestrare qualcosa è necessario avere diversi server (si può anche avere uno solo, ma a che pro?), e per avere diversi server è necessaria una domanda per essi. Tra gli strumenti di questo campo, il più noto è Kubernetes, sviluppato Google.
Il passo successivo è la virtualizzazione a livello di OS. Attualmente, il concetto di «containerizzazione» ha guadagnato una vasta diffusione, derivante dallo strumento Docker, fornendo funzionalità di contenitori isolati l'uno dall'altro, ma che vengono eseguiti nel contesto di un unico sistema operativo. Cosa significa questo: in ciascuno di questi contenitori è possibile eseguire un'applicazione, o anche un insieme di applicazioni, che penseranno di essere le uniche presenti nell'intero sistema operativo, senza sospettare nemmeno dell'esistenza di qualcun altro su quella macchina. Questa funzione è molto utile sia per eseguire applicazioni identiche di versioni diverse, sia semplicemente per applicazioni in conflitto, e anche per suddividere porzioni di un'applicazione in strati. Questo stampo di strati può successivamente essere registrato in un'immagine, che può essere utilizzata, ad esempio, per il deployment dell'applicazione. Cioè, installando questa immagine, e distribuendo i contenitori che contiene, si ottiene un ambiente pronto per eseguire la tua applicazione! Nella fase iniziale, puoi utilizzare questo strumento sia per scopi educativi, sia per ottenere un vantaggio reale, distribuendo la logica dell'applicazione su diversi strati. Tuttavia, è opportuno dire che la containerizzazione non è necessaria per tutti, e non sempre. La containerizzazione è giustificata nei casi in cui l'applicazione è "frammentata", suddivisa in piccole parti, ognuna responsabile di un compito specifico, quella che viene comunemente definita "architettura a microservizi".
Inoltre, oltre a fornire un ambiente, è necessario garantire anche un corretto deployment dell'applicazione, che comprenda varie trasformazioni del codice, installazioni di librerie e pacchetti associati all'applicazione, esecuzioni di test, notifiche su queste operazioni e così via. Qui dobbiamo prestare attenzione a un concetto come "Integrazione Continua" (CI – Continuous Integration). Gli strumenti principali in questo campo attualmente sono Jenkins (un software per CI, scritto in Java, che potrebbe sembrare un po' complesso all'inizio), Travis CI (scritto in Ruby, soggettivamente, leggermente più semplice di Jenkins,tuttavia, è comunque necessario avere alcune conoscenze nella configurazione del deployment), Gitlab CI (scritto in Ruby e Go).
Quindi, dopo aver parlato dell'ambiente in cui la tua applicazione dovrà operare, è finalmente giunto il momento di esaminare gli strumenti che il mondo moderno ci offre per creare queste applicazioni.
Iniziamo dalle basi: Backend (backend) – parte server. La scelta del linguaggio, del set di funzioni principali e della struttura predefinita (framework) qui è determinata principalmente da preferenze personali, ma è comunque opportuno menzionare per considerazione (l'opinione dell'autore sui linguaggi è piuttosto soggettiva, sebbene si proponga di fornire una descrizione imparziale):
- Python è un linguaggio abbastanza amichevole per l'utente inesperto, perdona alcuni errori, ma può essere anche abbastanza severo con lo sviluppatore, affinché non commetta errori gravi. È già un linguaggio di programmazione maturo e ben definito, apparso nel 1991.
- Go è un linguaggio sviluppato da Google, anch'esso molto amichevole e comodo, facile da compilare e ottenere un file eseguibile su qualsiasi piattaforma. Può essere semplice e piacevole, ma anche complesso e serio. È fresco e giovanile, apparso relativamente di recente, nel 2009.
- Rust è un po' più vecchio del suo collega precedente, rilasciato nel 2006, ma è ancora relativamente giovane rispetto ai suoi simili. È orientato a sviluppatori più esperti, pur cercando di risolvere molte delle attività a basso livello per conto del programmatore.
- Java è un veterano dello sviluppo commerciale, emerso nel 1995, ed è uno dei linguaggi più utilizzati nello sviluppo di applicazioni aziendali oggi. Con i suoi concetti di base e la complessità della configurazione dell'ambiente di esecuzione, può diventare piuttosto complicato per un principiante.
- ASP.net è una piattaforma per lo sviluppo di applicazioni, rilasciata da Microsoft. Per scrivere funzioni, si utilizza principalmente il linguaggio C# (si pronuncia C-sharp), apparso nel 2000. Per complessità, è paragonabile a un livello tra Java e Rust.
- PHP è stato originariamente utilizzato per il pre-processing di HTML, attualmente, sebbene mantenga un assoluto predominio nel mercato dei linguaggi, si osserva una tendenza al calo del suo utilizzo. Caratterizzato da una bassa soglia di ingresso e dalla facilità di scrittura del codice, ma, allo stesso tempo, nello sviluppo di applicazioni piuttosto ampie, la funzionalità del linguaggio potrebbe risultare insufficiente.
E la parte finale della nostra applicazione – la più tangibile per l'utente – Frontend (frontend) – è il volto della tua applicazione, è proprio con questa parte che l'utente interagisce direttamente.
Senza entrare nei dettagli, il moderno frontend si basa su tre pilastri, framework (e non solo), per la creazione di interfacce utente. Di conseguenza, i tre più popolari sono:
- ReactJS – non è un framework, ma una libreria. In effetti, differisce dal titolo orgoglioso di framework solo per l'assenza di alcune funzionalità 'out of the box' e per la necessità di installarle manualmente. Esistono diverse varianti di 'preparazione' di questa libreria, che formano dei veri e propri framework. Può risultare un po' complicato per i principianti, a causa di alcuni principi di base e della configurazione piuttosto complessa dell'ambiente di sviluppo. Tuttavia, per un avvio veloce, è possibile utilizzare il pacchetto 'create-react-app'.
- VueJS – è un framework per la creazione di interfacce utente. Tra questa triade, merita giustamente il titolo di framework più user-friendly; per sviluppare in Vue, la soglia di ingresso è inferiore rispetto agli altri blasonati fratelli. Inoltre, tra di loro è il più giovane.
- Angular – è considerato il più complesso dei framework citati, ed è l'unico che richiede la presenza di TypeScript (un'estensione del linguaggio Javascript). È spesso utilizzato per la creazione di grandi applicazioni aziendali.
Riassumendo quanto sopra, si può concludere che oggi l'implementazione di un'applicazione è radicalmente diversa rispetto a come si svolgeva in passato. Tuttavia, nessuno vieta di eseguire il 'deploy' alla vecchia maniera. Ma ne vale la pena, rispetto al tempo risparmiato all'inizio, considerando il gran numero di etti che il programmatore che ha scelto questo percorso dovrà affrontare? Credo che la risposta sia 'no'. Investendo un po' più di tempo per familiarizzare con questi strumenti (e non ce ne vuole molto, poiché è necessario capire se siano necessari nel progetto attuale o meno), sarà possibile recuperare quel tempo, riducendo significativamente, ad esempio, i casi di errori fantasma, legati all'ambiente e che si manifestano solo sul server di produzione, le notti trascorse a capire cosa abbia causato il crash del server e perché non riesca a riavviarsi, e molto altro.
Fonte: habr.com
