programinės įrangos inžinerija"DevOps"sistemos architektūraTechnologija
Programinė įranga kaip eksperimentas vs programinė įranga kaip infrastruktūra
Šis palyginimas nagrinėja dvi kontrastingas programinės įrangos inžinerijos filosofijas: greitą, kartotinį eksperimentinio kodo požiūrį į stabilų, kritinį infrastruktūros programinės įrangos pobūdį. Vienas iš jų orientuotas į greitį ir atradimus, o kitas teikia pirmenybę pagrindinių skaitmeninių paslaugų ir pasaulinių sistemų patikimumui ir ilgalaikei priežiūrai.
Akcentai
Eksperimentinis kodas sutelkia dėmesį į koncepcijos egzistavimo įrodymą, o infrastruktūros kodas įrodo, kad ji gali išlikti.
Infrastruktūrai reikalingas griežtas "sprogimo spindulio" planavimas, kad būtų išvengta kaskadinių sistemos gedimų.
Pokyčių kaina yra sąmoningai maža eksperimentuose ir sąmoningai didelė infrastruktūroje.
Eksperimento sėkmė yra nauja įžvalga; Infrastruktūros sėkmė yra tyli, nuobodi operacija.
Kas yra Programinė įranga kaip eksperimentas?
Kodas, skirtas greitam mokymuisi, prototipų kūrimui ir hipotezių testavimui greitai besikeičiančioje aplinkoje.
Pirmenybę teikia pristatymo greičiui, o ne ilgalaikiam architektūriniam tobulumui.
Dažniausiai naudojamas startuolių aplinkoje, siekiant rasti produkto atitiktį rinkai.
Laikosi "greito žlugimo" mentaliteto, kad sumažintų švaistomus kūrimo išteklius.
Dažnai remiasi technine skola kaip apskaičiuotu kompromisu dėl patekimo į rinką.
Paprastai turi trumpesnį gyvenimo ciklą, dažnai atmetamas išmokus pamoką.
Kas yra Programinė įranga kaip infrastruktūra?
Pagrindinis kodas, sukurtas dideliam pasiekiamumui, saugumui ir nuosekliam ilgalaikiam veikimui.
Sukurta taip, kad atlaikytų didžiulį mastelį ir vienu metu veikiančias vartotojo apkrovas.
Pagrindinis dėmesys skiriamas atgaliniam suderinamumui, kad būtų išvengta tolesnės priklausomybės.
Reikalinga išsami dokumentacija ir griežti automatizuoti testavimo protokolai.
Sukurtas taip, kad gyvavimo ciklas būtų dešimtmečiai, o ne mėnesiai ar metai.
Palaiko pagrindines paslaugas, tokias kaip bankininkystė, energijos tinklai ir debesų platformos.
Palyginimo lentelė
Funkcija
Programinė įranga kaip eksperimentas
Programinė įranga kaip infrastruktūra
Pagrindinis tikslas
Mokymasis ir atradimas
Stabilumas ir patikimumas
Klaidos nuokrypis
Aukštas (skatinamas augti)
Žemas (numatoma nulinė prastova)
Vystymosi greitis
Greitos iteracijos
Metodiškas ir apgalvotas
Techninė skola
Priimta ir laukiama
Aktyviai minimizuojamas ir valdomas
Dokumentai
Minimalus arba "just-in-time"
Išsamus ir išsamus
Testavimo griežtumas
Dėmesys pagrindinėms funkcijoms
Ribiniai atvejai ir testavimas nepalankiausiomis sąlygomis
Dėmesys sąnaudoms
Mažos pradinės investicijos
Dėmesys bendroms nuosavybės sąnaudoms
Mastelio keitimas
Dažnai antraeilis
Integruota nuo pirmos dienos
Išsamus palyginimas
Rizikos valdymas ir patikimumas
Eksperimentinė programinė įranga traktuoja klaidas kaip mokymosi galimybes, dažnai veikiančias aplinkoje, kurioje avarija paveikia nedaug žmonių. Tačiau infrastruktūros programinė įranga prastovas traktuoja kaip katastrofišką įvykį, reikalaujantį gynybinio programavimo ir perteklinių sistemų. Skirtumas slypi tame, ar kodui leidžiama sulaužyti dalykus, kad judėtų greitai, ar turi likti nepažeistas, kad pasaulis judėtų.
Ilgaamžiškumas ir priežiūra
Eksperimentas dažnai yra laikinas tiltas į atsakymą, dažnai perrašomas arba nurašomas, kai tikslas pasiekiamas. Infrastruktūros kodeksas yra sukurtas kaip nuolatinis įrenginys, reikalaujantis kruopštaus atnaujinimo planavimo, kuris gali apimti nuo penkerių iki dešimties metų. Infrastruktūros kūrėjai turi galvoti, kaip jų kodas atrodys prižiūrėtojui 2035 m., o eksperimentuotojai sutelkia dėmesį į kitą savaitę.
Poveikis inžinerinei kultūrai
Eksperimentinę programinę įrangą kuriančios komandos klesti dėl kūrybiškumo, daug sukimosi reikalaujančių darbo eigų ir daug energijos reikalaujančių sprintų. Infrastruktūros komandos vertina discipliną, gilias architektūrines apžvalgas ir pasididžiavimą pastatyti tai, kas niekada nepavyksta. Šie skirtingi mąstymai dažnai lemia skirtingus samdos profilius: "įsilaužėliai" pirmenybę teikia pirmiesiems, o "sistemų inžinieriai" traukia į antruosius.
Ekonominiai veiksniai
Eksperimentinė programinė įranga paprastai finansuojama atsižvelgiant į poreikį greitai užimti rinką arba patvirtinti nišą. Infrastruktūra yra investicija į fondą, kur klaidos kaina gali sukelti didžiulius finansinius ar teisinius įsipareigojimus. Vienas iš jų yra agresyvus augimo žaidimas, o kitas – esamos vertės ir veiklos tęstinumo apsaugos priemonė.
Privalumai ir trūkumai
Programinė įranga kaip eksperimentas
Privalumai
+Itin greitas grįžtamasis ryšys
+Mažos išankstinės išlaidos
+Skatina inovacijas
+Didelis lankstumas
Pasirinkta
−Trapi kodų bazė
−Kaupia techninę skolą
−Prastas mastelio keitimas
−Nepatikimas vartotojams
Programinė įranga kaip infrastruktūra
Privalumai
+Išskirtinis patikimumas
+Aukšti saugumo standartai
+Aiški dokumentacija
+Didžiulis pajėgumas
Pasirinkta
−Lėti vystymosi ciklai
−Didelės inžinerinės išlaidos
−Atsparus pokyčiams
−Kompleksinė priežiūra
Dažni klaidingi įsitikinimai
Mitas
Eksperimentinė programinė įranga yra tik "blogas" kodas, parašytas tingių kūrėjų.
Realybė
Tyčinis eksperimentinis kodas yra strateginis pasirinkimas teikti pirmenybę mokymuisi. Jis yra "tinkamas tikslui", jei tikslas yra patvirtinimas, nors jis tampa problemiškas, jei jis galiausiai nėra pertvarkytas ar pakeistas.
Mitas
Infrastruktūros programinė įranga niekada nesikeičia ir nesivysto.
Realybė
Infrastruktūra turi vystytis, tačiau tai daroma labai atsargiai. Pakeitimai įgyvendinami naudojant mėlynai žalius diegimus arba kanarėlių leidimus, siekiant užtikrinti, kad pereinamojo laikotarpio pagrindas išliktų tvirtas.
Mitas
Vėliau galite lengvai paversti eksperimentą infrastruktūra.
Realybė
Tai yra įprasti spąstai, vedantys į "spagečių" sistemas. Tikroji infrastruktūra paprastai reikalauja visiško architektūrinio permąstymo, nes pagrindinės eksperimento prielaidos retai būna keičiamos.
Mitas
Tik startuoliai kuria eksperimentinę programinę įrangą.
Realybė
Net milžiniškos technologijų įmonės naudoja eksperimentines šakas ar "laboratorijas" funkcijoms išbandyti. Svarbiausia yra izoliuoti šiuos eksperimentus, kad jie nekeltų grėsmės pagrindinei infrastruktūrai, nuo kurios priklauso vartotojai.
Dažnai užduodami klausimai
Kada turėčiau nustoti laikyti programą eksperimentu?
Perėjimas turėtų įvykti tuo metu, kai jūsų programinė įranga pereina iš "malonu turėti" į "kritinę" jūsų vartotojams. Jei 15 minučių gedimas sukelia didelių finansinių nuostolių arba vartotojų pasitraukimą, perėjote į infrastruktūros sritį ir turite atitinkamai pakoreguoti testavimo ir diegimo griežtumą.
Ar infrastruktūros programinė įranga naudoja skirtingas programavimo kalbas?
Nors bet kuri kalba gali būti naudojama abiem, infrastruktūra dažnai linksta į kompiliuotas kalbas su stipriu rašymu, pvz., Go, Rust ar C++, kad būtų užtikrintas našumas ir saugumas. Eksperimentinė programinė įranga dažnai naudoja lanksčias, aukšto lygio kalbas, tokias kaip Python ar Ruby, kurios leidžia greičiau kurti prototipus ir lengviau keisti sintaksę.
Ar eksperimentinėje programinėje įrangoje techninė skola visada bloga?
Nebūtinai. Eksperimento metu techninė skola yra tarsi paskola su didelėmis palūkanomis, padedanti greičiau nusipirkti būstą. Tai tampa "bloga" skola tik tada, kai niekada jos negrąžinsite arba jei bandysite pastatyti dangoraižį (infrastruktūrą) ant to laikino pamato.
Kuo skiriasi testavimo strategijos?
Eksperimentuose daugiausia dėmesio skiriama "Laimingo kelio" testavimui – tikrinama, ar pagrindinė funkcija tinka paprastam naudotojui. Infrastruktūros testavimas yra apsėstas "Edge Cases" ir "Chaos Engineering", kai kūrėjai tyčia sulaužo sistemos dalis, kad pamatytų, ar likusios gali išgyventi šoką.
Ar viena įmonė gali vienu metu valdyti abu metodus?
Taip, ir sėkmingiausi tai daro. Jie dažnai naudoja "bimodalinę IT" strategiją, kai viena komanda prižiūri pagrindines, stabilias sistemas (infrastruktūrą), o kita judri komanda tyrinėja naujas ribas (eksperimentas). Iššūkis yra valdyti perdavimą tarp šių dviejų kultūrų.
Kokia yra didžiausia rizika per ilgai išlikti "eksperimento" fazėje?
Didžiausia rizika yra "sisteminis pažeidžiamumas". Kai pridedate daugiau funkcijų prie laisvai pastatyto eksperimento, sudėtingumas auga eksponentiškai. Galiausiai sistema tampa tokia trapi, kad atlikus vieną nedidelį pakeitimą nesusijusios dalys sugenda, o tai veiksmingai sustabdo visas būsimas naujoves.
Kodėl dokumentacija yra daug svarbesnė infrastruktūrai?
Infrastruktūra yra bendras išteklius, kuris išgyvena savo pirminius kūrėjus. Neturėdami išsamios dokumentacijos, žmonės, prižiūrintys sistemą po penkerių metų, nesupras, kodėl slypi už konkrečių saugos ar našumo pasirinkimų, todėl ateityje atnaujinant atsiras pavojingų klaidų.
Ar "Infrastruktūra" reiškia tik debesų serverius ir duomenų bazes?
Ne, tai reiškia programinės įrangos vaidmenį. Pagrindinė autentifikavimo biblioteka, kurią naudoja tūkstančiai programų, yra "infrastruktūra", nors tai tik kodo dalis. Jei žmonės stato ant jo, tai yra infrastruktūra; Jei žmonės jį naudoja norėdami pamatyti, ar idėja veikia, tai yra eksperimentas.
Nuosprendis
Pasirinkite eksperimentinį metodą, kai tyrinėjate nežinomas rinkas arba išbandote naujas funkcijas, kuriose nesėkmės kaina yra maža. Pereikite prie infrastruktūros mąstymo, kai jūsų produktas taps kritine priklausomybe vartotojams, kurie pasikliauja jūsų paslauga, kad veiktų be trikdžių.