ArchConf, dag 3 - Microservices AntiPatterns

13 December 2017 // Hans Thunberg

Började dag 3 på ArchConf 2017 med en föreläsning av Mark Richards där han tog upp ämnet “Microservices AntiPatterns”. Ämnet är intressant om man beslutat sig för att mikrotjänster är den arkitektur som är vägen framåt.

Här kommer en sammanfattning av “Microservices AntiPatterns” med Mark Richards.

Mark började först med att beskriva skillnaden mellan anti-patterns och fallgropar, då hans efterföljande föreläsning tar upp just fallgropar när det kommer till mikrotjänster.

Andrew Koenig “an anti-pattern is something that seemed like a good idea when you begin, but leads you into trouble”

Neal Ford “a pitfall is something that was never a good idea, even from the start”

Följande anti-patterns diskuterades på föreläsningen:

• Function-driven identification anti-pattern
• I was taught to share anti-pattern
• The timeout anti-pattern
• Hop on the bus anti-pattern
• Data driven migration anti pattern

Function-driven identification anti-pattern

Hur skall vi strukturera våra mikrotjänster, både om vi kommer från en ett befintligt system som skall brytas ner enligt mikrotjänster eller från ett helt nytt projekt som skall leverera ett nytt system?

Mark nämner 3 olika tillvägagångssätt som han stött på:

• Drivet utifrån funktionerna i systemet (top down)
• Drivet utifrån datastrukturen i systemet (bottom up)
• Drivet från hur klienter efterfrågar informationen

Ingen av dessa 3 fungerar i praktiken var för sig, men i kombination har det visat sig ge bra resultat. Så en process för att strukturera mikrotjänster skulle kunna se ut så här i flera iterationer:

• Dela upp mikrotjänster grovt baserat på funktionsområde
• Utifrån den grova uppdelningen, strukturera mikrotjänster vidare baserat på datastruktur. Partionera tjänster och data för varje tjänst.
• Utifrån hur tjänsterna skall konsumeras av klienterna, förfina ytterligare och strukturera mikrotjänster.

I was taught to share anti-pattern

Mikrotjänster baseras bland annat på en modell som förespråkar “share nothing”, dvs där varje tjänst i sig är isolerad, självständig och självförsörjande. Men hur fungerar detta ihop med andra principer som vi fått till oss som återanvändning och DRY principen (don’t repeat yourself)?

Det är ju inte alls ovanligt att det finns gemensam funktionalitet som återanvänds i flera tjänster, tex anpassningar av loggning, säkerhet, mfl. Ett vanligt scenario är att dessa gemensamma funktioner paketeras som en modul i en jar-fil och att tjänsterna sedan beror på dessa jar-filer. Här rekommenderar Mark att man hellre skapar flera små moduler med specifika uppgifter per modul, snarare än en enda modul med allt gemensamt. Detta för att slippa göra nya releaser av tjänster som inte beror på vissa delar av den gemensamma funktionaliteten. Mark nämner att detta inte löser problemet, men kan göra det mer hanterbart.

Ett annat sätt som nämns är replikering av kod och genom detta medvetet bryta mot DRY principen. Rent praktiskt handlade detta om att koordinera gemensam källkod mellan systemägare och att varje systemägare ansvarar för att införa förändringarna i sina system. Rent konkret kopiera in den gemensamma källkod som behövs i respektive system.

The timeout anti-pattern

I ett distribuerat system, som det innebär att implementera mikrotjänster, så är det inte ovanligt att tjänster exponerar resurser RESTful både för tjänst till tjänst och för klient till tjänst integration. Det är heller inte ovanligt att man för dessa integrationer konfigurerar statiskt hur lång tid en klient kan tänka sig att vänta på ett svar från en tjänst. När en tjänst inte inte längre är responsiv och inte svarar inom förväntad tid så uppstår en timeout och klienten får aldrig veta om tjänsten lyckades fullfölja sitt uppdrag eller inte. Klienten gör ett nytt försök med samma anrop (tänk ett köp av aktier) och har då med lite otur köpt fler aktier än vad som var avsett från början.

För att hantera situationer där tjänster under perioder behöver mer utrymme i form av tid för att processa ett anrop så nämner Mark följande förslag:

• Dynamisk hantering av timeout konfiguration, för att hantera att svarstider kan variera över tid (inom rimliga intervall).
• Implementera Circuit breaker pattern för att undvika att hela systemlandskapet påverkas om en tjänst inte är responsiv.

Hop on the bus anti-pattern

Med “bus” syftar Mark på ESB (enterprise service bus) och att det är vanligt att man i en distribuerad miljö med mikrotjänster använder sig av olika produkter som implementerar Api Gateway. Det är inte heller ovanligt att dessa Api Gateways har funktionalitet för att utföra komplexare bearbetning så som orkestrering och transaktioner. Detta är ett anti-pattern när det kommer till mikrotjänster, då beroendet till andra tjänster i systemlandskapet ökar. Vad Mark istället säger att vi skall använda dessa produkter till är enbart gemensamma infrastrukturfunktioner så som:

• Säkerhet
• Generering av korrelations information
• Audit information

Data driven migration anti pattern

I detta anti-pattern pratar Mark om vikten av att värna om ett företags kanske viktigaste tillgång, nämligen all typ av data. Migrera data är betydligt svårare än att migrera funktioner enligt mikrotjänster och därför rekommenderar Mark att:

• Bryt ut och flytta funktioner till mikrotjänster först, utan att ändra något alls runt lagring och datastruktur.
• Genomför migrering av data först när funktionen anses tillräckligt stabil (nämner månader, kanske kvartal innan detta genomförs).

Sammanfattningsvis

En välfylld lokal och ett intressant ämne, som vanligt inspirerande att lyssna på Mark Richards.