Amazon → Amazon Web Service
Az Amazon két munkatársa még 2003-ban saját infrastruktúra fejlesztéseként terjesztett elő egy felhő alapú architektúra tervet, mely már részletesen tartalmazta a jelenleg is alkalmazott technológiákat és szolgáltatásokat, valamint azt a fajta Auto Scaling Group technológiát, ami miatt piacvezető lett az AWS.
Ha jobban belegondolunk, abban az időben az Amazon már az egyik legnagyobb online kereskedelmi cég volt, elkezdték saját áruházukat megnyitni a beszállítók előtt, és e miatt egy roppant rugalmas, dinamikusan nővelhető és/vagy csökkenthető infrastruktúrára volt szükségük. Már három kontinensen voltak jelen (az AWS kezdeteihez hasonló, sőt, megegyező régiórendszerrel) – szinte evidens volt, hogy a rendelkezésre álló keretekből olyan fejlesztés készüljön, amely az áruházi és értékesítési funkciók mellett magát az infrastruktúrát is (valamint a mögötte álló technológiát) értékesíthetővé teszi. Az Amazon 2010-ben költözött be az AWS-be véglegesen: az AWS gyakorlatilag túlnőtte a “szülőjét”.
Privát, publikus és hibrid
Amikor a cloud-architektúrák alapjait vizsgáljuk, három lehetőség közül választhatunk. A privát felhő alapú megoldásoknál mind a fizikai erőforrások, mind pedig az azon alkalmazott szoftveres technológiák felett mi gyakoroljuk a teljes kontrollt (sőt gyakran a tulajdonjogot is), és általában egy kizárólag zárt rendszerben működő szolgáltatást nyújtunk a vállalatunk számára. Ilyen például egy belső munkatársaknak szánt, de skálázható alkalmazás, vagy egy sima belső vállalati tárhelymegoldás is akár.
Publikus felhő megoldások esetén bárki számára elérhető és használható szolgáltatást nyújtunk (természetesen szabályozott keretek között), és sem a felhasznált fizikai erőforrások, sem pedig a közben alkalmazott más technológiai megoldás tulajdonjoga nem köthető hozzánk, sőt, gyakran a tényleges fizikai eszközökhöz hozzá sem tudunk férni. Ha használjuk például a Dropbox-ot, akkor már használtunk Publikus felhő szolgáltatást.
A hibrid architektúra esetén (és ez a legelterjedtebb) a megoldás valahol a kettő között van: a nagy terhelést kapó (adott esetben terheléselosztást végző) eszközök publikus felhő alapú szolgáltatásban üzemelnek, a know-how-t “futtató”, vagy biztonsági szempontból kritikus háttérrendszerek pedig saját tulajdonban lévő közegben találhatóak, és ezek (a publikus és a privát site-ok/területek) valamilyen titkosított csatornán keresztül kommunikálnak egymással.
AWS régiók, kiszolgálói zónák
Az AWS régiókat nem egy-egy szerverszobaként, vagy adatközpontként kell elképzelnünk. Az AWS definíciója szerint egy régió több kiszolgálói zóna (availibility zone) összességéből áll össze, melyhez további CACHE / CDN kiszolgálói helyszín kapcsolódik (edge location).
Sőt még egy-egy availibility zone-t sem képzelendő el adatközpontként, hiszen több adatközpont összessége nyújtja a szolgáltatásokat – így biztosítható az igazán hatékony terheléselosztás és redundancia, valamint így vállalható a 99,99%-os rendelkezésre állás, amit az AWS szolgáltatásai jelentős részében vállal.
Ezek a régiók (és a régión belüli kiszolgálói zónák is) az AWS saját tulajdonában lévő redundáns hálózati gerincinfrastruktúrával vannak összekapcsolva, melyek elképesztő sebességgel kommunikálnak egymás között:
Az AWS-nek jelenleg kilenc publikus, egy kormányzati és egy készülő új régiója van. A kilenc publikus régió a következő helyszíneken található:
- US-WEST-1: North California
- US-WEST-2: Oregon
- US-EAST-1: Virginia
- SA-EAST-1: Sao Paolo
- EU-WEST-1: Írország
- EU-CENTRAL-1: Frankfurt
- AP-NORTHEAST-1: Tokyo
- AP-SOUTHEAST-1: Szingapúr
- AP-SOUTHEAST-2: Sydney
Az USA-ban található még egy zárt AWS régió (GovCloud), amely csak az amerikai kormányzati szervek használnak – illetve a legújabb régiót Kínában, Pekingben adják majd hamarosan át.
A folytatásban
Mielőtt rátérünk az egyik legfőbb kérdésre, hogy vajon biztonságos-e a felhő, áttekintjük azokat a cloud fogalmakat (IaaS, PaaS, SaaS), amelyek meghatározhatják az általunk képviselt stratégiát, illetve bemutatjuk ezek fejlődését is.
