Uzticamības pamats: sadalītās apstrādes tipu drošības sasniegšana vispārīgajā perifērijas skaitļošanā

Skaitļošanas paradigma piedzīvo seismiskas pārmaiņas. Gadu desmitiem mākonis ir bijis datu apstrādes epicentrs — centralizēts, milzīgas jaudas behemots. Taču strauji paplašinās jauna robeža: perifērija. Perifērijas skaitļošana — prakse apstrādāt datus to rašanās vietas tuvumā, nevis attālā datu centrā — nav tikai tendence; tā ir revolūcija. Tā nodrošina mūsu viedpilsētas, autonomos transportlīdzekļus, savienotās rūpnīcas un reāllaika veselības aprūpes ierīces. Šī inteliģences sadale sola zemāku latentumu, uzlabotu privātumu un lielāku darbības noturību. Tomēr šai decentralizētajai jaudai līdzi nāk slēpts un dziļš izaicinājums: datu integritātes uzturēšana plašā, heterogēnā un bieži vien haotiskā ekosistēmā. Šī izaicinājuma pamatā ir koncepts, kas pazīstams programmatūras inženieriem, bet tagad palielināts līdz globālam mērogam: tipu drošība.

Tradicionālā, monolītā lietojumprogrammā nodrošināt, ka funkcija, kas sagaida veselu skaitli, nesaņem virkni, ir standarta, atrisināma problēma. Vispārīgās perifērijas skaitļošanas pasaulē, kur tūkstošiem vai pat miljoniem dažādu ierīču sazinās pa neuzticamiem tīkliem, vienkārša tipu neatbilstība var izraisīt katastrofālu kļūmi. Tā var sabojāt datu kopas, apturēt ražošanas līnijas vai novest pie nepareiziem kritiskiem lēmumiem. Šis raksts ir padziļināts ieskats, kāpēc sadalītās apstrādes tipu drošība nav tikai "vēlama", bet gan absolūts uzticamu, mērogojamu un vispārīgu perifērijas sistēmu pamats. Mēs izpētīsim izaicinājumus, analizēsim jaudīgas stratēģijas un izklāstīsim arhitektūras modeļus, lai savaldītu sarežģītību un veidotu noturīgu perifēriju, pa vienam pareizi tipizētam datu gabalam vienlaikus.

Perifērijas skaitļošanas revolūcija: vairāk nekā tikai attālināti serveri

Pirms mēs iedziļināmies tipu drošības sarežģītībās, ir būtiski izprast perifērijas vides unikālo dabu. Atšķirībā no mākoņa, ko raksturo salīdzinoši viendabīgi, jaudīgi un labi pārvaldīti serveri, perifērija ir daudzveidības iemiesojums. Tā aptver plašu ierīču spektru:

• Ierobežoti sensori: Mazjaudas mikrokontrolieri (MCU) rūpnieciskos apstākļos vai vides monitori, kas vāc vienkāršus datu punktus, piemēram, temperatūru vai spiedienu.
• Viedierīces: Spējīgākas ierīces, piemēram, viedkameras, kases sistēmas vai medicīnas monitori, kas var veikt lokālu analīzi un agregāciju.
• Perifērijas vārtejas: Jaudīgi skaitļošanas mezgli, kas apkopo datus no daudzām mazākām ierīcēm, veic sarežģītu apstrādi un kalpo kā saziņas tilts uz mākoni vai citām perifērijas atrašanās vietām.
• Autonomās sistēmas: Ļoti sarežģītas perifērijas sistēmas, piemēram, autonomie transportlīdzekļi vai robotu rokas, kas pieņem kritiskus reāllaika lēmumus, pamatojoties uz milzīgu sensoru datu plūsmu.

Šī sadale nav tikai par atrašanās vietu; tā ir par funkciju. Apstrāde vairs nav monolīts uzdevums, bet gan sadalīta darbplūsma. Sensors varētu iegūt neapstrādātus datus, tuvējā vārteja tos attīrīt un filtrēt, reģionālais perifērijas serveris varētu palaist mašīnmācīšanās modeli uz tiem, un mākonis varētu saņemt galīgos, apkopotos ieskatus ilgtermiņa analīzei. Šis daudzpakāpju, daudzierīču apstrādes konveijers ir vieta, kur datu bojāšanas risks pieaug eksponenciāli.

Klusais sabotieris: Kas ir tipu drošība un kāpēc tā ir svarīga perifērijā?

Savā būtībā tipu drošība ir princips, ka programma vai sistēma novērš vai ierobežo kļūdas, kas rodas no neatbilstībām starp dažādiem datu tipiem. Piemēram, tā nodrošina, ka jūs nevarat veikt matemātisku saskaitīšanu ar teksta virkni vai uzskatīt laika zīmogu par ģeogrāfisku koordinātu. Kompilējamās valodās daudzas no šīm pārbaudēm notiek kompilēšanas laikā, notverot kļūdas, pirms kods vispār tiek palaists. Dinamiski tipizētās valodās šīs kļūdas tiek notvertas izpildlaikā, potenciāli izraisot programmas avāriju.

Sadalītā perifērijas vidē šis jēdziens pārsniedz vienas programmas robežas. Runa ir par to, lai nodrošinātu, ka datu apmaiņas līgums starp diviem neatkarīgiem servisiem, kas, iespējams, ir rakstīti dažādās valodās un darbojas uz dažādas aparatūras, tiek stingri ievērots. Kad perifērijas sensors Singapūrā nosūta temperatūras rādījumu, apstrādes mezglam Frankfurtē šie dati ir jāinterpretē ne tikai kā skaitlis, bet kā 32 bitu peldošā punkta skaitlis, kas apzīmē Celsija grādus. Ja Frankfurtes mezgls sagaida 16 bitu veselu skaitli, kas apzīmē Fārenheita grādus, visas sistēmas loģika tiek kompromitēta.

Galvenais izaicinājums: heterogenitāte un perifērijas datu "mežonīgie rietumi"

Galvenais iemesls, kāpēc tipu drošība perifērijā ir tik sarežģīta, ir vides milzīgā, nepieradinātā heterogenitāte. Mēs nestrādājam viena datu centra tīrajās, labi definētajās sienās. Mēs darbojamies digitālos "mežonīgajos rietumos".

Ierīču "Kembrija eksplozija"

Perifērijas tīklus veido ierīces no neskaitāmiem ražotājiem, kas izgatavotas dažādos laikos un ar dažādiem mērķiem. Mantota rūpnieciskā kontroliera no 1990. gadiem komunikācijai var izmantot patentētu bināro protokolu, kamēr pavisam jauna mākslīgā intelekta kamera straumē datus, kas kodēti modernā formātā. Vispārīgai perifērijas sistēmai jāspēj uzņemt, saprast un apstrādāt datus no visām šīm ierīcēm, nebūvējot to pielāgoti katrai no tām. Tas prasa robustu veidu, kā definēt un ieviest datu struktūras šajā daudzveidībā.

Protokolu un valodu Bābele

Nav vienas 'perifērijas valodas'. Ierīces sazinās, izmantojot MQTT, CoAP, AMQP, HTTP un neskaitāmus citus protokolus. Programmatūra, kas uz tām darbojas, varētu būt rakstīta C, C++, Python, Rust, Go vai Java valodā. Python serviss, kas sagaida JSON objektu ar lauku `{"timestamp": "2023-10-27T10:00:00Z"}`, cietīs neveiksmi, ja C++ serviss nosūtīs laika zīmogu kā Unix epohas veselu skaitli `{"timestamp": 1698397200}`. Bez kopīgas, ieviestas izpratnes par datu tipiem visa sistēma ir kā kāršu namiņš.

Tipu neatbilstības reālās izmaksas

Šīs nav akadēmiskas problēmas. Tipu kļūdām sadalītās perifērijas sistēmās ir smagas, taustāmas sekas:

• Rūpnieciskā ražošana: Robotu roka sagaida koordinātu kā `{x: 10.5, y: 20.2, z: 5.0}`. Sistēmas atjauninājuma dēļ jauns sensors to nosūta kā virkni `"10.5, 20.2, 5.0"`. Parsēšanas kļūda liek robotam apstāties, apturot vairāku miljonu dolāru vērtu ražošanas līniju, līdz kļūda tiek atrasta un izlabota.
• Savienotā veselības aprūpe: Pacienta sirdsdarbības monitors sūta datus katru sekundi. Kļūdas dēļ tas laiku pa laikam nosūta `null` vērtību vesela skaitļa vietā. Pakārtotā brīdināšanas sistēma, kas nav paredzēta `null` apstrādei, avarē. Tiek palaists garām kritisks sirds notikuma brīdinājums, apdraudot pacienta dzīvību.
• Autonomā loģistika: Autonomo piegādes dronu flote paļaujas uz GPS datiem. Viena ražotāja drons ziņo savu augstumu metros (piem., `95.5`), bet cits to ziņo pēdās, bet izmantojot to pašu skaitlisko tipu. Agregatora serviss, pieņemot, ka visi dati ir metros, nepareizi aprēķina drona augstumu, kas noved pie gandrīz notikušas sadursmes vai avārijas.

Definējot "vispārīgo" perifērijas skaitļošanu: sadarbspējas paradigma

Risinājums šai heterogenitātei nav piespiest katru ierīci būt identiskai. Tas ir neiespējami. Risinājums ir veidot vispārīgu perifērijas skaitļošanas ietvaru. Vispārīga sistēma ir tāda, kas nav saistīta ar konkrētu aparatūru, operētājsistēmu vai programmēšanas valodu. Tā paļaujas uz labi definētām abstrakcijām un līgumiem, lai ļautu atšķirīgiem komponentiem netraucēti sadarboties.

Iedomājieties to kā standartizētu jūras konteineru. Pirms tā izgudrošanas kuģa iekraušana bija haotisks, individuāls process katram kravas veidam. Konteiners standartizēja saskarni (formu un savienojuma punktus), paliekot agnostisks pret saturu (kas ir iekšā). Vispārīgajā perifērijas skaitļošanā tipu drošība nodrošina šo standartizēto saskarni datiem. Tā nodrošina, ka neatkarīgi no tā, kura ierīce rada datus vai kurš serviss tos patērē, šo datu struktūra un nozīme ir nepārprotama un uzticama.

Pamatstratēģijas tipu drošības ieviešanai visā perifērijā

Šāda uzticamības līmeņa sasniegšanai nepieciešama daudzslāņu pieeja. Runa nav par vienas maģiskas lodes atrašanu, bet gan par vairāku jaudīgu stratēģiju apvienošanu, lai izveidotu dziļu aizsardzību pret datu bojājumiem.

1. stratēģija: Shēmas prioritizēšana ar datu serializācijas formātiem

Visbūtiskākā stratēģija ir skaidri definēt savu datu struktūru. Tā vietā, lai vienkārši sūtītu brīvus JSON vai binārus blokus, jūs izmantojat shēmu, lai izveidotu formālu līgumu. Šī shēma darbojas kā vienots patiesības avots tam, kādam jāizskatās datu gabalam.

Vadošās tehnoloģijas šajā jomā ietver:

• Protocol Buffers (Protobuf): Google izstrādāts, Protobuf ir no valodas neatkarīgs, no platformas neatkarīgs mehānisms strukturētu datu serializēšanai. Jūs definējat savu datu struktūru vienkāršā `.proto` failā, un Protobuf kompilators ģenerē pirmkodu jūsu izvēlētajai valodai(-ām), lai viegli rakstītu un lasītu jūsu strukturētos datus. Tas nodrošina kompilēšanas laika drošību un ļoti efektīvu bināro serializāciju, kas ir ideāli piemērota perifērijas ierīcēm ar ierobežotiem resursiem.
• Apache Avro: Avro ir vēl viena jaudīga datu serializācijas sistēma. Galvenā iezīme ir tā, ka shēma tiek glabāta kopā ar datiem (bieži vien galvenē), kas ir lieliski piemērots shēmu attīstībai laika gaitā un tādām sistēmām kā datu ezeri un straumēšanas platformas, kur var pastāvēt dati no dažādām shēmu versijām.
• JSON Schema: Sistēmām, kas lielā mērā paļaujas uz JSON, JSON Schema nodrošina vārdnīcu JSON dokumentu anotēšanai un validēšanai. Tas ir mazāk veiktspējīgs nekā binārie formāti, piemēram, Protobuf, bet ir ļoti cilvēklasāms un darbojas ar jebkuru standarta JSON bibliotēku.

Piemērs: Protocol Buffers izmantošana sensoru datiem

Iedomājieties, ka mēs vēlamies definēt struktūru standarta vides sensora rādījumam. Mēs izveidotu failu ar nosaukumu `sensor.proto`:

(Piezīme: Šis ir piemērs, nevis izpildāms kods šajā kontekstā)

syntax = "proto3"; package edge.monitoring; message SensorReading { string device_id = 1; int64 timestamp_unix_ms = 2; // Unix epoha milisekundēs float temperature_celsius = 3; float humidity_percent = 4; optional int32 signal_strength_dbm = 5; }

No šī vienkāršā faila mēs varam ģenerēt C++ kodu mūsu sensora programmaparatūrai, Python kodu mūsu vārtejas apstrādes skriptam un Go kodu mūsu mākoņa datu saņemšanas servisam. Katrai ģenerētajai klasei būs stingri tipizēti lauki. Kļūst programmatiski neiespējami ievietot virkni `timestamp_unix_ms` laukā. Tas notver kļūdas kompilēšanas laikā, ilgi pirms kods tiek izvietots tūkstošiem ierīču.

2. stratēģija: Tipu droša komunikācija ar gRPC

Datu struktūras definēšana ir puse no cīņas. Otra puse ir nodrošināt, ka komunikācijas kanāls ievēro šīs definīcijas. Šeit izceļas tādi ietvari kā gRPC (gRPC Remote Procedure Call). Arī gRPC ir izstrādājis Google, un tas pēc noklusējuma izmanto Protocol Buffers, lai definētu servisu līgumus un ziņojumu formātus.

Ar gRPC jūs definējat ne tikai ziņojumus ('kas'), bet arī servisus un to metodes ('kā'). Tas izveido stingri tipizētu klienta un servera koda sagatavi (stub). Kad klients izsauc attālinātu metodi, gRPC nodrošina, ka pieprasījuma ziņojums atbilst nepieciešamajam tipam, un serializē to. Serveris to pēc tam deserializē un garantēti saņem pareizi tipizētu objektu. Tas abstrahē sarežģītās tīkla komunikācijas un serializācijas detaļas, nodrošinot sajūtu, ka tiek veikts lokāls, tipu drošs funkcijas izsaukums.

3. stratēģija: Līgumbalstīta API izstrāde

Perifērijas servisiem, kas sazinās, izmantojot RESTful API ar HTTP un JSON, OpenAPI Specification (agrāk Swagger) ir nozares standarts. Līdzīgi kā Protobuf, jūs definējat līgumu (YAML vai JSON failā), kas norāda katru galapunktu, sagaidāmos pieprasījuma parametrus un to tipus, kā arī atbildes ķermeņu struktūru. Šo līgumu var izmantot, lai ģenerētu klientu SDK, servera koda sagataves un validācijas starpprogrammatūru, nodrošinot, ka visa HTTP komunikācija atbilst norādītajiem tipiem.

4. stratēģija: Statiski tipizētu valodu spēks

Lai gan shēmas un līgumi nodrošina drošības tīklu, programmēšanas valodas izvēlei ir būtiska loma. Statiski tipizētas valodas, piemēram, Rust, Go, C++, Java vai TypeScript, liek izstrādātājiem deklarēt mainīgo datu tipus. Pēc tam kompilators pārbauda tipu konsekvenci visā koda bāzē. Šī ir jaudīga, proaktīva pieeja, lai novērstu veselu kļūdu klasi, pirms tās rodas.

Īpaši Rust gūst popularitāti perifērijas un IoT jomā, pateicoties tā veiktspējai, atmiņas drošībai un spēcīgajai tipu sistēmai, kas palīdz veidot neticami robustas un uzticamas lietojumprogrammas vidēm ar ierobežotiem resursiem.

5. stratēģija: Spēcīga izpildlaika validācija un sanitizācija

Pat ar visām kompilēšanas laika pārbaudēm pasaulē, jūs ne vienmēr varat uzticēties datiem, kas nāk no ārpasaules. Nepareizi konfigurēta ierīce vai ļaunprātīgs dalībnieks varētu nosūtīt nepareizi formatētus datus. Tāpēc katram perifērijas servisam vajadzētu uzskatīt savus ievades datus par neuzticamiem. Tas nozīmē ieviest validācijas slāni jūsu servisa robežā, kas skaidri pārbauda ienākošos datus pret to sagaidāmo shēmu, pirms tos apstrādā. Tā ir jūsu pēdējā aizsardzības līnija. Ja dati neatbilst — ja trūkst obligāts lauks vai vesels skaitlis ir ārpus sagaidāmā diapazona — tie ir jānoraida, jāreģistrē un jānosūta uz "mirušo vēstuļu" rindu analīzei, nevis jāļauj tiem sabojāt sistēmu.

Arhitektūras modeļi tipu drošai perifērijas ekosistēmai

Šo stratēģiju ieviešana nav saistīta tikai ar rīkiem; tā ir saistīta ar arhitektūru. Noteikti modeļi var dramatiski uzlabot tipu drošību sadalītā sistēmā.

Centrālais shēmu reģistrs: vienots patiesības avots

Liela mēroga perifērijas izvietošanā shēmas var savairoties. Lai izvairītos no haosa, Shēmu reģistrs ir būtisks. Tas ir centralizēts serviss, kas darbojas kā galvenā krātuve visām datu shēmām (vai tās būtu Protobuf, Avro vai JSON Schema). Servisi neglabā shēmas lokāli; tie tās iegūst no reģistra. Tas nodrošina, ka katrs sistēmas komponents izmanto to pašu līguma versiju. Tas arī nodrošina jaudīgas shēmu evolūcijas iespējas, ļaujot jums atjaunināt datu struktūras atpakaļ- vai uz priekšu saderīgā veidā, nesalaužot visu sistēmu.

Perifērijas servisu tīkls: politikas ieviešana tīkla līmenī

Servisu tīkls (piemēram, Linkerd vai Istio, vai vieglākas alternatīvas, kas paredzētas perifērijai) var daļu validācijas loģikas novirzīt no pašas lietojumprogrammas. Servisu tīkla starpniekserveris (proxy), kas atrodas blakus jūsu lietojumprogrammai, var tikt konfigurēts, lai pārbaudītu trafiku un validētu ziņojumus pret zināmu shēmu. Tas ievieš tipu drošību tīkla līmenī, nodrošinot konsekventu aizsardzības slāni visiem servisiem tīklā, neatkarīgi no valodas, kurā tie ir rakstīti.

Nemainīgs datu konveijers: stāvokļa bojāšanas novēršana

Viens izplatīts ar tipiem saistītu kļūdu avots ir stāvokļa mainīšana laika gaitā. Objekts sākumā ir derīgā stāvoklī, bet virkne operāciju to pārveido par nederīgu. Pieņemot nemainīguma (immutability) modeli — kur dati, kad tie ir izveidoti, nevar tikt mainīti — jūs varat novērst šīs kļūdas. Datu modificēšanas vietā jūs izveidojat jaunu kopiju ar atjauninātām vērtībām. Šis funkcionālās programmēšanas koncepts vienkāršo spriešanu par datu plūsmu un nodrošina, ka datu gabals, kas bija derīgs vienā konveijera punktā, paliek derīgs visā tā dzīves ciklā.

Praktisks gadījuma pētījums: globāls viedās lauksaimniecības tīkls

Pamatosim šos jēdzienus ar reālistisku, globālu scenāriju.

Scenārijs

Daudznacionāls agrobiznesa uzņēmums 'AgriGlobal' vēlas izveidot vienotu 'viedās fermas' platformu. Viņi pārvalda fermas Ziemeļamerikā, Dienvidamerikā un Eiropā. Viņu aparatūra ir mantotu apūdeņošanas kontrolieru sajaukums, kas izvada CSV datus pa seriālo portu, moderni augsnes mitruma sensori no Eiropas piegādātāja, kas izmanto JSON pār MQTT, un jauna autonomo dronu flote no Āzijas ražotāja, kas straumē binārus video plūsmas un GPS datus. Mērķis ir savākt visus šos datus reģionālajās perifērijas vārtejās, apstrādāt tos reāllaikā, lai pieņemtu lēmumus (piem., pielāgotu apūdeņošanu), un nosūtīt apkopotus ieskatus uz centrālo mākoņa platformu mākslīgā intelekta nodrošinātai ražas prognozēšanai.

Īstenošana

AgriGlobal arhitekti nolēma nerakstīt pielāgotus parsētājus katrai ierīcei. Tā vietā viņi pieņēma vispārīgu, uz shēmām balstītu arhitektūru:

1. Centrālais shēmu reģistrs: Viņi izveidoja centrālu Avro shēmu reģistru. Viņi definēja shēmas galvenajiem jēdzieniem, piemēram, `SoilMoistureReading`, `GpsCoordinate` un `IrrigationStatus`.
2. Adapteru servisi: Katram ierīces veidam viņi uzrakstīja nelielu 'adaptera' servisu, kas darbojas uz perifērijas vārtejas. Mantotā kontroliera adapters nolasa seriālos CSV datus un pārveido tos par derīgu `IrrigationStatus` Avro objektu. Sensoru adapters saņem JSON MQTT ziņojumus un pārvērš tos par `SoilMoistureReading` Avro objektiem. Katrs adapters ir atbildīgs tikai par vienu lietu: konkrētas ierīces neapstrādāto datu pārvēršanu kanoniskajā, stingri tipizētajā formātā, kas definēts shēmu reģistrā.
3. Tipu drošs apstrādes konveijers: Pakārtotajiem apstrādes servisiem, kas rakstīti Go valodā, nav jāzina par CSV vai JSON. Tie patērē tikai tīros, validētos Avro datus no ziņojumu kopnes, piemēram, Kafka vai NATS. To biznesa loģika ir vienkāršota, un tie ir pilnībā atsaistīti no fiziskās aparatūras.

Rezultāti

Sākotnējās investīcijas uz shēmām balstītā arhitektūrā atmaksājās ar uzviju:

• Ātra integrācija: Kad viņi iegādājās jaunu fermu ar cita zīmola meteoroloģisko staciju, viņiem bija jāuzraksta tikai jauns, neliels adaptera serviss. Galvenais apstrādes konveijers palika nemainīgs. Jaunas aparatūras integrācijas laiks samazinājās no mēnešiem līdz dienām.
• Uzlabota uzticamība: Ar datiem saistīto apstrādes kļūmju skaits samazinājās par vairāk nekā 90%. Kļūdas tika notvertas perifērijā ar adapteriem, kas atzīmēja nepareizi formatētus datus no bojāta sensora, pirms tie varēja saindēt centrālos analītikas modeļus.
• Nākotnes nodrošinājums: Sistēma tagad ir vispārīga. Tā ir veidota ap abstraktiem datu tipiem, nevis konkrētu aparatūru. Tas ļauj AgriGlobal ātrāk ieviest inovācijas, pieņemot labākās tehnoloģijas no jebkura piegādātāja, nepārveidojot visu savu datu platformu.

Nākotnes horizonts: Kas tālāk sagaida tipu drošību perifērijā?

Robustas tipu drošības meklējumi ir nepārtraukts ceļojums, un vairākas aizraujošas tehnoloģijas ir gatavas pacelt latiņu vēl augstāk.

WebAssembly (Wasm): universāla tipu droša izpildlaika vide

WebAssembly ir bināro instrukciju formāts stek-bāzētai virtuālajai mašīnai. Tas ļauj kodam, kas rakstīts tādās valodās kā Rust, C++ un Go, darboties izolētā vidē (sandbox) jebkur — arī perifērijas ierīcēs. Wasm ir labi definēts un stingri tipizēts atmiņas modelis. Tas padara to par pārliecinošu mērķi drošu, pārnēsājamu un tipu drošu funkciju izvietošanai perifērijā, radot universālu izpildlaika vidi, kas var abstrahēt pamatā esošo aparatūru un OS.

Mākslīgā intelekta nodrošināta datu tipu anomāliju atklāšana

Nākotnes sistēmas varētu izmantot mašīnmācīšanās modeļus, lai iemācītos normālu datu plūsmu 'formu'. Šie modeļi varētu atklāt ne tikai acīmredzamas tipu kļūdas (piem., virkne int vietā), bet arī smalkas semantiskas anomālijas (piem., temperatūras rādījums, kas tehniski ir derīgs float, bet ir fiziski neiespējams savai atrašanās vietai). Tas pievieno inteliģentas, kontekstuālas validācijas slāni.

Formālā verifikācija un pierādāmi pareizas sistēmas

Vis kritiskākajām perifērijas sistēmām (piemēram, kosmosa vai medicīnas ierīcēm) mēs varam redzēt formālās verifikācijas pieaugumu. Tā ir matemātiska pieeja, lai pierādītu, ka programmatūra ir brīva no noteiktām kļūdu klasēm, ieskaitot tipu kļūdas. Lai gan sarežģīta un resursietilpīga, tā piedāvā visaugstāko iespējamo pareizības garantiju.

Noslēgums: Izturīgas perifērijas veidošana, pa vienam tipam vienlaikus

Globālā pāreja uz perifērijas skaitļošanu ir neapturama. Tā atver bezprecedenta iespējas un efektivitāti visās nozarēs. Bet šī sadalītā nākotne var būt vai nu trausla un haotiska, vai robusta un uzticama. Atšķirība slēpjas stingrībā, ko mēs piemērojam tās pamatiem.

Sadalītās apstrādes tipu drošība nav funkcija; tas ir priekšnoteikums. Tā ir disciplīna, kas ļauj mums veidot vispārīgas, sadarbspējīgas sistēmas, kas var attīstīties un mērogoties. Pieņemot shēmas prioritizēšanas domāšanas veidu, izmantojot tipu drošus rīkus un protokolus un projektējot noturīgus arhitektūras modeļus, mēs varam pārsniegt individuālu ierīču pielāgotu risinājumu veidošanu. Mēs varam sākt veidot patiesi globālu, vispārīgu un uzticamu perifēriju — ekosistēmu, kurā dati plūst uzticami, lēmumi tiek pieņemti ar pārliecību un sadalītās inteliģences milzīgais solījums tiek pilnībā realizēts.