Scenario 1 – Utforma global skalning och säker åtkomst

  • 10 minuter

I följande två lektioner tittar vi på två affärsscenarier. Företagsbeskrivningar, projektmål och villkor har redan angetts åt dig. Du kan arbeta med detta själv, men det kan vara givande att samarbeta kring idéer med andra om det är möjligt.

Process för utveckling av lösningar

Ditt mål i dessa scenarier (och förmodligen i verkligheten) är att förstå:

  • Problemet som företaget måste lösa.
  • Eventuella krav och begränsningar som lösningen innebär.

Det här målet anges ofta i form av en problembeskrivning. Det är en formell uppsättning textstycken som tydligt definierar omständigheterna, nuvarande villkor och önskade resultat för en lösning. I det här steget låter du bli att ta reda på hur du ska lösa problemet, utan fokuserar i stället på vad du vill lösa.

När du (och förmodligen ditt team och dina intressenter) har enats om en problembeskrivning, bör du ta reda på så mycket som möjligt om kraven (målen) för projektet. Lägg sedan till alla begränsningar som lösningen har.

I det här läget kan man ha orealistiska begränsningar. Dessa kan du ta bort senare när du har sett förhållandet mellan kostnad och fördel för varje krav och begränsning.

I produktion finns det vanligtvis sex faser när man skapar en lösning. Att utveckla problembeskrivningen är bara början.

  1. Identifiering: Den ursprungliga instruktionen för problemet från kunden.
  2. Föreställande: En "blå himmel" beskrivning av hur framgång i projektet skulle se ut. Det uttrycks ofta som ”Jag kan...”-beskrivningar.
  3. Arkitekturdesignsession: En inledande layout av teknikalternativen och alternativen för en preliminär lösning.
  4. Konceptbevis (POC): När de optimala teknikerna och processerna har valts för lösningen konfigureras en POC med ett litet representativt exempel på hur en lösning kan se ut. Om det finns en lösning som körs i ett liknande exempel kan du använda den.
  5. Implementering: Implementera en stegvis distribution av den färdiga lösningen baserat på resultaten från föregående faser.
  6. Överlämning: En postmortem på projektet med en diskussion om framtida förbättringar.

I den här modulen kan du ha nytta av projektmallar och de senaste ikonerna. Dessa tillgångar kan också användas i produktionsarbetsbelastningar.

I scenarierna i den här modulen kommer vi att ägna lite tid åt att fastställa problembeskrivningen (identifiering). Men största fokus kommer att läggas på sessionen för arkitekturutformning. Om du vill fortsätta att utveckla en lösning efter modulen, kan du använda resurserna som finns i modulen.

Information om scenario

Kunden är en leverantör av tjänster och innehåll som levereras över hela världen. De har begärt din hjälp med att skapa ett system som kan hantera tusentals skrivningar per sekund och som i princip blir ett driftdataförråd.

Kunden behöver också kunna utföra dataanalys i realtid för att fastställa trender och hitta avvikelser. För närvarande görs detta med CLR-program (Common Language Runtime). Kunden vill inte ha ett informationslager eller använda stora delar av SQL-området, men de måste kunna utföra skalning där deras användare finns.

Kunden försöker också bestämma vilka autentiseringsmetoder som ska användas i hybridmiljön. Även om huvudlösningen och programmet finns i Azure, måste kunden också få med följande:

  • Ett program som körs på en dator som inte är en Azure-dator som är domänansluten.
  • Ett äldre program som inte tillåter ändringar av drivrutins- eller anslutningssträngen på datorn som inte är en Azure-dator.
  • Flera användare som kör rapporter från SQL-administrationsverktyg (SQL Server Management Studio, Azure Data Studio, PowerShell) på datorer som inte är Azure-datorer som inte är domänanslutna.

När det är möjligt vill kunden eliminera hårdkodade lösenord eller hemligheter i anslutningssträngarna och i appkonfigurationsfilerna. Man vill även eliminera användningen av lösenord i SQL-verktyg, eller hitta ett sätt att förbättra autentiseringen på.

Scenariovägledning

  • Börja med det alternativ för Azure SQL-distributionen som är mest kompatibelt med den aktuella lösningen och som finns nu.
  • Hur kan kunden skala över flera regioner med flera frågor åt gången, samtidigt som läsarbetsbelastningar isoleras från skrivarbetsbelastningar?
  • Hur kan kunden komma åt data i de olika distributionerna?
  • Vilka autentiseringsmetoder rekommenderar du för de interaktionssökvägar som beskrivs i scenariot?

Uppgifter

  1. När du har granskat scenariot och riktlinjerna, tar du reda på så mycket som möjligt om kraven för projektet.

  2. Skapa en lista med möjliga tekniker och processer som kan komma att användas i lösningen. Du kan anpassa scenariot med mer information där det behövs, om du vill. Du kan göra antaganden i det här fallet.

    Dricks

    I säkerhetsutmaningarna kan du använda spelboken med metodtips för Azure SQL-säkerhet.

  3. Med hjälp av en beslutsmatris eller någon annan typ av beslutsprocess, väljer du de tekniker och processer som ska utgöra den preliminära lösningen.

  4. Gör några anteckningar som visar projektets mål och begränsningar, samt den rekommenderade lösningsdesignen.

När du har en preliminär lösning i åtanke, är nästa steg vanligtvis att presentera den för en större grupp (eller kunden, ledningen osv. beroende på scenario). Du måste sammanställa och presentera lösningen på ett sätt som överensstämmer med projektets mål och begränsningar, samt hur din lösning hanterar dessa element.

När du är klar kan du svara på följande frågor för att utvärdera hur din lösning kan jämföras med en exempellösning. Det kan finnas flera rätta svar, så även om din lösning inte finns med i listan kan den fungera.