Riflessioni

Ancora su cloud e disservizi. Come si comportano i fornitori. Il turno di Amazon Web Services e Microsoft Office365

cmenzani cloud computing, Riflessioni , , , ,

In questo momento dove quasi tutti i grandi player dell’ITC sono attivi o hanno presentato le loro proposte sul cloud è importante seguirli anche nel loro comportamento davanti ai disservizi che inevitabilmente si trovano (e di conseguenza ci troviamo noi clienti) ad affrontare.

Amazon Web Services ad esempio, almeno per quanto ci riguarda ma non dubito che lo abbia fatto con tutti i propri clienti, dopo l’incidente causato da un fulmine agli inizi di agosto, ci ha presentato un (devo dire inaspettato e da noi non richiesta) billing scontato di diverse centinaia di euro.

Microsoft invece per il suo nuovo servizio Office365 ci invia stamani questa e-mail :

Gentile cliente,

L’obiettivo del team Office 365 è di fornire un servizio eccellente a tutti i clienti. L’8 settembre si è verificato un interruzione del servizio globale che ha colpito vari servizi di Office 365. Ci scusiamo per il disagio che questo inconviente ha causato a Lei e ai Suoi dipendenti.

Abbiamo preso l’impegno di comunicare ai nostri clienti, in modo onesto e trasparente, i disservizi e le azioni intraprese per impedirne il ripetersi.

• Cos’è successo?
º Una prima indagine ha rivelato che i clienti non hanno potuto accedere al servizio Office 365 a causa di un problema al Domain Name Service (DNS).

º La durata dell’incidente è stata approssimativamente dalle 20:00 PDT alle 23:30 PDT, lasso di tempo in cui i clienti non hanno potuto accedere al servizio Office 365.

º La Service Health Dashboard è stata regolarmente aggiornata nel corso di questo incidente, mantenendo informati i clienti, benché ci sia stato un breve momento in cui la Dashboard non è stata sempre raggiungibile.

• Quali azioni sono state intraprese per impedire il ripetersi di un simile incidente?

º Il problema alla rete del Data Center è stato risolto e stiamo analizzando la causa.

º Continuiamo a monitorare molto attentamente la situazione generale della rete per garantire ai nostri clienti un servizio di qualità.

Siamo consapevoli che ogni disservizio possa ripercuotersi negativamente sul Suo business. Come segnale concreto di impegno ad assicurare un servizio di alta qualità, Microsoft cambia la procedura di rimborso standard per questo incidente e rimborserà la Sua azienda proattivamente con un credito del 25% sulla fattura mensile. Il credito apparirà su una delle prossime fatture. Non è necessario contattare Microsoft per richiedere il rimborso. La procedura di rimborso può richiedere fino a 90 giorni di tempo.

 

Conclusioni

Oltre che a diffondere le potenzialità tecniche e di risparmio economico delle piattaforme in cloud ,  è  soprattutto  dalle risposte che i forniti di servizi riusciranno a dare al mercato a fronte degli “inevitabili” disservizi che si costruirà la fiducia del potenziale mercato, favorendo la migrazione della aziende in cloud.

Giudizio per il comportamento AWS e Office365 :  Positivo

Ma allora il cloud computing è una buona soluzione o no ? Riflessioni post disservizio di Amazon Web Services

cmenzani cloud computing, Riflessioni

Domenica sera il data center europeo con sede in Irlanda di Amazon Web Services (la piattaforma di cloud computing di Amazon, forse una delle prime, di sicuro la più famosa) a causa di una tempesta di fulmini si è trovato nelle condizioni di non poter fornire il servizio a molti dei suoi clienti e fra questi anche noi di Vivido utilizzatori di AWS da molto tempo .

Ovviamente abbiamo immediatamente avvisato i nostri clienti (si tratta di importanti catene alberghiere) sul disservizio che avrebbero dovuto sopportare. E questo è il problema principale e che ci sta più a cuore.

Ma adesso che la situazione di crisi è stata superata vorrei approfittarne per fare alcune considerazioni sull’utilizzo del cloud computing in generale.

E’ ovvio che la prima reazione da parte nostra è quella di disappunto e di impotenza , ed in alcuni casi leggendo i tweet con hastag #aws alcune reazioni sono state anche leggermente scomposte o comunque c’è chi immediatamente ne approfittato per mettere “definitivamente” in discussione il concetto di cloud computing. Comprensibile.

Ma se invece, con un pò di calma, andiamo ad analizzare come noi abbiamo affrontato eventi simili in passato allora ecco che lo scenario si capovolge letteralmente.

Circa un anno e mezzo questi stessi servizi li avevamo in-housing e quando è capitato un evento nettamente meno grave di quello di cui stiamo parlando, ma che ha visto uno storage fermarsi e la contemporanea necessità di inserire più server nel rack per sostituirne altrettanti che non funzionava più a dovere,  ci siamo trovati a dover interrompere il servizio.

Tutto questo in una situazione non programmata, quindi di emergenza, e questo cosa vuol dire in pratica ?

Richiamare alcuni dei nostri sistemisti che si trovavano presso clienti (quindi creando un ulteriore disservizio ) , cercare di recuperare nel minor tempo possibile l’hardware necessario, configurarlo, installarlo, testarlo e se tutto è andato bene (secondo voi ? ) andare in produzione. Tutto questo ha richiesto circa 48 ore di sospensione del servizio.

Nel caso di Amazon Web Service ci siamo dovuti preoccupare principalmente di gestire la comunicazione con i clienti e nel contempo operare alcuni work around consigliati dallo staff di Amazon in modo da anticipare il ripristino in altro modo , se i tempi di lavoro per risolvere il problema originario si fossero dovuti allungare oltremodo.
Ma non abbiamo dovuto vivere la frenesia (per usare un eufemismo) dell’episodio precedente, rassicurati anche dal fatto che un’organizzazione come Amazon Web Services stava seriamente lavorando alla risoluzione del problema.

Ai clienti oltre che tenerli informati sulle novità,  abbiamo inviato l’indirizzo della pagina dove viene visualizzato lo status  dei servizi Amazon in modo che potesse informarsi in tempo reale, con una ricaduta psicologica senza dubbio positiva.

A bocce ferme e al netto delle indubbie difficoltà che i clienti  hanno dovuto subire, il bilancio finale  di questa esperienza non può altro che essere positivo, sia in termini di un approccio più sereno ad un situazione di emergenza che a quello sempre da non sottovalutare dei costi .

 

 

[case study] Gestire il Supporto con una Ticket Application è commercialmente indispensabile.

cmenzani Riflessioni , ,

Una volta acquisito un nuovo cliente, sia esso per lo sviluppo software o per attività sistemistiche, lo invitiamo ad utilizzare Kayako lo strumento per la gestione dell’help desk che utilizziamo da anni.

Si tratta del classico uso di uno strumento di help desk , il cliente per ogni segnalazione viene invitato ad aprire un ticket inviando una e-mail ad un particolare indirizzo , l’e-mail viene immediatamente letta e presa in carico da un tecnico e da li in avanti l’eventuale comunicazione, fra cliente e tecnico, potrà proseguire comodamente sempre via e-mail, ed il sistema garantirà comunque la memorizzazione dello storico delle comunicazioni memorizzato all’interno di Kayako.

Non mi dilungo sul fatto che con l’utilizzo di Kayako (ma credo anche con buona parte degli altri tool della stessa categoria)  è possibile stabilire degli automatismi molto potenti che permettono di agevolare in modo impressionante il lavoro di assistenza, ma qui vorrei sottolineare il fatto che l’utilizzo costante di questo strumento può avere una importante ricaduta anche nella gestione del rapporto commerciale con il cliente .

Periodicamente i ticket vengono analizzati nel loro insieme o per singolo cliente e, ad esempio,  potremmo accorgerci che  :

  • vengono aperti molti (troppi) ticket , magari dalla stessa persona
  • un cliente importante, con applicazioni critiche,  apre pochi ticket od addirittura nessuno
  • etc.

Quindi analizzando ogni possibile scenario per così dire “anomalo” e rapportandolo con lo storico che abbiamo sulla stessa tipologia di ticket su gli altri clienti, possiamo comprendere meglio che tipo di intervento operare.

Di seguito un paio di esempi frutto della nostra esperienza recente :

  • è necessario definire un nuovo workflow nella gestione dell’assistenza con l’obbiettivo di ridurre l’apertura di ticket spesso duplicati nel tempo
  • condividiamo con il cliente che la criticità di certe applicazioni o infrastrutture giustificano il numero superiore alla media di ticket, quindi diventa molto più semplice ridiscutere un valore economico adeguato a questa scenario , che magari non poteva essere previsto in precedenza (ovvio che si deve porre attenzione a non sottoscrivere all’inizio del rapporto con il cliente particolari vincoli contrattuali che ci impediscano in futuro di poter gestire situazioni come quella descritta)
  • e molo altro ancora …..

 

Concludo affermando che anche società di servizi di piccole dimensioni posso ottenere dei grandi benefici, nella logica del miglioramento continuo dei rapporti con il cliente,  dall’utilizzo di questi strumenti.

 

La Coopetizione ? Mi piace !

cmenzani Riflessioni ,

Sto leggendo un libro che in una sua parte tratta di sostenibilità nel mondo degli affari.

Mi ha colpito questa parte,  in primo luogo perchè si adegua alla mentalità imprenditoriale della piccola e media impresa italiana  e poi perchè ha a che fare con il titolo che accompagna il mio blog dalla sua apertura “Condivisione e collaborazione sono meglio di protezionismo e competizione. Semplice no ?” ;-)

 

I nuovi leader dovranno anche considerare in modo diverso la competizione, perchè stanno emergendo nuove forma di collaborazione. E’ possibile continuare a farsi concorrenza in termini di prezzi e servizi, ma perchè non valutare le ottime ragioni per cooperare in settori come la logistica: che senso ha che due concorrenti facciano arrivare entrambi un camion mezzo vuoto dalla Francia ?

Perchè non condividere il trasporto, il deposito e la rete di distribuzione ?

Allo stesso modo, le aziende possono agire di concerto per migliorare gli standard dei fornitori,  ad esempio utilizzando un packaging più rispettoso dell’ambiente, oppure possono diminuire le emissioni di CO2 collaborando su quegli aspetti del business sui quali non c’è competizione.

Questa collaborazione di matricola ecologica tra i concorrenti si chiama “coopetizione” e rappresenta una capacità fondamentale dei dirigenti del futuro.

 

 

coopetition

foto dell’album Flickr jackberlin66

Google Chrome OS e Citrix Receiver : una bella coppia

cmenzani Riflessioni , , , , , , , ,

Durante l’evento di presentazione a San Francisco, lo scorso 7 dicembre, del netbook Cr-48 con Chrome OS , Google ha invitato Citrix Systems nella persona  Gordon Payne – Senior Vice President- , ad illustrare Citrix Receiver e come le due tecnologie si integrino perfettamente in modo da soddisfare anche le esigenze dell’utenza business.

Cr-48 è un prototipo di netbook che Google rilascerà, al momento solo negli USA, per testare Chrome OS, superata questa fase di test è probabile che ne venga rilasciata una versione commerciale.

Google afferma che il motivo per il quale è stato pensato e creato Chrome OS è che “la maggior parte del codice, della complessità, della gestione, dei problemi di sicurezza di un computer sono da imputare al sistema operativo, non al browser, e quasi (forse tutti?) i sistemi operativi sono stati ideati prima dell’avvento del web! Invece Chrome OS è stato progettato e realizzato per il web”.

L’idea che sta alla base del Chrome OS in fondo è quella del Network Computer o NetPC della Sun Microsystems nato a partire dal 1996, ma allora erano ancora assenti alcuni elementi infrastrutturali chiave, come la banda larga, il cloud computing, ambienti e strumenti di programmazione tali da poter rendere un’applicazione veloce, usabile e quindi fornire una esperienza utente all’altezza delle sue aspettative.

Adesso quel gap tecnologico si sta rapidamente colmando (come sempre nel nostro paese siamo orribilmente indietro, infatti non rappresentiamo lo stato dell’arte ed è di quella della quale sto parlando, non delle miserie nostrane).

E’ ovvio che un sistema operativo come Chrome OS che ha ambizioni di sostituire nel breve periodo Windows nei  nostri desktop  deve poter fornire la possibilità agli utenti, soprattutto quelli business, di poter accedere alle proprie applicazioni aziendali senza problemi.

Da qui la realizzazione della versione per Chrome OS di Citrix Receiver lo strumento che permetterà la connessione dai netbook Chrome OS alle applicazioni della propria azienda, con tutte le garanzie di sicurezza , gestione “di chi deve vedere cosa, e con quali diritti accedervi” e quant’altro tipico di un ambiente enterprise.

Per un’azienda lo scenario ipotizzabile per il futuro, è quello dove le nuove applicazioni saranno sviluppate nativamente per il web (HTML5 , WebGL)  , ma altresì tutto l’immenso parco di applicazioni sviluppate negli anni per “i vari” sistemi Windows potranno continuare ad essere utilizzate senza difficoltà, e l’accesso avrà luogo dallo stesso sistema operativo – Chrome OS, comunque open source – e, nelle intezioni di Google, anche dalla stessa tipologia di hardware (i figli e nipoti del Cr-48).

Già questo mi sembra un ottimo risultato, ma agli occhi di molti questa soluzione di Citrix può apparire come di retroguardia, ovvero Citrix, con le dovute differenze ovviamente,  sembrerebbe fare quello che a partire dalla metà degli anni 90, con l’affermarsi degli ambienti di sviluppo GUI, i produttore di applicazioni (che allora si sovrapponevano anche con i produttori di hardware) per mini ,come AS400, crearono dei framework il cui unico scopo era rifare il look alle loro applicazioni a caratteri, sviluppando degli ambienti che “webbificavano” quelle interfacce ormai vecchie.

Per quanto riguarda Citrix Receiver non è assolutamente così,  non fosse per altro che lo sviluppo delle applicazioni in ambiente Windows è ben lontano dall’esaurirsi, anzi Citrix Receiver restituisce alla sterminata platea di sviluppatori ed utilizzatori di Windows application una rinnovata giovinezza.

Non ultimo è che Citrix Receiver è disponibile anche per tutti i dispositivi mobile iOS, Android , Symbian, BlackBerry, ma come direbbe Carlo Lucarelli, “questa è un’altra storia” 🙂

L’intervento di Gordon Payne – Citrix Systems, Senior Vice President – è dal minuto 21:30 al 30:00 (circa)

Esperienza di migrazione in cloud (e dintorni)

cmenzani Riflessioni, roomshop , , ,

Il nostro servizio RoomShop, ideato nel 2006 e che fino agli inizi di questo anno ha avuto una crescita lenta quindi gestibile, dallo scorso giugno  ha conosciuto un incremento inaspettato di clienti (cosa senz’altro interessante e sempre auspicabile, ma alla quale , come vedremo è necessario sempre prestare la massima attenzione).

L’intero ecosistema era allocato all’interno di una farm di tutto rispetto, nei pressi dei nostri uffici, ed utilizzava server di nostra proprietà, non scendo nei dettagli , ma credetemi per sostenere il servizio che dobbiamo fornire l’architettura è sufficientemente complessa.

La parte più rognosa sta nel fatto che il servizio che offriamo consiste nell’interfacciarsi , in vario modo via XML o screen-scraping con i più importanti portali turistici esistenti (Expedia, Booking, Lastminute, Venere, etc.) per inserire con un solo-click (come recita il claim di RoomShop) da una unica interfaccia utente, tariffe e disponibilità e/o recuperare le tariffe dei competitor dei nostri clienti.
La sfida che impatta maggiormente è che ognuno dei portali turistici è una entità indipendente che dedice – giustamente – di modificare o manutere il proprio web site quando meglio lo ritiene opportuno, quindi da parte nostra dobbiamo il più rapidamente possibile (sempre troppo tardi per i nostri clienti 🙂  , adeguare i nostri programmi ai cambiamenti.

Un aumento improvviso di clienti (cioè di alberghi che utilizzano il servizio) , comporta ovviamente un proporzionale incremento di utilizzo di risorse, ed è qui che il modello definito “in-house”  (con questo termine intendo riferirmi  a gestire l’intera infrastruttura con propri server )  ha mostrato immediatamente la corda, soprattutto nei confronti della scalabilità,  rappresentato dalla seguente e semplice equazione :

Incremento improvviso e consistente di clienti = nuovi server + attività sistemistiche di configurazione e manutenzione + costi accessori (aumento di banda, etc)

Ovviamente l’adeguamento alla nuove richieste deve avvenire nel minor tempo possibile, pena la percezione da parte del cliente o del partner che il servizio nel suo complesso sia scadente  o comunque non adeguato ad un target professionale.

I nuovi server vanno acquistati (difficile pensare di averne a magazzino), i sistemisti hanno già attività pianificate (per fortuna) per la settimana e probabilmente anche per le due successive, insomma il tutto diventa assolutamente ingestibile.

La soluzione : Cloud

L’idea di passare in cloud non è balenata all’improvviso è già da un bel pò (più di anno) che testiamo i vari servizi , abbiamo account aperti su Amazon Web Services, Microsoft Windows Azure Platform, GoGrid,  altri li abbiamo testati e o li abbiamo, per il momento accantonati, o li abbiamo chiusi perchè non rispondevano alle nostre necessità.

Per quanto riguarda il passaggio del servizio RoomShop abbiamo iniziato a programmarlo già alla fine di luglio facendo un censimento preciso di tutti i servizi per ognuno dei quali è stato necessario effettuare verifiche di compatibilità.

Sono state proprio queste verifiche che hanno fatto si che , dall’idea iniziale di allocare tutto su un unico fornitore cloud, abbiamo optato per due servizi distinti e cioè :

  • Microsoft Azure :  dove risiedono principalmente i processi per il recupero ed inserimento delle informazioni da e per i portali
  • Amazon Web Services : che abbiamo ritenuto maggiormente affidabile e flessibile per quanto riguarda la gestione del data base

Successivamente abbiamo pianificato due sessioni di interventi a distanza di circa due settimane l’una dall’altra dove prima abbiamo migrato e quindi popolato  Azure Platform, dopodiché lo scorso martedì è stato migrato e popolato Amazon Web Services con il database ed i servizi residui.

Come è andata la migrazione ?

Dal punto di vista generale posso affermare che l’operazione ha avuto successo.
Inutile nascondere che per quanto si possa porre la massima attenzione ad ogni minimo particolare, qualcosa può sempre sfuggire (non tutte le necessarie informazioni sono state raccolte o ci sono state comunicate)  e anche nel nostro caso è accaduto, generando qualche incomprensione (accompagnata da uno sincero  scambio di opinioni) con un nostro partner.

Da notare che a differenza di gran parte delle applicazioni, che per quanto complesse siano,  vivono in confini “finiti” e quindi controllabili, RoomShop (e tutti i servizi che appartengono alla stessa categoria)  naviga in un mare magnum spesso in burrasca.

Ma questa è la sfida che a noi piace.

Qual’è la situazione adesso ?

E’ quella che ci aspettavamo. Tutte le criticità che prima si presentavano generando colli di bottiglia sulle varie parti del sistema si sono brillantemente risolte.

Le richieste arrivano da parte degli albergi e vengono immediatamente, e sottolineo immediatamente elaborate. Una meraviglia.

Sono certo che in Italia adesso siamo uno dei (o forse il) Channel Manager ( è questa la categoria alla quale appartiene il servzio RoomShop) con l’infrastruttura migliore.

E questo soprattutto grazie alle varie competenze e la passione che le persone in Vivido mettono su questo progetto.

Ma ?

E’ ovvio che c’è sempre un risvolto negativo. Qual’è in questo caso ? Bè ovviamente sempre lo stesso cioè il costo. Tutta questa affidabilità, volume di fuoco e scalabilità si paga e si paga cara. Ma questo è un altro argomento che affronterò in futuro  ;-)