Múlt hét péntek délutánján budapesti idő szerint háromnegyed három után pár perccel leálltak a Google Maps Platform egyes szolgáltatásai. Mint a hibabejelentő oldalakon látszik (a címlapképet a Google Maps Platform Status Dashboardról mentettük), a szolgáltatás több API-ja is (Directions API, Gaming Services, Maps Embed API, Maps JavaScript API, Maps Static API, Places Library) megborult, ami szolgáltatáskieséshez vezetett.

Olyan appoknál voltak fennakadások, melyek integrálták a Google Maps Platform API-kat, számolt be a The Register. Globális és lokális alkalmazásokban egyaránt leálltak, időszakosan használhatatlanná vált például a repülőket követő FlightRadar24. De mint a lap írja, az API-k IssueTracker oldala szerint kiesések voltak Brazíliától, Kanadáig, Ecuadortól, Japánig, az Egyesült Királyságtól a balti államokig szinte mindenhol.

De az volt a kisebbik probléma, hogy a FlightRadar jellegű szolgáltatások megadták magukat. Texas államban azonban az EMS (Express Mail Service) szolgáltatás állt le, mert a GPS-alapú nyomkövetőrendszerhez és a címtovábbításhoz is a Google Mapset használták. A kanadai Manitoba nevű cégnél pedig a Click Before You Dig nevű szolgáltatás sürgősségi ügyelete bénult meg. A Manitoba szolgáltatása a Google Maps adataira építve mondja meg ügyfeleinek, hogy egy adott földmunka veszélyeztet-e földben vezetett közművezetékeket.

A Google Cloudot szerencsére nem érintette a hiba.

A hiperskálázható szolgáltatások kockázatai

A Google Maps API-jainak problémája ismét felszínre hozta azokat a félelmeket, melyeket a különböző nemzetközi CIO-szervezetek pedzegettek a cloud computing hajnalán. Az EuroCIO például arra jutott, hogy a cloud computingnak óriási előnyei vannak, ám az erőforrások extrém magas koncentrációja miatt a veszélyeket is koncentrálja.

A 2010-es évek elején, amikor ez az állásfoglalás megszületett, még csak a legmerészebb cloud-evangelisták beszéltek arról a ma már nagyon is létező bonyolult felhős ökoszisztémáról, amelyben szolgáltatók erős alsó madárfogással szorongatják egymást, és bármelyik kiesése a rendszerből komoly – ha legtöbbször nem is végzetes – fennakadásokat okozhat a pillangóhatás miatt. Mivel a következményeket nem lehet megjósolni, a kataszrófahelyzetekre felkészülés lehetetlen és még sokba is kerül.

És akkor térjünk vissza a címben feltett kérdésre. Az informatikai vezetők egyik rémképe volt a vendor lock-in. Ez nem csak a költségek miatt volt kockázatos, hanem a péntekihez hasonló problémáknak a lehetőségét is előrevetítette, igaz kiszámíthatóbb módon. Az informatikai vezetők ezért mindig igyekeztek észszerű keretek között diverzifikálni (ami persze az üzemeltetési oldalon okozott némi többletköltséget).

A felhős korszakkal azonban ez a kalkulációs lehetőség elveszett. Ha valaki nem akar a Google-le szerződni, közel sem biztos, hogy nincs olyan beszállítója, szolgáltatója, amely közvetve vagy közvetlenül függ a keresőcég valamely online szolgáltatásától. De ugyanez igaz az egymással konkuráló globális szolgáltatókra, melyek bizonyos részterületeken együttműködnek, sőt egymás erőforrásait használják, hogy ügyfeleiket maximálisan kielégíthessék.

A pénteki hibát teljes egészében budapesti idő szerint este 8-ra sikerült elhárítani. Az okokat azonban még mindig keresik a Google szakemberei.