Forside /Blog /Microservices i et lille team: hvad det faktisk kræver

Microservices i et lille team: hvad det faktisk kræver

At arbejde med microservices i et startup-størrelse team er lidt som at jonglere på et énhjuls-cykel. Fleksibelt, skalérbart, frigørende, og krævende når man har begrænsede hænder. Noter fra gradvist at dekoble en Laravel-app hos Waitly.

At arbejde med microservices i et startup-størrelse dev-team er lidt som at jonglere på et énhjuls-cykel. 🎪

Det er fleksibelt, skalérbart, og frigørende, men også krævende når man har begrænsede hænder (og timer) til at holde det hele kørende.

Hvad vi faktisk laver

Hos Waitly er vi begyndt at bygge en modulær arkitektur hvor vores core-app gradvist bliver dekoblet til selvstændigt deployede services.

Målet er at vinde hastighed, autonomi, og klarere ansvars-grænser. Men det kræver allerede omhyggelig orkestrering, fælles ejerskab, og konstant fokus på observability, sikkerhed, og resilience.

Der findes ikke et "og så splitter vi bare servicen"-øjeblik. Det er inkrementelt, nogle gange grimt, og man opdager skjulte koblinger hver gang man prøver at tegne en ren grænse.

Hvad jeg har lært

Microservices kan skinne selv i små teams, hvis du investerer i den rigtige tooling, deployment-processer, og kommunikations-vaner. Uden dem har du bare omdannet en monolits kompleksitet til distribueret kompleksitet, hvilket er langt sværere at debugge. Med dem får du faktisk hastigheds- og autonomi-løftet.

Der findes ikke noget der hedder "bare backend" eller "bare frontend." Du har brug for generalister der kan samarbejde tæt på tværs af domæner. Teamet skal forstå sømmen mellem servicerne. En backend-udvikler der ikke kan ræsonnere om frontendens forventninger, designer APIs der gør ondt på alle.

Prioritering er nøglen. Vi kan ikke bygge alt, så stabilitet, GDPR og klarhed slår altid ekstra-features. I et lille team er ethvert "nice to have" en reel omkostning et andet sted.

Mit fokus i hverdagen

Styrke vores tekniske fundament, modne nøgle-services, reducere incident-belastning, og sikre at det vi bygger er bæredygtigt og sikkert, selv efterhånden som nye ting bliver lagt ovenpå.

Det sværeste er ikke at designe servicerne. Det er at designe den operationelle disciplin der holder dem vedligeholdelses-venlige når én person er ansvarlig for tre af dem på samme tid.

Nysgerrig på hvordan andre små teams tackler det her, eller hvis du bygger noget lignende, så lad os tale.

→ relateret

Relateret læsning.