A szerverhoszting jelentősége és eszközei folyamatosan változnak. Posztsorozatunkban megvizsgáljuk a jelenleg legnépszerűbb trendeket, és választ keresünk arra, hogyan hatnak ezek a hoszting világára, és hogyan tudunk beilleszkedni a jövő hálózatába.

A szerver nélküli (serverless) architektúra nem azt jelenti, hogy nincsenek szerverek - hiszen valahol futnia kell az alkalmazásoknak. Inkább arra utal, hogy a fejlesztőknek nem kell a szerverekről, azok skálázásáról vagy karbantartásáról gondoskodniuk. Ehelyett egy harmadik fél, például egy felhőszolgáltató kezeli a szerverinfrastruktúrát, és automatikusan skálázza az erőforrásokat az alkalmazás igényeinek megfelelően.

Ebben a felfogásban a fejlesztőknek csak a kóddal kell foglalkozniuk: minden másról egy szolgáltató gondoskodik. Neki kell tennie arról, hogy az alkalmazás megkapja a neki szükséges erőforrásokat, amíg fut, és felszabadítsa az erőforrásokat, amikor nincs rá szükség. Ebből következik, hogy az erőforrásokra csak addig van szükség, amíg az alkalmast aktívan használják. Amikor az alkalmazás nincs használatban, nem is fizetnek semmit a szolgáltatónak.

A szerver nélküli alkalmazásokat konténerben érkeznek, futnak le, ezt követően pedig az általuk használt erőforrások azonnal felszabadulnak. 

Hogyan hat ez a szerverhosztingra?

A hagyományos, kis hosztingszolgáltatók számára a serverless természetesen nem a jövőben rejlő lehetőség. Ehhez ugyanis az kell, hogy a szolgáltató eleve képes legyen az erőforrásait egyetlen nagy clusterben kezelni, ahol az erőforrások skálázása nem szervereken belül, hanem clusteren belül értelmezhető.

A ZeroTime azonban éppen ilyen szolgáltató. Mi enterprise szintű clusterrel dolgozunk, számunkra a serverless működés a mindennapok része, és készen állunk az ilyen alkalmazások futtatására.

Hogy miért lehet jó ez az ügyfeleink számára?

• Költséghatékonyság: Csak azért fizetnek, amit használnak. Nincsenek állandó költségek olyan erőforrásokért, amelyek nagy részét nem is használjuk ki.
• Automatikus skálázás: A rendszer automatikusan alkalmazkodik a kereslethez, így az alkalmazás soha nem "esik ki" nagy forgalom esetén sem.
• Fejlesztési egyszerűség: A szerver nélküli architektúra lehetővé teszi a fejlesztők számára, hogy a kódra koncentráljanak, az infrastruktúrával nem kell foglalkozniuk.
• Gyors piaci bevezetés: Mivel nincs szükség komplex infrastruktúra-konfigurációra, az alkalmazásokat gyorsabban lehet piacra dobni.

Persze fontos megjegyezni: attól, hogy konténerben gondolkozunk, az alkalmazás még lehet rossz minőségű. Sokszor előfordul, hogy összetákolt, az erőforrásokkal pazarlón bánó kódok számára kell értelmetlen erőforrásokat lefoglalni, ami egyáltalán nem jobb, mint amikor feleslegesen bérelnek helyet a tétlen szervereknek.

A megoldás a már korábban is emlegetett DevOps: el kell felejteni, hogy a fejlesztő és az üzemeltető két külön egység, amik csak átadják egymásnak a stafétabotot. Ennek a két területnek együtt kell működnie a kezdetektől annak érdekében, hogy a végén a felhasználó és a tulajdonos is a lehető legjobbat kapja.