Krijuesi dhe drejtor i «Otomato Software», një nga iniciatorët dhe instruktorët e certifikimit të parë DevOps në Izrael, Anton Vajs tregoi në vitin e kaluar për teorinë e kaosit dhe parimet kryesore të inxhinierisë së kaosit, si dhe shpjegoi se si është organizata ideale DevOps e së ardhmes.
Ne përgatitëm versionin tekstual të referatit.
Mirëmëngjesi!
DevOpsDays në Moskë për vitin e dytë radhazi, unë për herë të dytë në këtë skenë, shumica nga ju 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, po shumizohet, dhe më e rëndësishmja, do të thotë se ka ardhur koha të flasim për atë se çfarë nënkupton DevOps në vitin 2018.
Ngrini duar ata që mendojnë se në vitin 2018 DevOps është tashmë një profesion? Ka disa. Ka ndonjë DevOps-inxhinier në sallë, që në përshkrimin e punës shkruan «DevOps-inxhinier»? Ka ndonjë DevOps-menaxher? Asnjë. DevOps-arkitektë? Po ashtu, asnjë. Pak shumë. A është vërtet askush që nuk e ka shkruar se është DevOps-inxhinier?
Dhe kështu, shumica prej jush mendon se është një antipattern? Se nuk duhet të ekzistojë një profesion i tillë? Ne mund të mendojmë gjithçka, por derisa të mendojmë, industria vazhdon të lëvizë 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, e cila siguron bashkëpunim efektiv midis zhvilluesve dhe devops-ëve. E megjithatë, nuk është aq e re. Nëse dëshmojmë për Twitter-in, katër vjet më parë filluan të flisnin për këtë. Dhe deri tani, interesi për këtë po rritet e po rritet, domethënë problemi ekziston. Duhet zgjidhur problemi.
Ne jemi krijues, nuk e ndalim lehtë veten. Ne themi: DevOps nuk është një fjalë mjaft gjithëpërfshirëse, i mungojnë shumë elemente interesante. Dhe ne shkojmë në laboratorët tanë sekretë dhe fillojmë të krijojmë mutacione kurioze: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logjika është e fortë, apo jo? Ne kemi një sistem shpërndarjeje jo funksional, kemi sisteme të paqëndrueshme dhe përdorues të pakënaqur, nuk arrijmë të nxjerrim software-n në kohë, nuk përputhemi me buxhetin. Si do ta zgjidhim të gjithë këtë? Ne do të shpikim një fjalë të re! Ajo do të përfundojë me «Ops», dhe problemi zgjidhet.
Kështu e quaj këtë qasje — «Ops, dhe problemi zgjidhet».
Kjo është një gjë që largohet nga sfondi, nëse ne i kujtojmë vetes pse e kemi krijuar gjithë këtë. E kemi shpikur këtë DevOps për të bërë dorëzimin e softuerit dhe punën tonë në këtë proces sa më të lehtë, pa dhembje, efikase dhe, më e rëndësishmja, të këndshme.
DevOps ka dalë nga dhimbja. Dhe na ka lodhur të vuajmë. Dhe për t'u siguruar që kjo ndodh, ne bazojmë praktikat tona në praktikat e përjetshme: bashkëpunim efektiv, praktika të rrjedhës dhe më e rëndësishmja, mendimi sistemik, sepse pa të, asnjë DevOps nuk funksionon.
Çfarë është një sistem?
Dhe nëse po flasim për mendimin sistemik, le të kujtojmë se çfarë është një sistem.
Nëse je një revolucionar-haker, atëherë për ty sistemi është një e keqe e qartë. Është një re që mbulon dhe të detyron të bësh atë që nuk dëshiron të bësh.
Nga këndvështrimi i mendimit sistemik, sistemi është një e tërë që përbëhet nga pjesët. Në këtë kuptim, secili prej nesh është një sistem. Organizatat ku punojmë janë sisteme. Dhe ajo që ne po ndërtojmë së bashku quhet sistem.
E gjithë kjo është pjesë e një sistemi socioteknologjik të madh. Dhe vetëm nëse e kuptojmë se si ky sistem socioteknologjik punon së bashku, mund të optimizojmë diçka në këtë drejtim.
Nga këndvështrimi i mendimit sistemik, sistemi ka disa cilësi interesante. Së pari, ai përbëhet nga pjesë, do të thotë që sjellja e tij varet nga sjellja e pjesëve. Të gjitha pjesët e tij janë gjithashtu të ndërlidhura. Pra, sa më shumë pjesë të ketë një sistem, aq më e vështirë është të kuptohet ose parashikohet sjellja e tij.
Nga këndvështrimi i sjelljes, ka një fakt tjetër interesant. Një sistem mund të bëjë diçka që asnjë nga pjesët e tij të veçanta nuk mund ta bëjë.
Siç tha doktor Russell Ackoff (një nga themeluesit e mendimit sistemik), kjo është mjaft e lehtë të provohet përmes një eksperimentin mendor. Për shembull, kush në sallë di të shkruajë kod? Shumë duar, dhe kjo është e natyrshme, sepse është një nga kërkesat kryesore për profesionin tonë. Ju dini të shkruani, por duar tua ndaras mund të shkruajnë kod? Ka të tillë që do të thonë: «Nuk janë duar që shkruajnë kod, është truri im që shkruan kod». Dhe truri mund të shkruajë kod ndaras nga ju? Së paku, ndoshta jo.
Truri është një makinë e jashtëzakonshme, ne as 10% nuk e dimë se si funksionon, por nuk mund të funksionojë tërësisht ndaras nga sistemi që është organizmi ynë. Dhe kjo është lehtë e provueshme: hapni kutinë e kafkës, nxirrni trurin jashtë, vendoseni përpara kompjuterit, le të provojë dikush të shkruajë diçka të thjeshtë. „Hello, world” në Python, për shembull.
Nëse sistemi mund të bëjë diçka që asnjëra nga pjesët e tij veçmas nuk mund ta bëjë, atëherë kjo do të thotë se sjellja e tij nuk përcaktohet nga sjellja e pjesëve të tij. Por atëherë çfarë e përcakton? Ajo përcaktohet nga ndërveprimi midis këtyre pjesëve. Dhe për pasojë, sa më shumë pjesë ka, aq më të komplikuara janë ndërveprimet, aq më e vështirë është të kuptojmë dhe parashikojmë sjelljen e sistemit. Kjo e bën një sistem të tillë kaotik, sepse çdo ndryshim edhe më të vogël, që nuk është i dukshëm për syrin, në ndonjërën nga pjesët e sistemit mund të sjellë rezultate krejtësisht të paparashikueshme.
Kjo ndjeshmëri ndaj kushteve fillestare u zbulua dhe u studua për herë të parë nga meteorologu amerikan Ed Lorenz. Më vonë, ajo mori emrin „efekti flutur” dhe çoi në zhvillimin e një lëvizjeje të tillë të mendimit shkencor, e cila quhet „teoria e kaosit”. Kjo teori u bë një nga ndryshimet kryesore të paradigmatike në shkencë të shekullit të 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ë ndara komplekse dhe organizata të mëdha ndërkombëtare, në një moment kuptova se kjo është ajo që ndjej për veten time. Unë jam kaosolog. Kjo, në thelb, është një mënyrë e zgjuar për të thënë: „Nuk e kuptoj se çfarë ndodh këtu dhe nuk e di se çfarë të bëj me këtë.”
Mendoj se shumë prej jush ndihen kështu shpesh, kështu që ju gjithashtu jeni kaosologë. Ju ftoj në gildinë e kaosologëve. Sistemet që ne, të dashur kolegë kaosologë, do të studiojmë, quhen "sisteme komplekse adaptuese".
Çfarë është adaptiviteti? Adaptiviteti do të thotë se sjellja individuale dhe kolektive e pjesëve në një sistem adaptiv ndryshon dhe auto-organizohet, duke reaguar ndaj ngjarjeve ose zinxhirëve të mikro-ngjarjeve brenda sistemit. Kështu, sistemi përshtatet me ndryshimet përmes auto-organizimit. Dhe kjo aftësi për auto-organizim bazohet në bashkëpunimin vullnetar, plotësisht të decentralizuar të agjentëve autonomë të lirë.
Një tjetër pronë interesante e tillë e sistemeve është se ato janë të shkallëzuara lirisht. Çka duhet të na interesojë si inxhinierë të kaosit. Pra, nëse thamë se sjellja e një sistemi të ndërlikuar përcaktohet nga ndërveprimi i pjesëve të tij, çfarë duhet të na interesojë? Ndërveprimi.
Ka dy përfundime të tjera interesante.
Së pari, ne kuptojmë se nuk është e mundur të thjeshtohet një sistem të ndërlikuar duke e thjeshtuar pjesët e tij. Së dyti, mënyra e vetme për të thjeshtuar një sistem të ndërlikuar ë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 informacioni, i cili quhet shoqëria njerëzore. Ne ndërveprojmë përmes një gjuhe të përbashkët, nëse e kemi, nëse e gjejmë atë.
Por gjuha vetë është një sistem adaptiv i ndërlikuar. Në përputhje, për të ndërvepruar më efektivisht dhe thjesht, ne kemi nevojë për krijimin e disa protokollesh. Do të thotë një sërë simbolesh dhe veprimesh që do ta bëjnë shkëmbimin e informacionit midis nesh më të lehtë, më të parashikueshëm, më të kuptueshëm.
Dua të them se tendencat për ndërlikim, adaptivitet, decentralizim, për kaosit janë të pranishme në gjithçka. Si në sistemet që ne ndërtuam, ashtu edhe në ato që jemi pjesë.
Dhe për të mos u ndierë boshe, le të shikojmë se si ndryshojnë ato sisteme që ne i krijojmë.
E prisni këtë fjalë, e kuptoj. Ne jemi në një konferencë DevOps, sot kjo fjalë do të përmendet diku rreth njëqind mijë herë dhe pastaj do të na vijë në ëndrrat tona natën.
Mikroshërbimet janë arkitektura e parë softuerike që ka lindur si përgjigje ndaj praktikave DevOps, e cila ka për qëllim të bëjë sistemet tona më fleksibile, më të shkallëzueshme dhe të sigurojë dorëzimin e vazhdueshëm. Si e arrin këtë? Duke reduktuar vëllimin e shërbimeve, duke shkurtuar kufijtë e problemeve që këto shërbime trajtojnë dhe duke shkurtuar kohën e dorëzimit. Pra, ne e zvogëlojmë, e thjeshtojmë pjesët e sistemit, rrisim numrin e tyre dhe, për pasojë, rritet kompleksiteti i ndërveprimeve midis këtyre pjesëve, që do të thotë se lindin probleme të reja që duhet t'i zgjidhim.
Mikroshërbimet nuk janë fundi, ato në thelb janë dje, sepse po vjen Serverless. Të gjitha serverët janë djegur, nuk ka servera, nuk ka sisteme operative, vetëm kod ekzekutues i pastër. Konfigurimet veçmas, gjendjet veçmas, gjithçka menaxhohet nga ngjarjet. Bukuri, pastërti, qetësi, nuk ka ngjarje, nuk ndodh asgjë, çdo gjë është në rregull.
Ku është kompleksiteti? Komplexiteti, siç e dinë të gjithë, është në ndërveprime. Sa mund të bëjë një funksion vetë? Si ndërvepron me funksionet e tjera? Radhët e mesazheve, bazat e të dhënave, balancuesit. Si të rikrijojmë një ngjarje kur ndodhi një dështim? Një mori pyetjesh dhe pak përgjigjesh.
Mikroshërbimet dhe Serverless janë gjithçka që ne, hipsterët e kompjuterëve, i quajmë Cloud Native. Kjo është gjithçka për re. Por reja në thelb është gjithashtu e kufizuar në shkallëzim. Ne jemi mësuar ta mendojmë si një sistem të shpërndarë. Në të vërtetë, ku Jetojnë serverët e ofruesve të rejeve? Në qendrat e të dhënave. Kështu që kemi një model rrethor, shumë të kufizuar dhe të shpërndarë.
Sot ne kuptojmë që interneti i gjërave nuk është më vetëm fjalë të zëshme për faktin se, sipas parashikimeve modeste, në pesë deri në dhjetë vitet e ardhshme do të kemi miliarda pajisje të lidhura me internetin. Një numër të madh të dhënash të dobishme dhe të padobishme, të cilat do të derdhen në re dhe do të iven nga re.
Reja nuk do ta përballojë, prandaj ne flasim gjithnjë e më shumë për atë që quhet "përpunim periferik." Apo më pëlqen edhe një përkufizim tjetër "fog computing". Ai është i mbushur me misterin e romantizmit dhe enigmat.
Kompjuterët e mjegullës. Bëhet fjalë për atë se si re janë grumbuj të centralizuar të ujit, avullit, akullit, gurëve. Ndërsa mjegulla është pika uji që janë shpërndara rreth nesh në atmosferë.
Në paradigmen e mjegullës, shumica e punës kryhet nga këto pika në mënyrë krejtësisht autonome ose në bashkëpunim me pika të tjera. Ato i drejtohen re, vetëm kur vërtet kanë nevojë.
Pra, përsëri decentralizimi, autonomi, dhe sigurisht, shumë nga ju tashmë e kuptoni se në çfarë po shkon kjo, sepse nuk mund të flasësh për decentralizim dhe të mos përmendësh bllokadën.
Ka ata që besojnë, ata që kanë investuar në kriptovaluta. Ka ata që besojnë, por kanë frikë, si p.sh. unë. Dhe ka ata që nuk besojnë. Mund të merremi me të në mënyra të ndryshme. Ka teknologji, një gjë të re të paqartë, dhe ka probleme. Si çdo teknologji e re, ajo ngrit më shumë pyetje sesa jep përgjigje.
Haji rreth bllokadës është i kuptueshëm. Edhe nëse e lë jashtë ethet e arit, vetë teknologjia ofron premtime të shkëlqyera për një të ardhme të ndritshme: më shumë liri, më shumë autonomi, besim global të shpërndarë. Çfarë nuk do të dëshiroje?
Si pasojë, gjithnjë e më shumë inxhinierë në të gjithë botën fillojnë të zhvillojnë aplikacione të decentralizuara. Dhe kjo është një forcë nga e cila nuk mund të ikësh, thjesht duke thënë: "Eh, bllokada është thjesht një bazë të shpërndarë e zbatuar keq." Ose siç thonë skeptikët: "Nuk ka aplikacione reale për bllokadën." Nëse e mendoni, 150 vjet më parë ata thanë të njëjtën gjë për elektricitetin. Dhe madje në disa aspekte ishin të drejta, sepse ajo që elektriciteti bën sot të mundshme, në shekullin e 19-të ishte krejtësisht e pamundur.
A, kush e di se çfarë logoje është në ekran? Kjo është Hyperledger. Ky është një projekt që zhvillohet nën mbikëqyrjen e The Linux Foundation, ai përfshin një grup teknologjish bllokade. Kjo është në të vërtetë një forcë e komunitetit tonë të kodit të hapur.
Inxhinieria e kaosit
Pra, sistemi që ne po zhvillojmë bëhet gjithnjë e më kompleks, gjithnjë e më kaotik, gjithnjë e më adaptiv. Netflix – pionierët e sistemeve mikrosërvikuese. Ata ishin nga të parët që e kuptuan këtë, ata zhvilluan një grup mjetesh që e quajtën Simian Army, mjeti më i njohur prej të cilëve u bë . Ai përcaktoi atë që u bë e njohur si .
Në fakt, gjatë punës mbi raportin, ne madje përkthyem këtë tekst në gjuhën ruse, kështu që vizitoni , lexoni, komentoni, kritikoni.
Në përmbledhje, parimet e inxhinierisë së kaosit flasin për këtë. Sistemet e ndara të shpërndara janë natyrshëm të paparashikueshme dhe në thelb përmbajnë gabime. Gabimet janë të pashmangshme, që do të thotë se duhet t'i pranojmë këto gabime dhe të punojmë me këto sisteme në një mënyrë krejtësisht ndryshe.
Ne duhet të përpiqemi të krijojmë vetë këto gabime në sistemet tona të prodhimit, për t'i testuar ato për adaptivitetin e tyre, aftësinë për vetë-organizim, për mbijetesë.
Dhe kjo ndryshon gjithçka. Jo vetëm si i nxjerrim sistemet në prodhim, por edhe si i zhvillojmë, si i testojmë ato. Nuk ka asnjë proces stabilizimi, as kod të ngrirë, përkundrazi, ka një proces të vazhdueshëm të destabilizimit. Ne përpiqemi të vrasim sistemin dhe të shohim se si ai vazhdon të mbijetojë.
Protokollet e Integrimit të Sistemeve të Shpërndara
Prandaj, kjo kërkon nga sistemet tona që ato të ndryshohen gjithashtu. Që të bëhen më të qëndrueshme, ata kanë nevojë për disa protokolle të reja bashkëpunimi midis pjesëve të tyre. Që këto pjesë të mund të bien dakord dhe të arrijnë një vetë-organizim të caktuar. Dhe lindin lloje të ndryshme të reja të mjeteve, protokolleve të reja, të cilat unë i quaj protokolle të bashkëpunimit të sistemeve të shpërndara.
Çfarë po flas? Së pari, projekti . Një përpjekje për të krijuar një protokoll të përbashkët për ndjekjen e shpërndarë, i cili është një mjet krejt i domosdoshëm për debimin e sistemeve të ndara të komplikuara.
Tjetër — . Ne themi se nuk mund të parashikojmë se çfarë do të ndodhë me sistemin, prandaj është e nevojshme të rrisim observabilitetin e tij. Opentracing i përket grupit të mjeteve që ofrojnë observabilitetin e sistemeve tona. Por observabiliteti na nevojitet për të përcaktuar nëse sistemi sillet ashtu siç e presim ne apo jo. Si mund ta përcaktojmë sjelljen e pritur? Duke përcaktuar një politikë të tillë, një grup rregullash. Projekti Open Policy Agent merret me përcaktimin e këtij grupi rregullash në një gamë të gjerë: nga qasja deri te shpërndarja e burimeve.
Siç e thamë, sistemet tona janë gjithnjë e më të menaxhuara nga ngjarjet. Serverless është një shembull i shkëlqyer i sistemeve të menaxhuara nga ngjarjet. Që të mund të transferojmë ngjarje midis sistemeve dhe t'i ndjekim ato, na nevojitet një gjuhë e përbashkët, një protokoll i përbashkët për atë se si flasim për ngjarjet, si i komunikojmë ato midis nesh. Këtu merret me këtë projekti i quajtur .
Një rrjedhë e vazhdueshme ndryshimesh, e cila përshkon sistemet tona duke i destabilizuar vazhdimisht, është një rrjedhë e vazhdueshme e artefakteve software. Që të mund të mbajmë këtë rrjedhë të vazhdueshme ndryshimesh, na nevojitet një protokoll i përbashkët, me anë të të cilit do të mund të flasim për atë se çfarë është një artefakt software, si është verifikuar, çfarë verifikimi ka kaluar. Këtu merret me këtë projekti i quajtur . Pra, një protokoll i përbashkët për metadata të artefakteve software.
Dhe, përfundimisht, nëse duam që sistemet tona të jenë plotësisht autonome, adaptuese, të organizohen vetë, ne duhet t'u japim atyre të drejtën për autoidentifikim. Projekti i quajtur pikërisht me këtë merret. Ky është gjithashtu një projekt nën ombrellën e Cloud Native Computing Foundation.
Të gjitha këto projekte janë të reja, të gjitha kanë nevojë për dashurinë tonë, provimin tonë. Të gjitha janë kod i hapur, testimi ynë, zbatimi ynë. Ato na tregojnë se në çfarë drejtimi po shkon teknologjia.
Por DevOps kurrë nuk ka qenë fillimisht për teknologjinë, gjithnjë ka qenë për bashkëpunimin mes njerëzve. Prandaj, nëse duam që sistemet që po zhvillojmë të ndryshojnë, atëherë ne duhet të ndryshojmë. Në të vërtetë, ne po ndryshojmë, nuk kemi zgjidhje të veçantë.
Ka një libër të mrekullueshëm nga shkrimtarja britanike Rachael Botsman, në të cilin ajo shkruan për evolucionin e besimit nëpër histori. Ajo thotë se fillimisht, në shoqëritë primitive, besimi ishte lokal, domethënë ne besonim vetëm te ata që i njehja personalisht.
Më pas kishte një periudhë të gjatë - një kohë të errët, kur besimi ishte centralizuar, kur filluam të besojmë te njerëz të cilët nuk i njihnim në bazë të përkatësisë sonë ndaj një institucioni shoqëror ose shtetëror.
Dhe ja çfarë shohim në botën tonë moderne: besimi po bëhet gjithnjë e më i shpërndarë dhe i decentralizuar, dhe mbështetet në lirinë e rrjedhave të informacionit, në aksesin e informacionit.
Nëse mendoni thellë, ky akses i njëjtë, i cili e bën të mundur këtë besim, ne e realizojmë vetë. Kjo do të thotë se mënyra se si bashkëpunojmë dhe se si e bëjmë këtë duhet të ndryshojë, sepse organizatat IT centralizuese dhe hierarkike të vjetra nuk funksionojnë më. Ato fillojnë të zhduken.
Baza e organizatave DevOps
Organizata ideale DevOps e së ardhmes është një sistem decentralizuar, adaptiv, i përbërë nga ekipe autonome, secila e përbërë nga individë autonomë. Këto ekipe janë të shpërndara në gjithë botën, ato bashkëpunojnë efektivisht me njëra-tjetrën përmes komunikimit asinkron, përmes protokolleve të informacionit shumë të qarta. Shumë bukur, apo jo? Një të ardhme shumë e bukur.
Sigurisht, kjo është e pamundur pa ndryshime kulturore. Duhet të kemi udhëheqje transformative, përgjegjësi personale, motivim të brendshëm.
Kjo është baza e organizatave DevOps: transparenca e informacionit, komunikimi asinkron, udhëheqja transformative, decentralizimi.
Shterimi
Sistemet e cilave jemi pjesë, dhe ato që ndërtuam, janë gjithnjë e më kaotike, dhe ne, njerëzit, e kemi të vështirë të përballojmë këtë mendim, është e vështirë të heqim dorë nga iluzioni i kontrollit. Përpiqemi të vazhdojmë t'i kontrollojmë ato, dhe kjo shpesh çon në shterim. Po e them këtë nga përvoja ime, gjithashtu kam pësuar, gjithashtu jam invalid i defekteve të papritura në prodhim.
Shterimi ndodh kur përpiqemi të kontrollojmë atë që në thelb nuk mund të kontrollohet. Kur ‘shterim’, gjithçka humbet kuptimin, sepse humbasim dëshirën për të bërë diçka të re, ne kalojmë në një pozita mbrojtëse dhe fillojmë të mbrojmë atë që kemi.
Profesioni i inxhinierisë, siç më pëlqen të kujtoj shpesh, është kryesisht një profesion krijues. Nëse humbasim dëshirën për të krijuar diçka, ne kthehemi në hir, kthehemi në hiri. Njerëzit shterin, organizatat shterin.
Mendoj se vetëm pranuar fuqinë krijuese të kaosit, vetëm ndërtimi i bashkëpunimit sipas parimeve të tij – është ajo që do të na ndihmojë të mos humbasim atë të mirë që kemi në profesionin tonë.
Kështu që ju uroj: të doni punën tuaj, të doni atë që bëjmë. Ky botë ushqehet me informacione, na u dha nderi ta ushqejmë atë. Pra, le të studiojmë kaosin, të bëhemi kaologë, të sjellim vlerë, të krijojmë diçka të re, ndërkohë që problemet, siç e kemi kuptuar, janë të pashmangshme dhe kur të shfaqen, ne do të themi thjesht "Ops!", dhe problemi do të zgjidhet.
Çfarë tjetër përveç 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 këto parime, dhe mos u përpiqni të kërkoni mjete të tjera që dikush tjetër i nd construit.
Provo të kuptosh se si sistemet tua thyejnë dhe fillo t'i thyesh dhe shiko se si duruan goditjet. Kjo është më e rëndësishmja. Mjetet mund të kërkohen. Ka projekte të ndryshme.
Nuk e kuptova plotësisht momentin kur po flisnit për atë që sistemi nuk mund të thjeshtohet duke e thjeshtuar komponentët e tij, dhe menjëherë kaluat në mikroshërbime, të cilat pikërisht thjeshtojnë sistemin duke e thjeshtuar vetë komponentët dhe duke e komplikuar ndërveprimin. Kjo në thelb janë dy pjesë që bien ndesh me njëra-tjetrën.
Plotësisht e saktë, mikroshërbimet janë një temë shumë e diskutueshme. Në të vërtetë, thjeshtimi i pjesëve rrit fleksibilitetin. Çfarë na japin mikroshërbimet? Na japin fleksibilitet dhe shpejtësi, por sigurisht që nuk na japin thjeshtësi. Rrisin kompleksitetin.
Pra, në filozofinë DevOps, mikroshërbimet nuk janë një bekim kaq të madh?
Çdo bekim ka anën e tij të errët. Ka një bekim: rrit fleksibilitetin, na jep mundësinë të bëjmë ndryshime më shpejt, por rrit kompleksitetin dhe, për pasojë, brishtësi të gjithë sistemit.
Megjithatë, çfarë është më e rëndësishme: thjeshtimi i ndërveprimit apo thjeshtimi i pjesëve?
Fokusimi është padyshim në thjeshtimin e interaksioneve, sepse nëse e shohim këtë nga këndvështrimi i mënyrës si ne punojmë, në radhë të parë duhet të përqendrohemi në thjeshtimin e interaksioneve, dhe jo në thjeshtimin e punës së secilit prej nesh veç e veç. Sepse thjeshtimi i punës do të thotë të kthehemi në robotë. Kjo funksionon mirë në McDonald's, kur të është caktuar: vendos hamburgerin këtu, derdh sosin mbi të këtu. Kjo nuk funksionon aspak në punën tonë kreative.
A është e vërtetë që gjithçka që treguat jeton në një botë pa konkurrencë, dhe kaosi atje është kaq i mirë, dhe nuk ka kundërshtime brenda këtij kaosi, askush nuk dëshiron të hajë ose të vrasë tjetrin? Si duhet të jetojnë konkurrenca dhe DevOps?
Kjo varet nga cili lloj konkurence po flasim. A është konkurenca në vendin e punës apo konkurrenca midis kompanive?
Mbi konkurrencën e shërbimeve që ekzistojnë, sepse shërbimet nuk janë disa kompani. Ne po krijojmë një tip të ri të ambientit informativ, dhe çdo ambient nuk mund të jetojë pa konkurrencë. Ka konkurrencë kudo.
Të njëjtët Netflix, i marrim ata si një model rol. Pse e shpiku kjo? Sepse ata kishin nevojë të ishin konkurrues. Kjo fleksibilitet dhe shpejtësi në veprim janë kërkesa të vërteta konkurruese, ato sjellin kaos në sistemet tona. Pra, kaosi nuk është diçka që e bëjmë me vetëdije, sepse e duam, është diçka që lind nga kërkesat e botës. Ne thjesht duam të përshtatemi. Dhe kaosi është nga ana tjetër, rezultati i konkurrencës.
Kjo do të thotë, a është kaosi mungesë qëllimesh ndoshta? Ose ato qëllime që nuk duam t'i shohim? Ne jemi në një kuti dhe nuk e kuptojmë qëllimet e të tjerëve. Konkurrenca, në të vërtetë, është për shkak se kemi qëllime të qarta dhe e dimë se ku do të shkojmë në çdo moment tjetër. Në këtë pikëpamje, kjo është thelbi i DevOps.
Një tjetër këndvështrim mbi këtë çështje. Mendoj se qëllimi ynë është një: të mbijetojmë dhe ta bëjmë këtë me
sa më shumë kënaqësi. Dhe qëllimi konkurrues i çdo organizate është po ashtu. Mbijetesa ndodhi shpesh në një garë konkurruese, këtu nuk mund të bëjmë gjë tjetër.
Të këtij viti konferenca do të mbahet më 7 dhjetor në "Teknopolis". 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
