Overwegingen bij het ontwerp van hybride apps

  • Artikel

Microsoft Azure is de enige consistente hybride cloud. Hiermee kunt u uw ontwikkelingsinvesteringen hergebruiken en apps gebruiken die wereldwijd Azure, onafhankelijke Azure-clouds en Azure Stack kunnen overspannen. Dit is een uitbreiding van Azure in uw datacenter. Apps die clouds bespannen, worden ook wel hybride apps genoemd.

In Azure-toepassing Architecture Guide wordt een gestructureerde benadering beschreven voor het ontwerpen van apps die schaalbaar, flexibel en zeer beschikbaar zijn. De overwegingen die worden beschreven in Azure-toepassing Architectuurhandleiding gelden ook voor apps die zijn ontworpen voor één cloud en voor apps die clouds bespannen.

Dit artikel is een uitbreiding van de pijlers van softwarekwaliteit die worden besproken in de handleiding Azure-toepassingArchitecture, met name gericht op het ontwerpen van hybride apps. Daarnaast voegen we een plaatsingspijler toe, omdat hybride apps niet exclusief zijn voor één cloud of één on-premises datacenter.

Hybride scenario's variëren sterk met de resources die beschikbaar zijn voor ontwikkeling en gaan over overwegingen zoals geografie, beveiliging, internettoegang en andere overwegingen. Hoewel deze handleiding uw specifieke overwegingen niet kan opsnoemen, kan deze enkele belangrijke richtlijnen en best practices bieden die u kunt volgen. Het ontwerpen, configureren, implementeren en onderhouden van een hybride app-architectuur omvat veel ontwerpoverwegingen die mogelijk niet inherent bij u bekend zijn.

Dit document is gericht op het samenvoegen van de mogelijke vragen die zich kunnen voordoen bij het implementeren van hybride apps en biedt overwegingen (deze pijlers) en best practices om hiermee te werken. Door deze vragen tijdens de ontwerpfase aan te pakken, vermijdt u de problemen die ze in productie kunnen veroorzaken.

In wezen zijn dit vragen waarmee u moet nadenken voordat u een hybride app maakt. Om aan de slag te gaan, moet u het volgende doen:

  • De app-onderdelen identificeren en evalueren.
  • App-onderdelen evalueren op basis van de pijlers.

De app-onderdelen evalueren

Elk onderdeel van een app heeft een eigen specifieke rol binnen de grotere app en moet worden gecontroleerd met alle ontwerpoverwegingen. De vereisten en functies van elk onderdeel moeten aan deze overwegingen worden aangepast om de app-architectuur te helpen bepalen.

U kunt uw app opdelen in onderdelen door de architectuur van uw app te bestuderen en te bepalen waar deze uit bestaat. Onderdelen kunnen ook andere apps bevatten waarmee uw app communiceert. Wanneer u de onderdelen identificeert, evalueert u de beoogde hybride bewerkingen op basis van hun kenmerken door deze vragen te stellen:

  • Wat is het doel van het onderdeel?
  • Wat zijn de onderlinge afhankelijkheden tussen de onderdelen?

Een app kan bijvoorbeeld een front-end en back-end hebben gedefinieerd als twee onderdelen. In een hybride scenario is de front-end in de ene cloud en de back-end in de andere. De app biedt communicatiekanalen tussen de front-end en de gebruiker, en ook tussen de front-end en de back-end.

Een app-onderdeel wordt gedefinieerd in veel vormen en scenario's. De belangrijkste taak is het identificeren van deze personen en hun locatie in de cloud of on-premises.

De algemene app-onderdelen die u in uw inventaris moet opnemen, worden vermeld in tabel 1.

Tabel 1. Algemene app-onderdelen

Onderdeel Richtlijnen voor hybride apps
Clientverbindingen Uw app (op elk apparaat) heeft op verschillende manieren toegang tot gebruikers, vanaf één toegangspunt, waaronder de volgende manieren:
- Een client-servermodel dat vereist dat de gebruiker een client heeft geïnstalleerd om met de app te kunnen werken. Een servergebaseerde app die wordt geopend vanuit een browser.
- Clientverbindingen kunnen meldingen bevatten wanneer de verbinding wordt verbroken of waarschuwingen wanneer roamingkosten van toepassing kunnen zijn.
Verificatie Verificatie kan vereist zijn voor een gebruiker die verbinding maakt met de app of van het ene onderdeel dat verbinding maakt met een ander onderdeel.
API's U kunt ontwikkelaars programmatische toegang tot uw app bieden met API-sets en klassebibliotheken en een verbindingsinterface bieden op basis van internetstandaarden. U kunt ook API's gebruiken om een app op te maken in onafhankelijk operationele logische eenheden.
Services U kunt beknopte services gebruiken om de functies voor een app te bieden. Een service kan de engine zijn waarmee de app wordt uitgevoerd.
Wachtrijen U kunt wachtrijen gebruiken om de status van de levenscyclus en status van de onderdelen van uw app te ordenen. Deze wachtrijen kunnen berichten, meldingen en buffermogelijkheden bieden voor abonnerende partijen.
Gegevensopslag Een app kan staatloos of stateful zijn. Stateful apps hebben gegevensopslag nodig die kan worden bereikt door talloze indelingen en volumes.
Gegevens in de cache Een onderdeel voor gegevensopslag in uw ontwerp kan strategisch latentieproblemen aanpakken en een rol spelen bij het activeren van bursting in de cloud.
Gegevensopname Gegevens kunnen op verschillende manieren naar een app worden verzonden, variërend van door de gebruiker verzonden waarden in een webformulier tot continu grote hoeveelheden gegevensstromen.
Gegevensverwerking Uw taken voor gegevensverwerking (zoals rapporten, analyses, batchexports en gegevenstransformatie) kunnen worden verwerkt bij de bron of worden ge-offload op een afzonderlijk onderdeel met behulp van een kopie van de gegevens.

App-onderdelen beoordelen op pijlers

Evalueer voor elk onderdeel de kenmerken voor elke pijler. Wanneer u elk onderdeel evalueert met alle pijlers, worden mogelijk vragen die u niet hebt overwogen bekend bij u die van invloed zijn op het ontwerp van de hybride app. Het kan een toegevoegde waarde zijn om uw app te optimaliseren door op deze overwegingen te handelen. Tabel 2 bevat een beschrijving van elke pijler die betrekking heeft op hybride apps.

Tabel 2. Pijlers

Pijler Beschrijving
Plaatsing De strategische plaatsing van onderdelen in hybride apps.
Schaalbaarheid De mogelijkheid van een systeem om toegenomen belasting af te handelen.
Beschikbaarheid Het deel van de tijd dat een hybride app functioneel en werkend is.
Flexibiliteit De mogelijkheid voor een hybride app om te herstellen.
Beheerbaarheid Operationele processen die ervoor zorgen dat een systeem blijft werken.
Beveiliging Hybride apps en gegevens beschermen tegen bedreigingen.

Plaatsing

Een hybride app heeft inherent een plaatsingsoverweging, zoals voor het datacenter.

Plaatsing is de belangrijke taak van het plaatsen van onderdelen, zodat ze een hybride app het beste kunnen gebruiken. Hybride apps kunnen per definitie locaties overspannen, zoals van on-premises naar de cloud en tussen verschillende clouds. U kunt onderdelen van de app op twee manieren in clouds plaatsen:

  • Verticale hybride apps
    App-onderdelen worden verdeeld over verschillende locaties. Elk afzonderlijk onderdeel kan meerdere exemplaren hebben die zich slechts op één locatie bevinden.

  • Horizontale hybride apps
    App-onderdelen worden verdeeld over verschillende locaties. Elk afzonderlijk onderdeel kan meerdere exemplaren hebben die meerdere locaties beslaat.

    Sommige onderdelen kunnen zich bewust zijn van hun locatie, terwijl andere geen kennis hebben van hun locatie en plaatsing. Deze opwaartse inspanning kan worden bereikt met een abstractielaag. Deze laag, met een modern app-framework zoals microservices, kan definiëren hoe de app wordt gebruikt door de plaatsing van app-onderdelen die op knooppunten in clouds werken.

Controlelijst voor plaatsing

Controleer de vereiste locaties. Zorg ervoor dat de app of een van de onderdelen ervan moet werken in of certificering vereist voor een specifieke cloud. Dit kan de onafhankelijkheidsvereisten van uw bedrijf zijn of die door de wet zijn bepaald. Bepaal ook of er on-premises bewerkingen vereist zijn voor een bepaalde locatie of locatie.

Connectiviteitsafhankelijkheden vaststellen. Vereiste locaties en andere factoren kunnen de connectiviteitsafhankelijkheden tussen uw onderdelen bepalen. Als u de onderdelen plaats, bepaalt u de optimale connectiviteit en beveiliging voor communicatie tussen de onderdelen. Opties zijn VPN,ExpressRoute en hybride verbindingen.

Platformmogelijkheden evalueren. Kijk voor elk app-onderdeel of de vereiste resourceprovider voor het app-onderdeel beschikbaar is in de cloud en of de bandbreedte voldoet aan de verwachte doorvoer- en latentievereisten.

Draagbaarheid plannen. Gebruik moderne app-frameworks, zoals containers of microservices, om te plannen voor het verplaatsen van bewerkingen en om serviceafhankelijkheden te voorkomen.

Vereisten voor gegevenssoevereiniteit bepalen. Hybride apps zijn gericht op het geschikt maken van gegevensisolatie, zoals op een lokaal datacenter. Bekijk de plaatsing van uw resources om het succes te optimaliseren voor het voldoen aan deze vereiste.

Plan voor latentie. Bewerkingen tussen de cloud kunnen fysieke afstand tussen de app-onderdelen tot zich nemen. De vereisten vaststellen om rekening te houden met eventuele latentie.

Verkeersstromen beheren. Omgaan met piekgebruik en de juiste en beveiligde communicatie voor persoonlijke identificeerbare gegevens wanneer deze worden gebruikt door de front-end in een openbare cloud.

Schaalbaarheid

Schaalbaarheid is de mogelijkheid van een systeem om een verhoogde belasting van een app aan te kunnen, wat in de tijd kan variëren als andere factoren en druk op de grootte van de doelgroep, naast de grootte en het bereik van de app.

Zie Schaalbaarheid in de vijf pijlers van topprestaties in de architectuur voor de belangrijkste bespreking van deze pijler.

Met een horizontale schaalbenadering voor hybride apps kunt u meer exemplaren toevoegen om aan de vraag te voldoen en ze vervolgens uit te stellen tijdens mindere perioden.

In hybride scenario's vereist het uitschalen van afzonderlijke onderdelen extra overweging wanneer onderdelen worden verdeeld over clouds. Voor het schalen van het ene deel van de app kan het schalen van een ander onderdeel vereist zijn. Als het aantal clientverbindingen bijvoorbeeld toeneemt, maar de webservices van de app niet op de juiste manier worden geschaald, kan de belasting van de database de app verzadigen.

Sommige app-onderdelen kunnen lineair worden geschaald, terwijl andere afhankelijkheden voor schalen hebben en mogelijk beperkt zijn tot in welke mate ze kunnen worden geschaald. Een VPN-tunnel die hybride connectiviteit biedt voor de locaties van app-onderdelen heeft bijvoorbeeld een limiet voor de bandbreedte en latentie waar deze naar kan worden geschaald. Hoe worden onderdelen van de app geschaald om ervoor te zorgen dat aan deze vereisten wordt voldaan?

Controlelijst voor schaalbaarheid

Drempelwaarden voor schalen vaststellen. Als u de verschillende afhankelijkheden in uw app wilt afhandelen, bepaalt u in welke mate app-onderdelen in verschillende clouds onafhankelijk van elkaar kunnen worden geschaald, terwijl u wel voldoet aan de vereisten voor het uitvoeren van de app. Hybride apps moeten vaak bepaalde gebieden in de app schalen om een functie te verwerken terwijl deze communiceert en van invloed is op de rest van de app. Als u bijvoorbeeld een aantal front-end-exemplaren overschrijdt, moet de back-end mogelijk worden geschaald.

Schaalschema's definiëren. De meeste apps hebben drukke perioden, dus u moet hun piektijden samenvoegen in schema's om optimaal schalen te coördineren.

Gebruik een gecentraliseerd bewakingssysteem. Platformbewakingsmogelijkheden kunnen automatische schalen bieden, maar hybride apps hebben een gecentraliseerd bewakingssysteem nodig waarmee de systeemtoestand en -belasting worden geaggregeerd. Een gecentraliseerd bewakingssysteem kan het schalen van een resource op de ene locatie initiëren en schalen, afhankelijk van de resource op een andere locatie. Daarnaast kan een centraal bewakingssysteem bijhouden welke clouds resources automatisch schalen en welke clouds niet.

Maak gebruik van mogelijkheden voor automatisch schalen (zo beschikbaar). Als mogelijkheden voor automatisch schalen deel uitmaken van uw architectuur, implementeert u automatisch schalen door drempelwaarden in te stellen die bepalen wanneer een app-onderdeel omhoog, uit, omlaag of in moet worden geschaald. Een voorbeeld van automatisch schalen is een clientverbinding die automatisch wordt geschaald in de ene cloud om verhoogde capaciteit af te handelen, maar die ervoor zorgt dat andere afhankelijkheden van de app, verspreid over verschillende clouds, ook worden geschaald. De mogelijkheden voor automatisch schalen van deze afhankelijke onderdelen moeten worden vastgesteld.

Als automatisch schalen niet beschikbaar is, kunt u scripts en andere resources implementeren om handmatig schalen mogelijk te maken, geactiveerd door drempelwaarden in het gecentraliseerde bewakingssysteem.

Bepaal de verwachte belasting per locatie. Hybride apps die clientaanvragen verwerken, zijn mogelijk voornamelijk afhankelijk van één locatie. Wanneer de belasting van clientaanvragen een drempelwaarde overschrijdt, kunnen er op een andere locatie extra resources worden toegevoegd om de belasting van binnenkomende aanvragen te verdelen. Zorg ervoor dat de clientverbindingen de toegenomen belasting kunnen verwerken en ook alle geautomatiseerde procedures voor de clientverbindingen kunnen bepalen om de belasting te verwerken.

Beschikbaarheid

Beschikbaarheid is de tijd dat een systeem functioneel is en werkt. Beschikbaarheid wordt gemeten als een percentage van de uptime. App-fouten, infrastructuurproblemen en systeembelasting kunnen allemaal de beschikbaarheid verminderen.

Zie Beschikbaarheid in de vijf pijlers van topprestaties in de architectuur voor de belangrijkste bespreking van deze pijler.

Controlelijst voor beschikbaarheid

Redundantie bieden voor connectiviteit. Hybride apps vereisen connectiviteit tussen de clouds waar de app over is verspreid. U hebt een keuze uit technologieën voor hybride connectiviteit, dus gebruik naast uw primaire technologie een andere technologie om redundantie te bieden met geautomatiseerde failovermogelijkheden als de primaire technologie uitvallen.

Foutdomeinen classificeren. Fouttolerante apps vereisen meerdere foutdomeinen. Foutdomeinen helpen bij het isoleren van het storingspunt, zoals als één harde schijf on-premises uitvalt, als een top-of-rack-switch uitvalt of als het volledige datacenter niet beschikbaar is. In een hybride app kan een locatie worden geclassificeerd als een foutdomein. Met meer beschikbaarheidsvereisten moet u evalueren hoe één foutdomein moet worden geclassificeerd.

Upgradedomeinen classificeren. Upgradedomeinen worden gebruikt om ervoor te zorgen dat exemplaren van app-onderdelen beschikbaar zijn, terwijl andere exemplaren van hetzelfde onderdeel worden voorzien van updates of onderdelenupgrades. Net als bij foutdomeinen kunnen upgradedomeinen worden geclassificeerd door hun plaatsing op meerdere locaties. U moet bepalen of een app-onderdeel kan worden bijgewerkt op de ene locatie voordat het op een andere locatie wordt bijgewerkt, of dat andere domeinconfiguraties vereist zijn. Eén locatie zelf kan meerdere upgradedomeinen hebben.

Exemplaren en beschikbaarheid bijhouden. App-onderdelen met hoge mate kunnen beschikbaar zijn via taakverdeling en synchrone gegevensreplicatie. U moet bepalen hoeveel exemplaren offline kunnen zijn voordat de service wordt onderbroken.

Zelfherstel implementeren. Als een probleem een onderbreking van de beschikbaarheid van apps veroorzaakt, kan een detectie door een bewakingssysteem zelfherstelende activiteiten voor de app initiëren, zoals het leeglopen van het mislukte exemplaar en het opnieuw uitvoeren ervan. Waarschijnlijk is hiervoor een centrale bewakingsoplossing vereist, geïntegreerd met een hybride pijplijn voor continue integratie en continue levering (CI/CD). De app is geïntegreerd met een bewakingssysteem om problemen te identificeren waarvoor een app-onderdeel mogelijk opnieuw moet worden geïnstalleerd. Het bewakingssysteem kan ook hybride CI/CD activeren om het app-onderdeel en mogelijk andere afhankelijke onderdelen op dezelfde of andere locaties opnieuw teploeeren.

Service level agreements (SLA's) onderhouden. Beschikbaarheid is essentieel voor overeenkomsten om verbinding te houden met de services en apps die u met uw klanten hebt. Elke locatie waar uw hybride app afhankelijk van is, kan een eigen SLA hebben. Deze verschillende SLA's kunnen van invloed zijn op de algemene SLA van uw hybride app.

Flexibiliteit

Tolerantie is de mogelijkheid voor een hybride app en systeem om te herstellen van fouten en te blijven functioneren. Het doel van tolerantie is om de app terug te halen naar een volledig functionerende status nadat er een fout optreedt. Tolerantiestrategieën omvatten oplossingen zoals back-up, replicatie en herstel na noodherstel.

Zie Resiliency in the five pillars of architecture excellence (Tolerantie in de vijf pijlers van topprestaties in de architectuur) voor de belangrijkste bespreking van deze pijler.

Controlelijst voor tolerantie

Afhankelijkheden voor herstel na noodgevallen blootleggen. Voor herstel na noodherstel in de ene cloud zijn mogelijk wijzigingen in app-onderdelen in een andere cloud vereist. Als een of meer onderdelen van de ene cloud worden overgeslagen naar een andere locatie, binnen dezelfde cloud of in een andere cloud, moeten de afhankelijke onderdelen op de hoogte worden gesteld van deze wijzigingen. Dit omvat ook de connectiviteitsafhankelijkheden. Voor tolerantie is een volledig getest app-herstelplan voor elke cloud vereist.

Herstelstroom tot stand te laten komen. Bij een effectief ontwerp voor de herstelstroom zijn app-onderdelen geëvalueerd voor de mogelijkheid om buffers, nieuwe pogingen, mislukte gegevensoverdracht opnieuw uit te proberen en, indien nodig, terug te vallen op een andere service of werkstroom. U moet bepalen welk back-upmechanisme moet worden gebruikt, wat de herstelprocedure inhoudt en hoe vaak het wordt getest. U moet ook de frequentie voor zowel incrementele als volledige back-ups bepalen.

Gedeeltelijke herstelmogelijkheden testen. Een gedeeltelijk herstel voor een deel van de app kan gebruikers geruststellen dat niet alles niet beschikbaar is. Dit deel van het plan moet ervoor zorgen dat een gedeeltelijke herstelactiviteit geen neveneffecten heeft, zoals een back-up- en herstelservice die communiceert met de app om deze zonder problemen af te sluiten voordat de back-up wordt gemaakt.

Bepaal de aansttigators voor herstel na noodherstel en wijs verantwoordelijkheid toe. In een herstelplan moet worden beschreven wie en welke rollen back-up- en herstelacties kunnen initiëren naast de back-ups die kunnen worden gemaakt en hersteld.

Zelfherstelende drempelwaarden vergelijken met herstel na noodherstel. Bepaal de zelfherstelmogelijkheden van een app voor het automatisch initiëren van herstel en de tijd die nodig is om zelfherstel van een app te worden beschouwd als een fout of geslaagd. Bepaal de drempelwaarden voor elke cloud.

Controleer de beschikbaarheid van tolerantiefuncties. Bepaal de beschikbaarheid van tolerantiefuncties en -mogelijkheden voor elke locatie. Als een locatie niet de vereiste mogelijkheden biedt, kunt u die locatie integreren in een gecentraliseerde service die de tolerantiefuncties biedt.

Downtimes bepalen. Bepaal de verwachte downtime vanwege onderhoud voor de app als geheel en als app-onderdelen.

Documenteren van procedures voor probleemoplossing. Definieer procedures voor probleemoplossing voor het opnieuw inzetten van resources en app-onderdelen.

Beheerbaarheid

De overwegingen voor het beheren van uw hybride apps zijn essentieel bij het ontwerpen van uw architectuur. Een goed beheerde hybride app biedt een infrastructuur als code waarmee consistente app-code kan worden geïntegreerd in een gemeenschappelijke ontwikkelingspijplijn. Door het consistente systeembrede en afzonderlijke testen van wijzigingen in de infrastructuur te implementeren, kunt u zorgen voor een geïntegreerde implementatie als de wijzigingen slagen voor de tests, zodat ze kunnen worden samengevoegd in de broncode.

Zie DevOps in de vijf pijlers van architectuur-topprestaties voor de kerndiscussie over deze pijler.

Controlelijst voor beheerbaarheid

Bewaking implementeren. Gebruik een gecentraliseerd bewakingssysteem van app-onderdelen verspreid over clouds om een geaggregeerde weergave van hun status en prestaties te bieden. Dit systeem omvat het bewaken van zowel de app-onderdelen als de bijbehorende platformmogelijkheden.

Bepaal de onderdelen van de app die moeten worden gecontroleerd.

Coördinaatbeleid. Elke locatie die een hybride app omvat, kan een eigen beleid hebben dat betrekking heeft op toegestane resourcetypen, naamconventaties, tags en andere criteria.

Rollen definiëren en gebruiken. Als databasebeheerder moet u bepalen welke machtigingen vereist zijn voor verschillende persona's (zoals een app-eigenaar, een databasebeheerder en een eindgebruiker) die toegang nodig hebben tot app-resources. Deze machtigingen moeten worden geconfigureerd voor de resources en in de app. Met een op rollen gebaseerd toegangsbeheersysteem (RBAC) kunt u deze machtigingen instellen voor de app-resources. Deze toegangsrechten zijn lastig wanneer alle resources in één cloud worden geïmplementeerd, maar nog meer aandacht vereisen wanneer de resources zijn verspreid over clouds. Machtigingen voor resources die in de ene cloud zijn ingesteld, zijn niet van toepassing op resources die zijn ingesteld in een andere cloud.

CI/CD-pijplijnen gebruiken. Een CI/CD-pijplijn (Continue integratie en continue ontwikkeling) kan een consistent proces bieden voor het maken en implementeren van apps die clouds bespannen en om kwaliteitscontrole te bieden voor hun infrastructuur en app. Met deze pijplijn kunnen de infrastructuur en app in de ene cloud worden getest en in een andere cloud worden geïmplementeerd. Met de pijplijn kunt u zelfs bepaalde onderdelen van uw hybride app implementeren in de ene cloud en andere onderdelen in een andere cloud, waardoor de basis voor de implementatie van hybride apps wordt gevormd. Een CI/CD-systeem is essentieel voor het verwerken van de afhankelijkheden die app-onderdelen voor elkaar hebben tijdens de installatie, zoals de web-app die een connection string nodig heeft voor de database.

De levenscyclus beheren. Omdat resources van een hybride app locaties kunnen overspannen, moet de levenscyclusbeheermogelijkheid van elke locatie worden samengevoegd in één beheereenheid voor de levenscyclus. Bedenk hoe ze worden gemaakt, bijgewerkt en verwijderd.

Bestudeer strategieën voor probleemoplossing. Het oplossen van problemen met een hybride app omvat meer app-onderdelen dan dezelfde app die in één cloud wordt uitgevoerd. Naast de connectiviteit tussen de clouds wordt de app uitgevoerd op twee platforms in plaats van één platform. Een belangrijke taak bij het oplossen van problemen met hybride apps is het onderzoeken van de geaggregeerde status- en prestatiebewaking van de app-onderdelen.

Beveiliging

Beveiliging is een van de belangrijkste overwegingen voor elke cloud-app en wordt nog belangrijker voor hybride cloud-apps.

Zie Beveiliging in de vijf pijlers van uitmuntendheid van architectuur voor de kerndiscussie over deze pijler.

Controlelijst voor beveiliging

Ga uit van schending. Als één deel van de app is aangetast, moet u ervoor zorgen dat er oplossingen zijn om de verspreiding van de inbreuk te minimaliseren, niet alleen binnen dezelfde locatie, maar ook op meerdere locaties.

Toegestane netwerktoegang bewaken. Bepaal het netwerktoegangsbeleid voor de app, zoals alleen toegang tot de app vanuit een specifiek subnet en sta alleen de minimale poorten en protocollen toe tussen de onderdelen die nodig zijn om de app goed te laten werken.

Robuuste verificatie gebruiken. Een robuust verificatieschema is essentieel voor de beveiliging van uw app. Overweeg het gebruik van een federatieverificatie-id-provider die mogelijkheden voor een enkele aanmelding biedt en gebruik maakt van een of meer van de volgende schema's: gebruikersnaam en wachtwoord, openbare en persoonlijke sleutels, twee-factor of meervoudige verificatie en vertrouwde beveiligingsgroepen. Bepaal de juiste bronnen voor het opslaan van gevoelige gegevens en andere geheimen voor app-verificatie, naast de certificaattypen en hun vereisten.

Versleuteling gebruiken. Bepaal welke gebieden van de app gebruikmaken van versleuteling, zoals voor gegevensopslag of clientcommunicatie en -toegang.

Gebruik beveiligde kanalen. Een beveiligd kanaal in de clouds is essentieel voor het bieden van beveiligings- en verificatiecontroles, realtime-beveiliging, quarantaine en andere services in clouds.

Rollen definiëren en gebruiken. Implementeert rollen voor resourceconfiguraties en toegang met één identiteit in clouds. Bepaal de RBAC-vereisten (op rollen gebaseerd toegangsbeheer) voor de app en de platformbronnen.

Controleer uw systeem. Systeembewaking kan gegevens van zowel de app-onderdelen als de gerelateerde cloudplatformbewerkingen in een logboek opslaan en aggregeren.

Samenvatting

Dit artikel bevat een controlelijst met items die belangrijk zijn om te overwegen tijdens het ontwerpen en ontwerpen van uw hybride apps. Als u deze pijlers bekijkt voordat u uw app implementeert, voorkomt u dat u tijdens productie-uitval tegen deze vragen aan loopt en dat u mogelijk uw ontwerp opnieuw moet bekijken.

Het kan van tevoren een tijdrovende taak lijken, maar u krijgt eenvoudig uw rendement op investeringen als u uw app ontwerpt op basis van deze pijlers.

Volgende stappen

Zie de volgende resources voor meer informatie: