Esperienza di migrazione in cloud (e dintorni)

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  ;-)