Cloud... from behind the scenes... (parte prima)

  • 23/04/2012 08:00:00

<p>Prima parte del mio punto di vista di quello che il Cloud e' non dal punto di vista commerciale/end-user ma dal punto di vista logico, organizzativo tecnico/back-end.</p>

Prima parte del mio punto di vista di quello che il Cloud e' non dal punto di vista commerciale/end-user ma dal punto di vista logico, organizzativo tecnico/back-end.

Si parla tanto di Cloud, questo nuovo modo di fare cio' che si fa da una vita... outsourcing. Tante (belle) promesse di servizi e risparmio economico. Le stesse cose che promettevano le soluzioni in hosting e housing nell'era odierna. Le offerte sono tante, interessanti ma pongono dei quesiti. Da CTO, il mio pensiero e' rivolto - una volta tanto - non a descrivere il bello del Cloud visto dal basso, lato IT e lato provider di servizi, e non dall'alto - per l'utenza finale. Un po' come quando, salendo di quota in aereo tra le nuvole, si passa da quelle temporalesche e portatrici di pioggia a quelle bianche e ammalianti viste dall'alto, al sole bianche e candide.

Implementare un'infrastruttura di servizi orientati al Cloud e' una cosa - secondo me - da visionari. Esco dalla scuola di pensiero in cui i piccoli provider siano quelli che lavorano meglio, poiche' dedicano maggiore attenzione alla qualita' del servizio e non alla quantita'. E' facile confondersi ed e' ancora piu' facile perdere la fiducia del Cliente, basti vedere quello che e' successo in casa qualche tempo fa con Aruba o, piu' in grande, quando e' andato off-line il servizio di Amazon o, purtroppo, RIM (BlackBerry). Gli incidenti capitano, e capiteranno. Le macchine perpetue non esistono e, diciamocelo, se esistessero dovremmo cambiare lavoro.

Gestire un'infrastruttura di servizi in Cloud prevede una quantita' di punti di vista, tecnici ed organizzativi. Partendo dal basso, verso l'alto:

  1. Alimentazione (impatto ambientale)
  2. Networking
  3. Infrastrutture server
  4. Sistemi operativi
  5. Applicazioni

Poi, in orizzontale su tutti, troviamo:

  1. Manutenzione ordinaria e straordinaria
  2. Sicurezza
  3. Amministrazione dei sistemi ordinaria (patch, gestione credenziali, aggiornamenti, backup, ecc)
  4. Amministrazione di sistema straordinaria

In tutti gli aspetti e' necessaria una visione d'insieme molto radicata nella progettazione dei sistemi. Qualsiasi movimento sulla scacchiera composta dai due elenchi di cui sopra si trascina appresso conseguenze importanti e che possono (pre)giudicare il successo di un fornitore di servizi. I CTO che affrontano l'idea, o sono chiesti di farlo, di iniziare un percorso di CSP (esistera'?) - o Cloud Service Provider - devono considerare aspetti che vanno molto al di fuori delle comuni competenze, e piu' i provider sono piccoli, piu' sono richieste ad essi capacita' adattive.

Quali partner scegliere per le proprie soluzioni? Come procedere in modo graduale per poter fornire livelli di servizio sempre migliori? Quali soluzioni tecnologiche rappresentano la soluzione piu' idonea per raggiungere i propri obiettivi di business?

Qui i CTO giocano una parte estremamente importante nel futuro di un CSP. Una loro errata decisione puo' avere impatti gravissimi sul successo od insuccesso di un fornitore. La lungimiranza di progettazione di un'infrastruttura destinata a fornire servizi ad una serie di entita' distinte (e che devono rimanere tali) e' molto piu' complessa ed articolata da gestire di una singola Azienda, o di una societa' che offre servizi di Location.

L'elemento - non cosi' scontato come si penserebbe - che diventa fondamentale per poter meglio avere idea di quali strade percorrere e' la conoscenza. La conoscenza tecnica che consente di adottare misure tecniche per raggiungere un obiettivo, ma anche la conoscenza del servizio offerto e dell'utenza che accede al Cloud. Un esempio pratico di questa idea potrebbe essere pensato come in questo breve esempio. Supponiamo che il Service Provider decida di erogare servizi di pubblicazione delle applicazioni attraverso una soluzione XenApp o XenDesktop. L'esempio e' riferito ad una analisi lato networking.

  1. [tecnico] l'aumento dell'utenza richiede un aumento di banda
  2. [marketing] gran parte dell'utenza utilizza dispositivi tablet e mobile mediante Vodafone (40% del totale)
  3. [tecnico] decisione di upgrade della banda con l'aggiunta di un carrier in datacenter (Vodafone)
  4. [servizio] aumento di banda sul datacenter
  5. [servizio] riduzione dei single point of failure grazie all'introduzione di nuovi carrier
  6. [servizio] miglioramento del servizio a tutta l'utenza mobile

Ecco che una soluzione di fatto gestita, o meglio pilotata dal Dipartimento Tecnico sfrutta (anziche' litigare) dipartimenti normalmente avversi (marketing) per ottenere vantaggi sempre maggiori all'interno della propria infrastruttura. Tali decisioni, naturalmente, si riflettono anche sull'intera infrastruttura di servizio.

[continua] Cloud... from behind the scenes (parte seconda)

  • Contatti

Data Protection & Copyright

RIGHTS CHAIN LTD.

Networking & IT

Coming soon

Social Profile