Server e dominio, legami e differenze

Spesso capita che mi si rivolga questa domanda, oppure interfacciandomi con i clienti capisco che non abbiano le idee molto chiare su cosa siano queste due entità e come siano legate tra di loro. Per molti addirittura non c'è differenza, come fossero una cosa unica.

Proviamo a fare chiarezza.

Come funziona un'applicazione web

Ogni software web (sito, e-commerce, web application ecc.) è, per definizione, un programma informatico, un software appunto. A differenza però dei programmi installati nel proprio computer, le applicazioni web non funzionano sul vostro computer, non sono installate lì.

Sfruttano la rete, il web, per essere distribuite dalla fonte ed essere poi fruite tramite il vostro browser preferito.

Il server

In particolare, il codice sorgente (migliaia di file alla matrix) vengono depositati su un server (un computer sempre connesso alla rete pubblica, accessibile e si spera sempre acceso) in modo che gli utenti possano "usare" questo codice - appunto via web - richiamando una pagina internet.

Il server (aka la macchina/virtual machine) è accessibile su internet tramite il suo indirizzo IP. L’indirizzo IP permette di identificare univocamente nel mondo una specifica risorsa di rete, come fosse il suo codice fiscale:

• digito l'IP corretto, finisco sul server dove c'è il codice di cui sopra e lo uso
• digito l'IP sbagliato e finisco nell’applicazione di qualcun altro.

Il dominio

È chiaro che diventa scomodo pensare di navigare il web digitando IP come se non ci fosse un domani, e qui viene in aiuto il dominio. Il dominio è l'etichetta con il tuo nome che appiccichiamo sulla macchina, in modo che digitando www.qualcosa.com l'utente finisca nell'IP di cui sopra.

Con il dominio, inoltre, definiamo la paternità, anche legale, del codice che rendiamo pubblico. Il cliente deve pertanto essere sempre intestatario sia del dominio che del server, poiché se il codice è suo allora anche tutto ciò che serve a farlo girare deve essere suo.

Ancora oggi, purtroppo, si riscontrano situazioni di clienti che hanno il dominio e/o la macchina intestata al fornitore e, nonostante sia tutto digitale, può risultare lungo e laborioso un semplice cambio di proprietà, soprattutto con certi provider.

Quindi che si navighi un progetto mediante il sicuramente più funzionale www.qualcosa al posto del becero IP, si sta usando stesso software, lo stesso codice, l’unico esistente. È solo una questione di nome visualizzato nella barra degli indirizzi.

Come sviluppare un’applicazione web

Ci sono mille teorie ed altrettante pratiche. Senza entrare troppo nel dettaglio possiamo dire che il lavoro che facciamo durante lo sviluppo, cioè quello di scrivere matrix, viene effettuato inizialmente nei nostri computer, non sul server. Trasformiamo i nostri computer in una specie di server, in modo che abbiano le stesse caratteristiche della macchina di produzione, cioè quella reale, quella "online", quella dell'IP. Si fa questa cosa per essere sicuri che il programma che stiamo scrivendo giri (funzioni) anche lì.

È come un "simulatore": se simulo in locale l'ambiente di produzione posso sviluppare senza dover attendere i tempi della rete per ri-caricare il codice ad ogni modifica (ci sono giorni in cui salvi centinaia di volte), e posso anche verificare più agilmente che sia tutto ok, dato che interrogare il mio pc è più veloce che interrogare un server che - quando è vicino - è a Francoforte o a Milano.

Tornando a noi, astraendo molto (lo preciso per i puristi) una volta che abbiamo finito di lavorare in locale, uniamo i nostri matrix in matrimonio tramite GIT (per chi si fosse perso il primo capitolo della saga lo può trovare qui). Successivamente li mettiamo sul server di produzione, che è sempre quello dell'IP di prima, in modo che si possa vedere da tutti coloro che sanno quell'IP, ovvero per adesso solo noi e il cliente.

Per fare un server ci vogliono le nuvole

Ma questi server, e questi IP, quando si parla di cloud, non nascono sugli alberi. Parte del lavoro è l'allestimento della macchina e l’allocazione dell’IP, ovvero la creazione dal nulla di un computer connesso alla rete, configurato con i programmi che ci servono (proprio come il computer dell'ufficio) e quindi la creazione, sempre dal nulla, di un nuovo IP che fino a quel momento non esisteva. Questa procedura di generazione di macchine (con il loro IP, backup, repository, sicurezza ecc. ecc.) la facciamo in cloud perchè funziona meglio e costa meno. È un’operazione che una volta ottenuto il lavoro va fatta il prima possibile, per due motivi sostanziali:

1. dopo le iniziali fasi di briefing, analisi e progettazione, il progetto esce momentaneamente dagli uffici tecnici per essere accolto nelle mani dei creativi. Durante il periodo in cui viene disegnato il layout, il reparto di sviluppo è fermo, in attesa che il progetto rientri con il suo bel vestito nuovo. Se, mentre loro disegnano, noi creiamo l’infrastruttura cloud server, allora faremo due cose nel tempo solare di una.
2. solo dal momento in cui è pronta la macchina è possibile rilasciare (mettere online) il codice che abbiamo in locale. Prima no. Del resto se non c'è il server dove lo potrei mai pubblicare? Se la macchina viene allestita subito, quando prendiamo la pillola rossa e avviamo i lavori potremo verificare sin dal primo istante ogni funzione con continui rilasci. Nonostante l’ambiente locale sia pressochè identico, ci sono sempre alcune sottili differenze. È l’immancabile bello della diretta. Se invece l’ambiente di produzione viene creato a fine lavoro, oltre a perdere il parallelismo del punto 1 rischiamo di scoprire a giochi fatti qualche problema (e doverlo risolvere in tempo che ovviamente a quel punto non avremo più, rischiando ritardi sulla consegna).

Per nostra politica, ed indiscutibile etica, i server vengono sempre intestati - cioè fatti pagare (incluso legalmente) - al cliente. Tra le mille opzioni, sofismi e filosofie incluse, ho scelto AWS come partner ideale a questo scopo, cioè Amazon (si, quella stessa Amazon), che come potrete immaginare di server ne ha più un paio, tanto da poterli vendere ed essere uno dei principali player mondiali.

Peraltro da poco è attiva la farm italiana, fresca fresca (letteralmente) e i nuovi progetti li stiamo tutti allocando lì. Così anche chi ha problemi di GDPR e dati all'estero è a posto.

Di solito a questo punto del discorso qualcuno, con tono di sfida dice: “Io non mi fido del cloud, non so dove siano i miei dati. Preferisco un bel server fisico in azienda, così lo vedo, è tutto sotto controllo e non va giù!!11!!1!.” (come se il poterlo guardare ne rendesse automaticamente sicuro il contenuto).

A parte che se in una giornata di lavoro dovesse andar giù AWS (avete visto Mad Max? Ecco...) l’ultimo dei problemi sarebbe il tuo progetto, dato che 1/3 di internet gira con loro e, di conseguenza, nemmeno la tua giornata lavorativa potrebbe continuare...

Ma se ciò non bastasse sia messo agli atti che il tanto adorato server fisico probabilmente è immerso in una rete che, stando alla qualità media riscontrata, almeno in Italia, è bucabile passando dalla stampante sulla scrivania del titolare con un corso di due ore su youtube.

Ad ogni modo il concetto non cambia, che si tratti di server fisico o di cloud la questione “scatola in cui mettere cose” ed “etichetta per riconoscerla” rimane.

Dato che di sicuro il cliente ancora non ha un account aws, strano ma vero, perchè fino a ieri pagava tutto all'ex fornitore e "aaah ma io non so mica niente di quelle cose lì" (come se il non saperle lo delegittimasse dal finire nel penale se succedesse qualche casino), ci occupiamo di creare per lui un account ex novo, dentro cui poi creare la nostra infrastruttura cloud (server, repo, backup, IP, sicurezza, database, e tutte le altre cose di matrix).

È un po' come aprire un profilo Facebook, se non fosse per il fatto che la prima cosa che il venale Bezos mi chiede, a differenza in questo senso del ben più hipster Mark, è una carta di credito (mica è il più ricco a caso).

Per questo motivo organizziamo una call con il cliente in cui farlo accedere all’account creato ed inserire i dati della sua carta di credito, senza che noi possiamo in nessun modo risalire ad alcuna informazione, per la massima sicurezza.

Terminare la configurazione però, proseguendo l’analogia con Facebook, non vuol dire avere automaticamente un profilo, degli amici e una wall su cui postare. Creare l'account non vuol dire avere tutto pronto. Anzi, abbiamo solo una scatola vuota in questo momento. AWS non sa cosa ti serva tra i suoi oltre 150 servizi. Devi attivarli tu e saperli orchestrare correttamente affinchè alla fine del giro tutto funzioni come ti aspettavi.

Progettata e allestita l’infrastruttura potremo finalmente eseguire il primo rilascio del famoso codice (una frase di una riga che richiede però molte molte ore di lavoro esperto e preciso).

La magagna (se no a che serviva tutto sto cinema?!)

Finito il nostro lavoro in locale? Si

Rilasciato sul server? SI

Ciao cliente, hai verificato via IP? Si

Tutto ok? Si.

Ottimo. Qui il nostro lavoro è finito.

Eppure il sito non si vede via www.qualcosa. Si, ma il nostro lavoro è finito lo stesso, se non hai acquistato altro. Perchè?

Perchè ora che la scatola è piena bisogna metterci l’etichetta, che non abbiamo noi.

Nella maggior parte dei casi il cliente ha già il dominio. Per fare in modo che il lavoro, che è già online, finito, visibile tramite IP, sia online visibile anche via dominio, è chi ha in mano il dominio che deve fare qualcosa, ovvero applicare la famosa etichetta.

Registrar e propagazione DNS

Questa procedura, in termini di click da fare, dipende da un milione di fattori (e dai tempi) decisi dal "registrar", che è l'ente preposto alla registrazione e mantenimento del dominio, cioè colui da cui il cliente l'ha acquistato (Aruba, Godaddy, Netsons, Register, AWS stessa volendo ecc.).

Il cliente, in quel momento, dopo che ha confermato che quanto visto via IP sia ok, deve (lui o chi per lui, ma comunque non noi), dare il via a questa procedura di metaforico incollaggio.

Non è ancora finita però, c'è un tempo tecnico da attendere, che questa volta non compete nemmeno il cliente (né tantomeno lo sviluppo che in questa storia non c'entra più niente), ma che ha a che fare con il registrar e la famosa "propagazione del DNS".

Immaginatevi come se tutti i provider di ogni nazione si incontrassero su Skype (o qualsiasi altra app di videocall che preferite, basta che non funzioni molto bene) e uno di loro, quello del cliente, dia a tutti l'informazione che un certo dominio da quel momento debba reindirizzare tutti gli utenti di internet verso un certo IP. C'è quello sveglio che capisce al volo e c'è quello con poca banda che ci mette un po' di più. Ma pian pianino questa info viene recepita da tutti.

Possono volerci anche 48/72 h, tipo per le Barbados, il Congo Belga e le isole che ne so in mezzo al niente; tendenzialmente se il cliente usa un fornitore italiano/europeo allora nel giro di poche ore, a volte minuti, dovrebbe essere tutto sistemato, ovvero digito www.qualcosa e vedo l’applicativo che prima vedevo solo digitando l'IP.

Proprio per via del fatto che non solo il cliente deve fare qualcosa, ma abbiamo in mezzo anche un ente terzo che (a volerla vedere terra terra) non c’entra con il contratto di fornitura in essere, ecco che è bene attivarsi il prima possibile, dato che operativamente abbiamo le mani legate. O finisce che il cliente realizza che "non si va online in tempo" (anche se "online", tecnicamente, c'eravamo già da eoni).

In ogni caso, diatriba del dominio smarcata, non ci sono due progetti diversi, nè due server diversi o due matrix diversi, ma lo stesso, unico progetto (del resto il cliente un progetto solo acquista, mica due). Quindi quel che vedevamo via IP è già "il progetto", è già "online", non lo diventa solo quando ci appiccichiamo il dominio.

Il problema è che con il dominio tutti lo possono vedere, anche gli altri, quello sì! Ecco perché è importante che la conferma del software in produzione venga data con assoluta certezza prima del puntamento del dominio.

Sensibilizzazione e consulenza

Noi, che in ASB\ crediamo fortemente nella formazione e nei clienti/partner più che nei clienti/acquirenti, solleviamo sempre l’argomento durante il briefing e non perchè si voglia mettere in difficoltà con questioni tecniche ma, al contrario, proprio per aver la possibilità di aiutare con la nostra esperienza.

In più, in fin dei conti, siamo di fatto obbligati a chiedere ed approfondire perchè il cliente si aspetta che, dopo il nostro lavoro, quanto acquistato sia visibile. Ricordandogli che, invece, noi oltre un certo punto non possiamo andare, sottolineiamo che anche lui è parte integrante del progetto nonchè l'unico preposto a chiudere il giro allacciando il dominio.

Facendolo, poi, ancora in fase preliminare di progetto gli diamo anche il tempo necessario perché si attivi subito a contattare chi di dovere, attenzionandolo sul fatto che di lì a pochi giorni gli arriverà un IP, il quale dovrà essere subito fatto puntare dal dominio. Perché i giorni passano, il nostro lavoro è e rimane finito, ma no www no party.