Microservices — i dag er service orienteret arkitektur, som du jour — er stor, men ikke for alle. Der er mange situationer, hvor de kan gøre mere skade end gavn.
Foto: Joe McKendrick
Det er ordet fra Adam Drake, en teknisk business transformation ekspert, der for nylig sendt nogle ord af advarsel om microservices. Han advarer mod de øgede operationelle overhead, problemer med ydeevne og skalerbarhed problemer.
Drake giver vigtige trin i vurderingen af en virksomheds behov for microservices arkitektur. Når de to første skridt er taget, han opfordrer “, så overvej igen, om microservices er den rigtige retning for din organisation. Chancerne er, at en masse af de problemer, som du havde tidligere, vil simpelthen forsvinde.”
- Rydde op i programmet. Dette omfatter at sikre, at systemet “har god automatiseret test og med de aktuelle versioner af alle biblioteker, rammer og sprog,” Drake siger.Gøre brug af Api ‘ er. “Refactor anvendelse i overskuelige moduler med klare Api’ er,” Drake siger. “Ikke tillade bits af kode, for at nå i moduler direkte. Al kommunikation skal ske via Api ‘ præsenteret af modulet.”Separate tjenester: en Separat modul fra sin ansøgning, men holde det på den samme vært, siger Drake. “Det starter med at give dig nogle af nytten af helt separate microservices, men med færre af de operationer, hovedpine,” siger Drake. Der vil stadig være kommunikations-problemer at slås med, men uden den medfølgende udfordringer, der vil komme op, når de separate komponenter, der kører på tværs af distribuerede netværk.Flyt adskilt modul til en ny vært. “Nu vil du har til at beskæftige sig med spørgsmål omkring kommunikation over et netværk, men vil du have købt dig en lidt mindre kobling mellem de to systemer,” Drake siger.Adskilt opbevaring kapaciteter. Endelig, Drake siger, “hvis det er muligt, refactor data storage system, så modulet på den anden vært, nu har det samlede ansvar for opbevaring af data inden for dets kontekst.”Overvej dine organisatoriske beredskab. En microservices-kyndige virksomheden har et hold, der kan rekvirere ressourcer på et øjebliks varsel, med lidt eller ingen hjælp udefra, Drake siger. “Hvis din organisation har kun én eller et par personer i hele dev team, der kan oprette nye tjenester, virtuelle eller andet, du er ikke klar til microservices.” Være klar til at overvåge. “Hvis du ikke overvåger systemet og anvendelse af resultater af din monolith, så vil du have en hård tid med microservices,” siger Drake. Vigtige målinger, omfatter “system-niveau målinger (såsom CPU og RAM), program-niveau målinger (f.eks anmodning ventetid for hver effektparameter, eller fejl per endpoint), og business-niveau målinger (såsom transaktioner per sekund, eller omsætning per sekund) til at forstå effektiviteten af dine systemer.”Være godt rustet til continuous integration og løbende implementering. Drake sætter det i perspektiv: Hvis monolith mangler en god CI/CD-tilgang, så en microservices arkitektur kommer til at være hundrede gange så udfordrende, “Forestil dig at have 10 hold og 100 tjenesteydelser, hvilket kræver manuel integration, test og implementering. Forestil dig nu det samme, manuelt arbejde, men med kun én monolit. Hvor mange måder kan ting gå galt med 100 service? Hvor mange måder med en monolit?”