Væksten i computerkapacitet og udviklingen af virtualiseringsteknologier på x86-platformen på den ene side, og udbredelsen af IT-outsourcing på den anden side, har ført til konceptet utility computing (IT som en offentlig tjeneste). Hvorfor ikke betale for IT ligesom for vand eller elektricitet – præcist så meget og på det rette tidspunkt, og ikke mere.
Det var på dette tidspunkt, at konceptet med cloud computing blev introduceret – forbrug af IT-tjenester fra "skyen", dvs. fra et eksternt ressourcepulje, uden at bekymre sig om, hvordan og hvorfra disse ressourcer kommer. Ligesom vi ikke bekymrer os om infrastrukturen for vandværker. På dette tidspunkt var der også blevet arbejdet med den anden side af konceptet – nemlig forståelsen af IT-tjenester og hvordan man administrerer dem inden for ITIL / ITSM.
Der er udviklet en række definitioner for clouds (cloud computing), men man bør ikke betragte dem som uomtvistelige sandheder – det er blot måder at formalisere måderne til at tilbyde utility computing.
- "Cloud computing er en teknologi for distribueret databehandling, hvor computerressourcer og kapacitet tilbydes brugeren som en internet-service" Wikipedia
- "Cloud computing er en model til at levere let tilgængelig netværksadgang til et fælles pulje af konfigurerbare computerressourcer (f.eks. netværk, servere, datalagringssystemer, applikationer og tjenester) efter behov, som hurtigt kan tildeles og leveres med minimal ledelsesbestræbelser eller minimal indgriben fra tjenesteudbyderen" NIST
- "Cloud computing er en paradigme for at muliggøre netværksadgang til et skalerbart og fleksibelt pulje af distribuerede fysiske eller virtuelle ressourcer, der tilbydes som selvbetjening og administreres efter behov" ISO/IEC 17788:2014. Informationsteknologi — Cloud computing — Oversigt og terminologi.
Ifølge NIST findes der tre hovedtyper af clouds:
- IaaS – Infrastructure as a Service — Infrastruktur som en service
- PaaS – Platform as a Service — Platform som en service
- SaaS — Software as a Service — Software som en service
For en meget forenklet forståelse af forskellen lad os overveje modellen Pizza-as-a-Service:
NIST definerer de nødvendige egenskaber for IT-tjenester, der gør dem til cloud-baserede.
- Universel netværksadgang (broad network access) – tjenesten skal have et universelt netværksinterface, der giver mulighed for at tilslutte og bruge tjenesten næsten af hvem som helst med minimale krav. For eksempel – for at bruge elnettet 220V er det tilstrækkeligt at tilslutte sig en hvilken som helst stikkontakt med et standard universelt interface (stik), som ikke ændrer sig, uanset om det er en kedel, en støvsuger eller en bærbar computer.
- Målbarhed af tjenesten (measured service) – en nøglekarakteristik ved cloudtjenester er måleligheden af tjenesten. Hvis vi vender tilbage til analogien med elektricitet – betaler du præcis det, du har forbrugt, med minimal granularitet, helt ned til omkostningerne ved at koge vand til en kedel, hvis du kun har været hjemme én gang i løbet af måneden og har drukket en kop te.
- Selvbetjeningskonfiguration af tjenester efter behov (on demand self service) – cloududbyderen giver kunden mulighed for fornuftig konfiguration af tjenesten uden behov for interaktion med udbyderens medarbejdere. For at koge en kedel er det slet ikke nødvendigt at kontakte Energiselskabet på forhånd og give dem besked og få tilladelse. Fra det øjeblik, huset er tilsluttet (kontrakten er indgået), kan alle forbrugere selv bestemme den leverede kapacitet.
- Øjeblikkelig elasticitet (rapid elasticity) – cloududbyderen leverer ressourcer med mulighed for øjeblikkelig øgning / reduktion af kapaciteten (inden for rimelige rammer). Så snart kedlen tændes, leverer udbyderen straks 3 kW kapacitet til nettet, og så snart den slukkes, reduceres leveringen til nul.
- Sammenlægning af ressourcer i en pulje (resource pooling) – udbyderens interne mekanismer gør det muligt at samle separate genererende kapaciteter i en fælles pulje (bassiner) af ressourcer, som derefter leveres som tjeneste til forskellige forbrugere. Inklusive kedlen er vi mindst bekymrede over, hvilken specifik elproducent der leverer kapaciteten. Og alle andre forbrugere forbruger denne kapacitet sammen med os.
Det er vigtigt at forstå, at de ovenfor beskrevne karakteristika for skyen ikke er taget ud af den blå luft, men er en logisk konklusion baseret på konceptet utility computing. Og den offentlige tjeneste skal have disse karakteristika inden for rammerne af konceptet. Hvis en eller anden karakteristik ikke overholdes, bliver tjenesten ikke ringere og ikke "giftig"; den stopper blot med at være skybaseret. Men hvem har sagt, at alle tjenester skal være det?
Hvorfor nævner jeg dette særskilt? I de forløbne 10 år siden definitionen fra NIST blev præsenteret, har der været mange diskussioner om "ægte skymiljø" ifølge definitionen. I USA anvendes der fortsat nogle gange i retssager formuleringen "overholder bogstaverne i loven, men ikke ånden" — og i tilfælde med skycomputing er det ånden, der er det vigtigste, med ressourcer til leje i to musetryk.
Det skal bemærkes, at de fem nævnte karakteristika gælder for offentlige cloud-tjenester, men ved overgangen til private clouds bliver de fleste af dem valgfrie.
- Universel netværksadgang (broad network access) – inden for en privat cloud har organisationen fuld kontrol over både de genererende ressourcer og slutbrugerne. Derfor kan denne karakteristik betragtes som automatisk opfyldt.
- Måling af tjenesten (measured service) – dette er den nøglekarakteristik ved konceptet utility computing, betaling baseret på faktisk forbrug. Men hvordan betaler en organisation sig selv? Her er der tale om en opdeling af produktion og forbrug internt i virksomheden, hvor IT bliver leverandøren, og forretningsenhederne bliver forbrugere af tjenester. Og mellemmomenterne finder sted mellem enhederne. Der er to driftsformer: chargeback (ved reelle mellemmomenter og finansiel bevægelse) og showback (i form af rapportering af ressourceforbrug i rubler, men uden finansiel bevægelse).
- Selvbetjening af tjenester efter behov (on demand self service) – inden for organisationen kan der være en fælles IT-service, og i så fald mister denne karakteristik sin betydning. Men hvis der er interne IT-specialister eller applikationsadministratorer i forretningsenhederne, er det nødvendigt at arrangere et selvbetjeningsportal. Konklusionen er, at karakteristikken er valgfrie og afhænger af virksomhedens struktur.
- Øjeblikkelig elasticitet (rapid elasticity) mister sin betydning inden for organisationen på grund af den faste opstilling af udstyr til den private sky. Det kan anvendes begrænset i interne afregninger. Konklusion – det er ikke relevant for den private sky.
- Sammenlægning af ressourcer i et pulje (resource pooling) – i dag findes der stort set ikke organisationer, der ikke anvender servervirtualisering. Derfor kan man betragte denne egenskab som automatisk opfyldt.
Spørgsmål: Hvad er egentlig denne private sky? Hvad skal virksomheder købe og implementere for at bygge den?
Svar: Den private sky er et skifte til en ny administrativ model for IT-forretning, der består af 80 % administrative foranstaltninger og kun 20 % teknologi.
Betaling kun for forbrugte ressourcer og let adgang, uden at skulle investere hundredevis af millioner i kapitalomkostninger, har skabt et nyt teknologisk landskab og fremkomsten af milliardvirksomheder. For eksempel blev moderne giganter som Dropbox og Instagram startet som startups på AWS med nul egen infrastruktur.
Det skal understreges, at værktøjerne til styring af cloud-tjenester bliver betydeligt mere indirekte, og en nøgleopgave for IT-direktøren bliver at vælge leverandører og overvåge kvaliteten. Lad os se nærmere på problematikken ved disse to nye opgaver.
Som en alternativ til den klassiske tunge infrastruktur med egne datacentre og hardware, er cloud-løsninger deceptivt lette. Det er nemt at komme ind i skyen, men spørgsmålet om udgang bliver ofte overset. Ligesom i enhver anden branche stræber cloud-udbydere efter at beskytte deres forretning og komplicere konkurrencen. Den eneste seriøse konkurrencefaktor opstår kun ved det indledende valg af cloud-serviceudbyder, og herefter vil udbyderen gøre alt for at holde kunden. Det er dog langt fra alle bestræbelser, der vil være rettet mod kvaliteten af tjenesterne eller deres udvalg. Først og fremmest handler det om at levere unikke tjenester og anvende usædvanlig systemsoftware, som gør det svært at skifte til en anden udbyder. Derfor, ved valg af tjenesteudbyder, skal man samtidig planlægge en overgangsplan fra denne udbyder (i realiteten en komplet DRP - disaster recovery plan) og overveje arkitekturen for datalagring og sikkerhedskopiering.
En anden vigtig aspekt af den nye rolle for CIO'en er kontrol med kvaliteten af tjenesterne fra udbyderen. Næsten alle cloud-udbydere overholder SLA ifølge deres egne interne metrikker, som kan have en meget indirekte betydning for kundens forretningsprocesser. Derfor bliver implementeringen af et eget overvågnings- og kontrolsystem et af de nøgleprojekter, når væsentlige IT-systemer flyttes til en cloud-udbyder. Fortsætter vi temaet om SLA, er det vigtigt at understrege, at langt størstedelen af cloud-udbydere begrænser ansvarligheden for manglende opfyldelse af SLA til den månedlige abonnementsbetaling eller en andel af betalingen. For eksempel vil AWS og Azure ved overskridelse af tilgængelighed på 95% (36 timer om måneden) give 100% rabat på abonnementsafgiften, mens Yandex.Cloud giver 30%.
Og selvfølgelig må man ikke glemme, at cloud-løsninger ikke kun findes hos mastodonterne som Amazon og kæmperne som Yandex. Der findes også mindre cloud-løsninger — på størrelse med en kat eller endda en mus. Eksemplet CloudMouse viser, at nogle gange kan et cloud-løsning blot forsvinde. Du vil ikke få hverken kompensation eller rabat — du vil ikke få noget, bortset fra en total datatab.
På grund af de nævnte problemer med implementering af IT-systemer af høj klasse med forretningskritisk betydning i cloudinfrastrukturer har vi i de seneste år set et fænomen kaldet "cloud repatriation".
Indtil 2020 havde cloud computing nået toppen af overdrevet forventninger, og konceptet er på vej ind i skuffelsens dal (ifølge Gartners hype-cyklus). Ifølge undersøgelser og op til 80% af virksomhedskunderne vender tilbage og planlægger at returnere belastninger fra cloud til deres egne datacentre af følgende grunde:
- For at øge tilgængeligheden / ydeevnen;
- For at reducere omkostningerne;
- For at overholde kravene til informationssikkerhed.
Hvad skal vi gøre, og hvordan er det «egentlig»?
Der er ingen tvivl om, at cloud-løsninger er kommet for at blive. Og hver år vil deres rolle vokse. Men vi lever ikke i en fjern fremtid, men i 2020 i en ret konkret situation. Hvad skal vi gøre med cloud-løsninger, hvis du ikke er en opstartsvirksomhed, men en klassisk virksomhedskunde?
- Cloud-løsninger er først og fremmest stedet for tjenester med uforudsigelige eller meget udprægede sæsonbelastninger.
- I de fleste tilfælde er det billigere at vedligeholde tjenester med forudsigelige, stabile belastninger i dit eget datacenter.
- Begyndelsen af arbejdet med cloud-løsninger skal ske med testmiljøer og lavprioriterede tjenester.
- Overvejelser omkring placering af informationssystemer i cloud begynder med udviklingen af en metode til at flytte fra en cloud til en anden (eller tilbage til dit eget datacenter).
- Placeringen af et informationssystem i cloud begynder med udviklingen af en backup-plan til en infrastruktur, som du selv kontrollerer.
Kilde: habr.com
