Scenario 1 - op wereldwijde schaal en veilige toegang
In de volgende twee eenheden bekijkt u twee bedrijfsscenario's. De beschrijving, projectdoelen en beperkingen van het bedrijf zijn al voor u vastgelegd. U werkt voor uzelf, maar het kan interessant zijn om met andere mensen te brainstormen, indien mogelijk.
Proces om oplossingen te ontwikkelen
Uw doel, in deze scenario's en waarschijnlijk ook in de praktijk, is om het volgende te begrijpen:
- Het probleem dat het bedrijf moet oplossen.
- Eventuele vereisten en beperkingen met betrekking tot een oplossing.
Dit doel is vaak in de vorm van een probleemstelling. Het is een formele set alinea's waarmee duidelijk de omstandigheden, de aanwezige toestand en de gewenste resultaten voor een oplossing worden gedefinieerd. Op dit moment moet u nog niet kijken naar hoe u het probleem oplost, maar naar wat u wilt oplossen.
Nadat u (en waarschijnlijk uw team en belanghebbenden) en probleemverklaring heeft opgesteld, moet u zoveel mogelijk vereisten (doelen) voor het projecten zoeken als u vinden kunt. En vervolgens de beperkingen van de oplossingen in kaart brengen.
Op dit moment is het aanvaardbaar om onrealistische beperkingen te hebben. U kunt die later terugtrekken nadat u een kosten/baten-verhouding voor elke vereiste en beperking hebt.
In productie zijn er meestal zes fasen voor het maken van een oplossing. Het ontwikkelen van de probleemstelling is slechts het begin.
- Detectie: de oorspronkelijke instructie van het probleem van de klant.
- Envisioning: Een 'blauwe hemel' beschrijving van hoe succes in het project eruit zou zien. Dit zijn vaak zinnen als "Met ... kan ik ...".
- Ontwerpsessie voor architectuur: Een eerste indeling van de technologieopties en keuzes voor een voorlopige oplossing.
- Proof of concept (POC): Nadat de optimale technologieën en processen voor de oplossing zijn geselecteerd, wordt een POC ingesteld met een klein representatief voorbeeld van hoe een oplossing eruit kan zien. Een oplossing die momenteel wordt gebruikt, kan, indien aanwezig, als parallel voorbeeld worden gebruikt
- Implementatie: Implementatie van een gefaseerde implementatie van de voltooide oplossing op basis van bevindingen uit de vorige fasen.
- Handoff: Een postmortem over het project met een bespreking van toekomstige verbeteringen.
In deze module kunt u gebruikmaken van projectsjablonen en de nieuwste pictogrammen. U kunt deze activa ook gebruiken in uw productieworkloads.
Voor de scenario's in deze module moet u enige tijd besteden aan het vaststellen van de probleemstelling (detectie). Maar de focus zal liggen op de ontwerpsessie voor architectuur. Als u na de module een oplossing verder wilt ontwikkelen, kunt u daarvoor de assets in de module gebruiken.
Scenariodetails
Uw klant is een provider van services en content over de hele wereld. De klant heeft uw hulp gevraagd bij het bouwen van een systeem dat duizenden schrijfbewerkingen per seconde kan uitvoeren in wat in wezen een operationele datamart is.
Daarnaast moet de klant de mogelijkheid hebben om realtime analyses uit te voeren op basis van de gegevens, om trends te bepalen en afwijkingen te identificeren. Momenteel wordt dit met Common Language Runtime (CLR)-toepassingen uitgevoerd. De klant is niet op zoek naar een datawarehouse en gebruikt grote delen van de SQL surface area, maar moeten ook kunnen schalen naar waar gebruikers wonen.
De klant probeert ook te bepalen welke verificatiemethoden gebruikt moeten worden in de hybride omgeving. Hoewel de hoofdoplossing en -toepassing zich in Azure bevinden, heeft de klant ook het volgende nodig:
- Een toepassing op een niet-Azure-machine die domein-gekoppeld is.
- Een oudere toepassing waarmee het stuurprogramma of de verbindingsreeks in een niet-Azure-machine niet kan worden gewijzigd.
- Meerdere gebruikers die rapporten uitvoeren vanuit SQL-beheertools (SQL Server Management Studio, Azure Data Studio, PowerShell) op niet-Azure-machines die niet domein-gekoppeld zijn.
Waar mogelijk wil de klant hardcoded wachtwoorden of geheimen verwijderen in de verbindingsreeksen en app-configuratiebestanden. En het wordt aangeraden wachtwoorden in SQL-hulpprogramma's te elimineren of een manier te vinden om die verificatie te verbeteren.
Leidraad voor dit scenario
- Begin met de Azure SQL-implementatieoptie die het meest compatibel is met de huidige oplossing en nu beschikbaar is.
- Hoe kunnen klanten opschalen naar meerdere regio's waarbij meerdere query's tegelijk plaatsvinden, terwijl leesworkloads worden gescheiden van schrijfworkloads?
- Hoe kan de klant toegang krijgen tot gegevens in de verschillende implementaties?
- Welke verificatie methoden zou u aanbevelen voor de interactie paden die in het scenario worden beschreven?
Opdrachten
Nadat u het scenario en de beschikbare leidraad hebt bekeken, haalt u er net zoveel vereisten voor het project uit als u kunt vinden.
Maak een lijst met de mogelijke technologieën en processen die in een oplossing kunnen worden gebruikt. U bent vrij het scenario te verduidelijken door er meer informatie aan toe te voegen. In dat geval mag u aannames maken.
Tip
Voor de problemen ten aanzien van de beveiliging kunt u overwegen gebruik te maken van het playbook voor Azure SQL Security Best Practices.
Als u een beslissingsmatrix of een ander besluitvormingsproces gebruikt, kunt u technologieën en processen selecteren die uw voorlopige oplossing vormen.
Maak notities die uw projectdoelen en -beperkingen aangeven, evenals het aanbevolen oplossingsontwerp.
Nadat u een voorlopige oplossing in gedachten hebt, bestaat de volgende stap er vaak uit deze te presenteren aan het grotere team (of klant, leidinggevende, enzovoort, afhankelijk van het scenario). U moet uw oplossing samenstellen en presenteren op een manier die de projectdoelen en -beperkingen deelt, evenals de manier waarop uw oplossing deze punten aanpakt.
Als u klaar bent, beantwoordt u de volgende vragen om te evalueren hoe uw oplossing zich verhoudt tot een voorbeeldoplossing. Er kunnen meerdere juiste antwoorden zijn, dus zelfs als uw oplossing er niet bij staat, kan deze zinvol zijn.