Docker (2013) i Kubernetes (2014)

Godina je 2013., i negdje u jednom od tih open-plan ureda s ležaljkama koje nitko ne koristi, netko izgovara rečenicu koju je izgovorio bilijun puta prije njega i izgovorit će je bilijun puta poslije: „Kod mene radi.” Ta rečenica je najstarija laž u softveru koja nikad nije laž. Uvijek je istinita — na njegovom laptopu, s njegovom verzijom baze, s njegovim varijablama okoline (to su onе sitne postavke — lozinke, putanje, adrese — koje program čita kad se pokrene, a koje je on postavio prije osam mjeseci i otad zaboravio da postoje) — i uvijek je, u praksi, potpuno beskorisna. Jer na serveru, tamo gdje aplikacija stvarno treba raditi, ništa od toga ne postoji.

Postavljanje servera 2013. je čudna mješavina rituala i molitve. Ili ručno, prijavom preko SSH-a (to je, pojednostavljeno, daljinski pristup tuđem računalu preko interneta, gdje sjedneš i tipkaš naredbe kao da si fizički pred njim) i tipkanjem naredbi koje pamtiš napamet kao zaklinjanje, ili skriptama koje su trebale biti pouzdane, a zapravo su samo bilježnica tuđih grešaka koje nitko nikad nije obrisao. Virtualke pomažu — cijela ta priča s hipervizorima (bila je riječ o njoj par poglavlja ranije) rješava barem dio problema, jednu mašinu možeš kopirati u drugu. Ali virtualka je debela. Nosi sa sobom čitav operativni sustav, kernel, gomilu stvari koje ti aplikacija od stotinjak megabajta ne treba, a ti je pokreneš, čekaš da se digne, i trošiš resurse na teret koji nitko nije tražio.

I onda, na nekoj konferenciji, na pozornici koja bi po svakoj logici trebala biti tiha jer firma koja je na njoj umire — dotCloud, startup koji se guši i koji se iz čistog očaja okreće nečemu potpuno drugom — jedan inženjer pokaže nešto što nazivaju kontejner, a tehnologiju koja stoji iza njega krste imenom Docker. Nije virtualka. Nije skripta. Aplikacija je spakirana sa svime što joj treba da radi — bibliotekama, ovisnostima, verzijama — u kutiju koja se, jednom kad je zapečaćena, pokreće identično bilo gdje. Na njegovom laptopu. Na serveru. Na tuđem laptopu. Svugdje isto.

Industrija ne reagira zainteresirano. Industrija reagira kao da je netko upravo otkrio vatru u sobi punoj ljudi koji su cijeli život palili šibice jednu po jednu i čudili se zašto im je hladno — a startup, vidjevši što je napravio, uskoro preimenuje cijelu firmu u Docker, jer zašto se zvati dotCloud kad te pamte po kutiji, a ne po tome što je u njoj umiralo.

A onda, godinu dana kasnije, ulazi igrač koji do tad nije trebao objašnjavati ništa nikome: Google. Izvlači nešto što je godinama čuvao kao interni alat, sustav zvan Borg, kojim je dugi niz godina žonglirao vlastitim serverima u razmjerima koje ostatak svijeta nije ni zamišljao — i poklanja tu ideju svijetu, pod novim, grčkim imenom. Kubernetes. Odjednom developeri koji su prije jedva znali razliku između servera i routera počinju izgovarati riječi kao orkestracija, deklarativno stanje, pod — s ozbiljnošću kojom se prije govorilo samo o produkciji baze podataka. Pod je, ako te zanima, osnovna jedinica u Kubernetesu: obično jedan ili više kontejnera koji se pokreću, sele i gase zajedno, kao paket koji se ne rastavlja.

Pa dobro — kaže onaj razumni glas u tebi, onaj koji nije pročitao ni jedan blog post o ovome i samo želi da mu aplikacija radi bez drame — što je to kontejner, zapravo? Zašto se zove baš tako? I zašto je, molim te, orkestracija riječ koju sad koristi pola interneta? Odlična pitanja. Krenimo redom, jer odgovori nisu ni približno tako komplicirani kako zvuče na konferencijskim slajdovima.

Dobro, kaže laik, čuo sam tu riječ svugdje — kontejner, kontejner, stavi to u kontejner — i zvuči mi kao virtualka s marketinškim rebrendingom. Jesam u pravu?

Ne baš — i zapravo je to dobro pitanje, jer si opipao pravu sličnost, samo izvukao pogrešan zaključak; upravo ta sličnost je zamka u koju je pola interneta upalo 2013. Zato krenimo od nečega što nema veze s računalima. Krenimo od broda.

Prije nego što je postojao kontejner kakav znaš — ona metalna kutija koja stoji na kamionima i vlakovima — luke su bile pakao. Radnici su ručno tovarili vreće, sanduke, bačve — svaki teret drugog oblika, drugačije pakiran, drugačije se slaže. Brod bi u luci stajao danima. Onda je 1956. neki tip po imenu Malcolm McLean rekao: dosta, svejedno mi je što je unutra, sve ide u istu standardiziranu kutiju određenih dimenzija, i tu kutiju svaki brod, svaki kran, svaki kamion na planetu zna kako primiti. Nije bitno je li unutra bio TV, banana ili poluvojna oprema — kutija je kutija. Luke su se ispraznile u satima umjesto danima. Globalna trgovina, kakvu danas znaš, postoji uglavnom zahvaljujući toj jednoj dosadnoj metalnoj kutiji.

Softverski kontejner je točno ta ideja, prekopirana skoro slovo po slovo, pola stoljeća kasnije. Umjesto kutije koja ne pita što je unutra teretu, imaš paket koji ne pita na kojem serveru se pokreće. Unutra spakiraš svoju aplikaciju i baš sve što joj treba da radi — biblioteke, verzije, konfiguraciju, cijeli mali svemir ovisnosti — i taj paket onda ide na tvoj laptop, na test server, na produkcijski server u nekom podrumu u Frankfurtu, i svugdje se ponaša identično. Zato ta legendarna rečenica „radi na mojoj mašini” prestaje biti opravdanje i postaje priznanje krivnje. Ako je u kontejneru, radi svugdje. Ili ne radi nigdje, što je bar iskreno.

OK, kaže laik, ali virtualka isto to radi, ne? I ona je paket koji nosi svoj svijet sa sobom.

Jest, i to je razlika koja stvarno vrijedi objasniti, jer je većina ljudi preskače. Virtualka ne dijeli ništa s domaćinom (serverom na kojem se pokreće) — ona je gost koji je odlučio sagraditi vlastitu kuću, s temeljima, sa zidovima, s vlastitim operativnim sustavom od nule, unutar tuđe kuće. Pokreneš pet virtualki na jednom serveru i pokrenuo si pet potpuno zasebnih operativnih sustava, pet jezgri, pet svega, samo da bi svaka od njih na kraju radila jednu jedinu malu aplikaciju. To je kao da za svaki obrok kuhaš u posebno iznajmljenoj kući, s vlastitom strujom i vodom.

Kontejner ne gradi kuću. Kontejner iznajmljuje sobu u kući koja već postoji. Svi kontejneri na tom serveru dijele istu jezgru operativnog sustava — istu kuhinju, ako hoćeš — i samo se pobrinu da jedan ne zna da drugi postoji, da jedan ne pojede drugome hranu iz frižidera. Zato je kontejner težak nekoliko megabajta, a virtualka nekoliko gigabajta. Zato se kontejner pokreće za pola sekunde, a virtualka se budi kao da je ustala iz zimskog sna. Manje ponavljanja, više gustine — na istom serveru staneš deset, dvadeset puta više kontejnera nego virtualki, jer ne plaćaš cijenu duplog operativnog sustava za svaki od njih.

A to dijeljenje kuhinje, pita laik, kako to točno funkcionira? Ili je čarolija?

Nije čarolija, i ovo je dio koji Docker voli prešutjeti u marketingu: sve što Docker radi, Linux je već znao raditi godinama prije Dockera. Postoje dvije stvari u jezgri Linuxa — namespaces (imenski prostori) i cgroups (kontrolne grupe) — koje su postojale već sredinom dvijetisućih. Namespaces su ono što svakom procesu daje iluziju da je sam na svijetu — svoj popis datoteka, svoju mrežu, svoj popis drugih procesa — tako da kontejner A ne vidi kontejner B, iako obojica sjede na istom stroju. Cgroups je ono što tom procesu ograničava koliko procesora i memorije smije pojesti, da jedan kontejner ne udavi cijeli server. Docker 2013. nije izmislio ni jedno ni drugo. Docker je uzeo te dvije alatke, koje su do tada bile toliko nespretne za korištenje da ih je koristila samo hrpica ljudi koji su čitali dokumentaciju za zabavu, i stavio im lijep omot: jednu naredbu, jednu datoteku s receptom, jedan format koji svi razumiju.

— OK, shvatio sam kutije. Ali zašto su svi tako popizdili oko toga? Ljudi po konferencijama plaču od sreće, firme mijenjaju cijelu infrastrukturu — zbog kutije?

Ne zbog kutije. Zbog recepta za kutiju. To je razlika koju svi preskoče kad prvi put čuju za Docker, pa onda ostanu zbunjeni zašto je to toliko bitno. Zamisli da imaš Dockerfile — običnu tekstualnu datoteku, desetak redaka, ništa spektakularno na pogled. U njoj piše, korak po korak: uzmi ovu osnovu (recimo, Ubuntu), instaliraj ovo, kopiraj taj kod, pokreni ovu naredbu. Kad tu datoteku pokreneš, dobiješ identičnu kutiju — svaki put, na svakom stroju, bez iznimke.

— I to je to? Datoteka koja radi točno ono što je napisano da radi?

Znam da zvuči kao da hvalim vodu jer je mokra. Ali cijela infrastruktura prije toga sastojala se od ljudi koji pamte stvari. Netko je 2011. instalirao verziju biblioteke X na server, i sad ta informacija živi u njegovoj glavi, možda u nekom Wordovom dokumentu koji nitko ne ažurira, možda u mejlu od prije dvije godine. Dockerfile tu istu informaciju pretvara u kod. Ne u opis koda — u kod koji se stvarno izvršava i koji, ako je pogrešan, jednostavno ne radi. Ne može lagati na način na koji dokumentacija laže. Dokumentacija kaže „instaliraj verziju 3.2” i onda šest mjeseci nitko ne provjeri je li to još istina. Dockerfile to provjerava svaki put kad ga pokreneš, jer se svaki put stvarno izvršava.

To je ono „infrastruktura kao kod” o čemu ćeš čuti na svakom drugom slajdu — ponovljivost kao spas. Zvuči kao korporativni žargon, ali iza njega stoji jedna vrlo konkretna stvar: rečenica „radi na mojoj mašini” umire. Ne postoji više tvoja mašina i produkcijski server kao dva različita svemira koja se povremeno posvađaju. Postoji jedna slika — zamisli je kao recept, zapečaćen iz onog Dockerfilea o kojem smo govorili — a kontejner je jelo koje iz tog recepta stvarno nastane kad ga pokreneš, živa, radna instanca te slike. Developer testira sliku na laptopu, ista slika ide na server, ista ide u testno okruženje. Ako radi kod tebe, radi i tamo — jer to tehnički nije „slično okruženje”, to je bit za bit ista kutija.

— I to je onda upalilo brzo, pretpostavljam?

Brže nego što industrija obično prihvaća bilo što. Alati u ovom svijetu tipično trebaju godine da se probiju kroz konzervativizam timova kojima je „radi, ne diraj” sveto pravilo. Docker je unutar tri godine postao de facto standard — preuzimanja slika brojala su se u milijunima, gotovo svaka veća firma s tehnološkim odjelom imala ga je negdje u lancu do 2016. Neki ga zovu najbrže usvojenim developerskim alatom u povijesti, i teško je pronaći ozbiljnog kandidata koji bi to pobio.

— Onda su vlasnici sigurno postali bogati preko noći.

E, tu dolazimo do dijela koji je tragikomičan, i vrijedi ga upamtiti jer se ponavlja kroz cijelu povijest tehnologije. Firma iza Dockera, Docker Inc., gledala je kako joj se tehnologija širi eksponencijalno — i godinama nije znala kako od toga zaraditi. Alat je besplatan, otvorenog koda, koristi ga cijeli planet, a firma treba plaćati inženjere i račune. Probali su komercijalni „Docker Enterprise”, probali su vlastite alate za upravljanje kontejnerima, probali su se natjecati s Kubernetesom umjesto da ga prihvate. Na kraju su 2019. prodali enterprise dio firmi Mirantis, u poslu koji je zvučao više kao rasprodaja imovine nego kao trijumf. Tehnologija je pobijedila apsolutno; firma koja ju je izumila jedva je preživjela vlastiti uspjeh.

Zvuči poznato ako si čuo priču o Jacku Kilbyju — inženjeru koji je 1958. izumio integrirani krug (onu malu pločicu s tisućama sitnih elektroničkih komponenti nabijenih na jedno mjesto, bez koje danas ne postoji ni jedan kompjuter, telefon ni kalkulator) i time promijenio svijet, a od patenta nikad nije vidio ono bogatstvo koje bi logika sugerirala. Izum i biznis su dva različita posla, i povijest softvera je prepuna ljudi koji su savladali prvi a promašili drugi.

Dobro, kaže laik, imam ja sad Docker. Spakirao sam appicu u kutiju, radi svugdje isto, fenomenalno. Ali čekaj — imam sto tih appica, i imam, recimo, dvadeset strojeva na kojima to sve treba živjeti. Netko treba odlučiti koja kutija ide na koji stroj. Netko treba primijetiti kad jedna appica crkne u tri ujutro i podignuti novu umjesto nje. Netko treba znati da appica broj 47 priča s appicom broj 12 i da im obje treba otvoriti vrata jedna prema drugoj. Tko je taj netko?

E vidiš, upravo tu je Docker digao ruke. Docker je genijalan u tome da napravi JEDNU kutiju — jednu sliku koja se, kad je pokreneš, pretvori u živi, radni kontejner. Ali orkestar od sto takvih kutija, na sto pozornica, koje sve moraju svirati istu simfoniju bez da se pojede jedna drugu — to je posve drugi problem, i taj problem se zove orkestracija. Otkud, uzgred, i dolazi ime: Kubernetes je grčki za kormilara, onog tipa koji upravlja brodom. Ne onog koji je sagradio brod — Docker je sagradio kontejnere, u množini. Netko treba stati na krmu i voziti sve to zajedno bez sudara.

I tu dolazimo do dijela koji laik pita s podignutom obrvom: čekaj, otkud sad Google u ovoj priči? Docker je nastao iz dotCloud-a, malog startupa u nevolji (osnovao ga Francuz, ali sjedište mu je bilo u San Franciscu), a Google — firma koja objektivno nema nikakvu potrebu bilo što poklanjati — upravo je zato poklonila svijetu Kubernetes, softver sagrađen na godinama iskustva s Borgom, njihovim internim sustavom za planetarnu infrastrukturu. Borg sam nikad nije izašao iz Googleovih zidova, ali sve što su iz njega naučili — to su, u osnovi, otvorili svima.

OK, kaže laik, kul priča, ali kako to uopće radi? Naredim mu da nešto sredi i on to — samo sredi? Otprilike. I ovo je dio koji najviše zbunjuje ljude koji dolaze iz svijeta skripti, gdje računalu kažeš korak po korak što da radi: prvo ovo, onda ono, pa provjeri, pa ponovi. Kubernetes ne radi tako. Kubernetes radi deklarativno — riječ koja zvuči kudikamo strašnije nego što treba biti.

Zamisli termostat. Ti ne govoriš termostatu: uključi grijanje, čekaj sedam minuta, isključi, provjeri temperaturu, pa ako je hladno uključi opet. Ti kažeš termostatu samo jednu stvar: želim 21 stupanj. I onda se termostat, u pozadini, bez tvog nadzora, do kraja vremena bori da ta rečenica ostane istinita. Padne temperatura — on upali grijanje. Netko otvori prozor — on radi više. Tebe to više ne zanima, ti si svoju želju izrekao jednom.

Kubernetes je termostat za appice. Ti mu ne kažeš pokreni appicu na stroju broj tri, pa ako padne pokreni je na stroju broj pet, pa provjeri je li živa svake minute. Ti mu kažeš jednom, u jednom fajlu: želim da ova appica uvijek postoji u tri kopije. Sve ostalo je Kubernetesov problem. Padne kopija — on digne novu, negdje gdje ima mjesta, bez da te pita. Ugasi se cijeli stroj — on preseli sve što je na njemu živjelo na drugi. Ti si izrekao želju. On se cijeli život bori da ta želja ostane istinita, tiho, u pozadini, dok ti spavaš.

Jer da bi izrekao tu jednu, naizgled jednostavnu želju — tri kopije, molim — moraš napisati YAML fajl. YAML (skraćeno od „YAML Ain't Markup Language”, a u prijevodu — nije bitno, upamti samo da je to običan tekstualni format za opisivanje podataka i postavki, kao Word dokument za konfiguraciju, i koristi se posvuda, ne samo u Kubernetesu) za nešto ozbiljno u Kubernetesu nije tri linije. To je Deployment, koji treba Service da bi mogao pričati sa svijetom, koji treba Ingress da bi svijet mogao pričati s njim, koji treba ConfigMap za postavke, Secret za lozinke, i Namespace da se sve to ne pomiješa s appicom kolege iz drugog tima — i pažljivo, ovaj Namespace nema nikakve veze s onim „namespaces” iz Linux kernela o kojima smo pričali ranije, to je samo Kubernetesova posudila istu riječ za svoju posve drugu pregradu. Svaka od tih riječi je zapravo isto pitanje — kako želim da svijet izgleda — ali napisano formalnim, uvučenim, razmacima-osjetljivim jezikom u kojem jedan pogrešan razmak sruši cijelu priču bez ikakve poruke o grešci koja to objašnjava na ljudski način.

Zato postoji vic, koji je manje vic i više statistika, da Kubernetesovi inženjeri provedu više vremena čitajući YAML nego pišući kod koji zapravo nešto radi. YAML je postao liturgija — skup rečenica koje moraš izgovoriti točnim redom, u točnom obliku, da bi se sustav udostojio poslušati te. Cijela industrija konzultanata i certifikata izrasla je isključivo na tome da nauči ljude ispravno moliti YAML bogu deklarativnosti.

Pa dobro, pita laik, ako je toliko komplicirano — zašto ga svi koriste? Zato što je alternativa gora. Zato što kad imaš sto strojeva, ta se komplikacija svejedno mora negdje odraditi — pitanje je samo hoćeš li je platiti unaprijed, jednom, u obliku YAML-a i muke učenja, ili je platiti kasnije, svake noći u tri, kad ti custom bash skripta koju je napisao kolega koji je otišao prije dvije godine odluči prestati raditi bez ikakvog objašnjenja. Kubernetes je skup, ali je bar skup na dosljedan način.

Dobro pitanje. Zapravo, TO je pitanje. Jer prije nego što otvoriš YAML datoteku, prije nego što instaliraš bilo što s tri slova u nazivu, moraš odgovoriti na jedno drugo: koliko je velik tvoj problem?

Iskreno, pošteno, bez uvijanja — većini ljudi koji čitaju ovo poglavlje, ne treba. Ne treba ti Kubernetes ako imaš jednu aplikaciju, jedan server i tridesetak korisnika koji uglavnom spavaju noću kao i ti. Ne treba ti orkestracija ako tvoj cijeli sustav staje u jedan Docker Compose file — a to je samo jedna datoteka kojom kažeš „pokreni mi ove kontejnere zajedno, na ovom stroju”, bez ikakvog Kubernetesovog cirkusa oko toga — i pokrene se s tri komande. Ne treba ti klaster od petnaest strojeva da poslužiš blog koji čita tvoja mama i dva kolege s posla.

Kome, onda, stvarno treba? Tri poštena kriterija, bez marketinškog sjaja.

Prvo — skala. Ne „imam malo veći promet”, nego stotine ili tisuće instanci koje se moraju dizati, gasiti i premještati po strojevima brže nego što bi ih čovjek ručno stigao pratiti. Netflix, banke, svi koji imaju prometne udare u kojima za pola sata dobiju deset puta više korisnika — njima Kubernetes rješava problem koji bi inače trebao tim ljudi budnih 0-24.

Drugo — timovi. Ne jedan developer, nego pedeset timova koji svaki gura svoj mikroservis (to je pristup gdje se aplikacija ne piše kao jedna velika cjelina, nego kao skup malih, samostalnih servisa — svaki radi jednu stvar i s ostalima priča preko mreže) u istu infrastrukturu, i nitko od njih ne smije čekati drugoga da mu ‚instalira Node na server’. Kubernetes tu ne rješava tehnički problem toliko koliko organizacijski — daje svima isti jezik i ista pravila igre, pa se ne moraš svaki put dogovarati iznova.

Treće — multi-cloud, ili barem prijetnja da će do njega doći. Ako te muči strah da ćeš ostati zaključan kod jednog dobavljača (vendor lock-in, sjeti se poglavlja o cloudu — ono kad ti je toliko toga vezano za jednog pružatelja usluge da odlazak k drugom postane noćna mora), Kubernetes je taj zajednički jezik koji radi jednako na AWS-u, Google Cloudu, Azureu i na tvom vlastitom serveru u podrumu. Cijena te slobode je kompleksnost koju plaćaš svaki dan, bez obzira seliš li se ikad ili ne.

Ako se ne prepoznaješ u nijednom od ta tri slučaja — ne treba ti Kubernetes. I to je posve u redu reći na sastanku, glasno, iako te kolege gledaju kao da si upravo priznao da vjeruješ u ravnu Zemlju.

Zato postoji, kao tiha kontrarevolucija, pokret koji se zove „boring technology” (doslovno: „dosadna tehnologija”). Osnovna ideja: biraj alate koji su dosadni — staru, dobro poznatu tehnologiju koja radi bez drame — i sačuvaj svoj ograničeni budžet uzbuđenja za problem koji ti STVARNO donosi novac. Firma ima, kažu zagovornici, otprilike tri „inovacijska žetona” koje smije potrošiti na rizičnu, novu tehnologiju prije nego što timu i produktu presiječe žile. Potrošiš li sva tri žetona na infrastrukturu — na Kubernetes, na najnoviju bazu podataka, na trendi programski jezik — nemaš ništa ostavljeno za samu ideju zbog koje si uopće krenuo raditi.

Dakle, poštena preporuka, bez sramote: ako ti Docker Compose i jedan server rješavaju problem — to je pobjeda, ne poraz. Kubernetes čekaj dok te ne zaboli. Kad te stvarno zaboli, znat ćeš — i tada nećeš pitati treba li ti, nego kako brzo ga možeš dobiti.

Dobro pitanje za kraj — pa što je onda taj DevOps, ta riječ koju svi lijepe na CV kao naljepnicu za auto? Kratki odgovor: rušenje zida. Dugo je vrijedilo pravilo koje je zvučalo skoro pa razumno — developeri pišu kod, bace ga preko ograde, i onaj tim s druge strane („operations”, „ops”, ljudi koji spavaju s pagerom pod jastukom) mora to nekako pokrenuti, održati i ne dopustiti da se sruši u tri ujutro. Kod puca? Nije moj problem, ja sam ga samo napisao. E, upravo je to stav koji je Kubernetes — i sve što je oko njega izraslo — pokušao ugasiti.

Amazon je smislio mantru koja je u početku zvučala kao kazna, a na kraju se pokazala kao spas: you build it, you run it — ti si napisao, ti dežuraš. Ako tvoj servis padne u nedjelju u tri ujutro, javlja se pager (u doba prije mobitela to je bio mali uređaj koji je dežurnog inženjera budio kad nešto na produkciji pukne — danas je to samo lijepa metafora za „biti na dežurstvu”), i to tebi, ne nekom jadniku iz drugog tima koji ni ne zna što je particija baze o kojoj mu vičeš na telefon. Zvuči brutalno, i jest — ali je to najbrži tečaj empatije koji postoji. Kad znaš da ćeš ti biti taj koji čita svoj vlastiti error log u pidžami, iznenada pišeš bolji error log.

I tu u priču dolazi Kubernetes, kao alat koji tu filozofiju čini izvedivom — jer da developer zaista sam dežura za svoj servis, taj servis mora biti nešto što se može automatski podignuti, automatski zamijeniti i automatski skalirati (to je birokratski izraz za „povećati ili smanjiti broj kopija ovisno o tome koliko je ljudi trenutno navalilo na servis”) bez da netko u tri ujutro ručno tipka naredbe u terminal. Deklarativnost iz prošlog odjeljka — želim tri kopije, sustav se brine da ih uvijek ima — nije samo tehnička elegancija. To je razlog zašto dežurstvo ne znači nužno katastrofu. Pola vremena sustav se sam popravi prije nego ti stigneš otvoriti laptop.

Oko toga se onda nakupio cijeli zoološki vrt. Postoji zaklada — Cloud Native Computing Foundation, CNCF — nastala baš zato da ugosti Kubernetes i sve što je oko njega izniklo. Ako si ikad vidio onaj slajd koji konferencije vole pokazati, onaj s petsto logotipova nabijenih jedan uz drugi u sitnom fontu, to je landscape (karta ekosustava) CNCF-a. I nemoj se zavaravati da je to znak zdravlja — to je simptom. Toliko je alata da postoji alat koji ti pomaže odabrati koji alat koristiti, a onda i konferencija o tom alatu za odabir alata. Ekosustav koji cvate ovako bujno obično znači jedno: nitko zapravo ne zna koje je pet stvari doista nužno, pa se izmisli pet stotina, i neka tržište presudi.

Ali ispod svog tog šuma, poanta cijelog ovog poglavlja stoji mirna i jednostavna, i vraća nas na mjesto gdje smo počeli — na brodski kontejner. Kontejneri, ti softverski, Dockerovi, nisu pobijedili jer su pametni. Pobijedili su jer su dosadni. Standardna kutija, ista bilo gdje; bilo tko je može podignuti kranom, bilo tko je može spremiti na brod, bilo tko je može otvoriti na drugom kraju svijeta i znati što je unutra. Malcolm McLean je to skužio za robu na palubi pedesetih godina. Programeri su to isto skužili šezdesetak godina kasnije za redove koda — i onda su, dosljedno svom fahu, izmislili petsto alata da bi tu jednu dosadnu ideju učinili što kompliciranijom.