Rapport från JFokus 2014

Trender

Reaktiva system tror jag är årets ord. Årets mässa var inte så inriktat på någon speciell metodik utan var mer tekniskt inriktat. Över åren har olika trender varit starka och JFokus gör ett bra jobb att få talare inom de områden som just nu är starka. Det har pendlat från metoder som RUP till senaste decenniets agila metoder.

Andra år har det mer handlat om teknik. Agila metoder verkar de flesta vara mätta på att lära sig och någon ny teori som fungerar bättre har inte dykt upp. Vad gäller teknik är trenden med att använda flera språk och system tillsammans (i motsats till monoliter) fortfarande stark.

Fokus inom teknik går mot system som bättre hanterar många korta anrop.

Den mer sammanhållande trenden kommer från de krav som kommer av att vi använder webbläsare mer som en JavaScript-motor än som en terminal. Tillsammans med att system ska aggregera information från många ställen gör det att fokus inom teknik går mot system som bättre hanterar många korta anrop. Både mellan sig och mellan browsern och inuti systemet.

Det gör att vi i branchen både behöver bygga backend-system som är robusta och flexibla och browserprogram snarare än traditionella webbsidor. Det här är inte nytt men blir mer accentuerat för varje år.

Små och stora datorer

JFokus är två konferenser, en stor som handlar om it med Java-motorn som sammanhållande tema och en mindre som handlar om inbyggda system. Modernt uttryckt som “internet of things”.

Eftersom mitt yrkesområde bara berör vanliga servrar blev den mindre mässan inspiration och lek utan direkt användning i arbetslivet. Inte att förakta eller förringa! Första dagens förmiddag ägnad jag åt små datorer.

Liten, mindre, minst

Inbyggda system kan idag innebära att man kör Linux eller Windows, en hel nätverksstack och har tillgång till samma stöd som i en vanlig dator. I andra änden av skalan har men hela datorn på ett chip med begränsat minne och processor. Dessutom är den kanske batteridriven och batteriet behöver räcka ett bra tag (många år).

Vi började med att titta på en liten variant av dator med 16K minne. Det vi använde var ett OS som heter Contiki. Du skriver din applikation i C och länkar sedan in den i Contiki för att skapa en binär för den dator du ska köra applikationen på. Contiki tillhandahåller uppkoppling med ipv4/ipv6 och en wlan-variant som drar lite ström och kan routa trafik mellan enheter.

Routingen gör att du kan nå en avlägsen enhet genom att passera flera enheter på vägen dit vilket gör att varje enhet inte behöver så stor räckvidd. Det finns också en emulator för att utveckla och testa din app på din vanliga dator. Miljön och systemet kändes moget och var trevligt att använda.

Vår ciceron Joakim Eriksson tror på att enheter behöver prata ipv6 för att internet of things ska ta fart. Det är förstås lätt att tro på att vi inte kan ha olika standarder för alla olika enheter och ip är ett uppenbart val. Enheterna behöver typiskt kunna prata över radio och den standard vi fick presenterat för oss är “LoPAN” elller IEEE 802.15.4. Man behöver inte köra just ip över LoPAN och flera stora tillverkare använder sina egna protokoll.

Tar vi ett steg tillbaka och tittar på hur inbyggda system har mognat över tid var det en gång så att alla tillverkare gjorde sin egen elektronik. Tio år senare köpte man elektronik men gjorde sina egna os. Idag finns både hårdvara och OS att köpa både för enkla och lite större system. Till exempel kommer många av kretsarna från TI idag med en Java-vm och gör att företag betydligt snabbare kan använda nyheter i hårdvara.

Om vi ska leka med tanken att ha miljarder uppkopplade enheter behöver vi för övrigt komma på andra sätt att kommunicera på än vad t ex mobila nät klarar av. Om varje person i Stockholm skulle ha tio enheter skulle inte dagens bas-stationer räcka till.

Med bara lite lägre ambitioner kan billiga enheter fortfarande göra stor nytta. Ett företag i Spanien lever på att få procent på vad införandet av deras teknik kan spara. De har till exempel kopplat ihop en mätning av trafikmängd med hur många gatlyktor som är tända.

Reaktiva system

Tillbaka till världen av vanliga servrar som svarar på anrop från webbläsare. Idén med ett system som är “reactive” är att det genom att var smidigt och tåligt kan reagera (react) till variationer i last och miljö. Reagera och hantera att nätverk kommer och går, att last går upp och ner och att maskiner går sönder.

De som kommit på “reactive manifesto” menar att sättet att uppnå detta är att använda meddelanden mellan fristående processer. Tankarna om systemet känns igen från telekom med Erlang som språk. Det mest uppenbara alternativet är node.js som använder JavaScript vilket ju är asynkront till sin natur och även node.js var representerat på konferensen.

Det traditionella sättet att ta hand om anrop från webbläsare med en tråd per request är väldigt lätt att förstå och debugga men gör förstås att en server inte kan hantera fler samtidiga requests än storleken på dess trådpool. Dagens webbsystem behöver vara flexiblare än så.

Vi servar inte webbsidor idag, vi kör program i browsern som hämtar data med ajax eller till och med håller en uppkoppling öppen och blir anropade från servern för uppdateringar. Med async servlet kan vi göra processning i bakgrunden medan trådpoolen fortsätter med nästa request. Spring 4 har också detta stöd.

Processning i bakgrunden utgörs typiskt inte av en process utan vi behöver ofta hämta data från flera olika källor, databaser, andra servrar, kanske någon uträkning etc. Vi vill inte göra det seriellt utan skicka iväg alla frågor, få in svar och sedan kombinera ihop slutresultatet.

Det här blir väldigt snabbt väldigt snårigt om vi inte har praktiska abstraktioner. I en enklare nivå kan vi tänka oss Javas Executors och att använda Futures och för att hantera resultat som kommer att komma senare. För att göra större system kommer Akka in i bilden. I Akka har vi typiskt många (tusen eller miljontals) enkla processer som kallas Actors som vi skickar meddelanden till och som även mellan pratar mellan sig genom meddelanden.

Actors har väldigt lite overhead så det kostar inget att dela upp problem genom att skapa flera actors för att ta hand om delar av problemet. I ramverket ingår också att ta hand om fel om en actor kraschar. Det hela är moget och mycket användbart.

Det enda tråkiga men som knappast går att undvika är att system med många löst kopplade processer är bra mycket svårare att debugga och testa än den gamla varianten med en tråd genom hela processningen. Kanske något så enkelt som transaktionsid och logg-aggregering kan räcka en bra bit.

Akka, Futures, Promises, Rx extensions m fl abstraktioner finns för både Java och Scala men många saker blir betydligt elegantare i Scala.

Men Java 8 då?

Jo konferensen innehöll ett antal föredrag om Java 8 med dess funktionella delar men ämnet är rätt gammalt så det kan du läsa om på andra håll.

Bild av Stephen Chin under CC BY 2.0