Le tecnologie dietro la nuova Area Cliente e il Site Tools

Di recente abbiamo annunciato il lancio della nostra nuova Area Cliente e del Site Tools. Il nostro COO ne ha parlato dal punto di vista commerciale e dell’importanza di questo progetto per la nostra crescita futura. Io invece, vorrei darvi una prospettiva tecnica sul perché vediamo queste nuove interfacce come una pietra miliare per SiteGround.

SiteGround è sempre stata prima di tutto una società di servizi. Tuttavia, per molti anni, la nostra crescita aziendale è stata strettamente legata alla nostra evoluzione tecnica. Più software sviluppiamo internamente, più la qualità del nostro servizio aumenta, con un effetto positivo anche sulla nostra reputazione. Non solo, abbiamo anche dimostrato di essere un’azienda high-tech che produce soluzioni software potenti e intelligenti, sempre tra le prime al mondo a implementare le tecnologie più innovative.

Quindi, quando ci siamo resi conto che molte delle nostre idee venivano rallentate o rese impossibili dalle limitazioni della piattaforma utilizzata, abbiamo avuto il coraggio di pensare più in grande e di andare oltre ciò che il mercato offriva. Abbiamo voluto osare e ricreare tutto dalle fondamenta.

La sfida

Dal punto di vista aziendale, volevamo gestire una piattaforma (frontend e backend) che funzionasse su qualsiasi dispositivo, avesse un aspetto moderno, fosse leggera, veloce, sicura e facilmente scalabile. Traducendolo in termini tecnici, abbiamo individuato i seguenti obiettivi:

1. Velocità e UX avanzata

Abbiamo deciso di utilizzare applicazioni single-page in quanto tecnologia indispensabile per un’esperienza web più veloce.

2. Scalabilità e sicurezza

Abbiamo deciso di adottare la filosofia dei micro-servizi e basare tutto sulle API. In questo modo, il sistema può scalare più facilmente e gli incidenti hanno un perimetro inferiore di danno.

Quando hai molti servizi, tuttavia, l’autenticazione e l’autorizzazione rappresentano un grosso problema. Quindi avevamo bisogno di una soluzione sicura, rapida e semplice per il problema del Cross-Origin Resource Sharing (CORS), per il quale abbiamo scelto di utilizzare i web token JSON.

Operare su larga scala quando si hanno milioni di siti ospitati su centinaia di migliaia di container, richiede organizzazione, ricerca di servizi e un layer di messaggistica affidabile per i quali presenterò Consul e NSQ.

Infine, osservabilità, monitoraggio e notifica, sono fondamentali data la complessità del sistema. Per questi, utilizziamo Prometheus e Grafana.

Le soluzioni

1. Applicazioni single-page con React e Redux

Tre anni fa, quando abbiamo iniziato a lavorare al progetto, sapevamo che le applicazioni single-page stavano diventando sempre più popolari perché consentivano una migliore esperienza utente, tempi di caricamento delle pagine più rapidi, design modulare e altro ancora. Anche l’ecosistema SPA si stava evolvendo rapidamente. C’erano molti framework JavaScript come AngularJS, ReactJS e Vue.js. Sembrava naturale e ovvio che quando si parlava di qualcosa di leggero, veloce e basato su API, l’applicazione single-page era la risposta. Dopo alcuni test con diversi framework, abbiamo deciso di utilizzare ReactJS + Redux per la nuova Area Cliente e il SIte Tools, poiché mostravano i migliori risultati in termini di prestazioni.

Caricamento veloce della pagina

Abbiamo due principali applicazioni single-page. Una è l’app Area Cliente e l’altra è il Site Tools. Sono entrambi usati ogni ora da migliaia di persone e il numero è in aumento. Portare la logica dell’applicazione nei browser degli utenti, dove JS viene eseguito localmente, ha reso le cose più veloci. Il motivo è che nel backend avviene una minore manipolazione dei dati. Inoltre, le nostre app hanno una cache degli oggetti con CDN. Questo rende davvero veloce per gli utenti di tutto il mondo caricare rapidamente l’app e iniziare a usarla.

Guida allo stile unificata

Le applicazioni single-page consentono di lavorare con componenti pronti che sono riutilizzabili e fanno sì che le interfacce seguano determinati standard. Per le nostre, abbiamo scritto una guida di stile, che rende le nostre interfacce omogenee e ci permette di scrivere nuovo codice più velocemente. Solo la repository della guida di stile, con tutti gli esempi, è di circa 550.000 righe di codice!

Poiché lo sviluppo è piuttosto ampio e in crescita e il codice con cui lavoriamo è voluminoso, dovevamo assicurarci che i nostri standard fossero rispettati e non condizionati dai cambiamenti. Ecco perché abbiamo coperto il codice con i test Visual ed e2e (Cypress). Se una modifica del codice cambia visivamente una determinata pagina in modo significativo, veniamo avvisati e possiamo persino interrompere automaticamente le build e il deploy del codice.

2. API RESTful e micro servizi

Ora abbiamo oltre 100 API che possono essere utilizzate per gestire un singolo sito ospitato sui nostri server. Strumenti come l’installazione WordPress, l’emissione di un certificato SSL privato, la creazione di un account email, la creazione di nuovi database MySQL, l’aggiunta di chiavi SSH e persino la migrazione di siti tra server, vengono effettuati tramite API. Vediamo insieme i vantaggi che ci offrono:

Favoriscono l’utilizzo di linguaggi differenti

Abbiamo ingegneri software che scrivono nei seguenti linguaggi/framework per la nostra piattaforma:

• PHP (Symfony, Zend Framework)
• Perl (Dancer)
• Go
• Python
• JavaScript (ReactJS, AngularJS), TypeScript

Per essere sicuri che tutte le parti potessero parlare tra loro, avevamo bisogno di API RESTful per collegare la comunicazione.

Il design delle API RESTful è ben conosciuto

La cosa positiva delle API RESTful è che praticamente tutti gli sviluppatori hanno familiarità con e le comprendono. Ciò significa che quando abbiamo bisogno di aggiungere nuove funzionalità non dobbiamo formare gli sviluppatori o far loro apprendere tutti i pro e contro del sistema. Possono semplicemente concentrarsi sul nuovo pezzo di codice necessario e integrarlo nel sistema.

I nostri partner possono utilizzare le API

Il fatto che sia tutto basato su API semplifica l’accesso ai partner e consente loro di creare siti, installare un CMS o eseguire altre funzioni sulla nostra piattaforma. Ciò ci rende flessibili ed è una buona base per la nostra futura crescita aziendale.

Personalizzazione dell’accesso utente

Le API RESTful applicano il principio CRUD che dice che ogni oggetto manipolato dall’API dovrebbe supportare le seguenti 4 funzioni: creazione, lettura, aggiornamento, eliminazione. Insieme alla rappresentazione unificata delle risorse REST, ciò consente una facile separazione delle azioni, un accesso personalizzato e il controllo dell’utente.

Insieme ai web token JSON, abbiamo utilizzato le API per fornire livelli di accesso personalizzati nelle nostre nuove interfacce. È ora possibile consentire a un operatore di creare account di posta per un nome di dominio, ma non avere accesso agli account di posta esistenti o ad altri strumenti. Per cominciare, abbiamo introdotto solo 3 ruoli utente: proprietario del sito, collaboratore e cliente white-label, ma abbiamo gettato le basi per poter aggiungere facilmente molte opzioni di personalizzazione in futuro. Il controllo degli accessi in base al ruolo, ci consente di fornire un accesso granulare a servizi e funzionalità specifici.

Identificazione e tracciamento dei problemi più semplice

Più granulare è la costruzione, più è facile isolare una parte non funzionante, sostituirla o sistemarla. Questo è uno dei principali vantaggi che vediamo dalla filosofia dei micro-servizi. Siamo in grado di tracciare e risolvere più facilmente i problemi con una funzione specifica fornita da un particolare servizio. Possiamo anche tracciare meglio le prestazioni e l’utilizzo dei diversi servizi in modo da poter ridimensionare le risorse della piattaforma e prevenire problemi.

3. Token Web JSON

Dal momento in cui abbiamo iniziato a lavorare su applicazioni single-page, sapevamo di dover in qualche modo ridimensionare il nostro setup di autenticazione e autorizzazione. Dato il numero di API che dialogano tra loro e gli utenti che interagiscono con queste API (che sono state distribuite su domini diversi), il vecchio sistema di autorizzazione non poteva essere usato. I due problemi principali che abbiamo avuto sono stati:

• Gestire i cookie del Cross-Origin Resource Sharing e le intestazioni HTTP non è semplice e volevamo evitarlo. La combinazione dei web token JSON con le nostre API, ci consente di risolvere questo problema.
• Scalare un sistema backend che controlla ogni richiesta API era una procedura terribile, dal punto di vista delle prestazioni delle sessioni.

Dopo alcune ricerche, abbiamo deciso di utilizzare i web token JSON per questa parte dell’infrastruttura. Abbiamo configurato un sistema di autenticazione e autorizzazione personalizzato. Questo porta diversi benefici come:

• Meccanismo di autorizzazione uniforme per diverse API
• Carico del server ridotto e meno DB hit
• Capacità di utilizzare questa soluzione su diversi domini
• Più facile ottenere scalabilità orizzontale
• Un livello di sicurezza più elevato per i nostri utenti
• Autenticazione unica (SSO)

4. Organizzazione e messaggistica

Più cresciamo, più server (come unità hardware) e container (come unità virtuale) operiamo. Il container Linux è l’unità principale della nostra infrastruttura, ma il modo in cui gestiamo questi container sta cambiando nel tempo. Ordinare nuovi server, distribuire un container con lo stack software necessario, aggiungere quel nuovo container a tutti i database che alimentano diversi servizi e API, tutto questo e altro richiede organizzazione. Per questa parte, abbiamo scritto molto codice specifico per la nostra piattaforma e i nostri processi. Tuttavia, dipendiamo fortemente da alcuni software per raggiungere i nostri obiettivi. Usiamo Consul di HashiCorp per l’individuazione dei servizi e l’automazione dei sistemi. La nostra piattaforma di messaggistica preferita è NSQ. Usiamo Ansible per automatizzare molte attività di fornitura e gestione software.

Due buoni esempi sono i sistemi di aggiornamento automatico Let’s Encrypt e WordPress rielaborati da noi. Essi venivano eseguiti localmente su ogni server di hosting, mentre ora si basano su un approccio distribuito. I server vengono automaticamente registrati nel sistema. I servizi utilizzano il rilevamento automatico fornito da Consul. Quindi vengono utilizzate le API sopra menzionate e l’emissione e il rinnovo dell’SSL avvengono per ogni nuovo nome di dominio che registriamo nel sistema. Lo stesso vale per ogni app che entra nel sistema di aggiornamento automatico di WordPress.

5. Prometheus / Grafana per l’osservabilità

Anche il modo in cui offriamo nuovi servizi è cambiato. Nel mondo nativo del cloud, non ci preoccupiamo più del fallimento dei singoli host. Nessun ingegnere nel NOC (centro operativo) viene chiamato quando questo accade. Non ci sono sistemisti che trattano macchine e servizi con amore. Ora monitoriamo l’intera infrastruttura tenendo presenti i seguenti obiettivi:

• Dobbiamo sapere quando le cose vanno male
• Siamo in grado di eseguire il debug e approfondire il contesto specifico
• Dobbiamo essere in grado di vedere i cambiamenti nel tempo e fare previsioni
• I dati dovrebbero essere facilmente consumati da altri sistemi e processi

Per rendere più specifico quanto detto sopra, ora stiamo ridefinendo gli scenari di “fallimento” e gli avvisi che riceviamo per ciascuno. Ad esempio, potremmo ricevere avvisi che richiedono l’interazione umana in caso di impatto diretto sull’utente, come quando viene interessato un servizio che influenza direttamente i siti dei clienti. Tuttavia, potremmo non aver bisogno di avvisi o dell’intervento umano in caso di guasto di un nodo specifico, poiché i dati vengono ridistribuiti automaticamente su altri nodi e non vi è alcun impatto sull’utente.

Quando lavoriamo su questi avvisi, ci proponiamo di passare dall’avviso ai sottosistemi che generano il problema. Affinché i nostri ingegneri possano fare una rapida analisi e offrire una soluzione, dobbiamo disporre di sufficienti dati. Sfruttiamo un tracciamento distribuito che ci consente di seguire le richieste specifiche degli utenti dai browser dei nostri clienti, attraverso più API e servizi, fino a quando non raggiungono database e/o storage engine. Ogni record relativo a una richiesta, nel sistema di tracciamento distribuito, ci fornisce informazioni sulla profilazione delle prestazioni e un modo per correlare i problemi con altri eventi. Utilizziamo il tracciamento distribuito per eseguire il debug più velocemente e ottimizzare il nostro codice.

Abbiamo scelto di utilizzare Prometheus e Grafana per la profilazione, la raccolta delle metriche, l’analisi dei registri e il tracciamento distribuito degli eventi. Siamo ora in grado di correlare informazioni provenienti da più fonti e rilevare o prevedere i problemi.

Conclusione

Il software che abbiamo dovuto scrivere per affrontare la sfida e fornire le soluzioni sopra descritte è enorme, ma abbastanza gratificante. Per concludere, vi lascio con alcuni numeri che arrivano dalle repository del nuovo software e dal nostro JIRA:

• 2.539.604 righe di codice
• Copertura test sul codice al 99%
• 9.250 task JIRA
• 199.560 parole nei task JIRA

Siamo particolarmente orgogliosi della copertura dei test sul codice. Anche se 2,5 milioni di righe di codice sono impressionanti, sappiamo che non si tratta di un valore che indica il successo. Il fatto che tutto il nostro codice sia coperto da test è, tuttavia, un grande risultato. Fin dall’inizio, abbiamo impostato il test sul codice come uno dei nostri criteri principali per fornire un software di qualità. La nostra nuova Area Cliente e il Site Tools dovevano garantire qualità, per non tradire il fantastico servizio a cui sono abituati i nostri clienti. Siate certi che ci impegniamo a fornire sempre un servizio di hosting di prima qualità, da adesso con strumenti di gestione e collaborazione ancora migliori, basati sulle migliori e più innovative tecnologie web al mondo.