programmatūras inženierijaDevOpssistēmas arhitektūraTehnoloģija
Programmatūra kā eksperiments vs programmatūra kā infrastruktūra
Šis salīdzinājums pēta divas kontrastējošas programmatūras inženierijas filozofijas: ātra, iteratīva eksperimentālā koda pieeja salīdzinājumā ar infrastruktūras programmatūras stabilo, misijai kritisko raksturu. Kamēr viens koncentrējas uz ātrumu un atklāšanu, otrs prioritāti piešķir uzticamībai un ilgtermiņa uzturēšanai būtiskiem digitālajiem pakalpojumiem un globālajām sistēmām.
Iezīmes
Eksperimentālais kods koncentrējas uz koncepcijas esamības pierādīšanu, bet infrastruktūras kods pierāda, ka tas var izdzīvot.
Infrastruktūrai ir nepieciešama stingra "sprādziena rādiusa" plānošana, lai novērstu kaskādes sistēmas kļūmes.
Pārmaiņu izmaksas ir apzināti zemas eksperimentos un apzināti augstas infrastruktūrā.
Eksperimenta panākumi ir jauna atziņa; Infrastruktūras panākumi ir klusa, garlaicīga darbība.
Kas ir Programmatūra kā eksperiments?
Kods, kas paredzēts ātrai mācīšanai, prototipu izstrādei un hipotēžu testēšanai strauji mainīgā vidē.
Prioritāte ir piegādes ātrums, nevis ilgtermiņa arhitektūras pilnība.
Parasti izmanto starta vidē, lai atrastu produkta atbilstību tirgum.
Izmanto "ātras neveiksmes" mentalitāti, lai samazinātu izšķērdētos izstrādes resursus.
Bieži paļaujas uz tehnisko parādu kā aprēķinātu kompromisu ienākšanai tirgū.
Parasti tam ir īsāks dzīves cikls, kas bieži tiek izmests, kad mācība ir apgūta.
Kas ir Programmatūra kā infrastruktūra?
Pamatkods, kas izstrādāts augstai pieejamībai, drošībai un konsekventai ilgtermiņa veiktspējai.
Izstrādāts, lai izturētu milzīgu mērogu un vienlaicīgas lietotāju slodzes.
Koncentrējas uz atpakaļsaderību, lai novērstu lejupejošo atkarību pārtraukšanu.
Nepieciešama plaša dokumentācija un stingri automatizēti testēšanas protokoli.
Izstrādāts ar dzīves ciklu, kas ilgst gadu desmitus, nevis mēnešus vai gadus.
Pamatā ir tādi būtiski pakalpojumi kā bankas, energotīkli un mākoņplatformas.
Salīdzinājuma tabula
Funkcija
Programmatūra kā eksperiments
Programmatūra kā infrastruktūra
Primārais mērķis
Mācīšanās un atklāšana
Stabilitāte un uzticamība
Pielaide neveiksmei
Augsts (veicināts izaugsmei)
Zems (gaidāms nulles dīkstāves laiks)
Attīstības ātrums
Ātras iterācijas
Metodisks un apzināts
Tehniskais parāds
Pieņemts un gaidāms
Aktīvi minimizēts un pārvaldīts
Dokumentācija
Minimāls vai tieši laikā
Visaptverošs un izsmeļošs
Testēšanas stingrība
Koncentrējieties uz pamatfunkcionalitāti
Robežgadījumi un stresa testēšana
Izmaksu fokuss
Zems sākotnējais ieguldījums
Koncentrējieties uz kopējām lietošanas izmaksām
Mērogojamība
Bieži vien pēcdoma
Iebūvēts no pirmās dienas
Detalizēts salīdzinājums
Riska pārvaldība un uzticamība
Eksperimentālā programmatūra uztver kļūdas kā mācību iespējas, bieži darbojoties vidē, kur avārija ietekmē dažus cilvēkus. Infrastruktūras programmatūra tomēr uztver dīkstāvi kā katastrofālu notikumu, kas prasa aizsardzības programmēšanu un liekas sistēmas. Atšķirība ir tajā, vai kodam ir atļauts lauzt lietas, lai ātri kustētos, vai arī tam jāpaliek nesalauztam, lai pasaule kustētos.
Ilgmūžība un uzturēšana
Eksperiments bieži vien ir pagaidu tilts uz atbildi, kas bieži tiek pārrakstīts vai atcelts, tiklīdz mērķis ir sasniegts. Infrastruktūras kods tiek veidots kā pastāvīgs aprīkojums, kas prasa rūpīgu atjauninājumu plānošanu, kas var ilgt piecus līdz desmit gadus. Infrastruktūras izstrādātājiem ir jādomā par to, kā viņu kods izskatīsies uzturētājam 2035. gadā, bet eksperimentālisti koncentrējas uz nākamo nedēļu.
Ietekme uz inženierzinātņu kultūru
Komandas, kas veido eksperimentālu programmatūru, plaukst radošums, intensīvas darbplūsmas un augstas enerģijas sprinti. Infrastruktūras komandas novērtē disciplīnu, dziļus arhitektūras pārskatus un lepnumu par to, ka būvē kaut ko tādu, kas nekad neizdodas. Šie atšķirīgie domāšanas veidi bieži noved pie dažādiem darbā pieņemšanas profiliem, "hakeriem" dodot priekšroku pirmajam un "sistēmu inženieriem" pievēršoties otrajam.
Ekonomiskie virzītājspēki
Eksperimentālo programmatūru parasti finansē nepieciešamība iegūt tirgu vai ātri apstiprināt nišu. Infrastruktūra ir ieguldījums fondā, kur kļūdas izmaksas var radīt milzīgas finansiālas vai juridiskas saistības. Viens ir agresīva izaugsmes spēle, bet otrs ir esošās vērtības un darbības nepārtrauktības aizsardzības pasākums.
Priekšrocības un trūkumi
Programmatūra kā eksperiments
Iepriekšējumi
+Ārkārtīgi ātra atgriezeniskā saite
+Zemas sākotnējās izmaksas
+Veicina inovācijas
+Augsta elastība
Ievietots
−Trausla kodu bāze
−Uzkrāj tehnisko parādu
−Slikta mērogojamība
−Neuzticams lietotājiem
Programmatūra kā infrastruktūra
Iepriekšējumi
+Izcila uzticamība
+Augsti drošības standarti
+Skaidra dokumentācija
+Milzīga mēroga jauda
Ievietots
−Lēni attīstības cikli
−Augstas inženiertehniskās izmaksas
−Izturīgs pret pārmaiņām
−Kompleksa apkope
Biežas maldības
Mīts
Eksperimentālā programmatūra ir tikai "slikts" kods, ko rakstījuši slinki izstrādātāji.
Realitāte
Tīšs eksperimentālais kods ir stratēģiska izvēle, lai noteiktu prioritāti mācīšanās. Tas ir "piemērots mērķim", ja mērķis ir validācija, lai gan tas kļūst problemātisks, ja tas galu galā netiek pārveidots vai aizstāts.
Mīts
Infrastruktūras programmatūra nekad nemainās un neattīstās.
Realitāte
Infrastruktūrai ir jāattīstās, bet tā to dara ļoti piesardzīgi. Izmaiņas tiek īstenotas, izmantojot zilzaļos izvietojumus vai kanāriju izlaidumus, lai nodrošinātu, ka pārejas laikā pamats paliek stabils.
Mīts
Vēlāk eksperimentu var viegli pārvērst infrastruktūrā.
Realitāte
Tas ir izplatīts slazds, kas noved pie "spageti" sistēmām. Patiesa infrastruktūra parasti prasa pilnīgu arhitektūras pārdomāšanu, jo eksperimenta pamatpieņēmumi reti ir mērogojami.
Mīts
Tikai jaunuzņēmumi veic eksperimentālu programmatūru.
Realitāte
Pat milzīgi tehnoloģiju uzņēmumi izmanto eksperimentālas filiāles vai "laboratorijas", lai pārbaudītu funkcijas. Galvenais ir izolēt šos eksperimentus, lai tie neapdraudētu pamatinfrastruktūru, no kuras ir atkarīgi lietotāji.
Bieži uzdotie jautājumi
Kad lietotne ir jāpārtrauc uzskatīt par eksperimentu?
Pārejai vajadzētu notikt brīdī, kad jūsu programmatūra pāriet no "patīkami būt" uz "kritisku" jūsu lietotājiem. Ja 15 minūšu pārtraukums rada ievērojamus finansiālus zaudējumus vai lietotāju pārtraukšanu, jūs esat pārcēlies uz infrastruktūras sfēru un attiecīgi jāpielāgo testēšanas un izvietošanas stingrība.
Vai infrastruktūras programmatūra izmanto dažādas programmēšanas valodas?
Lai gan abām valodām var izmantot jebkuru valodu, infrastruktūra bieži vien sliecas uz kompilētām valodām ar spēcīgu rakstīšanu, piemēram, Go, Rust vai C++, lai nodrošinātu veiktspēju un drošību. Eksperimentālā programmatūra bieži izmanto elastīgas, augsta līmeņa valodas, piemēram, Python vai Ruby, kas ļauj ātrāk izstrādāt prototipus un vieglāk mainīt sintaksi.
Vai tehniskais parāds eksperimentālajā programmatūrā vienmēr ir slikts?
Ne obligāti. Eksperimentā, tehniskais parāds ir kā augstu procentu aizdevums, kas palīdz jums iegādāties māju ātrāk. Tas kļūst par "sliktu" parādu tikai tad, ja jūs to nekad neatmaksājat vai ja mēģināt uzbūvēt debesskrāpi (infrastruktūru) virs šī pagaidu pamata.
Kā atšķiras testēšanas stratēģijas?
Eksperimentos galvenā uzmanība tiek pievērsta "laimīgā ceļa" testēšanai, pārbaudot, vai galvenā funkcija darbojas vidusmēra lietotājam. Infrastruktūras testēšana ir apsēsta ar "Edge Cases" un "Haos Engineering", kur izstrādātāji apzināti salauž sistēmas daļas, lai redzētu, vai pārējās var izdzīvot šoku.
Vai viens uzņēmums var apstrādāt abas pieejas vienlaicīgi?
Jā, un visveiksmīgākie to dara. Viņi bieži izmanto "bimodālo IT" stratēģiju, kurā viena komanda uztur pamata, stabilas sistēmas (infrastruktūra), bet cita veikla komanda pēta jaunas robežas (eksperiments). Izaicinājums ir pārvaldīt nodošanu starp šīm divām kultūrām.
Kāds ir lielākais risks palikt "eksperimenta" fāzē pārāk ilgi?
Lielākais risks ir "sistēmiskā nestabilitāte". Pievienojot vairāk funkciju brīvi veidotam eksperimentam, sarežģītība pieaug eksponenciāli. Galu galā sistēma kļūst tik trausla, ka, veicot vienu nelielu izmaiņu, nesaistītās daļas sabojājas, efektīvi apturot visas nākotnes inovācijas.
Kāpēc dokumentācija ir tik daudz kritiskāka infrastruktūrai?
Infrastruktūra ir kopīgs resurss, kas pārdzīvo tās sākotnējos radītājus. Bez padziļinātas dokumentācijas cilvēki, kas uztur sistēmu pēc pieciem gadiem, nesapratīs, kāpēc slēpjas aiz konkrētām drošības vai veiktspējas izvēlēm, izraisot bīstamas kļūdas turpmāko atjauninājumu laikā.
Vai "Infrastruktūra" attiecas tikai uz mākoņserveriem un datu bāzēm?
Nē, tas attiecas uz programmatūras lomu. Galvenā autentifikācijas bibliotēka, ko izmanto tūkstošiem lietotņu, ir "infrastruktūra", lai gan tā ir tikai koda daļa. Ja cilvēki būvē uz tā, tā ir infrastruktūra; Ja cilvēki to vienkārši izmanto, lai redzētu, vai ideja darbojas, tas ir eksperiments.
Spriedums
Izvēlieties eksperimentālo pieeju, kad pētāt nezināmus tirgus vai testējat jaunas funkcijas, kur neveiksmes izmaksas ir zemas. Pārejiet uz infrastruktūras domāšanu, kad jūsu produkts kļūst par kritisku atkarību lietotājiem, kuri paļaujas uz jūsu pakalpojuma darbību bez pārtraukumiem.