Microservices — dagens service oriented architecture du jour — är bra, men inte för alla. Det finns många situationer där de kan göra mer skada än nytta.
Foto: Joe McKendrick
Det är ordet från Adam Drake, en teknisk business transformation expert, som nyligen skrev några ord av försiktighet om microservices. Han varnar för ökade operativa kostnader, prestanda och skalbarhet problem.
Drake har viktiga steg i att bedöma ett företags behov av microservices arkitektur. När de två första stegen är tagna, han uppmanar “sedan fundera igen om microservices är rätt riktning för din organisation. Chansen är stor att en hel del av de problem som du hade tidigare kommer helt enkelt att försvinna.”
- Rensa upp i ansökan. Detta innefattar bland annat att säkerställa att systemet “, har bra automatiserade tester och använder aktuella versioner av alla bibliotek, ramar, och språk,” Drake säger.Använda Api: er. “Refaktorera ansökan till tydliga moduler med tydliga Api: er,” Drake säger. “Tillåt inte bitar av kod för att komma in i modulerna direkt. All samverkan ska ske via Api: er som presenteras av modulen.”Separata tjänster: en Separat modul från dess tillämpning, men håll det på samma värd, säger Drake. “Det börjar med att ge dig några av nyttan av en helt separat microservices, men med färre operationer huvudvärk, säger Drake. Det kommer fortfarande att vara communications-relaterade frågor att brottas med, men utan tillhörande utmaningar som kommer att komma upp en gång separata komponenter som körs över distribuerade nätverk.Flytta separerade modul till en ny värd. “Nu har du att ta itu med de frågor som rör kommunikation över ett nätverk, men du har köpt dig själv en lite mindre koppling mellan de två systemen,” Drake säger.Separat lagring kapacitet. Slutligen, Drake säger, “om det är möjligt, refaktorera data storage system så att modulen på den andra värd nu har det totala ansvaret för lagring av data i sitt sammanhang.”Betrakta din organisations beredskap. En microservices kunniga företag har personal som kan tillhandahålla resurser på ett ögonblick, med liten eller ingen hjälp utifrån, Drake säger. “Om din organisation har endast en eller ett fåtal personer i hela dev team som kan ställa upp nya tjänster, virtuella eller på annat sätt, är du inte redo för microservices.” Vara beredd att övervaka. “Om du inte övervaka system och applikationer prestanda av din monolit, då du kommer att ha en eländig tid med microservices, säger Drake. Statistiken inkluderar “system-nivå statistik (såsom CPU och RAM), tillämpning-nivå statistik (till exempel begäran latens per endpoint, eller fel per endpoint), och business-nivå statistik (såsom transaktioner per sekund, eller intäkt per sekund) för att förstå resultatet av ditt system.”Att vara väl utrustad för continuous integration och continuous deployment. Drake sätter det i perspektiv: Om den monolit som saknar en bra CL/CD-metod, då en microservices arkitektur kommer att vara hundra gånger så utmanande, “Tänk att ha 10 lag och 100 tjänster, som alla kräver manuell integration, testning och driftsättning. Föreställ dig nu att samma manuellt arbete, men med endast en monolit. Hur många sätt kan saker gå fel med 100 tjänster? Hur många sätt med en monolit?”