Edge databehandling er fortsatt en voksende og spennende ny arkitektur for bedrifter på tvers av flere bransjer. Distribuering av datakraft over et desentralisert nettverk gir nye muligheter for AI- og IoT-baserte applikasjoner. Etterspørselen er slik at edge computing fortsatt er en voksende og spennende ny arkitektur for bedrifter på tvers av flere bransjer. Distribuering av datakraft over et desentralisert nettverk gir nye muligheter for AI- og IoT-baserte applikasjoner. Etterspørselen er slik Gartner spår innen 2025 vil 75 % av bedriftsgenererte data bli opprettet og behandlet på kanten.
Imidlertid er kostnadene og ventetiden for å sende alle disse dataene tilbake til skyen for behandling betydelige. For å beholde lønnsomheten, må bedrifter holde så mye data på kanten som mulig, samtidig som de flytter behandlingen til kanten. Fordelene med disse kravene er mange, inkludert:
- Sanntidsbehandling, lavere ventetid, raskere svar
- Spenst og tilgjengelighet, uten å stole på en stabil forbindelse til skyen
- Mer ressurs- og kostnadseffektivt, mindre datafrakt
Jeg tror organisasjoner oppnår disse kravene og realiserer disse fordelene via et konsept jeg kaller sky-til-kant-dataplanet.
Et sky-til-kant-dataplan forener sky og kant til én enkelt løsning som lar deg definere dataene og forretningslogikken én gang, pakke den sammen som en tjeneste og ganske enkelt distribuere den uten å måtte bekymre deg om den skal kjøres i skyen eller ut på kanten (som kan endre seg over tid). Dette frigjør dataplanet automatisk og adaptivt for å flytte rundt på tjenester, optimaliserer datatilgang, koordinering og replikering, og sikrer fysisk samlokalisering av data, databehandling og bruker for lavest mulig ventetid med høyest gjennomstrømning og tilgjengelighet.
Å velge mellom sky og kant er ikke en binær, svart-hvitt avgjørelse, men har mange nyanser av grått i mellom. Fra et arkitektonisk perspektiv består kanten av mange hierarkiske lag mellom skyen og enhetene; hvert lag er lenger unna skyen, men nærmere sluttbrukerne – et kontinuum.
Hvor du trenger tjenestene dine for å kjøre i dette kontinuumet er veldig mye avhengig av brukstilfeller og kan endres i løpet av levetiden til en applikasjon, avhengig av bruksmønstre eller endringer i funksjoner og forretningskrav. Kritiske parametere som latens, gjennomstrømning, konsistens, tilgjengelighet, skalerbarhet, dataressurser osv. endres drastisk etter hvert som du beveger deg gjennom dette kontinuumet. Dette resulterer i både nye muligheter og utfordringer:
En av de nye tjenestene som er muliggjort av denne arkitekturen, er gjennomsiktige tjenester for mobil plassering. Denne nye klassen av tjenester er en ting av skjønnhet. Det betyr at tjenester er gratis å kjøre hvor som helst og samarbeide med andre tjenester uten begrensninger. Den lar også den underliggende plattformen optimalisere den generelle systematferden ved å flytte tjenester etter behov, basert på endringer i bruk, tilgjengelige ressurser, kommunikasjonsmønstre, feilscenarier og mer.
Hvis tjenester ikke er plasseringsgjennomsiktige, må systemets kjøretidstopologi være en del av designet og kodet inn i selve tjenestene. I praksis betyr dette hardkodingsbeslutninger som:
- Hvis kommunikasjonen mellom tjenestene er lokal eller distribuert – tillater samtidighet eller distribusjon
- Hvis tjenester skal betraktes som stasjonære eller mobile — festet til en spesifikk fysisk adresse eller gratis å flyttes
- Hvordan tjenestene kan reagere på svikt – selvhelbredende skott som kan migreres til andre noder om nødvendig eller bindes i hoften med den mislykkede noden
Å låse inn beslutninger som dette på forhånd vil gjøre systemet vanskeligere å kjøre effektivt, utvikle seg, tilpasse og vedlikeholde over tid. Disse bør ikke være design- eller utviklingsbeslutninger, ikke distribusjonsbeslutninger, men kjøretidsbeslutninger, som ikke påvirker koden.
Det er vanskelig å spå fremtiden. Dette inkluderer å vite hvordan en applikasjon vil bli brukt over tid, hvordan endringer i bruks- og belastningsmønstre vil utvikle seg, og hvordan fremtidige funksjoner eller endringer i forretningskrav vil påvirke den opprinnelige utformingen, forutsetningene og kjøretids-/driftsegenskaper.
Å ikke måtte ta disse avgjørelsene eller bekymre deg for hvordan de skal vedlikeholdes effektivt, men kun fokusere på API, datamodell og forretningslogikk reduserer tiden til markedet og den totale risikoen betraktelig.
Her er min visjon for data…
Data eksisterer alltid hvor og når det er nødvendig, men bare for den tiden det er nødvendig.
- Å ha de nyeste og korrekte dataene alltid tilgjengelig for deg akkurat når du trenger det og uansett hvor du befinner deg – i den sentrale skyen eller i ytterkanten – høres ut som en utviklers drøm.
- På den annen side har det blitt sagt at «latskap er en dyd», noe som i høy grad gjelder databehandling i et distribuert system. Å replikere data til steder der det aldri vil være nødvendig er et tap (med mindre det er nødvendig for motstandskraft/failover). Det samme gjelder for å holde på data lenger enn nødvendig (holde ressurser som gisler og tvinge fram unødvendige konsistensmekanismer).
- Å balansere dette er veldig vanskelig og bør ideelt sett gjøres av plattformen adaptivt ved kjøretid på globalt systemnivå, i stedet for av utvikleren.
Data er alltid samlokalisert med prosessering og sluttbruker – noe som sikrer ultralav ventetid, høy gjennomstrømning og robusthet.
- Hvis ikke, som i tradisjonell tre-lags statsløs arkitektur, er data ofte et annet sted enn der du trenger det og må derfor hentes før de brukes og skyves ut til lagring etter modifikasjon. Dette øker ventetiden, reduserer gjennomstrømning og setter tjenesten på nåde av tilgjengeligheten til lagringstjenesten.
Data og databehandling beveger seg adaptivt sammen med sluttbrukeren.
- Mange brukssaker på kanten tjener brukere på farten (f.eks. mobiltelefoner, biler). For å betjene disse brukerne så effektivt som mulig, må dataene og datamaskinen deres flyttes geografisk med dem.
Data injiseres i tjenestene etter behov – automatisk, rettidig, effektivt og intelligent.
- Datalagringsadministrasjon er ofte svært påtrengende i applikasjonsdesign og forretningslogikk: Hvordan kartlegge domeneobjekter til DB-tabeller (OR-mapping), transaksjonsadministrasjon, lagrings-API-kall for henting og oppdatering av tilstanden, etc.
- Å eksternalisere alt dette til plattformen og i stedet få dataene injisert i tjenesten når nye data er tilgjengelige (akkurat som vi er vant til med arrangementer i et pub/subsystem) gjør koden lettere å designe, skrive, forstå og vedlikeholde.
- I tillegg, hvis tjenesten utfører all databehandling selv, er det en svart boks for plattformen. Plattformen har ingen anelse om hvilke tilgangsmønstre som har blitt brukt, på hvilke data, når data trygt kan bufres, replikeres, skjæres, forhåndshentes, deles osv. Tvert imot, hvis plattformen utfører all databehandling, så kan den se bredt på tvers av alle tjenester og optimalisere dataadministrasjonen for det totale systemet på en trygg måte.
Jeg tror RedMonk-analytiker Steve O’Gradys konsept for vertikal integrasjon passer godt inn i denne fortellingen. Det hele fører til det jeg føler er en destillasjon av en sky-til-kant programmeringsmodell (et kontinuum, som beskrevet tidligere). Denne modellen handler om å abstrahere bort alt som ikke er kjernevirksomhetsverdi, og etterlate de tre tingene som aldri kan delegeres: Datamodell, API og forretningslogikk.
Som Timothy Keller sa, “Frihet er ikke så mye fravær av restriksjoner som å finne de rette, de frigjørende restriksjonene.”
Ved å bruke en serverløs utvikleropplevelse (DX), tror jeg at svaret på å utvide sanntidsdata og databehandling til kanten kan realiseres i en fullstendig administrert utvikler PaaS-modell. Denne modellen abstraherer all infrastruktur til en enkelt deklarativ programmeringsmodell og forener effektivt skybasert og edge-native utvikling. Dette er “vertikal integrasjon” og sky-til-kant-dataplanvisjonen.
Konklusjon
I dag blir cloud computing og edge computing vanligvis behandlet som separate domener. Imidlertid skaper raskt voksende krav til intelligent lav-latensbehandling av kantgenererte data krav til en ny tilnærming som kombinerer sky og edge til ett enkelt kontinuum. Med skybaserte applikasjoner har arkitekter og utviklere allerede omfavnet konseptene som kreves for å bygge tjenester som kjører i en i hovedsak uendelig skalerbar (men logisk sentralisert) skyinfrastruktur. Å utvide denne tenkningen til en fullstendig desentralisert infrastruktur, inkludert kanten, er et naturlig neste skritt i bedriftsapplikasjonsarkitekturen. Programmeringsmodeller som muliggjør en datasentrisk, plasseringstransparent tilnærming kombinert med intelligente kjøretider som automatisk gjør det mulig å samlokalisere data og prosessering der og når det er nødvendig, vil tillate utviklere å dra full nytte av et slikt fullstendig distribuert kant-til-sky-miljø .