Matching AWS-tjenester til applikasjonen din - dummies

AWS applikasjonsutvikling krever langsiktig planlegging. Selv om du leverer et produkt i stadig kortere intervaller, er målet å skape et program som er fleksibelt nok og pålitelig nok til å håndtere organisatoriske behov på lang sikt. Med dette i bakhodet, sjekk kriteriene du må vurdere når du samler AWS-tjenester til din søknad.

Arbeide med tjenester i den frie perioden

Nå som du forstår hva tjenestene gjør, må du begynne å ta valg om hvilke tjenester du skal prøve. Husk at du bare har 12 måneder til å ta beslutninger om hvilke tjenester som skal brukes i virksomheten din. Tolv måneder kan virke som mye tid, men du vil oppdage at det fordamper for øynene dine mens du prøver å jonglere ditt daglige ansvar, møter og andre behov.

Kort sagt, å ta en god beslutning om hva du skal prøve i løpet av den begrensede tiden du har, er viktig. Du kan til slutt bestemme at AWS ikke vil tilfredsstille dine behov i det hele tatt (så usannsynlig som det kan virke, gitt alt som AWS har å tilby).

Fokus på viktige problemer i prøveperioden er nøkkelen til å gjøre AWS-arbeidet for deg. Når du tenker på AWS, må du vurdere disse problemene:

• Kostnad: Bestem om AWS skal utføre oppgaven for mindre penger.
• Hastighet: Bestem om hastighetsstraffen ved bruk av skyen oppveier fordelene.
• Pålitelighet: Kontroller risikoen for å bruke skyen mot å holde oppgaven i huset. (Skyen kan faktisk vise seg mer pålitelig.)
• Sikkerhet: Definer sikkerhetskravene for søknaden din, og avgjør om risikoen for bruk av skyen er akseptabel.
• Personvern: Angi programmets personvernkrav (spesielt de juridiske). Å opprettholde et brudd på personvern når dataene er plassert på andres system, kan være vanskelig å administrere og forårsake permanent skade på selskapets omdømme.
• Fleksibilitet: Vurder om bruk av en skygtjeneste vil redusere fleksibiliteten til det punktet som søknaden blir uhåndterlig til. I de fleste tilfeller reduserer tilliten til skyen fleksibilitet fordi verten forbeholder seg noen konfigurasjonsmuligheter for kun internt bruk.

Når du har avgjort at bruk av AWS utgjør akseptable risikoer og gir fordeler for å kompensere for eventuelle negative, må du avgjøre nøyaktig hvilke tjenester du skal bruke. Det kan hende du finner ut at du ikke kan støtte noen tjenester på grunn av rettslige krav eller hastighetskrav, selv om du har et kostnadsincitament til å bruke disse tjenestene.Arbeid gjennom tjenestene en om gangen før du begynner å eksperimentere; å gjøre det, vil spare tid som du kan bruke til å bedre teste tjenestene som vil tilfredsstille dine behov.

Samhandling med tjenester etter den frie perioden

Den frie perioden vil ende på et tidspunkt. I den frie perioden eksperimenterer du med applikasjoner og kan muligens distribuere enkle applikasjoner. Men etter at du har gått over dette punktet, må du vurdere hvordan du fortsetter å samhandle med AWS (eller om du vil prøve noe annet). Følgende liste utforsker interaksjonsbehov fra en rekke perspektiver:

• Redundans: Et stort problem med skyen er at ingen synes å innse at skyen kan mislykkes. En nyhetshistorie tjener til å illustrere poenget. S3-tjenesten var ute i flere timer i USA-ØST-1-regionen. Problemet med denne feilen er at det ikke bare påvirket S3 - det påvirket mange andre tjenester, for eksempel Dockerhub. Faktisk rammet utbruddet en stor sving av Internett. Hvis en feil som dette kan skje en gang, kan det skje flere ganger, og du må planlegge for det ved å levere flere datakilder, hvorav noen ikke kan stole på skyen i det hele tatt.
• Kompromisser: Hvert trekk kommer med kompromisser av noe slag. Du kan ikke føle deg som om du først gjør kompromisser, men etter hvert som applikasjonen vokser inn i de ulike tjenestene, begynner kompromissene å dukke opp. I applikasjonsutviklingsfasen må du avgjøre hvilke nivåer av tjenester du trenger for å sikre at applikasjonen fortsetter å virke som forventet. Ellers kan du komme forbi den frie perioden, har mye investert i AWS, og bare da finne ut at brukerne aldri vil være fornøyd med kompromissene du må gjøre.
• Flere tilbydere: AWS og andre onlinetjenester gir ofte støtte for alternativer som fungerer på tvers av skyleverandører. For eksempel kan du støtte Docker-apper over Amazon, Google og Microsoft Cloud Services. Følgelig betyr bruk av Docker at du kan ha en plan B på plass som ikke krever at du hopper gjennom hoops når en av dine skygtjenester har en feil.