Continuando ad approfondire la struttura dell’istanza WordPress appena configurata, possiamo apprezzarne la topologia nella figura che segue.
Vediamo l’elenco di componenti non come una semplice lista, bensì organizzato in una sorta di diagramma a blocchi che fornisce anche l’idea di quale di essi abbia un ruolo più o meno esposto al pubblico.
Nella fascia sinistra della finestra troviamo dall’alto verso il basso il Load Balancer, che riceve le connessioni in ingresso, poi il server web, lo strato di persistenza ed il blocco di storage esterno.
Ciò che ci interessa approfondire è l’impostazione delle opzioni di scalabilità e come tutto ciò influisca sui costi. Notiamo innanzitutto i colori nello schema a blocchi a sinistra: il Load Balancer è verde, l’Application Server è azzurro, il database arancione, lo storage grigio. Gli stessi colori vengono usati nella parte destra della finestra per indicare l’apporto che ognuno di essi fornisce alla formazione del costo totale.
Date le impostazioni di scalabilità verticale, i quattro componenti richiederanno almeno 7 cloudlet di tipo reserved, come spiega la formula in alto a destra (1+2+3+1=7). Gli addendi della somma sono i cloudlet che rispettivamente utilizzeranno le componenti nell’ordine in cui le abbiamo nominate: 1 per il Load Balancer, 2 per l’Application Server, 3 per il database ed 1 per lo storage. Ogni numero appare di un colore diverso, richiamando quello della componente nello schema a blocchi di sinistra.
I costi di ogni cloudlet vanno a costituire il costo minimo orario, equivalente a quel 0,057 euro che appare poco più in basso rispetto alla formula. Per le opzioni di scalamento verticale impostate, le quattro componenti potrebbero arrivare a 56 cloudlet (8+16+24+8, l’altra formula in alto a destra). Il prezzo orario massimo che si potrebbe sostenere equivale a 0,517 euro. Si noti che subito al di sotto dei prezzi di cui si è appena detto appare un’ulteriore barra che indica il livello del prezzo, ed è composta da segmenti colorati: ognuno di questi prende il colore dal componente cui si riferisce.
Per quanto riguarda la scalabilità orizzontale, abbiamo visto in precedenza che i fattori che la contraddistinguono sono visibili già prima di entrare nella finestra della topologia. Gli stessi fattori possono essere modificati nella sezione Horizontal Scaling che vediamo al centro dell’ultima figura. In questo caso, stiamo guardando le impostazioni dell’Application Server ed infatti il suo fattore di scalabilità orizzontale è impostato a 2. Tale valore incide sul costo ed una sua modifica diventerebbe subito evidente nella porzione destra della finestra. Proviamo a modificare il fattore di scalabilità orizzontale di AppServer da 2 a 4.
Notiamo nella figura che segue come ciò ha influito sul prezzo.
Come esercizio, si potrebbe ragionare su come tale modifica abbia influito nei vari passaggi di calcolo del prezzo orario.
I prezzi di Jelastic sono sicuramente competitivi, ma ci siamo dilungati sulla loro modalità di calcolo in quanto il Cloud permette di commisurare le risorse alle reali necessità contingenti, e di regolare di conseguenza i costi. Al di là degli aspetti tecnici, un progetto su una piattaforma come Jelastic va pianificato comprendendo bene qual è il range di prezzo su cui il costo potrebbe muoversi, e quanto ciò potrebbe essere sostenibile sull’investimento che si affronta.
Dobbiamo dire che, a seguito delle varie prove che abbiamo condotto, Jelastic ha dimostrato di possedere un’assoluta trasparenza sui prezzi. Ciò è evidente dall’utilizzo di colori e somme per spiegare la formazione del prezzo ma anche dai link sempre evidenziati che conducono ai pannelli di fatturazione e alla relativa documentazione (“Quotas & Pricing” e “How Princing Works”), nonché da un’ulteriore finestra esplicativa che si apre al passaggio del mouse sulla barra collocata al di sotto dei prezzi. Da questa otterremo una spiegazione ancora più approfondita sul perché la nostra installazione abbia un determinato costo orario.
