Se vendi prodotti soggetti a forte domanda (biglietti, collezioni in edizione limitata, prenotazioni, scorte limitate), ti sarà sicuramente capitato di discutere della necessità di rendere il sito scalabile. Di solito la discussione si conclude in uno dei due modi seguenti: cambiare piattaforma oppure aggiungere una soluzione improvvisata e sperare per il meglio.
Nessuna delle due è una vera soluzione. Una è costosa, lenta e rischiosa. L’altra è un insieme di soluzioni puntuali installate sotto pressione, di solito la settimana prima dell’inizio dei saldi.
C'è una terza opzione, che è sempre stata presente nel nostro prodotto. L'abbiamo riprogettata ed è già disponibile nel vostro pannello di controllo.
Abbiamo iniziato con un proxy inverso. Poi lo abbiamo visto trionfare in silenzio.
Il primo CrowdHandler era un proxy inverso. Bastava indirizzarlo verso qualsiasi sito web per ottenere una coda che non poteva essere aggirata, senza alcuna integrazione di codice. Nessun plugin. Nessun SDK. Solo DNS.
Quando nel 2021 abbiamo rilanciato il servizio come SaaS self-service, quel modello sembrava ormai superato. Sempre più clienti gestivano le proprie CDN e, quando c’è già un edge in funzione, inserirvi un worker è più vantaggioso che concatenare un altro proxy davanti ad esso. Abbiamo quindi rilasciato una famiglia di integrazioni edge e SDK, lasciando che gli utenti scegliessero quella più adatta al proprio stack. L’implementazione DNS è rimasta nella gamma per chiunque desiderasse una soluzione veloce e non aggirabile.
Poi, senza troppo clamore, è diventato uno degli strumenti più affidabili che gestiamo. Si posiziona davanti alla vostra infrastruttura anziché al suo interno, quindi il vostro server non deve mai sostenere i costi legati alla verifica e al reindirizzamento degli utenti, e tutto ciò che abbiamo imparato in anni di esperienza in materia di scalabilità risiede nel nostro livello, anziché nel vostro codice. Per la maggior parte dei siti WordPress, rappresenta un’integrazione migliore rispetto al nostro plugin per WordPress. Ci rendiamo conto di come possa suonare.
Il programma di installazione parte ora dal presupposto che tu abbia già qualcosa davanti a te
L'onboarding è un processo guidato in tre fasi: emissione del certificato, impostazione dell'origine, attivazione di CrowdHandler.
Abbiamo inoltre rivisto la soluzione per un caso che si è rivelato molto comune: l'esecuzione della nostra implementazione DNS dietro un altro proxy inverso, che nella maggior parte dei casi è Imperva. Se ci state integrando sopra un WAF o un livello di sicurezza già esistente, la procedura di configurazione lo rileva fin dalla prima schermata, anziché solo dopo il terzo ticket di assistenza.
Metti la finestra in cache. Metti il registratore di cassa in coda.
È questo che conta.
Ogni sito è in realtà composto da due siti distinti. I contenuti di marketing sono identici per tutti i visitatori e, una volta memorizzati nella cache, sono scalabili praticamente a costo zero. Il percorso transazionale — carrello, checkout, prenotazione — è invece unico per ogni utente, richiede un uso intensivo del database e non è mai veramente scalabile. Se li tratti come un unico insieme, ti ritroverai con le caratteristiche peggiori di entrambi.
Appcelerator ora ti permette di impostare questa configurazione a livello di URL, direttamente dal pannello di controllo. Imposta una regola di comportamento e la tua pagina di destinazione verrà servita dal punto di presenza AWS più vicino al visitatore. Nessun controllo della coda. Nessuna attesa. Nessun viaggio di andata e ritorno verso il tuo server di origine. Per la maggior parte degli utenti, la pagina viene caricata più velocemente di quanto il tuo server potrebbe mai fare.
Non appena si avvia un percorso di acquisto o di prenotazione, si viene inseriti nella coda e quelle pagine vengono fornite senza essere memorizzate nella cache, come è necessario che sia.
Sembra semplice. Separare gli aspetti di marketing da quelli transazionali è il segreto di un’architettura web scalabile, e la maggior parte dei team lo impara a proprie spese, durante una vendita, alle dieci del mattino. La differenza, in questo caso, è che è possibile applicarlo a posteriori — a un sito che nessuno ha progettato in questo modo — tramite un proxy inverso e un pannello di controllo, invece che con un progetto di migrazione su una nuova piattaforma.
La coda è l'elemento visibile. La scalabilità è il prodotto.
Se ci pensate come gli “esperti delle code”, Appcelerator sembra un modo più semplice per configurare una coda. Ed è proprio così.
Ma guardate cosa fa in una giornata normale, senza offerte speciali né code in corso. Fornisce i vostri contenuti memorizzabili nella cache dalle sedi periferiche di AWS in tutto il mondo, ognuna delle quali è più vicina ai vostri utenti rispetto alla vostra origine. Assorbe il traffico che il vostro server non vede mai. Mantiene un quadro in tempo reale delle prestazioni del vostro sito. Ed è pronto a regolare l’accesso ai vostri percorsi transazionali nel momento stesso in cui questi vengono sottoposti a pressione.
Poiché tutto passa attraverso un unico livello, le parti si alimentano a vicenda. La cache riduce il carico che arriva al tuo server di origine. Un server di origine meno carico sostiene un tasso di transazioni più elevato. Un tasso di transazioni più elevato significa che la coda accetta gli utenti più velocemente, il che si traduce in tempi di attesa più brevi — o, in una giornata tranquilla, nell’assenza totale di coda. Nel frattempo, lo stesso livello monitora i tempi di risposta sui percorsi rilevanti, così quando la domanda registra un picco, la velocità di accettazione riflette ciò che il sito è effettivamente in grado di gestire in quel momento, piuttosto che una cifra ipotizzata da qualcuno durante una riunione di pianificazione.
Cosa stai effettivamente attivando
Una coda non aggirabile. Caching di livello CDN per i contenuti che devono essere memorizzati nella cache. Transazioni protette da coda per i percorsi che ne necessitano. Misurazione continua delle prestazioni. Nessuna integrazione del codice.
Punta il tuo DNS verso di noi e l'architettura che avresti dovuto avere verrà applicata davanti a quella che hai effettivamente. Il tuo server di origine non deve nemmeno sapere che sta succedendo. Il tuo CMS non ha bisogno di alcun plugin. I tuoi sviluppatori non devono intervenire se non per approvare una modifica al DNS.
È in diretta oggi
Appcelerator è ora disponibile nel tuo pannello di controllo, nelle impostazioni di distribuzione del tuo dominio.
Se utilizzi il nostro plugin per WordPress, o se hai rimandato un’integrazione adeguata perché ti sembrava un progetto troppo complesso dal punto di vista tecnico, vale la pena dedicarci dieci minuti del tuo tempo. E se hai bisogno di una mano per capire quali dei tuoi URL debbano essere inseriti da una parte o dall’altra della linea cache/coda, contattaci: è un argomento che ci piace approfondire.
Hai in programma una promozione, un lancio o una campagna che potrebbe mettere alla prova tutto questo? Iscriviti gratuitamente a CrowdHandler.