Indholdsfortegnelse:
Video: Windows Server 2012 R2 installation 2025
Uanset hvor mange tjenester AWS tilbyder, kræver du stadig en vis mængde hardware til at bruge tjenesterne. Mængden af hardware, du har brug for, når du arbejder med tjenester i skyen, er minimal, fordi AWS-hardware gør alt tungt løft. Når du arbejder med tjenester lokalt, har du brug for ekstra hardware, fordi AWS ikke længere løfter tungt for dig. Derfor bør du overveje forskellige hardwarekrav afhængigt af, hvor du er vært for AWS-tjenesten.
Hosting tjenesterne lokalt
Skjult i AWS-dokumentationen er alle mulige nyttige oplysninger om forskellige tjenester. For eksempel forbinder AWS Storage Gateway en lokalt softwareappliance (et program kombineret med lige nok operativsystemfunktion til at køre på hardware eller på en virtuel maskine) med skybaseret lagring.
Med andre ord bruger du gatewayen til at forbinde din applikation med den datalagring, det kræver. Det kan virke som om at køre gatewayen i skyen ville være en god ide, fordi du ikke ville skulle investere i ekstra hardware. Men når du ser på kravene, ser du, at AWS Storage Gateway leveres med specifikke hardware-, eksempel- og lagerkrav. Det vigtige ved at forstå er, at skyen præsenterer grænser, som du skal overveje i enhver planlægningsfase.
Når du er sikker på at du kan køre din planlagte konfiguration, kan du begynde at overveje fordelene og ulemperne ved at arbejde i skyen. For eksempel, når du er vært for tjenesten i skyen, får du automatisk skalering efter behov, og Amazon udfører mange af de administrative opgaver for dig. Men for et realistisk perspektiv skal du kompensere for disse fordele med bevidsthed om ulemperne, såsom:
- Mulighed for lavere applikationshastighed
- Behov for at opretholde en pålidelig internetforbindelse
- Manglende fleksibilitet
- Sælgere går ud af drift
Selv om grundlæggende hardwarebehov bliver billigere, du skal overveje ekstraudgifter i form af afskedigelser. De fleste organisationer finder, at hardwareomkostningerne ved at flytte til skyen er væsentligt mindre end at opretholde en fuld it-afdeling, hvorfor de gør flytningen. Men du skal gøre bevægelsen med den forståelse, at du har andre forhold at overveje, når du gør.
Hosting af tjenesterne i skyen
Når hosting er lokalt, skal du give alle nødvendige infrastrukturer, som kan blive dyre.AWS giver vejledning om minimumskravene til hosting af en service lokalt.
En god tommelfingerregel, når du henter tjenester lokalt, er at se alle leverandører, der leveres som minimum. Hvis du ikke har planer om at indlæse tjenesten kraftigt, arbejder disse minimum normalt. Men når du klikker på linket Optimering Gateway Performance, er det første forslag, du ser, at tilføje ressourcer til din gateway. Planlægning for for stor kapacitet er bedre end for ikke nok, men at få konfigurationen så tæt som muligt på det, du har brug for, hjælper altid økonomisk.
Ikke alle tjenesterne vil fungere lokalt, men du kan blive overrasket over at finde ud af, at mange gør. Problemet er at definere præcist, hvordan du planlægger at bruge en given tjeneste og de kompromiser, du er villig til at gøre. Når du f.eks. Er vært for en tjeneste lokalt, kan det være svært at give det samme niveau af tilslutningsmuligheder, som du kan levere til tredjepart, når du er vært for den samme tjeneste i skyen.
Definere et godt udviklingsmiljø
Når du har kendskab til de ressourcer, der kræves til AWS, og har taget højde for det grundlæggende i dit opsætning, skal du overveje dit udviklingsmiljø. Det første problem du skal overveje er et sprog. AWS er ligeglad med, hvad IDE du bruger (selvom valget af IDE bestemmer hvilke funktioner du har til rådighed for fjernadgang), men det er ligeglad med sprog. Du skal verificere, at AWS understøtter det sprog, du ønsker, for den tjeneste, du vil have adgang til. Her er for eksempel valgmulighederne for Simple Queue Service (SQS).
Du kan oprette et implementeringsmiljø ved hjælp af EC2. Denne vejledning beskriver, hvordan du udfører denne opgave. Den største fordel ved denne tilgang er, at du teoretisk kan udvikle AWS-applikationer overalt, fordi udvikling ikke længere kræver et lokalt system med specifikke ressourcer.
Denne tilgang er dog absolut ikke gratis, og det betyder, at du skal have en pålidelig internetforbindelse, uanset hvor du vil udføre udviklingsopgaver - hvilket ikke er et problem på arbejdspladsen, men muligvis et problem derhjemme. Den skybaserede udviklingsmetode bruger AWS Command Line Interface (CLI).
Hovedårsagen til at bruge et lokaliseret udviklingsmiljø er, at du beholder adgangen til lokale ressourcer og de kodebiblioteker, som din organisation i øjeblikket er afhængig af til at udføre udviklingsopgaver.
Denne mulighed har også en fordel i pålidelighed, fordi du ikke stole på en fjernforbindelse for at bruge den. Hvis din internetforbindelse går ned, kan du fortsætte med at udvikle kode (men testning er ikke mulig, før forbindelsen er gendannet). Når du bruger denne indstilling, har du brug for yderligere båndbredde - i hvert fald til forsøgsformål og tilladelser til AWS-adgangen via organisationens firewall.
Du er ikke begrænset til kun to muligheder, når du arbejder med AWS. For eksempel kan du bruge et lokalt udviklingsmiljø, men placere din kode på S3.Brugen af skybaseret datalagring betyder, at du kan have lokaliserede opsætninger på flere steder (så du bevarer adgangen til lokale ressourcer) og stadig får fordele ved skybaseret udvikling, f.eks. At få adgang til din kode fra ethvert sted, hvor du have et udviklingsmiljø konfigureret.
Denne vejledning er også interessant, fordi den fortæller dig, hvordan du konfigurerer dit udviklingsmiljø for at bruge Elastic Beanstalk til projekt, kildekontrol og depotbrug. Som med et lokalt udviklingsmiljø har du stadig brug for nødvendige tilladelser til internetadgang og tilstrækkelig båndbredde til at håndtere stigningen i dataforespørgsler for at gøre denne mulighed fungere godt. Faktisk er båndbreddekravene højere end en lokal konfiguration, og udviklingsmiljøet skal arbejde med eksterne ressourcer.
Det er ikke let at vælge det rigtige udviklingsmiljø. I mange tilfælde bliver valget et af personlige præferencer og organisatoriske krav. For eksempel kan en cloud-baseret udviklingsløsning måske ikke være en mulighed, når man beskæftiger sig med følsomme udviklingsopgaver; Sikkerhedsbehov kunne trodle andre ønsker.
