Mi a különbség a Microservice és a Konténerek között?
A konténerek és a microservice-ek lehetővé teszik a fejlesztők számára, hogy gyorsan és egyszerűen építsenek robusztus, könnyen skálázható alkalmazásokat.
Habár a „konténer” és a „microservice” nem ugyanazt jelenti, mégis gyakran egy mondatban emlegetjük őket.
A különbség
Adott a kérdés, hol futtassuk microservice alapú alkalmazásunkat? Erre a kérdésre nyújt gyors és egyszerű megoldást a konténerizáció és a konténerorkesztrációs rendszerek (Kubernetes).
Ki lesz a Nagy-Konténerháború győztese?
Jelen pillanatban az alkalmazások túlnyomó többsége Docker konténerekben fut. Azonban a Kubernetes számára nem fontos,hogy milyen konténerben futtatjuk alkalmazásunk, mindaddig amíg az támogatja a CRI-t (Container Runtime Interface). Felmerül bennünk a kérdés hogy mi is a CRI?
A Container Runtime Interface a Kubernetes 1.5-ös verziójával lett bevezetve. Az 1.5-ös verzió előtt a kubelet és a konténer runtime meglehetősen egybefonódott. Ez meglehetősen sok fejlesztési erőforrást vett igénybe, ahogy új konténer alternatívák jelentek meg. A CRI bevezetésével a Kubernetes fejlesztői egy jól definiált standardizált interface-t hoztak létre, hogy ezen keresztül a kubelet kommunikálhasson a különböző konténer technológiákkal.
Mint említettük a legtöbb alkalmazás Docker konténerben futva működik a Kubernetes alatt. A Docker azonban közvetlenül nem használja a CRI-t. A Docker az évek során a monolitikus felépítésből fokozatosan microservice architektúrára váltott, így bizonyos funkcionalitások saját projectekbe költöztek mint például a containerd, ami a high-level image-ek kezelésért felelős, vagy például a runc, ami a low-level konténer runtime-ért felel. Manapság amikor Dockert használunk tulajdonképpen egy stack-et használunk ahol a docker daemon intéz hívásokat a containerd felé ami kommunikál a runc-vel. A Docker a másik irányba, a Kubernetes felé a dockershim-en keresztül kommunikál.
A dockershim azonban mindig is csak egy átmeneti megoldásként volt létrehozva ezért a Kubernetes 1.20-as frisstésében a dockershim támogatása megszűnik. Nem kell azonban aggódnunk mivel számos alternatív konténer technológia jött létre az évek során ami kompatibilis a Kubernetes-el.
Konklúzió
Ahogy láthatjuk, számos konténer alternatíva létezik a Docker mellett, sőt igazából a Docker is egy stack különböző eszközökkel felvértezve. Fontos megemlíteni, hogy mindegyik konténer alternatíva rendelkezik előnyökkel és hátrányokkal, így a felhasználó kiválaszthatja a saját stack-je számára legmegfelelőbb megoldást. A verseny erős de már látszik – mint ahogy a Kubernetesnél is – melyik megoldás mögé fognak beállni a nagyok és fogja tovább vinni a konténer legacy-t.
Ajánlott Datatronic szolgáltatás a témához...
Források
