I sapun dhe drejtor i «Otomato Software», një nga iniciatorët dhe instruktoret e parë të çertifikimit DevOps në Izrael, Anton Weiss, foli vitin e kaluar për teorinë e kaosit dhe parimet kryesore të inxhinierisë së kaosit, si dhe shpjegoi si është organizata ideale DevOps e të ardhmes.
Kemi përgatitur një version tekstual të referatit.
Mirëmëngjes!
DevOpsDays në Moskë po organizohet për herë të dytë, unë jam për herë të dytë në këtë skenë, shumë nga ju janë për herë të dytë në këtë sallë. Çfarë do të thotë kjo? Do të thotë se lëvizja DevOps në Rusi po rritet dhe përhapet, dhe më e rëndësishmja, kjo do të thotë se ka ardhur koha të flasim për atë se çfarë do të thotë DevOps në vitin 2018.
Të ngrini dorën ata që mendojnë se në vitin 2018, DevOps është tashmë një profesion? Ka të tillë. A ka në sallë inxhinierë DevOps, të cilët në përshkrimin e punës kanë shkruar «inxhinier DevOps»? A ka në sallë menaxherë DevOps? Asnjë. Arkitektë DevOps? Po ashtu. Paksa e paktë. A të vërtetë askush nuk ka shkruar se është inxhinier DevOps?
Pra, shumica prej jush mendojnë se kjo është një antipattern? Se një profesion i tillë nuk duhet të ekzistojë? Ne mund të mendojmë gjithçka që duam, por ndërkohë industria po ecën përpara nën tingujt e tubës DevOps.
Kush ka dëgjuar për temën e re, që quhet DevDevOps? Kjo është një metodologji e re që ndihmon në sigurimin e bashkëpunimit efektiv midis zhvilluesve dhe DevOps-ëve. Dhe nuk është kaq e re. Nëse gjykojmë sipas Twitter-it, 4 vjet më parë ka filluar të flitet për të. Dhe deri tani, interesi për të po rritet, domethënë ka një problem. Problemi duhet zgjidhur.
Ne jemi njerëz kreativë, nuk ngushtohemi aq lehtë. Themë: DevOps nuk është një fjalë mjaft e plotë, i mungojnë shumë elemente interesante. Dhe ne shkojmë në laboratorët tanë sekrete dhe fillojmë të prodhojmë mutacione të çuditshme: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logjika është e fortë, apo jo? Nëse sistemi ynë i dërgimit nuk funksionon, sistemet tona janë të paqëndrueshme dhe përdoruesit janë të pakënaqur, ne nuk arrijmë të nxjerrim softuerin në kohën e duhur, nuk arrijmë të përputhemi me buxhetin. Si do ta zgjidhim të gjithë këtë? Do të shpikim një fjalë të re! Ajo do të përfundojë me «Ops», dhe problemi është zgjidhur.
Kështu e quaj këtë qasje — «Ops, dhe problemi është zgjidhur».
Të gjitha këto bien në plan të dytë, nëse ne kujtojmë se përse e kemi shpikur këtë. E kemi shpikur të gjithë këtë DevOps, për ta bërë dërgimin e softuerit dhe punën tonë në këtë proces sa më të pa penguar, pa dhimbje, efikase, dhe më e rëndësishmja, kënaqëse.
DevOps ka lindur nga dhimbja. Dhe na ka ardhur në majë të hundës të vuajmë. Dhe për të ndodhur kjo, ne mbështetemi në praktika të përjetshme: bashkëpunim efektiv, praktika fluksi, dhe më e rëndësishmja, mendimi sistemor, sepse pa të asnjë DevOps nuk funksionon.
Çfarë është një sistem?
Dhe nëse po flasim për mendimin sistemor, le të kujtojmë se çfarë është një sistem.
Nëse je një haker-revolucionar, për ty sistemi është një e keqe e qartë. Është një re që mbulon ty dhe të detyron të bësh atë që nuk dëshiron.
Nga perspektiva e mendimit sistemor, sistemi është një njësi e caktuar që përbëhet nga pjesë. Në këtë kuptim, secili prej nesh është një sistem. Organizatave në të cilat punojmë, janë sisteme. Dhe ajo që ne po ndërtojmë, është e quajtur një sistem.
Të gjitha këto janë pjesë e një sistemi të madh socio-teknologjik. Dhe vetëm nëse ne e kuptojmë se si funksionon ky sistem socio-teknologjik së bashku, vetëm atëherë do të mund të optimizojmë vërtet diçka në këtë qëllim.
Nga perspektiva e mendimit sistemor, sistemi ka disa pronësi interesante. Së pari, ai përbëhet nga pjesë, çka do të thotë se sjellja e tij varet nga sjellja e pjesëve. Megjithatë, të gjitha pjesët e tij gjithashtu janë të varura nga njëra-tjetra. Kështu, sa më shumë pjesë të ketë një sistem, aq më e vështirë është të kuptosh ose parashikosh sjelljen e tij.
Nga perspektiva e sjelljes, këtu ka një fakt të tjerë interesant. Një sistem mund të bëjë diçka që asnjë nga pjesët e tij të ndara nuk mund ta bëjë.
Siç tha doktori Russell Ackoff (një nga themeluesit e mendimit sistemor), ky është një provim mjaft i lehtë përmes një eksperimentimi mendor. Për shembull, kush në sallë di të shkruajë kod? Shumë duar, dhe kjo është normale, sepse është një nga kërkesat kryesore të profesionit tonë. Ju dini të shkruani, por duart tuaja ndarë nga ju mund të shkruajnë kod? Ka disa që do të thonë: «Duart e mia nuk shkruajnë kod, mendja ime shkruan kod». Dhe a mund mendja të shkruajë kod ndarë nga ju? Shqetësisht, ndoshta jo.
Truri – një makinë e mrekullueshme, ne nuk dimë as 10% se si funksionon aty, por ai nuk mund të funksionojë veçmas nga sistemi që është organizmi ynë. Dhe kjo është lehtësisht e provueshme: hapni kutinë tuaj të kafkës, nxirrni trurin nga aty, vendoseni përpara kompjuterit dhe lejoni të provojë të shkruajë diçka të thjeshtë. "Hello, world" në Python, për shembull.
Nëse një sistem mund të bëjë diçka që asnjë nga pjesët e tij nuk mund ta bëjë veçmas, atëherë kjo do të thotë se sjellja e tij nuk përcaktohet nga sjellja e pjesëve të tij. Por çfarë e përcakton atë? Ajo përcaktohet nga ndërveprimi midis këtyre pjesëve. Dhe për rrjedhojë, sa më shumë pjesë, aq më të komplikuara janë ndërveprimet, aq më e vështirë është të kuptosh dhe parashikosh sjelljen e sistemit. Dhe kjo e bën një sistem të tillë kaotic, sepse çdo ndryshim i vogël, i padukshëm për syrin në ndonjë nga pjesët e sistemit, mund të çojë në rezultate plotësisht të paparashikueshme.
Kjo ndjeshmëri ndaj kushteve fillestare u zbulua dhe u studiua për herë të parë nga meteorologu amerikan Ed Lorenz. Më pas ajo mori emrin "efekti flutur" dhe çoi në zhvillimin e një lëvizjeje shkencore të njohur si "teoria e kaosit". Kjo teori u bë një nga zhvendosjet kryesore të paradigmatike në shkencë në shekullin e 20-të.
Teoria e kaosit
Njerëzit që merren me studimin e kaosit e quajnë veten kaosologë.
Në fakt, arsyeja e këtij raporti është se, duke punuar me sisteme të shpërndara komplekse dhe organizata të mëdha ndërkombëtare, në një moment të caktuar kuptova se ky është ai që ndjej për veten time. Unë – jam kaosolog. Kjo është një mënyrë e zgjuar për të thënë: "Nuk e kuptoj se çfarë po ndodh këtu dhe nuk e di çfarë të bëj me këtë."
Mendoj se shumë nga ju gjithashtu ndiheni shpesh kështu, kështu që ju gjithashtu jeni kaosologë. Ju ftoj në guildën e kaosologëve. Sistemet që ne, kolegët e dashur kaosologë, do të studiojmë quhen "sisteme adaptuese komplekse".
Çfarë është adaptiviteti? Adaptiviteti do të thotë që sjellja individuale dhe kolektive e pjesëve në një sistem të tillë adaptues ndryshon dhe vetë-organizohet, duke u përgjigjur ndaj ngjarjeve ose zinxhirit të mikro-ngjarjeve në sistem. Kështu, sistemi adaptohet ndaj ndryshimeve përmes vetë-organizimit. Dhe kjo aftësi e vetë-organizimit bazohet në bashkëpunimin e plotë, të decentralizuar të agjentëve autonomë të lirë.
Një tjetër cilësi interesante e këtyre sistemeve është se ato janë të shkallëzueshme lirisht. Çfarë duhet të na interesojë ne, si inxhinierë kaosologë? Ndërveprimi.
Ka edhe dy përfundime interesante.
Së pari, ne kuptojmë se një sistem kompleks nuk mund të thjeshtohet përmes thjeshtimit të pjesëve të tij. Së dyti, mënyra e vetme për të thjeshtuar një sistem kompleks është përmes thjeshtimit të ndërveprimeve midis pjesëve të tij.
Si ndërveprojmë? Ne të gjithë jemi pjesë e një sistemi të madh informativ që quhet shoqëria njerzore. Ne ndërveprojmë përmes një gjuhe të përbashkët, nëse e kemi atë, nëse e gjejmë.
Por gjuha vetë është një sistem adaptiv kompleks. Prandaj, për të ndërvepruar më efektivisht dhe më thjesht, na nevojitet krijimi i disa protokolleve. Kjo do të thotë një rend të simboleve dhe veprimeve që do të bëjnë shkëmbimin e informacionit midis nesh më të thjeshtë, më të parashikueshëm, më kuptimplotë.
Dua të them se tendencat përkompleksim, adaptivitet, decentralizim, kaoticitet shihen në të gjithë. Si në sistemet që ne ndërtojmë, ashtu edhe në sistemet të cilëve ne i përkasim.
Dhe, për të mos qenë folës gojëmadh, le të shikojmë se si ndryshojnë ato sisteme që ne krijojmë.
E prisnit këtë fjalë, e kuptoj. Jemi në konferencën DevOps, sot kjo fjalë do të shqiptohet diku rreth njëqind mijë herë dhe më pas do të na shfaqet natën.
Mikroservisët janë arkitektura e parë e softuerit që ka lindur si një reagim ndaj praktikave DevOps, e cila ka për qëllim ta bëjë sistemin tonë më fleksibël, më të shkallëzueshëm dhe të sigurojë dorëzim të vazhdueshëm. Si e arrin këtë? Duke reduktuar vëllimin e shërbimeve, duke ngushtuar kufijtë e problemeve që këto shërbime përballojnë dhe duke reduktuar kohën e dorëzimit. Kjo do të thotë se ne e zvogëlojmë e thjeshtojmë pjesët e sistemit, duke rritur numrin e tyre; për pasojë, natyrshëm rritet kompleksiteti i ndërveprimeve midis këtyre pjesëve, duke shkaktuar probleme të reja që duhet të zgjidhim.
Mikroservisët nuk janë fundi, ata janë, në thelb, një ditë të kaluar, sepse po vjen Serverless. Të gjitha serverat janë shkrirë, nuk ka servera, nuk ka sisteme operative, vetëm kod të pastër ekzekutiv. Konfigurimet veçmas, gjendjet veçmas, gjithçka menaxhohet përmes ngjarjeve. Bukuri, pastërti, qetësi, nuk ka ngjarje, asgjë nuk ndodh, është gjithçka në rend.
Ku është kompleksiteti? Kompleksiteti, është e qartë, është në ndërveprime. Sa mund të bëjë një funksion vetë? Si ndërvepron me funksione të tjera? Radhët e mesazheve, bazat e të dhënave, balancuesit. Si mund të rifillosh ndonjë ngjarje kur ndodh një dështim? Një mori pyetjesh dhe pak përgjigjesh.
Mikroservisët dhe Serverless janë gjithçka që ne, hipsterët e teknologjisë, i quajmë Cloud Native. Kjo është e gjithë për cloud. Por cloud, në thelb, është gjithashtu i kufizuar në shkallëzim. Ne jemi mësuar ta shohim si një sistem të shpërndarë. Në të vërtetë, ku jetojnë serverat e ofruesve të cloud? Në qendrat e të dhënave. Kështu që kemi një model të caktuar, shumë të kufizuar, të shpërndarë.
Sot ne e dimë se interneti i gjërave nuk është më thjesht një frazë e madhe; sipas parashikimeve modeste, në pesë deri në dhjetë vitet e ardhshme do të kemi miliarda pajisje të lidhura me internetin. Një sasi e madhe e të dhënave të dobishme dhe të padobishme që do të derdhen në cloud dhe do të nxirren nga cloud.
Cloud nuk do të përballojë, prandaj ne flasim gjithnjë e më shumë për atë që quhet 'kalkulim periferik'. Ose më pëlqen një përcaktim i mrekullueshëm 'fog computing'. Ka një mistikë romantike dhe misteri.
Të kalkulimet në mjegull. Bëhet fjalë se cloud janë grumbuj të centralizuar të ujit, avujve, akullit, gurëve. Dhe mjegulla është pika e ujit që shpërndahet përreth nesh në atmosferë.
Në paradigmen e mjegullës, pjesa më e madhe e punës kryhet nga këto pika në mënyrë të autonomishme ose në bashkëpunim me pika të tjera. Ato konsumojnë cloud vetëm kur është vërtet urgjente.
Pra, përsëri decentralizimi, autonomi, dhe sigurisht, shumë prej jush e kuptoni tashmë se ku po shkon e gjithë kjo, sepse nuk mund të flasim për decentralizimin dhe të mos përmendim blockchain.
Ka ata që besojnë, ata janë ata që kanë investuar në kriptovaluta. Ka ata që besojnë, por kanë frikë, si unë, për shembull. Dhe ka ata që nuk besojnë. Mund të ketë shumë qasje. Ka teknologji, një gjë të re të paqartë, ka probleme. Siç është çdo teknologji e re, ajo ngre më shumë pyetje sesa përgjigje.
Hype rreth blockchain është i qartë. Edhe nëse e lëmë mënjanë zhurmën e floririt, vetë teknologjia ofron premtime të shkëlqyera për një të ardhme më të ndritshme: më shumë liri, më shumë autonomi, besim global të shpërndarë. Çfarë është për të mos dashur?
Si rezultat, gjithnjë e më shumë inxhinierë në mbarë botën po zhvillojnë aplikacione të decentralizuara. Dhe kjo është një forcë që nuk mund të injorohet duke thënë thjesht: 'Ah, blockchain është një bazë të shpërndarë e keqimplementuar'. Ose siç pëlqejnë të thonë skeptikët: 'Nuk ka aplikacione reale për blockchain'. Nëse mendoni mirë, 150 vjet më parë ata thonin të njëjtën gjë për energjinë elektrike. Dhe madje në disa aspekte kishin të drejtë, sepse ajo që energjia elektrike mund të mundësojë sot, në shekullin e 19-të ishte plotësisht e pamundur.
Me rastin, kush e di se çfarë logoje është në ekran? Kjo është Hyperledger. Ky është një projekt që po zhvillohet nën egidën e The Linux Foundation, përfshin një grup teknologjish blockchain. Kjo është vërtet forca e komunitetit tonë të kodit të hapur.
Inxhinieria e kaosit
Pra, sistemi që ne po zhvillojmë bëhet gjithnjë e më i komplikuar, gjithnjë e më kaotik, gjithnjë e më adaptiv. Netflix ka qenë pionier në sistemet mikroservis. Ata ishin disa nga të parët që e kuptuan këtë, ata zhvilluan një grup mjetesh, të cilin e quajtën Simian Army, më i njohuri prej të cilëve ishte . Ai përcaktoi atë që është njohur si .
Apropos, në procesin e punës mbi raportin, ne madje e përktheu këtë tekst në gjuhën ruse, kështu që vizitoni , lexoni, komentoni, kritikoni.
Për të qenë i shkurtër, parimet e inxhinierisë së kaosit flasin për këtë. Sistemet e ndara komplekse në thelb janë të paparashikueshme dhe në thelb kanë gabime. Gabimet janë të pashmangshme, çka do të thotë se duhet t'i pranojmë këto gabime dhe të punojmë me këto sisteme në një mënyrë krejtësisht të ndryshme.
Ne duhet të përpiqemi të futim këto gabime në sistemet tona të prodhimit, për të testuar këto sisteme për këtë aftësi adaptuese, për këtë aftësi vetë-organizimi, për mbijetesë.
Dhe kjo ndryshon gjithçka. Jo vetëm se si e nisnim sistemin në prodhim, por edhe se si i zhvillojmë, si i testojmë. Nuk ka një proces stabilizimi, ngrirjeje të kodit, përkundrazi, ka një proces të vazhdueshëm të destabilizimit. Ne përpiqemi ta vrasim sistemin dhe të shohim se si ai vazhdon të mbijojë.
Protokolet e Integrimit të Sistemit të Distribuar
Prandaj, kjo kërkon që sistemet tona të ndodhin ndryshime gjithashtu. Që të bëhen më të qëndrueshme, u duhen protokolle të reja bashkëpunimi mes pjesëve të tyre. Që këto pjesë të mund të bien dakord dhe të arrijnë një vetë-organizim. Dhe gjithashtu shfaqen mjete të reja, protokolle të reja, që unë i quaj "protokolet e bashkëpunimit të sistemeve të distribuar".
Për çfarë po flas? Së pari, projekti . Një përpjekje për të krijuar një protokoll të përbashkët të përcjelljes së distribuar, i cili është një mjet tërësisht i nevojshëm për debugimin e sistemeve komplekse të ndara.
Pastaj — . Ne themi se nuk mund të parashikojmë se çfarë do të ndodhë me sistemin, që do të thotë se duhet ta rrisim observabilitetin e tij. Opentracing i përket grupit të mjeteve që na japin observabilitetin e sistemeve tona. Por na nevojitet observabiliteti për të përcaktuar nëse sistemi sillet siç e presim apo jo. Si mund ta përcaktojmë sjelljen e pritur? Duke caktuar ndonjë politikë, një set rregullash. Projekti Open Policy Agent merret me përcaktimin e këtij seti rregullash në një gamë të gjerë: nga qasja deri te vendosja e burimeve.
Siç e thashë, sistemet tona janë gjithnjë e më shumë të menaxhuara nga ngjarjet. Serverless — është një shembull i shkëlqyer i sistemeve të menaxhuara nga ngjarjet. Që të mund të transmetojmë ngjarje mes sistemeve dhe t'i ndjekim ato, na nevojitet një gjuhë e përbashkët, një protokoll i përbashkët se si flasim për ngjarjet, si i kalojmë ato njëri-tjetrit. Këtë e bën projekti i quajtur .
Një fluks i vazhdueshëm ndryshimesh që mbulon sistemet tona, duke i destabilizuar vazhdimisht, është një fluks i vazhdueshëm i artefakteve të softuerit. Që të mund të mbajmë këtë fluks të vazhdueshëm të ndryshimeve, na nevojitet një protokoll i përbashkët, me ndihmën e të cilit mund të flasim për atë çfarë është një artifact softueri, si është verifikuar, çfarë verifikimi ka kaluar. Këtë e bën projekti i quajtur . Pra, një protokoll i përbashkët për metadatat e artefakteve të softuerit.
Dhe, në fund, nëse duam që sistemet tona të jenë plotësisht autonome, adaptuese, të vetë-organizohen, duhet t'u japim atyre të drejtën e vetë-identifikimit. Projekti i quajtur pikerisht këtë bënë. Ky është gjithashtu një projekt nën egidën e Cloud Native Computing Foundation.
Të gjitha këto projekte janë të reja, të gjitha kanë nevojë për dashurinë tonë, për verifikimin tonë. Të gjitha janë kod i hapur, testimi ynë, implementimi ynë. Ato na tregojnë në cilin drejtim po ecën teknologjia.
Por DevOps nuk ka qenë kurrë fillimisht për teknologjinë, gjithmonë ka qenë për bashkëpunimin mes njerëzve. Dhe kështu, nëse duam që sistemet që po zhvillojmë të ndryshojnë, atëherë ne duhet të ndryshojmë vetë. Në të vërtetë, ne tashmë po ndryshojmë, nuk kemi shumë zgjedhje.
Ka një libër të shkëlqyer nga shkrimtarja britanike Rachael Botsman, në të cilin ajo shkruan për evolucionin e besimit gjatë historisë njerëzore. Ajo thotë se në fillim, në shoqëritë primitive, besimi ishte lokal, domethënë ne besonim vetëm atyre që i njihnim personalisht.
Më pas kishte një periudhë të gjatë — një kohë të errët, kur besimi ishte centralizuar, kur filluam të besojmë njerëzve që nuk i njihnim në bazë të asaj se ishim pjesë e një institucioni shoqëror apo shtetëror.
Dhe ja, çfarë shohim në botën tonë moderne: besimi po bëhet gjithnjë e më shumë i shpërndarë dhe i decentralizuar, dhe bazohet në lirinë e flukseve të informacionit, në disponueshmërinë e informacionit.
Nëse e mendojmë mirë, kjo disponibiliteti që e bën atë besim të mundshëm e realizojmë ne. Kjo do të thotë se mënyra se si bashkëpunojmë dhe si veprojmë duhet të ndryshojë, sepse organizatat IT të vjetra, të centralizuara dhe hierarkike, po humbasin rëndësinë e tyre. Ato po shuhen.
Bazat e organizatave DevOps
Organizata ideale DevOps e së ardhmes është një sistem decentralizuar dhe adaptiv, përbërë nga ekipe autonome, secila prej të cilave përbëhet nga individë autonomë. Këto ekipe janë të shpërndara në të gjithë botën dhe bashkëpunojnë në mënyrë efektive me ndihmën e komunikimit asinkron, përmes protokolleve të informacionit me transparencë të lartë. Mjaft e bukur, apo jo? Një të ardhme shumë e bukur.
Sigurisht, kjo është e pamundur pa ndryshime kulturore. Ne duhet të kemi liderë transformues, përgjegjësi personale, motivim të brendshëm.
Kjo është baza e organizatave DevOps: transparenca e informacionit, komunikimet asinkrone, lideri transformues, decentralizimi.
Shkëputja
Sistemet që ne jemi pjesë e tyre, si edhe ato që ndërtojmë, po bëhen gjithnjë e më kaotike, dhe ne, njerëzit, na vështirëson të pranojmë këtë mendim, është e vështirë të heqim dorë nga iluzioni i kontrollit. Ne përpiqemi të vazhdojmë t'i kontrollojmë ato, dhe kjo shpeshherë na çon në shterim. Po e them këtë nga përvoja ime, edhe unë kam përjetuar, kam qenë gjithashtu i paaftë ndaj dështimeve të paparashikuara në prodhim.
Shkëputja ndodh kur ne mundohemi të kontrollojmë atë që në thelb nuk mund të kontrollohet. Kur ne shterim, gjithçka humbet kuptimin, sepse humbasim dëshirën për të bërë diçka të re, ne marrim një pozicion mbrojtës dhe fillojmë të mbrojmë atë që kemi.
Profili i inxhinierisë, siç më pëlqen ta kujtoj shpesh, është para së gjithash një profesion krijues. Nëse humbasim dëshirën për të krijuar diçka, atëherë shndërrohemi në hi, shndërrohemi në plehra. Njerëzit shterin, organizatat shterin.
Sipas mendimit tim, vetëm pranimi i fuqisë krijuese të kaosit, vetëm ndërtimi i bashkëpunimit sipas parimeve të tij — kjo do të na ndihmojë të mos humbasim atë që është e mirë në profesionin tonë.
Këtë ju uroj: të doni punën tuaj, të doni atë që bëjmë. Ky botë ushqehet me informacionin, na është dhënë nderi ta ushqejmë atë. Prandaj, le të studiojmë kaosin, le të jemi kaosologë, le të sjellim vlerë, të krijojmë diçka të re, dhe problemet, siç e dimë, janë të pashmangshme, dhe kur ato krijohen, ne thjesht do të themi 'Ops!', dhe problemi do të zgjidhet.
Çfarë tjetër për Chaos Monkey?
Në të vërtetë, të gjitha këto mjete janë shumë të reja. Edhe Netflix ndërtuan mjete për veten e tyre. Ndërtoni mjete për veten tuaj. Lexoni parimet e inxhinierisë së kaosit dhe përputhuni me ato parime, e jo të kërkoni mjete të tjera që dikush tjetër ka ndërtuar.
Provoni të kuptoni si dështojnë sistemet tuaja dhe filloni t'i bëni ato të dështojnë dhe shikoni si i përballojnë goditjet. Kjo është në radhë të parë. Dhe mjete mund të kërkoni. Ka projekte të ndryshme.
Nuk e kuptova plotësisht momentin kur ju thatë se sistemi nuk mund të thjeshtohet duke thjeshtuar komponentët e tij, dhe menjëherë kaluat tek mikroshërbimet, të cilat për nga ana e tyre thjeshtojnë sistemin duke thjeshtuar vetë komponentët dhe duke e komplikuar ndërlidhjen. Këto në thelb janë dy pjesë që përmbysin njëra-tjetrën.
Plotësisht e saktë, mikroshërbimet janë një temë shumë kontradiktore në përgjithësi. Në të vërtetë, thjeshtimi i pjesëve rrit fleksibilitetin. Çfarë na japin mikroshërbimet? Na japin fleksibilitet dhe shpejtësi, por patjetër nuk na japin thjeshtësi. Ato rrisin kompleksitetin.
Pra, në filozofinë DevOps, mikroshërbimet nuk janë aq të mira apo jo?
Çdo mirë ka anën e saj të errët. Ka një mirë: kjo rrit fleksibilitetin, na jep mundësinë për të bërë ndryshime më shpejt, por rrit kompleksitetin dhe, për pasojë, brishtësinë e gjithë sistemit.
Megjithatë, ku është akcenti më shumë: tek thjeshtimi i ndërlidhjes apo tek thjeshtimi i pjesëve?
Akcenti, padyshim, është tek thjeshtimi i ndërlidhjeve, sepse nëse e shohim nga pikëpamja se si punojmë, së pari duhet të fokusohemi në thjeshtimin e ndërlidhjeve dhe jo në thjeshtimin e punës së secilit prej nesh veçmas. Sepse thjeshtimi i punës — kjo është shndërrimi në robota. Kjo funksionon mjaft mirë në McDonald's, kur je i urdhëruar: këtu vë hamburgerin, këtu i hedh salcën. Kjo në punën tonë krijuese nuk funksionon fare.
A është e vërtetë se gjithçka që keni treguar jeton në një botë pa konkurrencë, dhe kaosi aty është kaq i mirë, dhe nuk ka kontradikta brenda këtij kaosi, askush nuk dëshiron të hajë, të vrasë? Si duhet të jetojnë konkurrenca dhe DevOps?
Epo, varet se për cilin konkurrencë po flasim. A është kjo konkurrenca në vendin e punës apo konkurrenca midis kompanive?
Konkurrenca e shërbimeve, të cilat ekzistojnë, sepse shërbimet nuk janë thjesht disa kompani. Ne po krijojmë një tip të ri të ambientit informacionit, dhe çdo ambient nuk mund të jetojë pa konkurrencë. Konkurenca është gjithandej.
Të njëjtët Netflix, marrim ata si model roli. Pse e shpikën këtë? Sepse kishin nevojë të ishin konkurrues. Kjo fleksibilitet dhe shpejtësi lëvizjeje, është kërkesa e vërtetë konkurruese, ajo sjell kaos në sistemet tona. Pra, kaosi nuk është diçka që e bëjmë me vetëdije, sepse e duam, është ajo që ndodh për shkak se kjo është ajo që kërkon bota. Na duhet të adaptohemi. Dhe kaosi është rezultat i konkurrencës.
Do të thotë, kaosi është mungesë e qëllimeve, apo jo? Apo ato qëllime që nuk duam t'i shohim? Jemi në një kasolle dhe nuk e kuptojmë qëllimet e të tjerëve. Në të vërtetë, konkurrenca ekziston falë qëllimeve tona të qarta, dhe ne e dimë se ku do të shkojmë në çdo moment të ardhshëm. Kjo, në mendimin tim, është themeli i DevOps.
Një tjetër pikëpamje mbi çështjen. Mendoj se qëllimi ynë është i njëjtë: të mbijetojmë dhe ta bëjmë këtë me
sa më shumë kënaqësi. Dhe qëllimi konkurrues i çdo organizate është po i tillë. Mbijetesa shpesh ndodh në luftën konkurruese, këtu s'ka çfarë të bëjmë.
Ky vit konferenca do të mbahet më 7 dhjetor në "Tehnopolis". Deri më 11 nëntor pranojmë aplikime për referate. nëse dëshironi të flisni.
Regjistrimi për pjesëmarrësit është i hapur, bileta kushton 7000 rubla. Bashkohuni!
Burimi: habr.com
