🥇Moderna infrastrukturer: utmaningar och möjligheter

I slutet av maj använder vi genomförde vi ett online-möte om „Moderna infrastrukturer och containrar: problem och perspektiv“. Vi diskuterade containrar, Kubernetes och orkestrering i allmänhet, urvalskriterier för infrastruktur och mycket mer. Deltagarna delade med sig av fallstudier från sin egen praktik.

Deltagare:

Evgenij Potapov, VD för „ITSumma“. Mer än hälften av hans kunder antingen har redan övergått eller vill övergå till Kubernetes.
Dmitrij Stolyarov, CTO för „Flant“. Har över 10 års erfarenhet av arbete med containersystem.
Denis Remchukov (aka Eric Oldmann), COO för argotech.io, tidigare på RAO EES. Lovade att berätta om fallstudier inom den "blodiga" företagssektorn.
Andrej Fedorovskij, CTO för „News360.com“Efter att företaget köptes av en annan aktör ansvarar han för en rad ML- och AI-projekt samt för infrastrukturen.
Ivan Kruglov, systemingenjör, tidigare på Booking.com.Just den personen som med sina egna händer har gjort mycket med Kubernetes.

Ämnen:

Deltagarnas insikter om containrar och orkestrering (Docker, Kubernetes och liknande); vad de har provat i praktiken eller analyserat.
Fallstudie: Företaget bygger en plan för att utveckla infrastrukturen under många år. Hur fattas beslutet om man ska bygga (eller överföra den nuvarande) infrastrukturen till containrar och Kubernetes eller inte?
Problem i världen av cloud-native, vad som saknas, låt oss fantisera om vad som kommer att hända imorgon.

En intressant diskussion uppstod; deltagarnas åsikter var så olika och väckte så många kommentarer att jag ville dela dem med er. Det finns en video på tre timmar, och nedan – en sammanfattning av diskussionen.

Är Kubernetes redan en standard eller en utmärkt marknadsföring?

„Vi kom till det (Kubernetes – red.) vid en tidpunkt då ingen ens kände till det. Vi kom till det innan det ens existerade. Vi ville ha det innan det“ — Dmitrij Stolyarov

Foto från Reddit.com

För 5-10 år sedan fanns det ett stort antal verktyg, men ingen enhetlig standard. Var sjätte månad dök det upp en ny produkt, ibland flera. Först Vagrant, sedan Salt, Chef, Puppet,… „och varje halvår omstrukturerar du din infrastruktur. Du har fem administratörer som ständigt är upptagna med att skriva om konfigurationerna“ — minns Andrej Fedorovskij. Han anser att Docker och Kubernetes har „tryckt undan“ de andra. Docker har blivit standard under de senaste fem åren, Kubernetes under de senaste två. Och det är bra för industrin..

Dmitrij Stolyarov och hans team älskar Kubernetes. De önskade sig ett sådant verktyg innan det ens fanns, och kom i kontakt med det när ingen annan visste vad det var. För närvarande, av bekvämlighetsskäl, tar de inte in kunder om de förstår att de inte kommer att implementera Kubernetes för dem. Enligt Dmitrij har företaget "ett flertal gigantiska framgångshistorier kring omvandling av föråldrad teknik."

Kubernetes är inte bara containerorkestrering, utan ett konfigurationshanteringssystem med en utvecklad API, komponenter för nätverk, L3-lastbalansering och Ingress-kontroller, vilket gör det relativt enkelt att hantera resurser, skala upp och abstrahera från underliggande infrastruktur.

Tyvärr måste man betala för allt i livet. Och denna skatt är stor, särskilt när det kommer till att övergå till Kubernetes för företag med välutvecklad infrastruktur, enligt Ivan Kruglov. Han skulle kunna arbeta både med traditionell infrastruktur och med Kubernetes. Det viktigaste är att förstå företagets och marknadens egenskaper. Men för exempelvis Evgenij Potapov, som skulle generalisera Kubernetes som vilket verktyg för containerorkestrering som helst, är denna fråga inte aktuell.

Evgenij jämförde situationen med den på 1990-talet, när objektorienterad programmering dök upp som ett sätt att programmera komplexa applikationer. Vid den tiden pågick debatter och nya verktyg som stödde OOP dök upp. Därefter kom mikrotjänster som ett sätt att gå bort från den monolitiska koncepten. Detta ledde i sin tur till framväxten av containrar och verktyg för deras hantering. "Jag tror att vi snart kommer till en tid då frågan om man ska skriva små applikationer som mikrotjänster inte längre kommer att ställas, det kommer att göras som standard i form av mikrotjänster," anser han. På liknande sätt kommer Docker och Kubernetes över tid att bli en standardlösning utan behov av val.

Problemet med databaser är stateless.

Foto av Twitter: @jankolario på Unsplash

I vår tid finns det många recept på hur man startar databaser i Kubernetes. Även hur man separerar den del som arbetar med disk I/O från, låt oss säga, applikationsdelen av databasen. Är det möjligt att databaser i framtiden kommer att förändras så mycket att de kommer att levereras i en låda där en del koordineras via Docker och Kubernetes, medan en annan del av infrastrukturen, genom separat mjukvara, tillhandahåller lagringsdelen? Kommer databaser att förändras som produkt?

Denna beskrivning liknar köhantering, men kraven på tillförlitlighet och synkronisering av information i traditionella databaser är mycket högre, menar Andrey. Cache hit ratio i normala databaser ligger på cirka 99%. Om en arbetare kraschar startar en ny och cachen "värms upp" från grunden. Tills cachen har värmts upp arbetar arbetaren långsamt, vilket betyder att den inte kan hantera användarlasten. Utan användarlast värms cachen inte upp. Det är en ond cirkel.

Dmitry håller helt med, — kvorum och shardning löser problemet. Men Andrey insisterar på att lösningen inte passar alla. I vissa situationer kan kvorum fungera, men det ger extra belastning på nätverket. NoSQL-databasen passar inte alltid.

Deltagarna på meetupen delade upp sig i två läger.

Denis och Andrey hävdar att allt som skriver till disken — databaser och annat — är omöjligt i Kubers aktuella ekosystem. Det är omöjligt att bevara integriteten och konsistensen av produktionsdata i Kubernetes. Det är en grundläggande egenskap. Lösning: hybrid infrastruktur.

Även moderna cloud-native databaser, som MongoDB och Cassandra, eller meddelandeköer som Kafka eller RabbitMQ, kräver konstant datalagring utanför Kubernetes.

Evgeny invänder: "Databaser i Kuber — en trauma nära ryska, eller nära företagsmässiga, som beror på att det saknas Cloud Adoption i Ryssland." Små eller medelstora företag i väst är Cloud. Att använda Amazon RDS-databaser är enklare än att själva hantera Kubernetes. I Ryssland används Kuber "on-premise" och databaser flyttas dit när de försöker bli av med djungeln.

Dmitry höll inte heller med påståendet att inga databaser kan hållas i Kubernetes: "Databas är inte bara databaser. Och om man stoppar in en gigantisk relationsdatabas — då absolut inte. Om man stoppar in något litet och cloud-native, som moraliskt är redo för en halv-efermerisk livsstil, kommer allt att gå bra." Dmitry nämnde också att verktygen för databasadministration inte är redo för varken Docker eller Kuber, vilket ger stora svårigheter.

Ivan är övertygad om att även om man bortser från begreppen stateful och stateless, så är ekosystemet för företagslösningar i Kubernetes ännu inte redo. Det är svårt att upprätthålla krav från lagstiftare och tillsynsmyndigheter med Kuber. Till exempel är det omöjligt att skapa en identitetslösning där strikta garantier för serveridentifiering krävs, ner till den hårdvara som sätts in i servrarna. Detta område utvecklas, men det finns fortfarande ingen lösning.
Deltagarna kunde inte nå en överenskommelse, så det kommer inte att finnas några slutsatser i detta avsnitt. Låt oss istället ge några praktiska exempel.

Fall 1. Cybersecurity för "megaregulatorn" med databaser utanför Kubernetes

I en välutvecklad cybersäkerhetssystem gör användningen av containrar och orkestrering det möjligt att försvara sig mot attacker och intrång. Till exempel, i en megaregulator har Denis och hans team implementerat en koppling mellan orkestratorn och en utbildad SIEM-tjänst som analyserar loggar i realtid och identifierar processen för attack, intrång eller systemfel. Vid en attack, ett försök att ladda upp något, eller under ett ransomware-intrång, aktiverar den genom orkestratorn snabbt containrar med applikationer snabbare än de blir smittade, eller snabbare än angriparen kan attackera.

Fall 2. Delvis flytt av databaser från Booking.com till Kubernetes

På Booking.com är huvuddatabasen MySQL med asynkron replikering — det finns en master och en hel hierarki av slavar. Vid tidpunkten för Ivans avsked från företaget hade ett projekt för att flytta slavar som kan "skjutas bort" med viss skada startats.

Förutom huvuddatabasen finns det en installation av Cassandra med skräddarsydd orkestrering, som skrevs innan Kubernetes blev mainstream. Det finns inga problem på det planet, men den har persistent lagring på lokala SSD. Avlägsna lagringslösningar, även inom samma datacenter, används inte på grund av problem med hög latens.

Den tredje klassen av databaser är söktjänsten Booking.com, där varje nod i tjänsten är en databas. Försök att flytta söktjänsten till Kubernetes misslyckades, eftersom varje nod har 60–80 GB lokal lagring, vilket är svårt att "starta upp" och "värma upp".

Som ett resultat flyttades inte sökmotorn till Kubernetes, och Ivan tror inte att det kommer att göras nya försök inom en snar framtid. MySQL-databasen har flyttats till hälften: endast slavarna, som det inte är så farligt att "skjuta bort". Cassandra har "anpassat sig" utmärkt.

Valet som infrastruktur är en uppgift utan en universallösning

Foto av Manuel Geissinger från Pexels

Anta att vi har ett nytt företag, eller ett företag där en del av infrastrukturen är gammaldags. De arbetar med en långsiktig plan för infrastrukturutveckling. Hur fattas beslutet om att bygga infrastrukturen med containrar och Kubernetes eller inte?

Företag som tävlar om nanosekunder är undantagna från diskussionen. En sund konservatism lönar sig av pålitlighetsskäl, men det finns ändå företag som bör överväga nya angreppssätt.

Ivan: "Jag skulle definitivt starta ett företag i molnet just nu, bara för att det är snabbare", även om det inte nödvändigtvis är billigare. Med utvecklingen av riskkapital har startups som har pengar inte stora problem, och huvudmålet är att erövra marknaden.

Ivan anser att utvecklingen av den nuvarande infrastrukturen är ett urvalskriterium. Om det har gjorts stora investeringar tidigare och det fungerar, finns det ingen anledning att omstrukturera. Om infrastrukturen däremot inte är utvecklad, och det finns problem med verktyg, säkerhet och övervakning, finns det anledning att överväga distribuerad infrastruktur.

Skatten måste betalas oavsett, och Ivan skulle betala den som tillåter honom att i framtiden betala mindre. "För bara genom att åka i ett tåg som drivs av andra kan jag färdas mycket längre än om jag sätter mig i ett annat tåg där jag måste fylla på bränsle själv." säger Ivan. När företaget är nytt och kraven på latenstid är tiotals millisekunder, skulle Ivan titta mot "operatörerna", där de idag "paketerar" klassiska databaser. De sätter upp en replikationskedja som automatiskt växlar vid fel och så vidare...

För ett litet företag med några servrar i Kubernetes är det meningslöst, säger Andrei. Men om det planerar att växa till hundra servrar eller mer, behövs automatisering och resursförvaltningssystem. 90 % av fallen rättfärdigar kostnaderna. Oavsett last och resurser är det meningsfullt för alla, från startups till stora företag med miljoner användare, att gradvis börja titta i riktning mot produkter för orkestrering av containrar. "Ja, det är verkligen framtiden", är Andrei säker på.

Denis angav två huvudsakliga kriterier — skalbarhet och driftsäkerhet. Han väljer de verktyg som passar bäst för uppgiften. "Det kan vara en no-name-lösning som byggts ihop själv, med Nutanix Community Edition. Det kan också vara en andra linje i form av en applikation på Kubernetes med en databas i bakgrunden som replikerar och har angivna RTO- och RPO-parametrar" (recovery time/point objectives — exempel).

Evgenij påpekade en möjlig problematik med expertis. För närvarande finns det inte så många högkvalificerade specialister på marknaden som verkligen förstår "insidan". Faktum är att om den valda teknologin är gammal, är det svårt att hitta någon annan än trötta och uttråkade äldre personer. Men andra deltagare anser att detta handlar om utbildningsfrågor.
Om man ställer frågan om valet mellan att köra ett litet företag i Public Cloud med databaser i Amazon RDS eller "on premise" med databaser i Kubernetes, så blev valet för deltagarna Amazon RDS, trots vissa nackdelar.

Eftersom de flesta av lyssnarna på meetupen inte kommer från "det blodiga" företagslivet, är distribuerade lösningar något att sikta på. Lagringssystem bör vara distribuerade, pålitliga och skapa latens som mäts i millisekunder, maximalt tiotals., — sammanfattade Andrei.

Utvärdering av användningen av Kubernetes

Lyssnaren Anton Zhbankov ställde en fälla-fråga till Kubernetes-apologeter: hur valde ni och genomförde kostnads-bevakningen? Varför Kubernetes, varför inte virtuella maskiner, till exempel?

Foto av Tatyana Eremina på Unsplash

De svarade Dmitrij och Ivan. I båda fallen, genom trial and error, gjordes en sekvens av beslut som ledde båda deltagarna till Kubernetes. Nu börjar företag själva utveckla mjukvara som är meningsfull att flytta till Kubernetes. Det handlar inte om klassiska tredjeparts-system som 1C. Kubernetes hjälper till när utvecklarna snabbt behöver göra släpp, under oavbruten Continuous Improvement.

Andrei's team försökte skapa en skalbar kluster baserat på virtuella maskiner. Noderna föll som dominobrickor, vilket ibland ledde till klusterkollaps. "Teoretiskt sett kan man få det att fungera och underhålla det manuellt, men det är väldigt tråkigt. Och om det finns en lösning på marknaden som fungerar ur lådan, går vi gärna dit. Och vi bytte till slut", berättar Andrei.

Det finns standarder för denna typ av analys och beräkning, men ingen kan säga hur korrekta de är på verklig hårdvara i drift. För beräkningarna är det också viktigt att förstå varje verktyg och ekosystem, men det är omöjligt.

Vad väntar oss

Foto av Drew Beamer på Unsplash

När teknologier utvecklas dyker allt fler fragment upp, och sedan sker en fasövergång där en leverantör kommer fram som har dödat tillräckligt med "kapital" för att allt ska förenas i ett enda verktyg.

Tycker ni inte att det kommer en tidpunkt då ett verktyg kommer att dyka upp som Ubuntu blev för Linuxvärlden? Kanske kommer ett enhetligt verktyg för containerisering och orkestrering även att inkludera Kubernetes. Det kommer att göra det enkelt att bygga on-premise moln.

Ivan svarade: "Google bygger just nu Anthos - deras paketlösning som distribuerar molnet och inkluderar Kubernetes, Service Mesh, övervakning – all bindning som behövs för mikrotjänster i 'on-premise'. Vi är nästan i framtiden."

Denis nämnde också Nutanix och VMware med produkten vRealize Suite, som kan hantera liknande uppgifter utan containerisering.

Dmitrij delade med sig av sin åsikt att minskning av "smärta" och sänkning av skatter är två områden där vi kan förvänta oss förbättringar.

Sammanfattningsvis av diskussionen kan vi lyfta fram följande problem med modern infrastruktur

Tre av deltagarna påpekade problemet med stateful.
Olika typer av problem med säkerhetssupport, inklusive risken att flera versioner av Python, applikationsservrar och komponenter hamnar i Docker.
Överutnyttjande, om vilket det är bättre att ha ett separat möte.
Utbildningsproblematiken, eftersom orkestrering är en komplex ekosystem.
En allmän problematik i branschen – användningen av verktyg utanför deras avsedda syfte.
Övriga slutsatser får ni dra själva. Det kvarstår en känsla av att kopplingen Docker + Kubernetes har svårt att bli en "central" del av systemet. Till exempel installeras operativsystem först på hårdvaran, vilket inte går att säga om containrar och orkestrering. Kanske kommer operativsystem och containrar att flätas samman med mjukvara för hantering av moln i framtiden.

Foto av Gabriel Santos Fotografia från Pexels
Passar på att hälsa till mamma och påminna om att vi har en Facebook-grupp “Hantera och utveckla stora IT-projekt”, kanal @feedmeto med intressanta inlägg från olika teknologibloggar. Och min kanal @rybakalexey, där jag berättar om utvecklingshantering i produktföretag.