- Docker Swarm piedāvā vienkāršu un stabilu orķestrēšanu, kas ir ideāli piemērota jaunuzņēmumiem un mazām komandām, kurām prioritāte ir ātrums un zemas ekspluatācijas izmaksas.
- Kubernetes izceļas liela mēroga, vairāku reģionu scenārijos un sarežģītās prasībās, taču tas ir saistīts ar daudz lielāku sarežģītību un stāvāku mācīšanās līkni.
- Izvēlei starp Swarm, Kubernetes vai Apache Mesos jābalstās uz faktiskajām biznesa vajadzībām, komandas kapacitāti un esošo arhitektūru.
- Labi izstrādātai arhitektūrai un optimizētam kodam ir lielāks svars projekta panākumos nekā izvēlētajam orķestrētājam.
Konteineru orķestrēšana ir kļuvusi par galveno pīlāru jebkurai komandai, kas strādā ar mikropakalpojumu arhitektūru , nepārtrauktu izvietošanu un izkliedētām lietojumprogrammām. Sākot darbu ar Docker, viss šķiet vienkārši, taču, pieaugot pakalpojumu, vides un mezglu skaitam, viss kļūst sarežģīti, un rodas divi nosaukumi: Docker Swarm un Kubernetes.
Izvēle starp Docker Swarm un Kubernetes vai to stratēģiska apvienošana ir kļuvusi par īstu dilemmu, īpaši jaunuzņēmumiem un augošiem uzņēmumiem, kas vēlas izvairīties no pārmērīgas inženierijas. Tam pievienojas arī citi orķestrēšanas rīki, piemēram, Apache Mesos, un apmācību programmas, kas integrē visu ekosistēmu (Docker, Swarm, Kubernetes, tīklošana, krātuve, uzraudzība utt.). Mēs sadalīsim visas šīs daļas progresīvā un praktiskā veidā, bet izmantojot saprotamu valodu, lai jūs varētu pieņemt pārdomātus lēmumus un ne tikai sekot jaunākajām tehnoloģiju tendencēm.
Docker, konteineri un nepieciešamība pēc orķestrēšanas
Pirms iedziļināties Docker Swarm un Kubernetes, ir vērts atcerēties, ko tieši Docker risina un kāpēc rodas nepieciešamība pēc orķestratora, sistēmai mērogojot. Docker ļauj iepakot lietojumprogrammu un visas tās atkarības vieglos, pārnēsājamos un reproducējamos konteineros, kas ir radikāli mainījis programmatūras izstrādi un ieviešanu.
Konteiners darbojas kā ļoti viegla mini virtuālā mašīna, kuras pamatā ir vārdtelpas un cgroups , ar savu izolētu failu sistēmu, procesiem, lietotāja telpu un tīkla saskarnēm. Izstrādātājam tas nozīmē, ka tas, kas darbojas viņu klēpjdatorā, darbosies tāpat arī ražošanas serverī, mākonī vai lokālā klasterī, ja vien ir pieejams Docker dzinējs.
Docker būtiskākās priekšrocības mūsdienās ir gandrīz pilnīga pārnesamība Linux, Windows un publiskajos mākoņos, augsta resursu efektivitāte (konteineri var patērēt līdz pat 40 % mazāk nekā tradicionālās virtuālās mašīnas) un stabila integrācija ar DevOps rīkiem, piemēram, Jenkins, GitHub Actions un GitLab CI/CD. Turklāt tādas funkcijas kā bezsaknes režīms un attēlu parakstīšana uzlabo drošību Docker konteineros.
Problēma rodas, kad mēs pārejam no dažiem konteineriem uz desmitiem vai simtiem, kas izvietoti vairākos mezglos ar dažādām versijām, vidēm un pieejamības prasībām. Manuāli pārvaldīt, kurš konteiners darbojas uz kura servera, kā līdzsvarot slodzi vai kā atjaunot nedarbojošu pakalpojumu, kļūst nepraktiski. Šeit noder tādi orķestrēšanas rīki kā Docker Swarm, Kubernetes vai Apache Mesos.
Kas ir Docker Swarm un kāpēc tam joprojām ir jēga?
Docker Swarm ir Docker ekosistēmas dzimtā orķestrētāja, kas izstrādāta ar ļoti skaidru filozofiju: piedāvāt vienkāršu, saprotamu un viegli apgūstamu orķestrēšanas risinājumu komandām, kas jau strādā ar Docker un nevēlas sarežģīt savu dzīvi vairāk, nekā nepieciešams.
Swarm arhitektūra ir balstīta uz diviem galvenajiem mezglu veidiem: pārvaldniekiem, kas uztur klastera stāvokli un pārvalda plānošanas lēmumus, un darbiniekiem, kas izpilda piešķirtos uzdevumus (konteineriem). Pēc tam pakalpojumi tiek definēti ar vienu vai vairākām kopijām, kas tiek automātiski sadalītas starp pieejamajiem mezgliem, izmantojot pārklājuma tīklus, lai droši savienotu konteinerus.
Viena no Swarm lielākajām priekšrocībām ir tā iestatīšanas ātrums: ar tādām komandām kā docker swarm init y docker service create Jūs varat izveidot un palaist pamata klasteri dažu minūšu laikā. Ja jūs jau izmantojat docker-compose.ymlPāreja uz pakalpojumiem Swarm šķiet ļoti dabiska, jo konceptuālais modelis ir līdzīgs un faili ir pazīstami jebkuram izstrādātājam, kurš kādu laiku strādā ar Docker; turklāt to ir viegli apgūt. Integrējiet Docker, Traefik un Portainer kā pilnīgs pārvaldības un maršrutēšanas komplekts.
Progresīvā kontekstā reālās ražošanas pieredze ir īpaši vērtīga: ir dokumentēti gadījumi, kad vairāk nekā 10 gadus kritiskas darba slodzes tiek pārvaldītas, izmantojot Docker Swarm, ar ļoti zemām ekspluatācijas izmaksām un bez nopietniem incidentiem. Tas atspēko mītu, ka Swarm ir tikai izstrādes rīks, un parāda, ka, ja tas ir labi izstrādāts, tas var stabili atbalstīt ražošanas arhitektūras.
Kubernetes: ārkārtēja jauda sarežģītiem scenārijiem
Kubernetes ir kļuvis par faktisko standartu uzņēmuma līmeņa konteineru orķestrēšanai, īpaši organizācijās, kas pārvalda simtiem vai tūkstošiem mikropakalpojumu, izvietošanu vairākos reģionos un stingras prasības attiecībā uz automātisko mērogošanu, drošību un novērojamību.
Tās izkliedētā arhitektūra ietver vadības plakni, kas sastāv no tādiem komponentiem kā API serveris, plānotājs un kontrollera pārvaldnieks, kas koordinē vēlamo klastera resursu stāvokli. Darba slodzes tiek izpildītas mezglos, kur atrodas podi — mazākās izvietošanas vienības, un podi var saturēt vienu vai vairākus cieši savienotus konteinerus.
Kubernetes ievieš papildu koncepcijas, piemēram, pakalpojumus, ienākšanu, konfigurācijas kartes (ConfigMaps), slepenos kodus (Secrets), izvietošanu (Deployments) un stāvokļa kopas (StatefulSets), kas ļauj detalizēti aprakstīt, kā lietojumprogrammas tiek atklātas, konfigurētas, kā tiek glabāti pastāvīgie dati un kā tiek pārvaldīti atjauninājumi un mērogošana. Tas viss ir definēts, izmantojot YAML manifestus, kas var būt diezgan plaši un sarežģīti.
Visas šīs iespējas trūkums ir stāva mācīšanās līkne, kas lietotājiem prasa apgūt ievērojamu skaitu resursu un modeļu, pirms viņi kļūst prasmīgi darbā ar platformu. Turklāt ekspluatācijas izmaksas ir augstākas: vadības plaknes uzturēšana, atjauninājumu pārvaldība, drošības uzraudzība un praksē nepieciešami platformas profili vai SRE ar padziļinātām zināšanām par Kubernetes un Linux sistēmu administrēšanu.
Praksē tikai relatīvi nelielai daļai lietojumprogrammu ir nepieciešams šāds sarežģītības līmenis jau no pirmās dienas. Daudzi jaunuzņēmumi un vidēja lieluma SaaS uzņēmumi var gadiem ilgi attīstīties ar vienkāršākām arhitektūrām, kuru pamatā ir Swarm vai citi ietvari, un Kubernetes nav būtisks viņu panākumiem.
Galvenās līdzības un atšķirības starp Docker Swarm un Kubernetes
Docker Swarm un Kubernetes kopīgs mērķis ir pārvaldīt konteinerus plašā mērogā, taču tie ievērojami atšķiras pēc sarežģītības līmeņa un tā, kā tie risina tādus jautājumus kā instalēšana, mērogošana, slodzes līdzsvarošana un augsta pieejamība. Šo nianses izpratne ir būtiska, lai izvairītos no sarežģītības radītas pārslodzes vai iespēju deficīta.
Uzstādīšana un sākotnējā konfigurācija
Instalēšanas ziņā Docker Swarm nepārprotami pārspēj vienkāršības ziņā, jo viss, kas nepieciešams, ir Docker instalēšana mezglos un dažas komandas, lai izveidotu klasteri, pievienotu vadītājus un darbiniekus un sāktu pakalpojumu izvietošanu. Starpsistēmu saderība ir augsta, un pieredze ir ļoti konsekventa.
No otras puses, Kubernetes atšķiras atkarībā no vides un izmantotā rīka, sākot no manuālas instalēšanas uzņēmuma iekšējās iekārtās līdz mākonī pārvaldītiem risinājumiem (piemēram, GKE, AKS vai EKS), kur vadības plakni pārvalda pakalpojumu sniedzējs. Lokālās vai pašpārvaldītās sistēmās instalēšana var būt ievērojami laikietilpīgāka un pakļauta kļūdām, ja netiek ievērota labākā prakse.
Mērogojamība un izvietošanas ātrums
Runājot par mērogojamību, Kubernetes piedāvā universālu ietvaru ar iebūvētu horizontālo poda automātisko mērogošanu (HPA) un vertikālo poda automātisko mērogošanu (VPA), kā arī atbalstu pielāgotām metrikām. Tas padara to ideāli piemērotu, ja nepieciešams ļoti precīzi reaģēt uz pēkšņām slodzes izmaiņām vai konsekventi pārvaldīt tūkstošiem instanču. Turklāt tas bieži tiek integrēts ar uzlabotiem uzraudzības rīkiem , lai informētu par šiem mērogošanas lēmumiem.
Docker Swarm prioritāri nosaka ātrumu un vienkāršību mērogošanā, ļaujot palielināt vai samazināt repliku skaitu ar ļoti vienkāršām komandām. Platformai nav tik sarežģītas iebūvētas automātiskās mērogošanas funkcijas, taču ir viegli pievienot ārējus skriptus vai uzraudzības sistēmas, kas automātiski pielāgo replikas, pamatojoties uz tādiem rādītājiem kā procesora jauda, atmiņa vai ziņojumu rindas.
Praksē daudzām lietojumprogrammām pietiek ar mērogošanu ik pēc dažām minūtēm, pamatojoties uz paredzamiem datplūsmas modeļiem, kas ir labi piemērots Swarm. Savukārt Kubernetes izceļas, ja nepieciešami ļoti smalki un bieži mērogošanas lēmumi vai ja datplūsmas un tīkla topoloģijas sarežģītība ir augsta.
Slodzes līdzsvarošana un tīkli
Slodzes līdzsvarošana ir vēl viena joma, kurā abas platformas pieejā atšķiras, lai gan abas efektīvi risina šo problēmu. Docker Swarm ietver iebūvētu slodzes līdzsvarošanu, tāpēc pieprasījumi pakalpojumam tiek sadalīti starp dažādām klasterī pieejamajām replikām.
Kubernetes deleģē daļu no šīs atbildības pakalpojumiem un bieži vien ārējiem slodzes līdzsvarotājiem, neatkarīgi no tā, vai tie ir no paša mākoņpakalpojumu sniedzēja vai trešajām pusēm. Pakalpojumu atklāšana tiek veikta, izmantojot iekšējo DNS, un atklātajām lietojumprogrammām var piekļūt, izmantojot IP adreses, HTTP maršrutus vai sarežģītākus noteikumus, kas definēti Ingress objektos.
Runājot par tīkla modeli, Kubernetes parasti izmanto plakanu tīklu starp podiem, paļaujoties uz CNI spraudņiem un tīkla politikām, lai kontrolētu saziņu starp mezgliem. Savukārt Swarm izveido pārklājuma un tilta tīklus pakalpojumiem un konteineriem, pat ļaujot šifrētu datplūsmu starp mezgliem, veidojot atbilstošos tīklus.
Augsta pieejamība un kļūdu tolerance
Gan Kubernetes, gan Docker Swarm piedāvā stabilus augstas pieejamības mehānismus, lai gan tie tiek ieviesti nedaudz atšķirīgi. Kubernetes podi ir sadalīti pa mezgliem, un, ja pods neizdodas vai mezgls nedarbojas, vadības plakne tos pārplāno uz citiem pieejamajiem mezgliem, saglabājot vēlamo repliku skaitu.
Kubernetes veselības sistēma un zondes ļauj noteikt problemātiskas podus, noņemt tos no slodzes līdzsvarošanas un automātiski atjaunot. Tas apvienojumā ar replikāciju un slodzes līdzsvarošanu nodrošina ievērojamu jaudu, lai izturētu kļūmes, nepārtraucot lietotāju pakalpojumus.
Swarm vidē augsta pieejamība ir atkarīga no pakalpojumu replikācijas un pārvaldnieku lomas, kuri uzrauga klastera stāvokli. Pakalpojumus var viegli dublēt un izplatīt starp mezgliem, tāpēc, ja viens no tiem neizdodas, replikas citos mezglos turpina apkalpot datplūsmu, kamēr pārvaldnieks pārdala uzdevumus.
Lietojumprogrammas konfigurācija un definīcijas modelis
Lietojumprogrammas definīcijas līmenī Kubernetes ievieš savu YAML manifestu ekosistēmu, ar patentētām API un specifiskiem klientiem, piemēram, kubectlTas nozīmē, ka jūs nevarat tieši atkārtoti izmantot savus Docker Compose failus vai Docker CLI, lai aprakstītu savus podus un pakalpojumus; jums ir jāpārveido loģika uz Kubernetes resursiem.
Tas var būt šķērslis, ja jums ir tikai Docker pieredze, jo definīcijas ir jāpārraksta un komandas jāmaina. Tomēr pretī jūs iegūstat ļoti precīzu kontroli pār tādiem aspektiem kā dzīves cikls, izvietošanas stratēģijas, pastāvīgu sējumu pārvaldība un novērojamība.
Savukārt Swarm daudz vairāk atbilst Docker darba metodei, ļaujot aprakstīt pakalpojumus ar YAML failiem, kas ir ļoti līdzīgi Compose failiem, un plaši atkārtoti izmantot esošos rīkus. Tā API neaptver 100% Docker komandu, taču aptver ievērojamu daļu no tām, kas samazina apguves līkni un ļauj izstrādātājam, kas pārzina Docker, ļoti īsā laikā izprast 80% Swarm.
Docker Swarm vs Kubernetes vs Apache Mesos: orķestrētāju trio
Lai gan mediju cīņa bieži tiek vienkāršota līdz Swarm pret Kubernetes, Apache Mesos joprojām ir klātesošs progresīvās orķestrācijas ainavā, īpaši vidēs, kas to jau izmanto citiem mērķiem, piemēram, Hadoop vai lieliem vispārējas nozīmes klasteriem, un alternatīvām, piemēram, Podman un KVM drošai virtualizācijai.
Docker Swarm nepārprotami piešķir prioritāti vienkāršībai un lietošanas ērtumam, ar maigu apgūšanas līkni un diezgan nemainīgu pieredzi. Tas padara to ļoti pievilcīgu projektiem, kuros prioritāte ir ātrums, samazināta darbības berze un pārāk daudz resursu neveltīšana pašai platformai.
Apache Mesos apvienojumā ar Marathon piedāvā jaudīgu un ļoti daudzpusīgu risinājumu klasteru pārvaldībai, kas var darbināt visu, sākot no lielo datu darba slodzēm līdz Docker konteineriem. Tā arhitektūra ir balstīta uz tādiem elementiem kā ZooKeeper, kas palīdz atrast klastera komponentus, un resursu sadales sistēma, kas informē Marathon par centrālā procesora un atmiņas pieejamību konteineru mērogošanai vai pārvietošanai.
Mesos ir atradis savu nišu kā vispārējas nozīmes klasteru platforma daudzos mākoņpakalpojumu sniedzējos, īpaši tur, kur jau pastāv uz tās balstīta infrastruktūra. Tās galvenā priekšrocība ir spēja pārvaldīt dažāda veida darba slodzes vienotā veidā, lai gan tas notiek uz zināmas konfigurācijas sarežģītības un resursu patēriņa rēķina.
Savukārt Kubernetes ir ieguvis popularitāti, pateicoties Google atbalstam un tādu lielu spēlētāju kā Red Hat un Microsoft Azure līdzdalībai. Podu, etiķešu un pakalpojumu ieviešana kā pamata elementi piešķir tam unikālu un ļoti modulāru pieeju sarežģītu lietojumprogrammu pārvaldībai ar dažāda veida konteineriem un prasībām.
Izvēloties starp Swarm, Kubernetes vai Mesos, jāņem vērā tādi faktori kā komandas lielums, pieejamā pieredze, esošā infrastruktūra, mākoņpakalpojumu sniedzējs un konkrētās projekta vajadzības. Nav viena uzvarētāja, bet gan rīki, kas ir vairāk vai mazāk piemēroti atkarībā no konteksta.
Vienkāršība pretstatā pārspīlētai inženierijai: īstā dilemma
Daudzi tehnoloģiju jaunuzņēmumi demonstrē bīstamu tendenci: ievieš Kubernetes un īpaši sarežģītas arhitektūras, lai gan biznesa problēma joprojām ir relatīvi vienkārša un to varētu atrisināt ar Swarm vai vēl mazāk sarežģītiem risinājumiem. Šī pārmērīgā inženierija var patērēt laiku un budžetu, kas nepieciešams citās jomās.
Desmit gadu pieredze klasteru pārvaldībā ar Docker Swarm ir parādījusi, ka lielākajai daļai vidējas izaugsmes jaunuzņēmumu un SaaS uzņēmumu Swarm ir vairāk nekā pietiekams. Ar labu arhitektūras un uzraudzības praksi kritiski incidenti var praktiski nerasties, savukārt infrastruktūras un personāla izmaksas tiek kontrolētas.
Kubernetes ieviešanas slēptās izmaksas bez nepieciešamības ietver izstrādes stundas, kas zaudētas sarežģītu cauruļvadu un manifestu izveidē, grūtības nolīgt profilus ar padziļinātu pieredzi K8 jomā, pārāk lielas infrastruktūras vadības plaknes un palīgpakalpojumu atbalstam, kā arī jauna veida tehnisko parādu, kas balstīts uz platformas raksturīgo sarežģītību.
Dibinātājiem ar ierobežotu budžetu un nelielām komandām katra stunda, kas pavadīta platformas uzturēšanai, ir stunda, kas netiek pavadīta produkta uzlabošanai vai lietotāju uzklausīšanai. Šādā scenārijā Swarm darbības vienkāršība kļūst par konkurences priekšrocību: mazāk rīku, mazāk slāņu un lielāka uzmanība tam, kas patiesi sniedz vērtību.
Kad Docker Swarm jums ir pietiekams, un kad Kubernetes ir tā vērts?
Docker Swarm parasti ir pietiekams arhitektūrām ar 5 līdz 50 mikropakalpojumiem, kuru datplūsmas apjoms svārstās no tūkstošiem līdz dažiem miljoniem pieprasījumu dienā, ar nosacījumu, ka patēriņa modelis ir samērā paredzams un nav nepieciešama globāla izvietošana vairākos reģionos.
Ja jūsu izstrādes komandā ir no 2 līdz 15 cilvēkiem, bez īpašas platformas vai SRE nodaļas, Swarm vienkāršība un tiešā integrācija ar Docker bieži vien ir labāk piemērota nekā Kubernetes sarežģītība. Tas nenozīmē upurēt novērojamību vai mērogojamību, bet gan to pragmatisku ieviešanu un pielāgošanu projekta vajadzībām.
Savukārt Kubernetes izceļas, ja vienlaikus tiek izpildīti vairāki nosacījumi: milzīgs mērogs ar simtiem mikropakalpojumu, klātbūtne vairākos reģionos vai mākoņos, stingras normatīvās prasības (atbilstība, uzlabota segmentācija, sarežģītas drošības politikas) un lielas komandas ar specializētām lomām platformas, drošības un novērojamības jomā.
Ir arī pilnīgi loģiski izvēlēties Kubernetes, ja pati K8s ekosistēma (Istio, Helm, operatori, pakalpojumu tīkls utt.) ir konkurētspējīgs diferenciators, vai nu tāpēc, ka jums ir nepieciešamas šīs īpašās iespējas, vai arī tāpēc, ka jūsu organizācija atbilst standartiem un rīkiem, kas balstīti uz Kubernetes.
Ja jūsu projekts neatbilst vismaz diviem vai trim no šiem nosacījumiem, jums, iespējams, vēl nav nepieciešama Kubernetes sarežģītība. Šādos gadījumos ir saprātīgāk pilnveidot arhitektūru, uzlabot kodu un izspiest pēdējo pilienu no Swarm vai citām vieglākām pieejām, pirms spert izšķirošo soli.
Konfigurācija, izvietošana un uzlabota novērošanas iespēja
Salīdzinot, kā lietojumprogrammas tiek izvietotas Swarm un Kubernetes, atšķirība definējamo resursu apjomā ir uzreiz pamanāma. Kubernetes vidē parasti tiek definēts vismaz viens izvietojums (Deployment), viens pakalpojums (Service) un ideālā gadījumā viens ienākšanas process (Ingress), kā arī konfigurācijas kartes (ConfigMap), slepenie dati (Secrets) un, ja piemērojams, PersistentVolumeClaims.
Tas nozīmē vairākus YAML failus un desmitiem konfigurācijas rindu, Tas nodrošina elastību, bet arī palielina kļūdu virsmu. Savukārt Swarm vidē tīmekļa pakalpojumu ar pamata slodzes līdzsvarošanu var aprakstīt tikai dažās rindās. docker-compose.yml, saglabājot visu vienā failā, ko ir vieglāk apspriest.
Runājot par uzraudzību un novērojamību, gan Swarm, gan Kubernetes nemanāmi integrējas ar tādiem jau izveidotiem ekosistēmas rīkiem kā Prometheus, Grafana un centralizētiem reģistrēšanas risinājumiem. Atšķirība slēpjas faktā, ka Kubernetes parasti piedāvā vairāk piesaistes punktu un iekšējo metriku, savukārt Swarm ir konfigurēts tiešāk ar mazāk starpkomponentiem.
Runājot par automātisko mērogošanu, Kubernetes ietver tādus uzlabotus mehānismus kā HPA un VPA, kas ļauj mērogot, pamatojoties uz centrālo procesoru, atmiņu vai pielāgotiem rādītājiem. Swarm nepiedāvā tik sarežģītu automātisko mērogošanu uzreiz, taču skriptu vai ārēju pakalpojumu izveide, kas pielāgo kopijas, pamatojoties uz biznesa rādītājiem, parasti ir vienkāršāka, nekā šķiet.
Padziļināta apmācība Docker, Swarm un Kubernetes jomā
Konteineru ekosistēmas izaugsme ir novedusi pie specializētiem apmācību kursiem, kas aptver visu, sākot no Docker pamatiem līdz pat padziļinātai orķestrēšanai ar Swarm un Kubernetes. Šie kursi parasti koncentrējas uz to, kā pareizi "Dockerizēt" lietojumprogrammas, izvairīties no bieži pieļautām kļūdām un jau no paša sākuma piemērot labāko praksi.
Visaptveroša apmācību programma parasti ietver moduļus par pastāvīgo krātuvi, Docker tīkliem un orķestrācijas modeļiem, kam seko īpaši bloki par Kubernetes klastera arhitektūru un ikdienas klastera uzraudzību un darbību. Mērķis ir panākt, lai studenti ne tikai zinātu, kā palaist konteinerus, bet arī kā pārvaldīt reālās vides, ņemot vērā stabilitāti un noturību.
Lai gūtu labumu no šāda veida kursiem, ieteicams iegūt iepriekšējas zināšanas Linux un Windows sistēmās, zināšanas par tīmekļa tehnoloģijām un pieredzi ar vismaz vienu populāru programmēšanas valodu, piemēram, Python, JavaScript, C++ vai C#. Ir svarīgi arī labi izprast Docker, lai apmācības laiks būtu veltīts padziļinātiem aspektiem, nevis pamatiem.
Šo apmācību kursu galvenais mērķis ir nodrošināt, lai dalībnieki spētu izstrādāt, izvietot un uzturēt konteinerizētus mikropakalpojumus, pielietojot labāko praksi, analizējot bieži sastopamās problēmas un mācoties izvairīties no visbiežāk pieļautajām kļūdām ražošanas vidē.
Papildus tehniskajiem aspektiem pastāv arī galvenā arhitektūras komponente : izpratne par to, kad ir jēga izmantot Swarm, kad ieteicams ieguldīt Kubernetes, kā novērtēt ekspluatācijas izmaksas un kā saskaņot infrastruktūru ar uzņēmuma stratēģiju un tempu.
Ja mēs visu liekam uz galda, patiesi izšķirošs nav pats orķestrētājs, bet gan arhitektūras kvalitāte, koda efektivitāte un skaidrība, ar kādu ir izstrādāti mikropakalpojumi. Labi izstrādāta sistēma Docker Swarm platformā var darboties daudz labāk nekā slikti ieviesta arhitektūra Kubernetes platformā, lai cik moderna tā arī nebūtu.
Galu galā galvenais ir izvēlēties orķestrēšanas rīku, kas vislabāk atbilst jūsu projekta fāzei, komandas lielumam un faktiskajām mērogošanas prasībām, vienmēr saglabājot vienkāršību kā sabiedroto un izvairoties no kārdinājuma sarežģīt infrastruktūru tikai tāpēc, lai papildinātu savu tehnisko CV.
