Småtjänster till småbarn

Den här hösten har vi för våra yngsta besökare byggt en Bolibompa-play-tjänst baserad på ny arkitektur med micro services. Bakgrunden till vårt teknikval kan man läsa om i ett tidigare blogginlägg – Från Conways law till microservices och det har varit mycket kul och lärorikt att gå från idé till tillämpning.

Bilden visar tre nya tjänster som var och en har en specifik uppgift:

Bild på arkitekturen för Bolibompa med micro services design
Bolibompa – arkitektur
  • BolibompaWeb ansvarar för rendering av webbsidor (html/js) och är skriven i Nodejs
  • PlaylistAPI har som uppgift att att hämta upp sändningsinformation från ett egenbyggt API i Escenic. Det är utvecklat i Spring Boot.
  • VideoApi hämtar videodata från ett internt API. Även den är skriven i Spring Boot.

Escenic är vårt CMS och där har vi ett API för att få ut redaktionell data om sändningar.

Play4API byggdes främst som ett API för vår videotjänst men används nu även av andra interna tjänster för att få ut videoinformation.

I bilden framgår också att våra micro services är deployade på Heroku vilket leder oss in på DevOps frågor som nu blir ännu mer centrala för oss eftersom man måste adressera dessa för varje micro service. Några delar är:

  • Vi har valt att använda Hystrix, ett open source projekt framtaget på Netflix.  Med Hystrix får vi både ett väldesignat API för att kontrollera anrop mot andra tjänster, men även ett övervakningsgränssnitt.
  • Egen CI-server med Jenkins där vi för varje commit kör tester och om vi så vill deploya direkt till Heroku miljöerna.
  • Med Dashing har vi fått en överskådlig vy över hur vår tjänst där status från Hystrix, NewRelic och Jenkins visas. Se bild nedan:
Dashboard för Bolibompa som med grafer och bilder visar hur våra olika micro services mår. Byggt med open source ramverket dashing.
Dashboard för Bolibompa byggt med open source ramverket dashing.

I dashboarden får vi bl.a. en snabb överblick på hur våra tjänster mår:
Apdex värdet ska helst vara 1 och räknas fram utifrån kombon felkod o svarstid
– I mitten syns Hystrix där man kan se hur våra centrala kommandon och trådpooler mår.
– Till höger grafer från Newrelic där vi snabbt kan se om våra svarstider sticker iväg och hur många fel vi har.

En intressant effekt att notera vid utvecklingen av våra micro services är att de alla blir till något av “pet projects”. Man bryr sig extra mycket – det är inte längre frågan om några anonyma kodrader i en stor monolit utan istället blir viljan att åstadkomma “det bästa” mer påtaglig. Men går “hela vägen” kvalitetsmässigt och eftersom en micro service är en egen körbar enhet så blir det uppenbart att man måste adressera alla aspekter. Några är:

  • Hur ska tjänsten exponeras mot omvärlden – hur skrivs ett bra API?
  • Hur gör vi med varierande last?
  • Hur ska de kommunicera med andra tjänster?

Många av dessa frågor försöker vi svara på i vårt korsbefruktande arkitekturprojekt.

Vi har t.ex. tagit fram riktlinjer för hur vi utformar våra API:er. Det handlar bl.a. om hur våra tjänster ska anropa varandra på ett standardiserat sätt. Vi balanserar mellan att ta fram ett regelverk vi tror vi alla långsiktigt tjänar på att följa och samtidigt att inte göra detta alltför rigoröst.

 Det vi redan nu kan konstatera är att vi är på god väg att uppnå våra uppsatta mål:

  • Kunna välja tekniska lösningar utifrån den uppgift som ska lösas.
  • Själva bestämma releasetakten.
  • Isolera fel (ett fel i en av våra micro services ska inte förstöra upplevelsen i någon annan publik tjänst)
  • Enkelt förstå de tjänster vi byggt och kunna göra trygga förändringar.
  • Ha kul!

Det finns mycket mer att berätta så fortsätt gärna följa vår blogg!

  • Johan

    Intressant! Finns det mer information kring valet av Heroku som plattform? Jag är säker på att ni har jämfört olika tjänster mot varandra och det är alltid intressant att se resultatet av ett sådant arbete.

    • Johan

      Bra fråga som egentligen förtjänar ett eget blogginlägg, men i korthet är valet av Heroku mycket en fråga om att det är en etablerad plattform som erbjuder en enkel konfiguration (som våra team själva kan hantera) och utan någon större inlåsningseffekt. Att t.ex. använda AWS direkt (som är en IaaS lösning) skulle kräva en större konfigurationsinsats. T.ex. Google App Engine som är mer jämförbar som en PaaS lösning har en högre inlåsningseffekt.
      Men vi utvärderar kontinuerligt våra teknikval.
      Jag hoppas att vi framöver kan redogöra för det här mer utförligt. Exempelvis finns förstås kostnadsperspektivet och där går det att göra en del optimeringar. Men varje optimering vi gör har ju i sig en utvecklingskostnad…

  • Pingback: The soundtrack of SVT ´(Dev|Sys|No|O)Ops´ Track 1: ”Warm it up” | Testbild | SVT.se()