Sky, mikrotjenester og datarot? Graf, ontologi og applikasjonsstoff til unnsetning.

0
149

George Anadiotis

Av George Anadiotis for Big on Data | 27. oktober 2021 | Emne: Enterprise Software

cloud-services.png

Sky-native arkitektur og bryte ned applikasjonsmonolitter er bra, men hvis du gjør det, trenger du også en måte å håndtere det finkornede rotet som oppstår, hevder EnterpriseWeb

Av ZinetroN — Shutterstock < /figur>

Hvordan løser du det eldgamle dataintegreringsproblemet? Vi tok opp dette i en av de første artiklene vi skrev for denne spalten tilbake i 2016. Det var en tid da nøkkelbegreper og trender som dominerer dagens landskap, som kunnskapsgrafer og datastoff, i beste fall var under radaren.

Dataintegrasjon høres kanskje ikke like spennende ut som AI eller maskinlæringsgodbiter drysset på vaniljeapper. Likevel er det brød og smør for mange, muliggjøringen av alle kule ting ved å bruke data, og en førsteklasses brukssak for konsepter som underbygger AI, argumenterte vi den gang.

Nøkkelkonseptene vi tok til orde for da, har blitt anerkjent og tatt i bruk i dag i deres kunnskapsgraf og datastoff-form: føderasjon og semantikk. Den gang var konseptene ikke så utbredt, og deler av teknologien var mindre moden og anerkjent. I dag er kunnskapsgrafer og datastrukturer top of mind; bare sjekk de siste Gartner-rapportene.

Grunnen til at vi ser tilbake på den gamle historien er ikke for å sole seg i litt “fortalt deg det” selvrettferdighet, men for å legge til den. Kunnskapsgrafer og datastrukturer kan, og vil forhåpentligvis etter hvert, løse problemer med dataintegrering. Men hva med applikasjonsintegrasjon? Kan grafer og ontologier hjelpe med det også?

Dataintegrering og applikasjonsintegrasjon

“99 databutikker”-fortellingen var basert på den sanne historien om hvordan spredningen av datakilder skaper problemer for bedriften. Men hva med applikasjoner og APIer? Den samme historien spiller der ute, så hvorfor ikke bruke den samme kuren for den sykdommen også? Det er det Dave Duggal og EnterpriseWeb ønsker å oppnå.

Duggal, grunnlegger og administrerende direktør for EnterpriseWeb, har brukt mesteparten av sin karriere på å starte, vokse, bygge og snu selskaper. Det som motiverte ham til å starte EnterpriseWeb var hans erfaring med å bygge og integrere applikasjoner, og se hvor statisk det gjorde driften i selskapene han drev. Han sa:

Måten tradisjonell programvareutvikling skjer den dag i dag, er først og fremst manuell kode og manuell integrasjon. Du koder og rekoder, integrerer og re-integrerer. Og det skalerer selvfølgelig ikke for dagens krav.

På et tidspunkt var alt på en stormaskin — en stor sentralisert monolitt, men også veldig kraftig. En av grunnene til at stormaskiner er veldig kraftige er at data og kode lever sammen på stormaskinen. Det var ikke dette falske skillet mellom datateamet og applikasjonsteamet.

Nå er vi distribuert. Vi har en hel rekke nye muligheter. Men vi har også en hel rekke utfordringer. For når vi disaggregerte fra stormaskinen og deretter monolittiske applikasjoner, som var disse tett koblede kodekulene til mer tjenestebaserte applikasjoner, til mikrotjenester og nå serverløse funksjoner, disaggregerte vi uten å ha en programmeringsmodell for komposisjon og administrasjon.

Vi tok med andre ord fra hverandre alt. Humpty Dumpty brøt. Alle brikkene lå på gulvet. Vi klarte ikke å faktisk introdusere en mekanisme, et middel eller en metode for å sette disse tingene sammen igjen og se på hvor vi er i dag.

Kjernen i Duggals avhandling, og EnterpriseWebs tilbud, er at de samme verktøyene som kan adressere dataintegrasjon bør også kunne adressere applikasjonsintegrasjon: grafer og ontologier.

SAP-tilfellet

Relaterte emner:< /h3> Big Data Analytics Cloud Innovation Tech and Work Collaboration Developer George Anadiotis

Av George Anadiotis for Big on Data | 27. oktober 2021 | Emne: Enterprise Software