Overwegingen bij het ontwerpen van hybride apps
Microsoft Azure is de enige consistente hybride cloud. Hiermee kunt u uw ontwikkelingsinvesteringen hergebruiken en apps inschakelen die wereldwijd Azure, de onafhankelijke Azure-clouds en Azure Stack kunnen omvatten. Dit is een uitbreiding van Azure in uw datacenter. Apps die clouds omvatten, worden ook wel hybride appsgenoemd.
De Azure Application Architecture Guide beschrijft een gestructureerde benadering voor het ontwerpen van apps die schaalbaar, flexibel en maximaal beschikbaar zijn. De overwegingen die worden beschreven in de Handleiding voor Azure-toepassingsarchitectuur evenzeer van toepassing op apps die zijn ontworpen voor één cloud en voor apps die clouds omvatten.
In dit artikel worden de pijlers van softwarekwaliteit uitgebreid besproken in de Azure ApplicationArchitecture Guide, zich specifiek richten op het ontwerpen van hybride apps. Daarnaast voegen we een plaatsing toe pijler 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 omvatten overwegingen zoals geografie, beveiliging, internettoegang en andere overwegingen. Hoewel deze handleiding uw specifieke overwegingen niet kan inventariseren, kan deze enkele belangrijke richtlijnen en aanbevolen procedures bieden die u kunt volgen. Het ontwerpen, configureren, implementeren en onderhouden van een hybride app-architectuur omvat veel ontwerpoverwegingen die mogelijk niet inherent aan u bekend zijn.
Dit document is bedoeld om de mogelijke vragen te aggregeren die zich kunnen voordoen bij het implementeren van hybride apps en biedt overwegingen (deze pijlers) en aanbevolen procedures om ermee te werken. Door deze vragen tijdens de ontwerpfase aan te pakken, voorkomt u de problemen die ze in productie kunnen veroorzaken.
In wezen zijn dit vragen waarover u moet nadenken voordat u een hybride app maakt. Om aan de slag te gaan, moet u het volgende doen:
- Identificeer en evalueer de app-onderdelen.
- Evalueer app-onderdelen 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 beoordeeld met alle ontwerpoverwegingen. De vereisten en functies van elk onderdeel moeten worden toegewezen aan deze overwegingen om de app-architectuur te bepalen.
U kunt uw app opsplitsen in de 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 bevindt de front-end zich in de ene cloud en bevindt de back-end zich 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 door veel formulieren en scenario's. De belangrijkste taak is het identificeren van ze en hun cloud- of on-premises locatie.
De algemene app-onderdelen die u in uw inventaris wilt opnemen, worden vermeld in tabel 1.
Tabel 1. Algemene app-onderdelen
| component | richtlijnen voor hybride apps |
|---|---|
| Clientverbindingen | Uw app (op elk apparaat) heeft op verschillende manieren toegang tot gebruikers, vanaf één toegangspunt, met inbegrip van de volgende manieren: - Een clientservermodel waarvoor de gebruiker een client moet hebben geïnstalleerd om met de app te kunnen werken. Een server-app die toegankelijk is vanuit een browser. - Clientverbindingen kunnen meldingen bevatten wanneer de verbinding is verbroken of waarschuwingen wanneer roamingkosten van toepassing kunnen zijn. |
| Authenticatie | 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. |
| Apis | U kunt ontwikkelaars programmatische toegang bieden tot uw app met API-sets en klassebibliotheken en een verbindingsinterface bieden op basis van internetstandaarden. U kunt ook API's gebruiken om een app op te schalen in onafhankelijk werkende logische eenheden. |
| Diensten | U kunt beknopte services gebruiken om de functies voor een app te bieden. Een service kan de engine zijn waarop de app wordt uitgevoerd. |
| Wachtrijen | U kunt wachtrijen gebruiken om de status van de levenscyclus en statussen van de onderdelen van uw app te ordenen. Deze wachtrijen kunnen berichten, meldingen en buffermogelijkheden bieden voor het abonneren van partijen. |
| Gegevensopslag | Een app kan staatloos of stateful zijn. Stateful apps hebben gegevensopslag nodig die kan worden bereikt door talloze indelingen en volumes. |
| Gegevens opslaan in cache | Een gegevenscacheonderdeel in uw ontwerp kan latentieproblemen strategisch aanpakken en een rol spelen bij het activeren van bursting in de cloud. |
| Gegevensopname | Gegevens kunnen op veel manieren naar een app worden verzonden, variërend van door de gebruiker ingediende waarden in een webformulier tot continu gegevensstromen met een hoog volume. |
| Gegevensverwerking | Uw gegevensverwerkingstaken (zoals rapporten, analyses, batchexports en gegevenstransformatie) kunnen worden verwerkt bij de bron of offloaden op een afzonderlijk onderdeel met behulp van een kopie van de gegevens. |
App-onderdelen beoordelen voor pijlers
Evalueer voor elk onderdeel de kenmerken voor elke pijler. Wanneer u elk onderdeel evalueert met alle pijlers, zijn vragen die u mogelijk niet hebt overwogen, bekend geworden die van invloed zijn op het ontwerp van de hybride app. Het reageren op deze overwegingen kan waarde toevoegen bij het optimaliseren van uw app. Tabel 2 bevat een beschrijving van elke pijler, omdat deze betrekking heeft op hybride apps.
Tabel 2. Pijlers
| beschrijving | |
|---|---|
| Plaatsing | De strategische positionering van onderdelen in hybride apps. |
| Schaalbaarheid | De mogelijkheid van een systeem om verhoogde belasting te verwerken. |
| Beschikbaarheid | Het aandeel van de tijd dat een hybride app functioneel is en werkt. |
| Herstellingsvermogen | De mogelijkheid voor een hybride app om te herstellen. |
| Meegaandheid | Bewerkingsprocessen die een systeem in productie houden. |
| Veiligheid | Hybride apps en gegevens beveiligen tegen bedreigingen. |
Plaatsing
Een hybride app heeft inherent een plaatsingsoverweging, zoals voor het datacenter.
Plaatsing is de belangrijke taak van het positioneren van onderdelen, zodat ze een hybride app het beste kunnen gebruiken. Hybride apps omvatten per definitie locaties, 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 locaties. Elk afzonderlijk onderdeel kan meerdere exemplaren hebben die zich op één locatie bevinden.horizontale hybride apps
App-onderdelen worden verdeeld over locaties. Elk afzonderlijk onderdeel kan meerdere exemplaren hebben die meerdere locaties omvatten.Sommige onderdelen kunnen zich bewust zijn van hun locatie, terwijl anderen geen kennis hebben van hun locatie en plaatsing. Deze deugdzaamheid kan worden bereikt met een abstractielaag. Deze laag, met een modern app-framework zoals microservices, kan definiëren hoe de app wordt onderhouden 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 bijbehorende onderdelen vereist is om in een specifieke cloud te kunnen werken of dat certificering is vereist voor een specifieke cloud. Dit kan bestaan uit soevereiniteitsvereisten van uw bedrijf of volgens de wet. Bepaal ook of on-premises bewerkingen vereist zijn voor een bepaalde locatie of landinstelling.
Connectiviteitsafhankelijkheden vaststellen. Vereiste locaties en andere factoren kunnen de connectiviteitsafhankelijkheden tussen uw onderdelen dicteren. Wanneer u de onderdelen plaatst, bepaalt u de optimale connectiviteit en beveiliging voor communicatie tussen deze onderdelen. U kunt kiezen uit VPN-,ExpressRoute-, en hybride verbindingen.
Platformmogelijkheden evalueren. Voor elk app-onderdeel controleert u of de vereiste resourceprovider voor het app-onderdeel beschikbaar is in de cloud en of de bandbreedte voldoet aan de verwachte doorvoer- en latentievereisten.
Plannen voor draagbaarheid. Gebruik moderne app-frameworks, zoals containers of microservices, om bewerkingen te verplaatsen en serviceafhankelijkheden te voorkomen.
Vereisten voor gegevenssoevereine bepalen. Hybride apps zijn bedoeld voor het inschakelen van gegevensisolatie, zoals in een lokaal datacenter. Bekijk de plaatsing van uw resources om het succes van deze vereiste te optimaliseren.
Plan latentie. Intercloudbewerkingen kunnen fysieke afstand tussen de app-onderdelen veroorzaken. Controleer de vereisten om te voldoen aan eventuele latentie.
Verkeerstromen beheren. Omgaan met piekgebruik en de juiste en beveiligde communicatie voor persoonsgegevens wanneer deze worden geopend door de front-end in een openbare cloud.
Schaalbaarheid
Schaalbaarheid is de mogelijkheid van een systeem voor het afhandelen van een verhoogde belasting voor een app, die in de loop van de tijd kan variëren als andere factoren en krachten van invloed zijn op de doelgroepgrootte, naast de grootte en het bereik van de app.
Zie Schaalbaarheid in de vijf pijlers van toparchitectuur voor de kerndiscussie van deze pijler.
Met een horizontale schaalaanpassing voor hybride apps kunt u meer exemplaren toevoegen aan de vraag en deze vervolgens uitschakelen tijdens rustigere perioden.
In hybride scenario's is voor het uitschalen van afzonderlijke onderdelen extra overwegingen vereist wanneer onderdelen over clouds worden verdeeld. Het schalen van een deel van de app kan het schalen van een ander onderdeel vereisen. Als het aantal clientverbindingen bijvoorbeeld toeneemt, maar de webservices van de app niet correct worden uitgeschaald, kan de belasting van de database de app overbelasten.
Sommige app-onderdelen kunnen lineair worden uitgeschaald, terwijl andere afhankelijkheden hebben en mogelijk worden beperkt tot in hoeverre ze kunnen worden geschaald. Een VPN-tunnel die hybride connectiviteit biedt voor de locaties van de app-onderdelen heeft bijvoorbeeld een limiet voor de bandbreedte en latentie waarmee deze 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 hoeverre app-onderdelen in verschillende clouds onafhankelijk van elkaar kunnen worden geschaald, terwijl u nog steeds 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 wanneer deze communiceert en van invloed is op de rest van de app. Als u bijvoorbeeld een aantal front-endexemplaren overschrijdt, moet de back-end mogelijk worden geschaald.
Schaalschema's definiëren. De meeste apps hebben drukke perioden, dus u moet hun piektijden aggregeren in schema's om optimale schaalaanpassing te coördineren.
Gebruik een gecentraliseerd bewakingssysteem. Platformbewakingsmogelijkheden kunnen automatische schaalaanpassing bieden, maar hybride apps hebben een gecentraliseerd bewakingssysteem nodig waarmee de systeemstatus 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 dat niet doen.
Maak gebruik van mogelijkheden voor automatisch schalen (indien beschikbaar). Als de 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 omlaag moet worden geschaald. Een voorbeeld van automatische schaalaanpassing is een clientverbinding die automatisch wordt geschaald in de ene cloud om meer capaciteit te verwerken, maar veroorzaakt 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 overwegen scripts en andere resources te implementeren om handmatig schalen mogelijk te maken, geactiveerd door drempelwaarden in het gecentraliseerde bewakingssysteem.
Bepaal de verwachte belasting op locatie. Hybride apps die clientaanvragen verwerken, zijn mogelijk voornamelijk afhankelijk van één locatie. Wanneer de belasting van clientaanvragen een drempelwaarde overschrijdt, kunnen extra resources op een andere locatie worden toegevoegd om de belasting van binnenkomende aanvragen te verdelen. Zorg ervoor dat de clientverbindingen de verhoogde belastingen kunnen verwerken en ook eventuele geautomatiseerde procedures voor de clientverbindingen 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 toparchitectuur voor de kerndiscussie van deze pijler.
Controlelijst voor beschikbaarheid
Redundantie bieden voor connectiviteit. Voor hybride apps is connectiviteit vereist tussen de clouds waar de app over is verdeeld. U hebt een keuze uit technologieën voor hybride connectiviteit, dus gebruik naast uw primaire technologiekeuze een andere technologie om redundantie te bieden met geautomatiseerde failovermogelijkheden als de primaire technologie uitvalt.
Foutdomeinen classificeren. Fouttolerante apps vereisen meerdere foutdomeinen. Foutdomeinen helpen bij het isoleren van het storingspunt, bijvoorbeeld als een enkele harde schijf on-premises mislukt, 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, hoe meer u moet 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 onderhouden met updates of functie-upgrades. Net als bij foutdomeinen kunnen upgradedomeinen worden geclassificeerd door hun plaatsing op verschillende locaties. U moet bepalen of een app-onderdeel kan worden bijgewerkt op de ene locatie voordat het op een andere locatie wordt geüpgraded of als andere domeinconfiguraties vereist zijn. Eén locatie zelf kan meerdere upgradedomeinen hebben.
Exemplaren en beschikbaarheid bijhouden. App-onderdelen met hoge beschikbaarheid kunnen beschikbaar zijn via taakverdeling en synchrone gegevensreplicatie. U moet bepalen hoeveel exemplaren offline kunnen zijn voordat de service wordt onderbroken.
Zelfherstel implementeren. In het geval dat een probleem een onderbreking van de beschikbaarheid van de app veroorzaakt, kan een detectie door een bewakingssysteem zelfherstelactiviteiten in de app initiëren, zoals het leegmaken van het mislukte exemplaar en het opnieuw implementeren ervan. Dit vereist waarschijnlijk een centrale bewakingsoplossing, geïntegreerd met een hybride CI/CD-pijplijn (Continuous Integration) en Continuous Delivery (CI/CD). De app is geïntegreerd met een bewakingssysteem om problemen te identificeren waarvoor een app-onderdeel opnieuw kan worden geïmplementeerd. Het bewakingssysteem kan hybride CI/CD ook activeren om het app-onderdeel en mogelijk andere afhankelijke onderdelen op dezelfde of andere locaties opnieuw te implementeren.
Service level agreements (SLA's) onderhouden. Beschikbaarheid is essentieel voor alle overeenkomsten voor het onderhouden van connectiviteit met de services en apps die u met uw klanten hebt. Elke locatie waarop uw hybride app afhankelijk is, heeft mogelijk een eigen SLA. Deze verschillende SLA's kunnen van invloed zijn op de algemene SLA van uw hybride app.
Herstellingsvermogen
Tolerantie is de mogelijkheid voor een hybride app en een hybride systeem om te herstellen van fouten en te blijven functioneren. Het doel van tolerantie is om de app terug te keren naar een volledig werkende status nadat er een fout is opgetreden. Tolerantiestrategieën omvatten oplossingen zoals back-up, replicatie en herstel na noodgevallen.
Zie Resiliency in de vijf pijlers van toparchitectuur voor de kerndiscussie van deze pijler.
Controlelijst voor tolerantie
Afhankelijkheden voor herstel na noodgevallen ontdekken. Herstel na noodgevallen in de ene cloud vereist mogelijk wijzigingen in app-onderdelen in een andere cloud. Als een of meerdere onderdelen van de ene cloud een failover naar een andere locatie hebben, binnen dezelfde cloud of naar een andere cloud, moeten de afhankelijke onderdelen op de hoogte worden gesteld van deze wijzigingen. Dit omvat ook de connectiviteitsafhankelijkheden. Tolerantie vereist een volledig getest app-herstelplan voor elke cloud.
Herstelstroom tot stand brengen. Een effectief ontwerp van een herstelstroom heeft app-onderdelen geëvalueerd voor de mogelijkheid om buffers, nieuwe pogingen, mislukte gegevensoverdracht opnieuw uit te voeren 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.
Test gedeeltelijke herstelbewerkingen. Een gedeeltelijk herstel voor een deel van de app kan gebruikers geruststellen dat alles niet beschikbaar is. Dit deel van het plan moet ervoor zorgen dat een gedeeltelijke herstelbewerking geen neveneffecten heeft, zoals een back-up- en herstelservice die interactie heeft met de app om deze probleemloos af te sluiten voordat de back-up wordt gemaakt.
Bepaal instigators voor herstel na noodgevallen en wijs verantwoordelijkheid toe. Een herstelplan moet beschrijven wie en welke rollen back-up- en herstelacties kunnen initiëren, naast wat er een back-up en herstelbewerking kan worden gemaakt.
Vergelijk zelfhersteldrempels met herstel na noodgevallen. Bepaal de zelfherstelmogelijkheden van een app voor automatische herstelinitiatie en de tijd die nodig is voor het zelfherstel van een app om te worden beschouwd als een fout of succes. 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 overwegen die locatie te integreren in een gecentraliseerde service die de tolerantiefuncties biedt.
Bepaal uitvaltijd. Bepaal de verwachte downtime vanwege onderhoud voor de app als geheel en als app-onderdelen.
Procedures voor het oplossen van problemen met documenten. Definieer procedures voor probleemoplossing voor het opnieuw implementeren van resources en app-onderdelen.
Meegaandheid
De overwegingen voor het beheren van uw hybride apps zijn essentieel voor het ontwerpen van uw architectuur. Een goed beheerde hybride app biedt een infrastructuur als code waarmee consistente app-code in een gemeenschappelijke ontwikkelingspijplijn kan worden geïntegreerd. Door consistente systeembrede en afzonderlijke tests van wijzigingen in de infrastructuur te implementeren, kunt u zorgen voor een geïntegreerde implementatie als de wijzigingen de tests doorstaan, zodat ze kunnen worden samengevoegd in de broncode.
Zie DevOps- in de vijf pijlers van architectuurexemplaar 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 gerelateerde platformmogelijkheden.
Bepaal de onderdelen van de app waarvoor bewaking is vereist.
Beleid coördineren. Elke locatie die een hybride app omvat, kan een eigen beleid hebben dat betrekking heeft op toegestane resourcetypen, naamconventies, 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 worden verspreid over clouds. Machtigingen voor resources die zijn ingesteld in de ene cloud, zijn niet van toepassing op resources die zijn ingesteld in een andere cloud.
Gebruik CI/CD-pijplijnen. Een CI/CD-pijplijn (Continuous Integration and Continuous Development) kan een consistent proces bieden voor het ontwerpen en implementeren van apps die betrekking hebben op clouds en om kwaliteitscontrole te bieden voor hun infrastructuur en app. Met deze pijplijn kunnen de infrastructuur en app worden getest op de ene cloud 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 naar een andere cloud, die in feite de basis vormen voor de implementatie van hybride apps. Een CI/CD-systeem is essentieel voor het verwerken van de afhankelijkheden die app-onderdelen hebben voor elkaar tijdens de installatie, zoals de web-app die een verbindingsreeks voor de database nodig heeft.
De levenscyclus beheren. Omdat resources van een hybride app locaties kunnen omvatten, moet de levenscyclusbeheerfunctie van elke locatie worden samengevoegd in één levenscyclusbeheereenheid. Overweeg hoe ze worden gemaakt, bijgewerkt en verwijderd.
Bekijk 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. Een belangrijke taak bij het oplossen van problemen met hybride apps is het onderzoeken van de geaggregeerde status- en prestatiebewaking van de app-onderdelen.
Veiligheid
Beveiliging is een van de belangrijkste overwegingen voor elke cloud-app en het wordt nog belangrijker voor hybride cloud-apps.
Zie Security in de vijf pijlers van topprestaties van architectuur voor de kerndiscussie van deze pijler.
Controlelijst voor beveiliging
Stel dat er sprake is van een schending. Als een 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 verschillende 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 functioneren.
Gebruik robuuste verificatie. Een robuust verificatieschema is essentieel voor de beveiliging van uw app. Overweeg het gebruik van een federatieve id-provider die mogelijkheden voor eenmalige aanmelding biedt en een of meer van de volgende schema's gebruikt: aanmelding met gebruikersnaam en wachtwoord, openbare en persoonlijke sleutels, tweeledige of meervoudige verificatie en vertrouwde beveiligingsgroepen. Bepaal de juiste resources voor het opslaan van gevoelige gegevens en andere geheimen voor app-verificatie, naast certificaattypen en hun vereisten.
Gebruik versleuteling. Bepaal welke gebieden van de app versleuteling gebruiken, zoals voor gegevensopslag of clientcommunicatie en -toegang.
Veilige kanalen gebruiken. Een veilig 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. Implementeer rollen voor resourceconfiguraties en toegang tot één identiteit in clouds. Bepaal de RBAC-vereisten (op rollen gebaseerd toegangsbeheer) voor de app en de bijbehorende platformbronnen.
Controleer uw systeem. Systeembewaking kan gegevens van zowel de app-onderdelen als de gerelateerde cloudplatformbewerkingen registreren 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 deze vragen ondervindt in productiestoringen en mogelijk moet u uw ontwerp opnieuw bekijken.
Het kan van tevoren een tijdrovende taak lijken, maar u krijgt eenvoudig uw rendement op investering als u uw app ontwerpt op basis van deze pijlers.
Volgende stappen
Zie de volgende bronnen voor meer informatie: