Architecture

Många utvecklare har säkert erfarenhet att arbeta med masterdata som exporteras med viss frekvens i sin helhet, t.ex. ett register från ett produktinformationssystem (PIM) som exporteras till fil en gång per dygn (ofta någon typ av textfil i komma-separerat format – CSV).

För det allra mesta är man intresserad enbart av förändringar, men bearbetar ändå hela registret, där kanske 95% av all information egentligen är helt ointressant. Inom bland annat e-handel är detta särskilt problematiskt, eftersom man typiskt också indexerar innehållet för att erbjuda sökfunktionalitet, så varje hanterad post medför beräkningsintensiv och tidskrävande bearbetning. Egen erfarenhet från ett tidigare projekt handlade om att bearbeta en artikelexport med omkring 40.000 poster, vilket tog runt 8 timmar i anspråk. Efter att ha ändrats enligt den lösningsbeskrivning som följer kunde samma jobb hanteras på några minuter.

Alla organisationer med någorlunda stor IT-miljö hamnar förr eller senare i utmaningar kring hantering av masterdata.

Allt som oftast brukar jag höra att man pratar om mikrotjänster (microservices) i integrationssammanhang, och ofta som en efterföljare till tjänsteorienterad arkitektur (SOA). Mikrotjänster kan vara ett väldigt användbart arkitekturmönster, men enligt min mening inte för att lösa integrationsbehov mellan olika applikationer, utan som ett sätt att dela upp monolitiska applikationer i mindre, autonoma delar som underlättar förvaltning och vidareutveckling.

Sedan datorkommunikationens begynnelse har vi haft en förkärlek till request/reply som integrationsmönster. Från början var det RPC, sedan kom CORBA, DCOM, SOAP Web Services och REST. Alla med fokus mot en server som tillhandahåller en tjänst och en klient som frågar och får svar. Många gånger har vi verkligen ansträngt oss för att jobba efter just detta mönster, t.ex. genom att bygga upp en lokal cache för att inte behöva överbelasta servern med frågor. Visst är det ett väldigt användbart mönster, men det har blivit så slentrianmässigt sätt att realisera på att man nästan glömt bort att det finns en annan modell – nämligen publish/subscribe.

Våfflor med hjortronsylt och grädde – ett klassiskt exempel på när helheten kan bli bättre än de ingående beståndsdelarna. Runt oss finns det gott om exempel på hur just tre olika delar kompletterar varandra och bidar en balanserad helhet. Inom komplex systemarkitektur finns det en trio som fungerar alldeles särskilt bra tillsammans, och som rubriken antyder kommer det att handla om mikrotjänster, Docker och Node.js.

Det är otroligt vanligt med online-tjänster som erbjuder att nollställa ett glömt lösenord genom att skicka en engångs-länk till den e-postadress man registrerade i samband med att kontot skapades. Det är nästan lika vanligt med lösningar som är ganska komplicerade att implementera – helt i onödan. Först kommer ett exempel på hur man kanske intuitivt skulle bygga en sådan funktion, och därefter en mycket enklare och elegantare lösning.

Det råder just nu något som närmast kan liknas vid GDPR-hysteri. Jag har själv arbetat mycket med system för behandling av extra känsliga personuppgifter och som regleras genom apoteksdatalagen som i sin tur är en påbyggnad på personuppgiftslagen (PUL). Apoteksdatalagen ger såväl större befogenheter som större ansvar beträffande hantering av personuppgifter jämfört med nuvarande personuppgiftslagstiftning.