Vælg microservices ud fra uafhængige ændringer

Hvilken ændring skal kunne ske uafhængigt?

At fordele en applikation på services skaber ikke i sig selv uafhængig udvikling. Skal de samme personer ændre og udrulle alle services sammen ved hver prisregel, består koordineringen. Netværkskald og ekstra driftsopgaver kommer oveni.

Microsoft beskriver uafhængig udrulning og eget dataansvar som vigtige kendetegn. Vi foreslår derfor at begynde med en konkret ændring: Hvilket fagområde skal kunne bære den uden samtidige tilpasninger andre steder?

Eksempel: tilbud og ordrer bliver foreløbig sammen

Produktet og arbejdsmåden er opdigtede. Ét team vedligeholder tilbud, ordrer og rapporter. Prisregler ændres samlet i tilbud og ordre. Rapportformater har andre ændringsbehov.

I planen forbliver applikationen først en modulær monolit: indre grænser, samlet udrulning. Spring Modulith viser eksempelvis forskellen på offentlig modulgrænseflade og indre implementering. Det er nyttigt at beskrive adskillelsen uden at vælge netop dette værktøj.

Medtag driften i beslutningen

En separat rapportservice skal kunne håndtere fejl i sin datakilde. Nogen skal stå for udrulning, overvågning og fejlafklaring. Teamet skal også have regler for gamle og nye grænsefladeversioner under en overgang. En selvstændig proces opfylder ikke alene betingelserne.

Registrér grunden til senere adskillelse, eksempelvis reelt behov for uafhængig udrulning eller en belastning, der kræver anden håndtering. Vurdér kobling, dataadgang og driftsindsats igen. Moduler, der udrulles sammen, kan også være klart strukturerede. En velafgrænset service kan omvendt være begrundet, før resten deles op. Antallet af services måler ikke beslutningens kvalitet.

Kilder

• Microsoft: Microservices architecture

• Spring Modulith: Fundamentals