Callista Tech Radar 2021

21 June 2021 // Erik Lupander

Vad gör vi egentligen i våra uppdrag? Vilken teknik och vilka verktyg jobbar vi egentligen med? Vi ställde dessa frågor till varandra för att lära känna oss själva lite bättre.

Här följer en liten sammanfattning av Callistas första “Tech Radar”.

1. Introduktion

Vi på Callista är konsulter med brinnande intresse för systemutveckling, arkitektur och teknik. För de som känner till eller på något vis deltagit i Callistas drygt 20-åriga resa vet säkert att vår verksamhet i alla år mestadels kretsat kring Javaplattformen och öppen källkod. Vi har sett mycket teknik komma och gå, metoder anammas och tyna ort - medan en del annat faktiskt förändrats förvånansvärt lite genom åren.

Genom en intern enkätundersökning bland medarbetarna i tekniknära uppdrag har vi lärt oss mer om oss själva och vi delar gärna med oss på aggregerad nivå lite av vad vi jobbar med i skrivande stund, vår/sommar 2021.

2. Programmeringsspråk

Javaplattformen och i synnerhet programmeringsspråket Java har i alla år varit den röda tråden i vår utvecklingsrelaterade verksamhet. Samtidigt har vi de senaste 5-6 åren blivit allt mer polyglotta utifrån att det som våra kunder efterfrågar i allt högre utsträckning är skickliga och erfarna utvecklare och arkitekter snarare än att fokusera på enskilda programmeringsspråk.

Resultatet av detta ser vi idag där ungefär hälften av oss faktiskt arbetar i våra uppdrag med ett annat programmeringsspråk än Java.

Figur 1: Våra huvudsakliga programmeringsspråk, per person

Java är fortsatt störst, men vi ser att Scala är på frammarsch precis som Typescript och Go.

2.1 Frontend

Om vi tittar lite närmare på vad frontend- respektive backend-utvecklare jobbar med blir bilden än mer nyanserad:

Figur 2: Våra huvudsakliga programmeringsspråk för frontend, per person som primärt arbetar med frontendutveckling

Det är ganska uppenbart att Typescript tagit över och kanske rent av blivit någon slags de-facto standard i våra uppdrag när det gäller frontendutveckling för de medarbetare som primärt arbetar med just frontendutveckling. Därtill kanske kan tilläggas att Typescript också används för en del backendutveckling samt i viss mån inom exempelvis DevOps, testramverk etc.

2.2 Backend

Figur 3: Våra huvudsakliga programmeringsspråk för backend, per person som primärt arbetar med backendutveckling

Sett till vad backendutvecklare jobbar med så är Javas relativa dominans något större, men då skall man som sagt komma ihåg våra rötter. Hade vi gjort den här undersökningen för 5-6 år sedan hade Java troligtvis legat nära 100%, möjligen undantaget något projekt som körde Groovy samt early adopters av Serverless-funktionalitet byggd kring Javascript.

Vi ser Scala som god tvåa, men även språk som Typescript, Python och Go används som huvudsakligt språk.

2.3 Vart är vi på väg?

Som komplement till vad vi sysslar med idag så är det intressant med framtidsspaningar. Den ena frågan ställdes utifrån hur troligt det är att man i sitt uppdrag kommer arbeta med ett antal olika språk om ett år: Figur 4: Programmeringspråk om ett år

Man kan se resultatet på frågan som att vi har några distinkta grupper av språk:

• Helt etablerade: Java, Typescript och Javascript. Vanliga i uppdragen idag.
• På väg att etablera sig: Python, Kotlin, Go, Scala
• På väg ut eller sällan förekommande hos våra kunder: Groovy, C#, Swift, Ruby, Rust

Den andra frågan är vad man utifrån helt personlig preferens skulle vilja arbeta med som man inte arbetar med idag. Man fick välja upp till tre språk: Figur 5: Programmeringspråk man gärna hade jobbat med, upp till tre val per person

Här är Go med viss marginal det populäraste alternativet. Många tilltalas av Go’s enkelhet i såväl utveckling som toolchain och egenskaper i runtime. Kotlin seglar in som näst populäraste alternativet, ofta med motiveringen att Kotlin känns som “ett modernare Java” som dessutom går att använda både för backend- och apputveckling (Android).

Att Rust tar sig in på topp-3 känns däremot ganska förvånande då den kanske vanligaste associationen till Rust är systemprogrammering och som ersättare till C eller C++ vilka är språk som vi inte jobbat aktivt med på många år. Dock så tilltalas många av oss av Rusts tydliga fokus på mycket hög prestanda i kombination med minnessäkerhet och kraftfulla språkkonstruktioner.

3. Hur körs tjänster och applikationer?

Backar vi bandet 10 år så var Java och olika typer av applikationsservrar och Servlet-containers dominerande i våra uppdrag - det var JBoss, GlassFish, Tomcat, Jetty m.fl.

Idag är först och främst betydligt fler “lager” inblandade i en typisk driftsmiljö. Absolut vanligast är att ens applikation exekverar i någon form av docker-container, men den exekveras ofta i en container-orkestrator som i sin tur kör antingen på en virtualiserad server eller på “bare metal”. Inuti containern körs JVM-baserade applikationer fortfarande på någon form av webbserver/servlet-container som man konfigurerat exempelvis Spring Boot att använda.

Således är frågan “Hur körs din applikation” en minst sagt mångfacetterad fråga att svara på.

3.1 Molnet eller annat?

Figur 6: Driftsmiljöer som används. Flera alternativ möjliga

3.2 Containerorkestratorer och molnplattformar

En sak som står utom tvivel är att docker-containern nästan helt tagit över som runtime-miljö oavsett om den kör en JVM-baserad plattform på insidan eller inte. En annan slutsats är naturligtvis att den klassiska applikationsservern för en alltmer tynande tillvaro. Det är helt enkelt inte många som ligger kvar på gammal hederlig JBoss/Wildfly eller motsvarande.

Figur 7: Driftsplattformar, flera alternativ möjliga Kubernetes har tagit över som containerorkestrator, antingen i sitt vanilla utförande, som managerad tjänst (exempelvis AWS EKS eller Googles GKS) eller som anpassad paketering i stil med RedHats OpenShift. Docker Swarm var i ropet för några år sedan, men verkar inte vara särskilt populärt längre.

Frågan kring “hur kör vi våra docker-containers” är mångfacetterad eftersom det finns fler (och mer lätthanterliga) alternativ än K8S. Vi jobbar med tjänster inom “serverless” som exempelvis AWS lambda. Vi kör AWS Fargate med ECS och det är vanligare än man kanske tror att en tjänst on-premise exekverar i docker-containers direkt på bare-metal.

3.3 Service Mesh

Service Mesh i stil med Istio är en relativt “hypad” teknologi, som dock inte riktigt letat sig in hos särskilt många av våra kunder än. Figur 8: Används en Service Mesh?

4. Ramverk och produkter

4.1 Spring och Java EE

En av de större “striderna” genom Javas relativa långa historia har varit Spring vs Java EE. Hos oss har Spring en tung dominans, med endast ett fåtal uppdrag där Java EE används. Vert.x är en liten uppstickare vi mycket väl kan få se mer av de kommande åren, kanske i kombination med ramverk och teknologier som Micronaut, GraalVM och liknande?

Figur 9: Ramverk som används inom Java, flera alternativ möjliga

4.2 API:er

På Callista jobbar vi med många olika kunder som befinner sig i så väl privat som offentlig sektor inom ett flertal domäner. När det gäller API:er så är det nästan uteslutande HTTP i någon form som gäller, där det kanske är troligare att t.ex. vårdsektorn fortfarande är tunga inom SOAP, medan den lilla start- eller scale-upen mer sannolikt kör GraphQL:

Figur 10: API-typer som används, flera alternativ möjliga

4.3 Databaser

På hög nivå pratar man oftast tre typer av databaser för långtidslagring av data:

• Relationsdatabas
• Dokumentdatabas
• Grafdatabas

Sedan finns det såklart ett antal andra typer såsom KV-stores, tidsseriedatabaser eller “event”-databaser såsom Kafkas ksqlDB.

Hos oss är bilden relativt okomplicerad om man ser till den klassiska “databasen”:

Figur 11: Typ av databaser som används, flera alternativ möjliga

4.4 Frontend-ramverk

Ramverk för frontend har en något högre omsättningstakt än exempelvis vad Spring och Java EE har haft för Java på backendsidan. Hos oss är det för närvarande React, Vue.js och Angular som är absolut vanligast:

Figur 12: Frontendramverk, flera alternativ möjliga

5. Andra spaningar

• Kafka väcker intresse hos många kunder och hos andra är det redan en etablerad och verksamhetskritisk teknik. Strömmande data är hett!
• Alla har enhetstester och de allra flesta har någon form av in-container / integrationstester. Även vanligt med automatiserade browser-baserade tester för projekt med frontend. Men minst hälften av projekten kompletterar med klassiska manuella tester utförda av dedikerade testare.
• I princip alla projekt har någon form av byggsystem för Continuous Integration, men sedan är det varierade grad av automatisk driftsättning till dev-, test- och produktionsmiljöer.
• Alla projekt loggar och de flesta jobbar med någon form av metrics även om tillvägagångssätt för insamling, lagring och sökning i dessa varierar.