Il dibattito è aperto, ma neanche tanto. La regola sembra proprio essere “se vuoi fare un servizio/prodotto cloud, uno dei motivi di successo risiede nel fatto che sia compatibile con Amazon AWS“.
Nel bene e nel male Amazon è partita per prima ed ha il più importante numero di clienti (stime, non dati ufficiali perché non pubblicati). La sua architettura e le sue API sono state le prime ad essere adottate e il servizio, con il pessimo SLA che tutti conosciamo, è considerato il punto di riferimento. Per quanto non sia facile portare via un cliente ad Amazon, anche se insoddisfatto, lo è ancora meno se questo si deve impegnare a riscrivere il software o a rivedere l’architettura generale della sua soluzione!
E’ come per gli smartphone
Da un certo punto di vista è come per il mobile: se oggi devi partire a sviluppare una App per un telefono/tablet il primo sistema che scegli è iOS. Non perché è il più bello o il più facile ma perché la base installata è enorme, c’è un ecosistema forte e gli utenti utilizzano la piattaforma in modo più consapevole e maturo. Una volta che lo sviluppatore è abituato a sviluppare in quel modo, e visti i risultati ottenuti sulla piattaforma Apple, il porting lo fa solo se gli costa poco (in termini di tempo e denaro) e gli conviene economicamente.
Lo storage ci è già arrivato
Nel mondo dello storage già è così. S3, il servizio di storage ad oggetti di Amazon AWS non è il migliore sul mercato, non ha le API migliori e neanche le migliori caratteristiche in assoluto: ciò non vuol dire che non sia valido ma che l’obiettivo di quel servizio è di servire applicazioni che sfruttano l’ecosistema Amazom, per quello è perfetto. S3 ha avuto tanto successo che tutti, dico tutti, i fornitori di soluzioni object storage (on-premise e pubbliche) si sono adattati e forniscono compatibilità con le API di Amazon. Oggi come oggi, una delle prime caratteristiche che si guarda sugli object storage è proprio la compatibilità con S3, anche se si ha l’obiettivo di sviluppare e gestire una soluzione in casa.
Questo avviene anche perché gli sviluppatori che conoscono le API Amazon sono molti di più di quelli che conoscono qualsiasi altra API… per non parlare po della documentazione e dell’esperienza disponibile gratuitamente in rete.
Compatibile=Enterprise
Da qualche tempo il dibattito si è spostato sulla compatibilità di Openstack con AWS. E’ lo stesso problema che si è posto sul lato storage: se non sei compatibile alle aziende interessa poco. Ancora oggi, per quanto la comunità sia attiva e per quanto i vendor spingano su Openstack, di casi di successo a livello enterprise non c’è traccia e i provider che lo adottano in produzione sono per lo più piccoli e non in grado di ospitare applicazioni cloud complesse e distribuite geograficamente.
E’ di qualche giorno fa questo articolo di Randy Bias che punta il dito su questo problema.
E poi diciamoci la verità Open riempie la bocca ma alle aziende interessano molto di più le parole compatibile/interoperabile, è li che sta la chiave di volta per evitare i lock-in
Nota finale
AWS non è adatto per tutto o per tutti. Soprattuto ora con tutti gli scandali legati ad NSA e sicurezza. Certo è però che la compatibilità con Amazon AWS è importante, sono sempre di quelli che legano il successo delle varie piattaforme di cloud management proprio a questa caratteristica.
Non è neanche facile dargli torto!
“AWS is a complete online service. OpenStack is software that can be used to build such a service.
OpenStack will be used to build many kinds of clouds of which some will be AWS compatible. Some will be for other special purposes.
This is OpenStack’s strength and weakness.
I think it’s a huge mistake to believe OpenStack is some kind of monolithic complete solution with a standardized reference architecture. It’s not even close. It’s just a cloud OS kernel not the cloud OS itself.” (Randy Bias)