anders lisdorf bloghoved

Mainframen og elefanten i rummet

Dekommissionering af mainframen og big data er faste punkter på IT strategien for mange firmaer i disse år. De færreste ser nogen forbindelse, da det ene handler om en fjern fjern fortid og det andet om en fjern (fjern) fremtid. Men faktisk kan de to ting have meget mere med hinanden at gøre end man skulle tro.

At få gjort noget ved mainframen har været et fast punkt på IT strategien de seneste 10-20 år. Punktet står der troligt ved hver 3 årig opdatering af strategien. Vi ved jo godt alle sammen, at det ikke kan fortsætte det her med mainframen. Mainframen er ofte elefanten i rummet. Vi bliver nød til at snakke om den.

Lad os snakke om elefanten i rummet

Sprog (altså rigtige menneskelige sprog) uddør også sjældent fra en dag til en anden. Istedet lider de gradvist af såkaldt funktionstab. Det vil sige at sproget holder op med at blive brugt i forskellige funktioner. Ofte er sidste stadie af et sprog, at det kun tales derhjemme privat. I dag lider dansk f.eks. funktionstab som videnskabeligt sprog og så småt også som arbejdssprog i virksomheder, hvor arbejdssproget bliver engelsk.

På samme måde vil mainframen nok også forsvinde gradvist ved funktionstab. Et af de områder, der står over for at blive tabt data processering. Mere specifikt batch processering af store data mængder, som ofte sker som en del af processeringen af data til datawarehouse eller andre analytiske eller klassifikationsmæssige funktioner.

Det er specielt data pipelinens først steps, før data rammer et egentligt ETL tool, som er relevante at kigge på. Dette step har ofte været understøttet af mainframes fordi de fleste operationelle systemer lå på mainframen da datawarehouset blev introduceret, og fordi mainframen er velprøvet teknologi, som man kan stole på. Men mainframen bliver belastet af at skulle processere de store mængder af data og forskellige ODBC kald til operationelle systemer. Det er altsammen noget, der trækker MIPS og det er ikke det, som en mainframe gør bedst.

Mød den anden elefant

Det er så her det andet strategi punkt kommer ind, nemlig Big Data. Say what?? Batch processering af store datamængder er nemlig lige præcis det som Hadoop gør exceptionelt godt. Hadoop og big data er ikke just castet, som en mainframe killer, men det er ikke desto mindre en oplagt udvikling. Det er nemlig, alle overskrifter og hype til trods, kun få procent af verdens firmaer, der lige står, og har problemer med at analysere flere terabyte data per sekund, der skal fødes gennem Flume, som de skal have lavet noget deep learning på med tensor flow på, før det gøres klart til visuel analyse i Tableau naturligvis i en Lambda arkitektur. Hvis vi kigger os selv dybt i øjnene, er det jo ikke lige det vi hører forretningen plage om hver dag, vel? Selvom det lyder spændende. Derfor står mange firmaer idag med et forundret udtryk, og kigger på deres eksperimentelle implementering af Big Data og prøver at huske, hvorfor det nu var de startede dette projekt.

Hvis vi tænker tilbage på, hvad forretningen egentlig gerne ville have, så var det opdateret data af høj kvalitet der er let tilgængeligt. IT afdelingen vil også gerne spare lidt på mainframen, som står derovre i hjørnet af serverrummet (hos KMD). Det er en ægte problem stilling, som rigtigt mange faktisk har.

Det er naturligvis ikke så fancy, at man bare gerne vil spare lidt håndører og have noget bedre kvalitet opdateret data, men det kan være lige præcist det, som er Hadoop’s killer use case i enterprise segmentet. For disse ting er i sig selv værdifulde, allerede inden vi kommer til alle de ekstra lækre ting som Hadoop kan.

Eksempler

Splice machine er et firma som til dels er bygget på denne use case. Mere specifikt at off loade arbejde fra RDBMSer til Hadoop. De har i et white paper beskrevet, hvordan man kan lave en operational data lake, som fjerner det tunge data load fra operationelle systemer, som mainframe systemer ofte er. De tilbyder med deres løsning et SQL lag ovenpå denne operationelle data lake, hvilket gør at slutbrugeren ikke vil opleve nogen forskel bortset fra, at data vil være meget hurtigere tilgængeligt, og fordi det hele nu er meget billigere bliver julefrokosten i IT afdelingen sikkert også ekstra festlig (tænkt upgrade fra Thomas Helmig Jam til Danseorkestret (træerne gror heller ikke ind i himlen…))

Den største leverandør af Hadoop, Cloudera, har også fået øjnene op for denne mulighed på det seneste. De har publiceret et white paper om, hvordan man kan bruge Cloudera Enterprise til at lave en ODS, og derved forbedre data processeringen til data warehouses. Her slår de på skalerbarheden, agiliteten og deres sikkerhedsfeatures. De har også sikret sig at data pipelinen kan forbinde sig til de mest udbredte ETL løsninger. På den måde behøver man ikke ændre noget i upstream systemer, men blot flytte den dyre langsomme processering fra mainframen og ramme det eksisterende format.

Denne model rammer lige i hjertet på CIOen, som kan levere hurtigere adgang til data til en billigere penge uden at forretningen skal introduceres til noget som helst nyt (hvilket alle ved, at de hader). De kan stadig fifle rundt med deres SQL og BI tools, som de er vant til.

En kamp mellem elefanter

Husk på at phonografen (altså pladeafspilleren) oprindeligt blev tænkt til at skulle bruges til forretningsbeskeder, men endte med at blive et underholdningsmedie. Vi skal derfor ikke blive overraskede over at en tilsyneladende uforudset brug kan overtage fokus. Det er præcist det, som er ved at ske. Store støvede gamle virksomheder med deres elefanter i rummet finder en anden elefant (Hadoop), som de i stigende grad kan få til at hjælpe med at få den første elefant ud af rummet.

Kommentarer (4)
Jørn Thyssen

Problematikken med at dataudtræk belaster transaktionssystemet er ikke unikt for mainframes. Det er derfor alle de store database-leverandører arbejder med at lave hybrid-databaser som kan håndtere både transaktioner og analyser, rapporter, mm. Det allerbilligste og -hurtigste er nemlig at lade data ligge hvor det bliver født!

DB2 på mainframe er ingen undtagelser og vi (IBM) tilbyder løsninger der giver mulighed for at afvikle analytiske forespørgsler i mod mainframe data uden at det operationelle miljø forstyrres og med minimal påvirkning af MIPS forbrug.

Mainframe er desuden en mere moderne platform end du giver udtryk for.

Disclaimer: arbejder med DB2 for z/OS hos IBM

Anders Lisdorf

Hej Peter

Jeg har ikke lige det præcise tal, men det er flere hundrede programmer jeg har arbejdet med på Mainframen.

Hvis du havde læst min blog tidligere ville det nok være meget klart, at jeg ikke er programmør, men det er altid godt med nye læsere. Jeg har derfor selvsagt ikke udviklet programmer til hverken mainframe, Unix, Linux, Hadoop eller nogen som helst andre platforme. Jeg skrev mit sidste program i BASIC i midten af 80'erne og har rodet lidt med C og med Python, hvis det har din interesse.

Lad mig tilføje, at jeg heller aldrig har skrevet min egen compiler, opsat et netværk, kæmper med selv de simpleste web administrationsopgaver på mine egne sites og stadig ikke rigtigt har forstået, hvad de der forskellige sorting algoritmer gør.

Håber det opklarer din undren.

Venlig hilsen Anders

Peter Johan Bruun

Hej Anders

Tak for dit svar, og det er som jeg forventede det.

Husk at djævlen altid ligger i detaljen, og at den dyreste sætning i IT Verdenen er "Hvor svært kan det være" .... det er altid en god ide at vide hvordan maskinrummet ser ud inden man anbefaler en udskiftning af materiellet.

Mvh. Peter J. Bruun.

PS: Jeg har læst lidt religions historie filosofi lekture, og Løgstrups etisk udfordrings tanker, kan for øvrigt også bruges indenfor IT leverandør / IT Indkøber forhold ;o)

Log ind eller Opret konto for at kommentere