Delen via

Evaluatie en gereedheid van microservices

  • Artikel

Een microservicesarchitectuur biedt veel voordelen voor uw toepassingen, waaronder flexibiliteit, schaalbaarheid en hoge beschikbaarheid. Naast deze voordelen biedt deze architectuur uitdagingen. Wanneer u op microservices gebaseerde toepassingen bouwt of bestaande toepassingen transformeert in een microservicesarchitectuur, moet u uw huidige situatie analyseren en evalueren om gebieden te identificeren die moeten worden verbeterd.

Deze handleiding helpt u bij het begrijpen van enkele overwegingen waarmee u rekening moet houden wanneer u overstapt op een microservicesarchitectuur. U kunt deze handleiding gebruiken om de volwassenheid van uw toepassing, infrastructuur, DevOps, ontwikkelingsmodel en meer te beoordelen.

Bedrijfsprioriteiten begrijpen

Als u een microservicearchitectuur wilt evalueren, moet u eerst de kernprioriteiten van uw bedrijf begrijpen. Kernprioriteiten kunnen bijvoorbeeld betrekking hebben op flexibiliteit, veranderingsacceptatie of snelle ontwikkeling. U moet analyseren of uw architectuur geschikt is voor uw kernprioriteiten. Houd er rekening mee dat bedrijfsprioriteiten na verloop van tijd kunnen veranderen. Innovatie is bijvoorbeeld een topprioriteit voor start-ups, maar na een paar jaar kunnen de kernprioriteiten betrouwbaarheid en efficiëntie zijn.

Hier volgen enkele prioriteiten om rekening mee te houden:

  • Innovatie
  • Betrouwbaarheid
  • Efficiëntie

Documenteer de SLA's die zijn afgestemd op verschillende onderdelen van uw toepassing om te zorgen voor een organisatie-toezegging die als richtlijn kan dienen voor uw evaluatie.

Beslissingen over architectuur vastleggen

Een microservicesarchitectuur helpt teams autonoom te worden. Teams kunnen bijvoorbeeld hun eigen beslissingen nemen over technologieën, methodologieën en infrastructuuronderdelen. Deze keuzes moeten echter de formeel overeengekomen principes respecteren, ook wel gedeelde governance genoemd, die de overeenkomst tussen teams uitdrukken over hoe de bredere strategie voor microservices moet worden aangepakt.

Houd rekening met deze factoren:

  • Is gedeeld beheer van kracht?
  • Houdt u beslissingen en hun compromissen bij in een architectuurdagboek?
  • Heeft uw team eenvoudig toegang tot uw architectuurlogboek?
  • Hebt u een proces voor het evalueren van hulpprogramma's, technologieën en frameworks?

Teamsamenstelling beoordelen

U moet de juiste teamstructuur hebben om onnodige communicatie tussen teams te voorkomen. Een microservicesarchitectuur stimuleert de vorming van kleine, gerichte, functionele teams en vereist een mindsetverandering, die moet worden voorafgegaan door teamherstructurering.

Houd rekening met deze factoren:

  • Worden uw teams gesplitst op basis van subdomeinen, volgens DDD-principes (Domain-Driven Design) ?
  • Zijn uw teams crossfunctioneel, met voldoende capaciteit om gerelateerde microservices onafhankelijk te bouwen en te gebruiken?
  • Hoeveel tijd wordt besteed aan ad-hocactiviteiten en -taken die niet zijn gerelateerd aan projecten?
  • Hoeveel tijd wordt besteed aan samenwerking tussen teams?
  • Hebt u een proces voor het identificeren en minimaliseren van technische schulden?
  • Hoe worden lessen geleerd en ervaring gecommuniceerd tussen teams?

De Twaalf-Factor-methodologie gebruiken

Het fundamentele doel van het kiezen van een microservicesarchitectuur is om sneller waarde te leveren en adaptief te zijn om te veranderen door flexibele procedures te volgen. De Methodologie van de Twaalf-Factor-app biedt richtlijnen voor het bouwen van onderhoudbare en schaalbare toepassingen. Deze richtlijnen bevorderen kenmerken zoals onveranderbaarheid, kortstondigheid, declaratieve configuratie en automatisering. Door deze richtlijnen op te nemen en veelvoorkomende valkuilen te vermijden, kunt u losjes gekoppelde, zelfstandige microservices maken.

Inzicht in de uitgevouwen benadering

Het transformeren van een monolithische toepassing naar een microservicesarchitectuur kost tijd. Begin met edge-services. Edge-services hebben minder afhankelijkheden van andere services en kunnen eenvoudig worden uitgesplitsd van het systeem als onafhankelijke services. We raden patronen zoals Strangler Fig en anti-corruptielaag ten zeerste aan om de monolithische toepassing in een werkende toestand te houden totdat alle services zijn opgesplitst in afzonderlijke microservices. Tijdens de scheiding kunnen de principes van DDD teams helpen bij het kiezen van onderdelen of services uit de monolithische toepassing op basis van subdomeinen.

In een e-commercesysteem hebt u bijvoorbeeld de volgende modules: winkelwagen, productbeheer, orderbeheer, prijzen, factuurgeneratie en meldingen. U besluit om de transformatie van de toepassing te starten met de meldingsmodule, omdat deze geen afhankelijkheden heeft van andere modules. Andere modules kunnen echter afhankelijk zijn van deze module om meldingen te verzenden. De meldingsmodule kan eenvoudig worden opgesplitst in een afzonderlijke microservice, maar u moet enkele wijzigingen aanbrengen in de monolithische toepassing om de nieuwe meldingsservice aan te roepen. U besluit de volgende module voor het genereren van facturen te transformeren. Deze module wordt aangeroepen nadat een order is gegenereerd. U kunt patronen zoals Strangler en Anti-corruptie gebruiken om deze transformatie te ondersteunen.

Gegevenssynchronisatie, meervoudige schrijfbewerkingen naar monolithische en microserviceinterfaces, gegevenseigendom, schemaontleding, joins, gegevensvolume en gegevensintegriteit kunnen het uitsplitsen en migreren van gegevens lastig maken. Er zijn verschillende technieken die u kunt gebruiken, zoals het bewaren van een gedeelde database tussen microservices, het loskoppelen van databases uit een groep services op basis van bedrijfsfunctionaliteit of domein en het isoleren van databases uit de services. De aanbevolen oplossing is om elke database met elke service te ontleden. In veel omstandigheden is dat niet praktisch. In dergelijke gevallen kunt u patronen zoals het patroon Databaseweergave en het Patroon Database Wrapping Service gebruiken.

DevOps-gereedheid beoordelen

Wanneer u overstapt op een microservicearchitectuur, is het belangrijk om uw DevOps-competentie te beoordelen. Een microservicesarchitectuur is bedoeld om flexibele ontwikkeling in toepassingen te vergemakkelijken om de flexibiliteit van de organisatie te vergroten. DevOps is een van de belangrijkste procedures die u moet implementeren om deze competentie te bereiken.

Wanneer u uw DevOps-functie voor een microservicesarchitectuur evalueert, moet u rekening houden met de volgende punten:

  • Kennen personen in uw organisatie de fundamentele procedures en principes van DevOps?
  • Begrijpen teams de hulpprogramma's voor broncodebeheer en hun integratie met CI/CD-pijplijnen?
  • Implementeert u DevOps-procedures correct?
    • Volg je agile-procedures?
    • Wordt continue integratie geïmplementeerd?
    • Wordt continue levering geïmplementeerd?
    • Wordt continue implementatie geïmplementeerd?
    • Wordt continue bewaking geïmplementeerd?
    • Is Infrastructure as Code (IaC) aanwezig?
  • Gebruikt u de juiste hulpprogramma's ter ondersteuning van CI/CD?
  • Hoe wordt de configuratie van faserings- en productieomgevingen beheerd voor de toepassing?
  • Heeft de toolketen ondersteuning voor de community en een ondersteuningsmodel en biedt deze de juiste kanalen en documentatie?

Bedrijfsgebieden identificeren die regelmatig veranderen

Een microservicesarchitectuur is flexibel en aanpasbaar. Tijdens de evaluatie voert u een discussie in de organisatie uit om te bepalen welke gebieden uw collega's vaak zullen veranderen. Door microservices te bouwen, kunnen teams snel reageren op wijzigingen die klanten aanvragen en regressietests minimaliseren. In een monolithische toepassing vereist een wijziging in één module talloze niveaus van regressietests en vermindert de flexibiliteit bij het vrijgeven van nieuwe versies.

Houd rekening met deze factoren:

  • Kan de service onafhankelijk worden geïmplementeerd?
  • Voldoet de service aan DDD-principes?
  • Volgt de service SOLID-principes?
  • Is de database privé voor de service?
  • Hebt u de service gebouwd met behulp van het ondersteunde microserviceschassispatroon?

Gereedheid van infrastructuur beoordelen

Wanneer u overstapt op een microservicesarchitectuur, is de gereedheid van de infrastructuur een essentieel punt om rekening mee te houden. De prestaties, beschikbaarheid en schaalbaarheid van de toepassing worden beïnvloed als de infrastructuur niet goed is ingesteld of als de juiste services of onderdelen niet worden gebruikt. Soms wordt er een toepassing gemaakt met alle voorgestelde methodologieën en procedures, maar de infrastructuur is ontoereikend. Dit resulteert in slechte prestaties en onderhoud.

Houd rekening met deze factoren wanneer u de gereedheid van uw infrastructuur evalueert:

  • Zorgt de infrastructuur voor de schaalbaarheid van de geïmplementeerde services?
  • Biedt de infrastructuur ondersteuning voor het inrichten via scripts die kunnen worden geautomatiseerd via CI/CD?
  • Biedt de implementatie-infrastructuur een SLA voor beschikbaarheid?
  • Hebt u een noodherstelplan en routineanalyseschema's?
  • Worden de gegevens gerepliceerd naar verschillende regio's voor herstel na noodgevallen?
  • Hebt u een back-upplan voor gegevens?
  • Worden de implementatieopties gedocumenteerd?
  • Wordt de implementatie-infrastructuur bewaakt?
  • Ondersteunt de implementatie-infrastructuur zelfherstel van services?

Releasecycli evalueren

Microservices zijn adaptief om te veranderen en te profiteren van flexibele ontwikkeling om releasecycli te verkorten en waarde te bieden aan klanten. Houd rekening met deze factoren wanneer u uw releasecycli evalueert:

  • Hoe vaak bouwt en releaset u toepassingen?
  • Hoe vaak mislukken uw releases na de implementatie?
  • Hoe lang duurt het om problemen na een storing te herstellen of op te lossen?
  • Gebruikt u semantische versiebeheer voor uw toepassingen?
  • Onderhoudt u verschillende omgevingen en voert u dezelfde release in een reeks door (bijvoorbeeld eerst naar fasering en vervolgens naar productie)?
  • Gebruikt u versiebeheer voor uw API's?
  • Voldoet u aan de juiste richtlijnen voor versiebeheer voor API's?
  • Wanneer wijzigt u een API-versie?
  • Wat is uw benadering voor het verwerken van API-versiebeheer?
    • Versiebeheer van URI-pad
    • Versiebeheer van queryparameters
    • Versiebeheer van inhoudstype
    • Aangepaste headerversiebeheer
  • Hebt u een praktijk voor het versiebeheer van gebeurtenissen?

Communicatie tussen services evalueren

Microservices zijn zelfstandige services die met elkaar communiceren over procesgrenzen om bedrijfsscenario's aan te pakken. Als u betrouwbare en betrouwbare communicatie wilt krijgen, moet u een geschikt communicatieprotocol selecteren.

Neem rekening met deze factoren:

  • Volgt u een API-eerste benadering, waarbij API's worden behandeld als eersteklas burgers?
  • Hebt u bewerkingen met lange ketens, waarbij meerdere services op volgorde communiceren via een synchrone communicatieprotocol?
  • Hebt u overal in het systeem rekening gehouden met asynchrone communicatie?
  • Hebt u de berichtbrokertechnologie en de mogelijkheden ervan beoordeeld?
  • Begrijpt u de doorvoer van berichten die services ontvangen en verwerken?
  • Gebruikt u directe client-naar-service-communicatie?
  • Moet u berichten behouden op berichtbrokerniveau?
  • Gebruikt u het patroon Gerealiseerde weergave om het chatty-gedrag van microservices aan te pakken?
  • Hebt u Retry, Circuit Breaker, Exponential Backoff en Jitter geïmplementeerd voor betrouwbare communicatie? Een veelgebruikte manier om dit te doen, is door het Ambassadeur-patroon te gebruiken.
  • Hebt u domeinevenementen gedefinieerd om de communicatie tussen microservices te vergemakkelijken?

Evalueren hoe services beschikbaar zijn voor clients

Een API-gateway is een van de kernonderdelen in een microservicesarchitectuur. Het rechtstreeks beschikbaar maken van services aan de clients leidt tot problemen met betrekking tot beheerbaarheid, controle en betrouwbare communicatie. Een API-gateway fungeert als een proxyserver, het onderscheppen van verkeer en het doorsturen naar back-endservices. Als u verkeer wilt filteren op IP-adres, autorisatie, gesimuleerde antwoorden, enzovoort, kunt u dit doen op API-gatewayniveau zonder wijzigingen aan te brengen in de services.

Neem rekening met deze factoren:

  • Worden de services rechtstreeks gebruikt door clients?
  • Is er een API-gateway die fungeert als een gevel voor alle services?
  • Kan de API-gateway beleidsregels instellen, zoals quotumlimieten, gesimuleerde antwoorden en filteren van IP-adressen?
  • Gebruikt u meerdere API-gateways om tegemoet te komen aan de behoeften van verschillende typen clients, zoals mobiele apps, web-apps en partners?
  • Biedt uw API-gateway een portal waar clients services kunnen detecteren en abonneren, zoals een ontwikkelaarsportal in Azure API Management?
  • Biedt uw oplossing L7-taakverdelings- of WAF-mogelijkheden (Web Application Firewall) samen met de API-gateway?

Transactieafhandeling evalueren

Gedistribueerde transacties vergemakkelijken de uitvoering van meerdere bewerkingen als één werkeenheid. In een microservicesarchitectuur wordt het systeem opgesplitst in talloze services. Eén bedrijfsgebruiksscenario wordt aangepakt door meerdere microservices als onderdeel van één gedistribueerde transactie. In een gedistribueerde transactie is een opdracht een bewerking die begint wanneer een gebeurtenis plaatsvindt. De gebeurtenis activeert een bewerking in het systeem. Als de bewerking slaagt, kan er een andere opdracht worden geactiveerd, die vervolgens een andere gebeurtenis kan activeren, enzovoort totdat alle transacties zijn voltooid of teruggedraaid, afhankelijk van of de transactie slaagt.

Neem rekening met de volgende overwegingen:

  • Hoeveel gedistribueerde transacties zijn er in het systeem?
  • Wat is uw benadering voor het verwerken van gedistribueerde transacties? Evalueer het gebruik van het Saga-patroon met orchestration of choreografie.
  • Hoeveel transacties omvatten meerdere services?
  • Volgt u een ACID- of BASE-transactiemodel om gegevensconsistentie en -integriteit te bereiken?
  • Gebruikt u bewerkingen voor lange ketens voor transacties die meerdere services omvatten?

Uw serviceontwikkelingsmodel evalueren

Een van de grootste voordelen van microservicesarchitecturen is technologiediversiteit. Op microservices gebaseerde systemen stellen teams in staat om services te ontwikkelen met behulp van de technologieën die ze kiezen. Bij traditionele toepassingsontwikkeling kunt u bestaande code hergebruiken wanneer u nieuwe onderdelen bouwt of een intern ontwikkelframework maakt om de ontwikkelingsinspanningen te verminderen. Het gebruik van meerdere technologieën kan hergebruik van code voorkomen.

Houd rekening met deze factoren:

  • Gebruikt u een servicesjabloon om nieuwe serviceontwikkeling te starten?
  • Volgt u de Twaalf-Factor-app-methodologie en gebruikt u één codebasis voor microservices, het isoleren van afhankelijkheden en het externaliseren van de configuratie?
  • Houdt u gevoelige configuratie in sleutelkluizen?
  • Zet u uw services in een container?
  • Kent u de vereisten voor gegevensconsistentie?

Uw implementatiebenadering evalueren

Uw implementatiemethode is uw methode voor het vrijgeven van versies van uw toepassing in verschillende implementatieomgevingen. Op microservices gebaseerde systemen bieden de flexibiliteit om versies sneller vrij te geven dan met traditionele toepassingen.

Houd rekening met de volgende factoren wanneer u uw implementatieplan evalueert:

  • Hebt u een strategie voor het implementeren van uw services?
  • Gebruikt u moderne hulpprogramma's en technologieën om uw services te implementeren?
  • Wat voor soort samenwerking is vereist tussen teams wanneer u services implementeert?
  • Richt u infrastructuur in met behulp van Infrastructure as Code (IaC)?
  • Gebruikt u DevOps-mogelijkheden om implementaties te automatiseren?
  • Hebt u dezelfde builds doorgegeven aan meerdere omgevingen, zoals voorgesteld door de Twaalf-Factor-app-methodologie?

Uw hostingplatform beoordelen

Schaalbaarheid is een van de belangrijkste voordelen van microservicesarchitecturen. Dat komt doordat microservices worden toegewezen aan bedrijfsdomeinen, zodat elke service onafhankelijk kan worden geschaald. Een monolithische toepassing wordt geïmplementeerd als één eenheid op een hostingplatform en moet holistisch worden geschaald. Dit resulteert in downtime, implementatierisico en onderhoud. Uw monolithische toepassing is mogelijk goed ontworpen, met onderdelen die betrekking hebben op afzonderlijke bedrijfsdomeinen. Maar vanwege een gebrek aan procesgrenzen wordt het potentieel voor het schenden van de beginselen van één verantwoordelijkheid moeilijker. Dit resulteert uiteindelijk in spaghetticode. Omdat de toepassing is samengesteld en geïmplementeerd als één hostingproces, is schaalbaarheid moeilijk.

Met microservices kunnen teams het juiste hostingplatform kiezen om hun schaalbaarheidsbehoeften te ondersteunen. Er zijn verschillende hostingplatforms beschikbaar om deze uitdagingen aan te pakken door mogelijkheden te bieden zoals automatisch schalen, elastisch inrichten, hogere beschikbaarheid, snellere implementatie en eenvoudige bewaking.

Houd rekening met deze factoren:

  • Welk hostingplatform gebruikt u voor het implementeren van uw services (virtuele machines, containers, serverloos)?
  • Is het hostingplatform schaalbaar? Ondersteunt het automatisch schalen?
  • Hoe lang duurt het om uw hostingplatform te schalen?
  • Begrijpt u de SLA's die verschillende hostingplatforms bieden?
  • Biedt uw hostingplatform ondersteuning voor herstel na noodgevallen?

Services bewaken

Bewaking is een belangrijk element van een toepassing op basis van microservices. Omdat de toepassing is onderverdeeld in een aantal services die onafhankelijk van elkaar worden uitgevoerd, kan het lastig zijn om fouten op te lossen. Als u de juiste semantiek gebruikt om uw services te bewaken, kunnen uw teams eenvoudig fouten bewaken, onderzoeken en erop reageren.

Houd rekening met deze factoren:

  • Controleert u uw geïmplementeerde services?
  • Hebt u een mechanisme voor logboekregistratie? Welke hulpprogramma's gebruikt u?
  • Beschikt u over een gedistribueerde traceringsinfrastructuur?
  • Registreert u uitzonderingen?
  • Onderhoudt u bedrijfsfoutcodes voor snelle identificatie van problemen?
  • Gebruikt u statustests voor services?
  • Gebruikt u semantische logboekregistratie? Hebt u belangrijke metrische gegevens, drempelwaarden en indicatoren geïmplementeerd?
  • Maskert u gevoelige gegevens tijdens logboekregistratie?

Correlatietokentoewijzing evalueren

In een microservicesarchitectuur bestaat een toepassing uit verschillende microservices die onafhankelijk van elkaar worden gehost en die met elkaar communiceren om verschillende zakelijke gebruiksvoorbeelden te bedienen. Wanneer een toepassing communiceert met back-endservices om een bewerking uit te voeren, kunt u een uniek getal, ook wel een correlatietoken genoemd, toewijzen aan de aanvraag. U wordt aangeraden correlatietokens te gebruiken, omdat ze u kunnen helpen bij het oplossen van fouten. Ze helpen u de hoofdoorzaak van een probleem te bepalen, de impact te beoordelen en een benadering te bepalen om het probleem op te lossen.

U kunt correlatietokens gebruiken om het aanvraagtrail op te halen door te identificeren welke services het correlatietoken bevatten en welke niet. De services die niet over het correlatietoken voor die aanvraag beschikken, zijn mislukt. Als er een fout optreedt, kunt u de transactie later opnieuw proberen. Om idempotentie af te dwingen, dienen alleen services die niet over het correlatietoken beschikken de aanvraag.

Als u bijvoorbeeld een lange reeks bewerkingen hebt waarbij veel services zijn betrokken, kunt u met het doorgeven van een correlatietoken aan services problemen eenvoudig onderzoeken als een van de services mislukt tijdens een transactie. Elke service heeft meestal een eigen database. Het correlatietoken wordt bewaard in de databaserecord. In het geval van een transactieherhaling negeren services met dat specifieke correlatietoken in hun databases de aanvraag. Alleen services die niet over het token beschikken, dienen de aanvraag.

Houd rekening met deze factoren:

  • In welke fase wijst u het correlatietoken toe?
  • Welk onderdeel wijst het correlatietoken toe?
  • Slaat u correlatietokens op in de database van de service?
  • Wat is de indeling van correlatietokens?
  • Worden correlatietokens en andere aanvraaggegevens vastgelegd?

De behoefte aan een microservicechassisframework evalueren

Een microserviceschassisframework is een basisframework dat mogelijkheden biedt voor kruislingse problemen, zoals logboekregistratie, afhandeling van uitzonderingen, gedistribueerde tracering, beveiliging en communicatie. Wanneer u een chassisframework gebruikt, richt u zich meer op het implementeren van de servicegrens dan interactie met infrastructuurfunctionaliteit.

Stel dat u een winkelwagenbeheerservice bouwt. U wilt het binnenkomende token valideren, logboeken naar de logboekregistratiedatabase schrijven en met een andere service communiceren door het eindpunt van die service aan te roepen. Als u een chassisframework voor microservices gebruikt, kunt u de ontwikkelingsinspanningen verminderen. Dapr is een systeem dat verschillende bouwstenen biedt voor het implementeren van kruislingse problemen.

Houd rekening met deze factoren:

  • Gebruikt u een chassisframework voor microservices?
  • Gebruikt u Dapr om te communiceren met kruislingse problemen?
  • Is uw chassisframework taal agnostisch?
  • Is uw chassisframework algemeen, zodat het allerlei toepassingen ondersteunt? Een chassisframework mag geen toepassingsspecifieke logica bevatten.
  • Biedt uw chassisframework een mechanisme voor het gebruik van de geselecteerde onderdelen of services, indien nodig?

Uw benadering voor het testen van toepassingen beoordelen

Normaal gesproken wordt het testen uitgevoerd nadat de ontwikkeling is voltooid en is de toepassing klaar om te worden geïmplementeerd voor gebruikersacceptatietests (UAT) en productieomgevingen. Er is momenteel een verschuiving in deze benadering, waarbij het testen vroeg (links) in de ontwikkelingslevenscyclus van toepassingen wordt verplaatst. Met shift-left testen wordt de kwaliteit van toepassingen verhoogd, omdat er tests worden uitgevoerd tijdens elke fase van de levenscyclus van de toepassingsontwikkeling, met inbegrip van de ontwerp-, ontwikkelings- en postontwikkelingsfasen.

Wanneer u bijvoorbeeld een toepassing bouwt, begint u met het ontwerpen van een architectuur. Wanneer u de shift-left-benadering gebruikt, test u het ontwerp voor beveiligingsproblemen met behulp van hulpprogramma's zoals Microsoft Threat Modeling. Wanneer u begint met ontwikkelen, kunt u uw broncode scannen door hulpprogramma's zoals SAST (Static Application Security Testing) uit te voeren en andere analysefuncties te gebruiken om problemen te ontdekken. Nadat u de toepassing hebt geïmplementeerd, kunt u hulpprogramma's zoals dynamische toepassingsbeveiligingstests (DAST) gebruiken om deze te testen terwijl deze wordt gehost. Functionele tests, chaostests, penetratietests en andere soorten testen worden later uitgevoerd.

Houd rekening met deze factoren:

  • Schrijft u testplannen die betrekking hebben op de volledige ontwikkelingslevenscyclus?
  • Neemt u testers op in vergaderingen met vereisten en in de volledige levenscyclus van de ontwikkeling van toepassingen?
  • Gebruikt u testgestuurd ontwerp of gedragsgestuurd ontwerp?
  • Test u gebruikersverhalen? Neemt u acceptatiecriteria op in uw gebruikersverhalen?
  • Test u uw ontwerp met behulp van hulpprogramma's zoals Microsoft Threat Modeling?
  • Schrijft u eenheidstests?
  • Gebruikt u statische codeanalyses of andere hulpprogramma's om de kwaliteit van code te meten?
  • Gebruikt u geautomatiseerde hulpprogramma's om toepassingen te testen?
  • Implementeert u Secure DevOps-procedures ?
  • Voert u integratietests, end-to-end toepassingstests, belasting-/prestatietests, penetratietests en chaostests uit?

Microservicesbeveiliging evalueren

Servicebeveiliging, beveiligde toegang en beveiligde communicatie zijn een van de belangrijkste overwegingen voor een microservicesarchitectuur. Een op microservices gebaseerd systeem dat meerdere services omvat en tokenvalidatie voor elke service gebruikt, is bijvoorbeeld geen haalbare oplossing. Dit systeem zou van invloed zijn op de flexibiliteit van het algehele systeem en het potentieel van de invoering van implementatiedrift tussen services.

Beveiligingsproblemen worden meestal afgehandeld door de API-gateway en de toepassingsfirewall. De gateway en firewall nemen binnenkomende aanvragen, valideren tokens en passen verschillende filters en beleidsregels toe, zoals het implementeren van OWASP Top 10-principes om verkeer te onderscheppen. Ten slotte verzenden ze de aanvraag naar de back-end microservices. Deze configuratie helpt ontwikkelaars zich te concentreren op bedrijfsbehoeften in plaats van de kruislingse zorg voor beveiliging.

Houd rekening met deze factoren:

  • Zijn verificatie en autorisatie vereist voor de service?
  • Gebruikt u een API-gateway om tokens en binnenkomende aanvragen te valideren?
  • Gebruikt u SSL of mTLS om beveiliging te bieden voor servicecommunicatie?
  • Beschikt u over netwerkbeveiligingsbeleid om de vereiste communicatie tussen services mogelijk te maken?
  • Gebruikt u firewalls (L4, L7) waar van toepassing om beveiliging te bieden voor interne en externe communicatie?
  • Gebruikt u beveiligingsbeleid in API Gateway om verkeer te beheren?

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen