Anton Weiss, fondinto kaj direktoro de Otomato Software, unu el la iniciatintoj kaj instruistoj de la unua DevOps-atestilo en Israelo, parolis ĉe la pasintjara. pri kaosa teorio kaj la ĉefaj principoj de kaosa inĝenierado, kaj ankaŭ klarigis kiel funkcias la ideala DevOps-organizo de la estonteco.
Ni preparis tekstan version de la raporto.
Bonan matenon!
DevOpsDays en Moskvo por la dua jaro sinsekva, ĉi tiu estas mia dua fojo sur ĉi tiu scenejo, multaj el vi estas en ĉi tiu ĉambro por la dua fojo. Kion ĝi signifas? Ĉi tio signifas, ke la movado DevOps en Rusio kreskas, multiĝas, kaj plej grave, tio signifas, ke venis la tempo por paroli pri tio, kio estas DevOps en 2018.
Levu viajn manojn, kiuj pensas, ke DevOps jam estas profesio en 2018? Estas tiaj. Ĉu estas iuj DevOps-inĝenieroj en la ĉambro, kies laborpriskribo diras "DevOps-Inĝeniero"? Ĉu estas DevOps-manaĝeroj en la ĉambro? Ne ekzistas tia. DevOps-arkitektoj? Ankaŭ ne. Ne sufiĉas. Ĉu vere estas vero, ke neniu diras, ke ili estas DevOps-inĝeniero?
Do plej multaj el vi pensas, ke ĉi tio estas kontraŭ-ŝablono? Ke tia profesio ne ekzistus? Ni povas pensi kion ni volas, sed dum ni pensas, la industrio solene antaŭeniras al la sono de la trumpeto DevOps.
Kiu aŭdis pri nova temo nomata DevDevOps? Ĉi tio estas nova tekniko, kiu permesas efikan kunlaboron inter programistoj kaj devopoj. Kaj ne tiel nova. Juĝante laŭ Tvitero, ili jam komencis paroli pri tio antaŭ 4 jaroj. Kaj ĝis nun la intereso pri tio kreskas kaj kreskas, tio estas, estas problemo. La problemo devas esti solvita.
Ni estas kreivaj homoj, ni ne nur ripozas trankvilaj. Ni diras: DevOps ne estas sufiĉe ampleksa vorto; al ĝi ankoraŭ mankas ĉiaj malsamaj, interesaj elementoj. Kaj ni iras al niaj sekretaj laboratorioj kaj komencas produkti interesajn mutaciojn: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La logiko estas fera, ĉu ne? Nia liversistemo ne funkcias, niaj sistemoj estas malstabilaj kaj niaj uzantoj estas malkontentaj, ni ne havas tempon por efektivigi programaron ĝustatempe, ni ne konvenas al la buĝeto. Kiel ni solvos ĉion ĉi? Ni elpensos novan vorton! Ĝi finiĝos per "Ops" kaj la problemo estas solvita.
Do mi nomas ĉi tiun aliron - "Ops, kaj la problemo estas solvita."
Ĉi ĉio malaperas en la fonon se ni memoras al ni kial ni elpensis ĉion ĉi. Ni elpensis ĉi tiun tutan aferon de DevOps por fari programaran liveron kaj nian propran laboron en ĉi tiu procezo kiel eble plej senbara, sendolora, efika kaj plej grave, ĝuebla.
DevOps kreskis pro doloro. Kaj ni estas lacaj de sufero. Kaj por ke ĉio ĉi okazu, ni fidas je ĉiamverdaj praktikoj: efika kunlaboro, fluaj praktikoj kaj plej grave, sistema pensado, ĉar sen ĝi neniu DevOps funkcias.
Kio estas la sistemo?
Kaj se ni jam parolas pri sistema pensado, ni memorigu nin, kio estas sistemo.
Se vi estas revolucia retpirato, tiam por vi la sistemo estas klare malbona. Ĝi estas nubo, kiu pendas super vi kaj devigas vin fari aferojn, kiujn vi ne volas fari.
El la vidpunkto de sistema pensado, sistemo estas tuto, kiu konsistas el partoj. En ĉi tiu senco, ĉiu el ni estas sistemo. La organizoj en kiuj ni laboras estas sistemoj. Kaj tio, kion vi kaj mi konstruas, nomiĝas sistemo.
Ĉio ĉi estas parto de unu granda soci-teknologia sistemo. Kaj nur se ni komprenos kiel ĉi tiu soci-teknologia sistemo funkcias kune, nur tiam ni povos vere optimumigi ion en ĉi tiu afero.
De sistema pensa perspektivo, sistemo havas diversajn interesajn ecojn. Unue, ĝi konsistas el partoj, kio signifas, ke ĝia konduto dependas de la konduto de la partoj. Krome, ĉiuj ĝiaj partoj ankaŭ estas interdependaj. Montriĝas, ke ju pli da partoj havas sistemo, des pli malfacilas kompreni aŭ antaŭdiri ĝian konduton.
De kondutisma vidpunkto, estas alia interesa fakto. La sistemo povas fari ion, kion neniu el ĝiaj individuaj partoj povas fari.
Kiel diris D-ro Russell Ackoff (unu el la fondintoj de sistema pensado), tio estas sufiĉe facile pruvebla per pensa eksperimento. Ekzemple, kiu en la ĉambro scias kiel skribi kodon? Estas multaj manoj, kaj ĉi tio estas normala, ĉar ĉi tio estas unu el la ĉefaj postuloj por nia profesio. Ĉu vi scias skribi, sed ĉu viaj manoj povas skribi kodon aparte de vi? Estas homoj, kiuj diros: "Ne miaj manoj skribas la kodon, sed mia cerbo skribas la kodon." Ĉu via cerbo povas skribi kodon aparte de vi? Nu, verŝajne ne.
La cerbo estas mirinda maŝino, ni eĉ ne scias 10% pri kiel ĝi funkcias tie, sed ĝi ne povas funkcii aparte de la sistemo, kiu estas nia korpo. Kaj ĉi tio estas facile pruvebla: malfermu vian kranion, elprenu vian cerbon, metu ĝin antaŭ la komputilon, li provu skribi ion simplan. "Saluton, mondo" en Python, ekzemple.
Se sistemo povas fari ion, kion neniu el ĝiaj partoj povas fari aparte, tiam tio signifas, ke ĝia konduto ne estas determinita de la konduto de siaj partoj. Per kio do ĝi estas determinita? Ĝi estas determinita de la interago inter ĉi tiuj partoj. Kaj sekve, ju pli da partoj, des pli kompleksaj la interagoj, des pli malfacilas kompreni kaj antaŭdiri la konduton de la sistemo. Kaj ĉi tio faras tian sistemon kaosa, ĉar ajna, eĉ la plej sensignifa, nevidebla ŝanĝo en iu parto de la sistemo povas konduki al tute neantaŭvideblaj rezultoj.
Tiu ĉi sentemo al komencaj kondiĉoj unue estis malkovrita kaj studita fare de amerika meteologo Ed Lorenz. Poste, ĝi estis nomita la "papilia efiko" kaj kaŭzis la evoluon de movado de scienca penso nomita "kaoso-teorio". Ĉi tiu teorio iĝis unu el la plej gravaj paradigmoŝanĝoj en 20-a-jarcenta scienco.
Kaoso-teorio
Homoj, kiuj studas kaoson, nomas sin kaosologoj.
Efektive, la kialo de ĉi tiu raporto estis, ke, laborante kun kompleksaj distribuitaj sistemoj kaj grandaj internaciaj organizaĵoj, iam mi konstatis, ke mi sentas min tiel. Mi estas kaosologo. Ĉi tio estas esence lerta maniero diri: "Mi ne komprenas, kio okazas ĉi tie kaj mi ne scias kion fari pri ĝi."
Mi pensas, ke ankaŭ multaj el vi ofte sentas tiel, do ankaŭ vi estas kaosologoj. Mi invitas vin al la gildo de kaosologoj. La sistemoj, kiujn vi kaj mi, karaj samideanoj, studos estas nomataj "kompleksaj adaptaj sistemoj".
Kio estas adaptebleco? Adaptebleco signifas ke la individua kaj kolektiva konduto de partoj en tia adapta sistemo ŝanĝiĝas kaj mem-organizas, respondante al okazaĵoj aŭ ĉenoj de mikro-okazaĵoj en la sistemo. Tio estas, la sistemo adaptiĝas al ŝanĝoj per mem-organizado. Kaj ĉi tiu kapablo sinorganizi baziĝas sur la libervola, tute malcentralizita kunlaboro de liberaj aŭtonomaj agentoj.
Alia interesa propraĵo de tiaj sistemoj estas ke ili estas libere skaleblaj. Kio sendube devus interesi nin, kiel kaosologoj-inĝenieroj. Do, se ni dirus, ke la konduto de kompleksa sistemo estas determinita de la interago de ĝiaj partoj, pri kio do ni interesiĝu? Interago.
Estas du pli interesaj trovoj.
Unue, ni komprenas, ke kompleksa sistemo ne povas esti simpligita simpligante ĝiajn partojn. Due, la nura maniero simpligi kompleksan sistemon estas simpligante la interagojn inter ĝiaj partoj.
Kiel ni interagas? Vi kaj mi ĉiuj estas partoj de granda informsistemo nomata homa socio. Ni interrilatas per komuna lingvo, se ni havas ĝin, se ni trovas ĝin.
Sed lingvo mem estas kompleksa adapta sistemo. Sekve, por interagi pli efike kaj simple, ni devas krei ian protokolojn. Tio estas, iu sinsekvo de simboloj kaj agoj, kiuj faros la interŝanĝon de informoj inter ni pli simpla, antaŭvidebla, pli komprenebla.
Mi volas diri, ke tendencoj al komplekseco, al adaptebleco, al malcentralizo, al kaoso povas esti spuritaj en ĉio. Kaj en la sistemoj, kiujn vi kaj mi konstruas, kaj en tiuj sistemoj, de kiuj ni estas parto.
Kaj por ne esti senbaza, ni rigardu kiel la sistemoj kiujn ni kreas ŝanĝiĝas.
Vi atendis tiun ĉi vorton, mi komprenas. Ni estas ĉe DevOps-konferenco, hodiaŭ ĉi tiu vorto estos aŭdita ĉirkaŭ cent mil fojojn kaj tiam ni sonĝos pri ĝi nokte.
Mikroservoj estas la unua programara arkitekturo kiu aperis kiel reago al DevOps-praktikoj, kiu estas dizajnita por igi niajn sistemojn pli flekseblaj, pli skaleblaj kaj certigi daŭran liveron. Kiel ŝi faras ĉi tion? Reduktante la volumon de servoj, reduktante la amplekson de problemoj, kiujn ĉi tiuj servoj procesas, reduktante livertempon. Tio estas, ni reduktas kaj simpligas partojn de la sistemo, pliigas ilian nombron, kaj sekve, la komplekseco de interagoj inter ĉi tiuj partoj senescepte pliiĝas, tio estas, novaj problemoj ekestas, kiujn ni devas solvi.
Mikroservoj ne estas la fino, mikroservoj estas, ĝenerale, jam hieraŭ, ĉar Serverless venas. Ĉiuj serviloj forbrulis, neniuj serviloj, neniuj operaciumoj, nur pura plenumebla kodo. Agordoj estas apartaj, ŝtatoj estas apartaj, ĉio estas regata de eventoj. Beleco, pureco, silento, neniu evento, nenio okazas, kompleta ordo.
Kie estas la komplekseco? La malfacilaĵo, kompreneble, estas en la interagoj. Kiom povas fari unu funkcio memstare? Kiel ĝi interagas kun aliaj funkcioj? Mesaĝaj atendovicoj, datumbazoj, balanciloj. Kiel rekrei iun eventon kiam malsukceso okazis? Multaj demandoj kaj malmultaj respondoj.
Mikroservoj kaj Serverless estas tio, kion ni geek hipsteroj nomas Cloud Native. Ĉio temas pri la nubo. Sed la nubo ankaŭ estas esence limigita en sia skaleblo. Ni kutimas pensi pri ĝi kiel distribuita sistemo. Fakte, kie loĝas la serviloj de nubaj provizantoj? En datumcentroj. Tio estas, ni havas ĉi tie specon de centralizita, tre limigita, distribuita modelo.
Hodiaŭ ni komprenas, ke la Interreto de Aĵoj ne plu estas nur grandaj vortoj, kiujn eĉ laŭ modestaj antaŭdiroj, miliardoj da aparatoj konektitaj al Interreto atendas nin en la venontaj kvin ĝis dek jaroj. Grandega kvanto da utilaj kaj senutilaj datumoj, kiuj estos kunfanditaj en la nubon kaj alŝutitaj el la nubo.
La nubo ne daŭros, do ni ĉiam pli parolas pri io nomata randa komputado. Aŭ ankaŭ mi ŝatas la mirindan difinon de "nebulkomputado". Ĝi estas envolvita en la mistikismo de romantismo kaj mistero.
Nebulkomputado. La punkto estas, ke nuboj estas centralizitaj amasoj de akvo, vaporo, glacio kaj ŝtonoj. Kaj nebulo estas gutetoj da akvo, kiuj estas disigitaj ĉirkaŭ ni en la atmosfero.
En la nebulparadigmo, la plej granda parto de la laboro estas farita de tiuj gutetoj tute aŭtonomie aŭ kunlabore kun aliaj gutetoj. Kaj ili turnas sin al la nubo nur kiam ili vere estas premataj.
Tio estas, denove malcentralizo, aŭtonomeco, kaj, kompreneble, multaj el vi jam komprenas kien ĉio ĉi iras, ĉar vi ne povas paroli pri malcentralizo sen mencii la blokĉenon.
Estas tiuj, kiuj kredas, ĉi tiuj estas tiuj, kiuj investis en kripta monero. Estas tiuj, kiuj kredas sed timas, kiel mi, ekzemple. Kaj estas tiuj, kiuj ne kredas. Ĉi tie vi povas trakti malsame. Estas teknologio, nova nekonata afero, estas problemoj. Kiel ĉiu nova teknologio, ĝi levas pli da demandoj ol ĝi respondas.
La ekzaltiĝo ĉirkaŭ blokĉeno estas komprenebla. Aparte de la orfebro, la teknologio mem tenas rimarkindajn promesojn por pli brila estonteco: pli da libereco, pli da aŭtonomeco, distribuita tutmonda fido. Kion oni ne volas?
Sekve, pli kaj pli da inĝenieroj tra la mondo komencas disvolvi malcentralizitajn aplikojn. Kaj ĉi tio estas potenco kiu ne povas esti forĵetita simple dirante: "Ah, blokĉeno estas nur malbone efektivigita distribuita datumbazo." Aŭ kiel skeptikuloj ŝatas diri: "Ne ekzistas realaj aplikoj por blokĉeno." Se vi pensas pri tio, antaŭ 150 jaroj oni diris la samon pri elektro. Kaj ili eĉ iel pravis, ĉar tio, kion la elektro ebligas hodiaŭ, neniel eblis en la 19-a jarcento.
Cetere, kiu scias, kia emblemo estas sur la ekrano? Ĉi tio estas Hyperledger. Ĉi tio estas projekto kiu estas disvolvita sub la aŭspicioj de The Linux Foundation kaj inkluzivas aron de blokĉenaj teknologioj. Ĉi tio estas vere la forto de nia malfermkoda komunumo.
Kaosa Inĝenieristiko
Do, la sistemo, kiun ni disvolvas, fariĝas pli kaj pli kompleksa, pli kaj pli kaosa, kaj pli kaj pli adapta. Netflix estas pioniroj de mikroservosistemoj. Ili estis inter la unuaj kiuj komprenis tion, ili evoluigis aron da iloj, kiujn ili nomis Simian Army, la plej fama el kiuj estis . Li difinis kio iĝis konata kiel .
Cetere, en la procezo de laboro pri la raporto, ni eĉ tradukis ĉi tiun tekston en la rusan, do iru al , legi, komenti, riproĉi.
Mallonge, la principoj de kaosa inĝenierado diras la jenon. Kompleksaj distribuitaj sistemoj estas esence neantaŭvideblaj kaj esence fuŝaj. Eraroj estas neeviteblaj, kio signifas, ke ni devas akcepti ĉi tiujn erarojn kaj labori kun ĉi tiuj sistemoj tute alimaniere.
Ni mem devas provi enkonduki ĉi tiujn erarojn en niajn produktadsistemojn por testi niajn sistemojn pri ĉi tiu sama adaptebleco, ĉi tiu sama kapablo por memorganizado, por supervivo.
Kaj tio ŝanĝas ĉion. Ne nur kiel ni lanĉas sistemojn en produktadon, sed ankaŭ kiel ni disvolvas ilin, kiel ni testas ilin. Ne estas procezo de stabiligo aŭ frostigo de la kodo; male, estas konstanta procezo de malstabiligo. Ni provas mortigi la sistemon kaj vidi ĝin daŭre pluvivi.
Protokoloj de Distribuitaj Sistemintegriĝoj
Sekve, ĉi tio postulas niajn sistemojn ŝanĝi iel. Por ke ili fariĝu pli stabilaj, ili bezonas novajn protokolojn por interagado inter siaj partoj. Por ke ĉi tiuj partoj povu konsenti kaj veni al ia memorganizado. Kaj aperas ĉiaj novaj iloj, novaj protokoloj, kiujn mi nomas "protokoloj por la interagado de distribuitaj sistemoj".
Pri kio mi parolas? Unue, la projekto . Iuj provas krei ĝeneralan distribuitan spurprotokolon, kiu estas absolute nemalhavebla ilo por sencimigi kompleksajn distribuitajn sistemojn.
Plue - . Ni diras, ke ni ne povas antaŭdiri, kio okazos al la sistemo, tio estas, ni bezonas pliigi ĝian observeblon, observeblon. Opentracing apartenas al familio de iloj kiuj donas observeblon al niaj sistemoj. Sed ni bezonas observeblon por determini ĉu la sistemo kondutas kiel ni atendas ĝin aŭ ne. Kiel ni difinas atendatan konduton? Difinante ian politikon, iun regulojn. La projekto Open Policy Agent laboras por difini ĉi tiun aron de reguloj trans spektro, kiu iras de aliro ĝis asigno de rimedoj.
Kiel ni diris, niaj sistemoj estas ĉiam pli okazigitaj. Senservilo estas bonega ekzemplo de eventaj sistemoj. Por ke ni transloku eventojn inter sistemoj kaj spuru ilin, ni bezonas iun komunan lingvon, iun komunan protokolon pri kiel ni parolas pri eventoj, kiel ni transdonas ilin unu al la alia. Tiel nomis projekto .
La konstanta fluo de ŝanĝoj, kiu trapasas niajn sistemojn, konstante malstabiligante ilin, estas kontinua fluo de programaraj artefaktoj. Por ke ni konservu ĉi tiun konstantan fluon de ŝanĝoj, ni bezonas iun komunan protokolon, per kiu ni povas paroli pri kio estas programaro, kiel ĝi estas provita, kian konfirmon ĝi pasis. Tiel nomis projekto . Tio estas, ofta metadatuma protokolo por softvarartefaktoj.
Kaj finfine, se ni volas, ke niaj sistemoj estu tute sendependaj, adapteblaj kaj memorganizitaj, ni devas doni al ili la rajton al memidentigo. Projekto nomita Ĝuste ĉi tion li faras. Ĉi tio ankaŭ estas projekto sub la aŭspicioj de la Cloud Native Computing Foundation.
Ĉiuj ĉi projektoj estas junaj, ili ĉiuj bezonas nian amon, nian validigon. Ĉi tio ĉio estas malferma fonto, nia testado, nia efektivigo. Ili montras al ni kien teknologio iras.
Sed DevOps neniam temis ĉefe pri teknologio, ĝi ĉiam temis pri kunlaboro inter homoj. Kaj, sekve, se ni volas, ke la sistemoj, kiujn ni evoluigas, ŝanĝiĝu, tiam ni mem devas ŝanĝiĝi. Fakte, ni ĉiuokaze ŝanĝiĝas; ni ne havas multe da elekto.
Estas mirinda Brita verkistino Rachel Botsman, en kiu ŝi skribas pri la evoluo de fido tra la homa historio. Ŝi diras, ke komence, en primitivaj socioj, fido estis loka, tio estas, ni fidis nur tiujn, kiujn ni persone konis.
Tiam estis tre longa periodo – malluma tempo, kiam la konfido estis centralizita, kiam ni komencis fidi homojn, kiujn ni ne konas surbaze de tio, ke ni apartenas al la sama publika aŭ ŝtata institucio.
Kaj jen kion ni vidas en nia moderna mondo: la fido fariĝas pli kaj pli distribuata kaj malcentralizita, kaj ĝi baziĝas sur la libereco de informaj fluoj, sur la havebleco de informoj.
Se vi pensas pri tio, ĉi tiu mem alirebleco, kiu ebligas ĉi tiun fidon, estas tio, kion vi kaj mi efektivigas. Ĉi tio signifas, ke kaj la maniero kiel ni kunlaboras kaj la maniero kiel ni faras ĝin devas ŝanĝiĝi, ĉar la centralizitaj, hierarkiaj IT-organizoj de malnovaj ne plu funkcias. Ili komencas formorti.
DevOps Organizaj Fundamentoj
La ideala DevOps-organizo de la estonteco estas malcentralizita, adapta sistemo kunmetita de aŭtonomaj teamoj, ĉiu konsistanta el aŭtonomaj individuoj. Ĉi tiuj teamoj estas disigitaj tra la mondo, kunlaborante efike unu kun la alia uzante nesinkronan komunikadon, uzante tre travideblajn komunikajn protokolojn. Tre bela, ĉu ne? Tre bela estonteco.
Kompreneble, nenio el ĉi tio eblas sen kultura ŝanĝo. Ni devas havi transforman gvidadon, personan respondecon, internan motivadon.
Ĉi tio estas la bazo de DevOps-organizoj: informa travidebleco, nesinkronaj komunikadoj, transforma gvidado, malcentralizo.
Brulado
La sistemoj de kiuj ni estas parto kaj tiuj, kiujn ni konstruas, estas ĉiam pli ĥaosaj, kaj estas malfacile por ni homoj elteni ĉi tiun penson, estas malfacile rezigni la iluzion de kontrolo. Ni provas daŭre kontroli ilin, kaj ĉi tio ofte kondukas al elĉerpiĝo. Mi diras tion el mia propra sperto, mi ankaŭ brulis, ankaŭ mi estis malfunkciigita pro neantaŭviditaj malsukcesoj en produktado.
Elĉerpiĝo okazas kiam ni provas kontroli ion, kio estas esence neregebla. Kiam ni forbrulas, ĉio perdas sian signifon ĉar ni perdas la deziron fari ion novan, ni defendas kaj komencas defendi tion, kion ni havas.
La inĝenieristiko, kiel mi ofte ŝatas rememorigi min, estas antaŭ ĉio krea profesio. Se ni perdas la deziron krei ion, tiam ni fariĝas cindro, fariĝas cindro. Homoj forbrulas, tutaj organizoj forbrulas.
Miaopinie, nur akcepti la krean povon de kaoso, nur konstrui kunlaboron laŭ ĝiaj principoj, tio helpos nin ne perdi tion, kio estas bona en nia profesio.
Jen kion mi deziras al vi: ami vian laboron, ami tion, kion ni faras. Ĉi tiu mondo nutras sin per informoj, ni havas la honoron nutri ĝin. Do ni studu ĥaoson, ni estu ĥaosologoj, ni alportu valoron, kreu ion novan, nu, problemoj, kiel ni jam eksciis, estas neeviteblaj, kaj kiam ili aperos, ni simple diros “Ops!” Kaj la problemo estas solvita.
Kio krom Chaos Monkey?
Fakte, ĉiuj ĉi tiuj instrumentoj estas tiel junaj. La sama Netflix konstruis ilojn por si mem. Konstruu viajn proprajn ilojn. Legu la principojn de kaosa inĝenierado kaj vivu laŭ tiuj principoj prefere ol provi trovi aliajn ilojn, kiujn iu alia jam konstruis.
Provu kompreni kiel viaj sistemoj rompiĝas kaj komencu detrui ilin kaj vidu kiel ili tenas. Ĉi tio venas unue. Kaj vi povas serĉi ilojn. Estas ĉiaj projektoj.
Mi ne bone komprenis la momenton, kiam vi diris, ke la sistemo ne povas esti simpligita simpligante ĝiajn komponantojn, kaj tuj transiris al mikroservoj, kiuj simpligas la sistemon simpligante la komponantojn mem kaj komplikante interagojn. Ĉi tiuj estas esence du partoj kiuj kontraŭdiras unu la alian.
Ĝuste, mikroservoj ĝenerale estas tre polemika temo. Fakte, simpligi partojn pliigas flekseblecon. Kion provizas mikroservoj? Ili donas al ni flekseblecon kaj rapidecon, sed ili certe ne donas al ni simplecon. Ili pliigas la malfacilecon.
Do, en la DevOps-filozofio, mikroservoj ne estas tia bona afero?
Ajna bono havas reverson. La avantaĝo estas, ke ĝi pliigas flekseblecon, permesante al ni fari ŝanĝojn pli rapide, sed ĝi pliigas la kompleksecon kaj tial la fragilecon de la tuta sistemo.
Tamen, kio estas pli da emfazo: pri simpligado de interago aŭ sur simpligado de partoj?
La emfazo, kompreneble, estas simpligi interagojn, ĉar se ni rigardas tion el la vidpunkto de kiel ni laboras kun vi, tiam, antaŭ ĉio, ni devas atenti simpligi interagojn, kaj ne simpligi la laboron. de ĉiu el ni aparte. Ĉar simpligi laboron signifas iĝi robotoj. Ĉi tie ĉe McDonald's ĝi funkcias normale kiam oni havas instrukciojn: jen oni metas la hamburgeron, jen oni verŝas la saŭcon sur ĝin. Ĉi tio tute ne funkcias en nia krea laboro.
Ĉu estas vere, ke ĉio, kion vi diris, vivas en mondo sen konkurenco, kaj la kaoso tie estas tiel afabla, kaj ne ekzistas kontraŭdiroj ene de ĉi tiu kaoso, neniu volas manĝi aŭ mortigi iun? Kiel konkurenco kaj DevOps faru?
Nu, dependas de kia konkurenco ni parolas. Ĉu temas pri konkurenco en la laborejo aŭ konkurenco inter kompanioj?
Pri la konkurado de servoj kiuj ekzistas ĉar servoj ne estas pluraj kompanioj. Ni kreas novan tipon de informa medio, kaj ajna medio ne povas vivi sen konkurado. Ĉie estas konkurenco.
La sama Netflix, ni prenas ilin kiel modelon. Kial ili elpensis ĉi tion? Ĉar ili devis esti konkurencivaj. Ĉi tiu fleksebleco kaj rapideco de movado estas ĝuste la tre konkurenciva postulo; ĝi enkondukas kaoson en niajn sistemojn. Tio estas, kaoso ne estas io, kion ni konscie faras, ĉar ni volas, ĝi estas io, kio okazas ĉar la mondo postulas tion. Ni devas nur adaptiĝi. Kaj kaoso, ĝi estas ĝuste la rezulto de konkurenco.
Ĉu tio signifas, ke kaoso estas la foresto de celoj, kvazaŭ? Aŭ tiujn celojn, kiujn ni ne volas vidi? Ni estas en la domo kaj ne komprenas la celojn de aliaj. Konkurado, fakte, ŝuldiĝas al tio, ke ni havas klarajn celojn kaj ni scias, kie ni alvenos en ĉiu venonta momento en la tempo. Ĉi tio, laŭ mia vidpunkto, estas la esenco de DevOps.
Ankaŭ rigardu la demandon. Mi pensas, ke ni ĉiuj havas la saman celon: pluvivi kaj fari ĝin kun
plej granda plezuro. Kaj la konkurenciva celo de iu ajn organizo estas la sama. Supervivado ofte okazas per konkuro, estas nenio, kion vi povas fari pri ĝi.
La ĉi-jara konferenco okazos la 7-an de decembro ĉe Technopolis. Ni akceptas petojn por raportoj ĝis la 11-a de novembro. nin se vi volus paroli.
Aliĝo por partoprenantoj estas malfermita, biletoj kostas 7000 XNUMX rublojn. Aliĝu al ni!
fonto: www.habr.com