Cloud computing v praxi: 7 poučení z nedávných výpadků u Amazonu
Cloud computing je na papíře skvělá věc. Je příjemné nebýt svázaný s určitým hardwarem, ale jen mít svoje data někde v cloudu, kam k nim můžete odkudkoliv přistupovat. To ovšem platí pouze za ideální situace, jelikož krutá realita nám v praxi uštědří občasné výpadky, jako se to právě povedlo koncem minulého měsíce i známému Amazonu.
1. Přečíst si vždy velmi pozorně SLA
Na celé situaci je zajímavé to, že tento čtyřdenní výpadek v podstatě nijak neporušil EC2 SLA Amazonu, kde se praví cosi o garanci 99,95 % dostupnosti během 365 dní. Do důsledku vzato totiž šlo o služby EBS a RDS a nikoliv o selhání EC2 jako takového. SLA tedy nebyla porušena dá se říci. Není to jistě pro Amazon omluva, ovšem námět k zamyšlení určitě...
2. Neberte všechny záruky vašeho poskytovatele na 100 %
Řada poskytovatel platila extra peníze za to, že Amazon hostoval jejich instance na více jak jedné AZ (Availability Zone). Amazon tento postup doporučuje zákazníkům ve svém FAQ, jelikož každá taková AZ běží na vlastním "železe" někde jinde. Logicky je tedy potom instance odolnější proti tornádům, povodním a podobným lokálním katastrofám. V praxi se to ovšem příliš neosvědčilo, takže Amazon bude mít co dělat, aby si napravil svoji pošramocenou reputaci. Naštvaného zákazníka samozřejmě nezajímá, jestli věc nefungovala kvůli katastrofě, nekompetentnosti, chybné struktuře nebo z jiného důvodu. Náchylnost k podobnému typu chyb nicméně jistě další zákazníky ke službě nepřitáhne.
3. Většina zákazníků stejně Amazonu odpustí
Jakkoliv postiženi byly někteří zákazníci, mnoho lidí i přesto u Amazonu zůstane, jelikož si dobře spočítali, že se jim to zkrátka stále vyplatí. Amazon jim pořád nabízí služby, které považují za potřebné či zajímavé: zejména co se týče rychlého a levného vybudování infrastruktury.
4. Stále existují cesty, jak doplnit základní funkce
Řada osob byla rovněž toho názoru, že když váš systém selhal v cloudu Amazonu, pak to nebyla jeho chyba. Buď jste považovali výpadek za přijatelné riziko, nebo jste selhali při optimálním návrhu své instance na cloud-computingový model Amazonu (kupříkladu firma Twilio byla stále online - pár námětů pro dobrý a odolný design naleznete zde). Jinými slovy, k minimalizaci vlivů výpadků použijte každou dostupnou cestičku - mějte dobrou politiku zálohování dat apod.
5. Stojí extra odolnost vždy extra peníze?
Jistý Bob Warfield přišel s řadou nápadů, jak postupovat v případě výpadku a oživit služby v jiném centru s cca 20 minutami výpadku a s maximálně 5 minutami ztráty dat.
6. Rozumějte dokonale všem alternativám
Abyste se mohli perfektně rozhodnout, jestli je u poskytovatele cloudu lepší alternativa A nebo B (respektive žádná, popřípadě C, ...), potřebujete znát dokonale jak jeho portfolium služeb, tak i svoji infrastrukturu.
7. Nedostatek transparentnosti může být Achillovou patou Amazonu
Několik zákazníků si stěžovalo, že se během výpadku nedočkali ze strany Amazonu žádných kloudných informací. Mnoho z nich proto dospělo k závěru: "Pokud by nás Amazon informoval o technickém průběhu svého výpadku, mohli bychom obnovit provoz výrazně rychleji." Plyne nám z toho logicky, že k optimalizaci systému na výkon, škálovatelnost nebo obnovu po katastrofách nestačí jen pár neurčitých informací někde ve FAQ. Není určitě špatný nápad vynutit si takové údaje smluvně.
