De groei van de rekenkracht en de ontwikkeling van x86-platformvirtualisatietechnologieën aan de ene kant, en de verspreiding van IT-outsourcing aan de andere kant, leidden tot het concept van utility computing (IT als een nutsdienst). Waarom betaalt u niet voor IT op dezelfde manier als voor water of elektriciteit: precies zoveel en precies wanneer u het nodig heeft, en niet meer.
Op dit moment verscheen het concept van cloud computing: de consumptie van IT-diensten uit de “cloud”, d.w.z. uit een externe bron van hulpbronnen, zonder zich er druk over te maken hoe of waar deze hulpbronnen vandaan komen. Net zoals we ons niets aantrekken van de infrastructuur van pompstations van waterbedrijven. Op dit punt was de andere kant van het concept uitgewerkt, namelijk het concept van IT-diensten en hoe deze te beheren binnen het raamwerk van ITIL / ITSM.
Er zijn een aantal definities van clouds (cloud computing) ontwikkeld, maar deze mogen niet als de ultieme waarheid worden beschouwd; ze zijn slechts een manier om manieren te formaliseren om utility computing aan te bieden.
- “Cloud computing is een gedistribueerde gegevensverwerkingstechnologie waarbij computerbronnen en stroom aan de gebruiker worden geleverd als een internetdienst” Wikipedia
- “Cloud computing biedt een model voor het bieden van gemakkelijke, netwerkgebaseerde toegang tot een gedeelde pool van on-demand, configureerbare computerbronnen (bijvoorbeeld netwerken, servers, opslag, applicaties en diensten) die snel kunnen worden ingericht en ingericht met minimaal beheer inspanning of tussenkomst. dienstverlener" NIST
- “Cloud computing is een paradigma voor het bieden van netwerktoegang tot een schaalbare en flexibele pool van gedistribueerde fysieke of virtuele bronnen, zelfbediening en on-demand beheerd” ISO/IEC 17788:2014. Informatietechnologie - Cloud computing - Overzicht en woordenschat.
Volgens NIST zijn er drie hoofdtypen wolken:
- IaaS – Infrastructuur als een service
- PaaS – Platform as a Service – Platform as a service
- SaaS - Software als een service
Laten we, voor een zeer vereenvoudigd begrip van het verschil, eens kijken naar het Pizza-as-a-Service-model:
NIST definieert de volgende noodzakelijke kenmerken van een IT-service die als cloudgebaseerd kan worden beschouwd.
- Universele netwerktoegang (brede netwerktoegang) – de dienst moet een universele netwerkinterface hebben waarmee bijna iedereen verbinding kan maken en de dienst kan gebruiken met minimale vereisten. Voorbeeld: om een elektrisch netwerk van 220 V te gebruiken, volstaat het om verbinding te maken met elk stopcontact met een standaard universele interface (stekker), wat niet verandert of het een waterkoker, een stofzuiger of een laptop is.
- Gemeten service – een belangrijk kenmerk van een cloudservice is de meetbaarheid van de service. Terugkomend op de analogie met elektriciteit: u betaalt precies zoveel als u verbruikt met minimale granulariteit, tot aan de kosten van het één keer koken van de ketel, als u de hele maand één keer in huis was en een kopje thee dronk.
- Zelfconfiguratie van diensten op aanvraag (on demand selfservice) – de cloudprovider biedt de klant de mogelijkheid om de dienst op intelligente wijze te configureren, zonder dat er interactie nodig is met de medewerkers van de provider. Om de ketel aan de kook te brengen is het absoluut niet nodig om vooraf contact op te nemen met Energosbyt en hen vooraf te waarschuwen en toestemming te verkrijgen. Vanaf het moment dat het huis is aangesloten (er een contract is afgesloten) kunnen alle verbruikers zelfstandig de geleverde stroom beheren.
- Onmiddellijke elasticiteit (snelle elasticiteit) – de cloudprovider biedt middelen met de mogelijkheid om de capaciteit onmiddellijk te vergroten/verkleinen (binnen bepaalde redelijke grenzen). Zodra de waterkoker wordt aangezet, levert de aanbieder direct 3 kW stroom aan het netwerk, en zodra hij wordt uitgeschakeld, wordt het vermogen teruggebracht tot nul.
- Pooling van hulpbronnen – de interne mechanismen van de dienstverlener maken het mogelijk om individuele opwekkingscapaciteiten te combineren tot een gemeenschappelijke pool van hulpbronnen, met de verdere levering van hulpbronnen als een dienst aan verschillende consumenten. Als we de ketel aanzetten, maken we ons het minst druk over uit welke specifieke energiecentrale de stroom komt. En alle andere consumenten verbruiken deze stroom samen met ons.
Het is belangrijk om te begrijpen dat de hierboven beschreven kenmerken van de cloud niet uit de lucht komen vallen, maar een logische conclusie zijn uit het concept van utility computing. En een publieke dienst moet deze kenmerken hebben binnen de kaders van het concept. Als een of ander kenmerk niet overeenkomt, wordt de dienst niet slechter en wordt hij niet "giftig", hij houdt gewoon op troebel te zijn. Welnu, wie zei dat alle diensten dat zouden moeten doen?
Waarom praat ik hier apart over? In de afgelopen tien jaar sinds de introductie van de NIST-definitie is er veel discussie geweest over ‘echte bewolking’ zoals gedefinieerd. In de Verenigde Staten wordt de formulering ‘voldoet aan de letter van de wet, maar niet aan de geest’ nog steeds soms gebruikt in de rechterlijke sfeer - en in het geval van cloud computing gaat het vooral om de geest, middelen die in tweeën kunnen worden gehuurd. muisklikken.
Opgemerkt moet worden dat de bovenstaande 5 kenmerken van toepassing zijn op de publieke cloud, maar bij de overstap naar een private cloud worden de meeste daarvan optioneel.
- Universele netwerktoegang (brede netwerktoegang) – binnen een private cloud heeft de organisatie volledige controle over zowel de opwekkingsinstallaties als de consumentenklanten. Dit kenmerk kan dus als automatisch vervuld worden beschouwd.
- Gemeten service is een belangrijk kenmerk van het utility computing-concept, betaling op basis van verbruik. Maar hoe kan een organisatie zichzelf betalen? In dit geval is er sprake van een scheiding tussen opwekking en verbruik binnen het bedrijf, wordt IT de aanbieder en worden bedrijfseenheden consumenten van diensten. En er vindt onderlinge verrekening plaats tussen afdelingen. Er zijn twee werkingsmodi mogelijk: terugboeking (met echte onderlinge verrekeningen en financiële bewegingen) en showback (in de vorm van rapportage over het verbruik van hulpbronnen in roebels, maar zonder financiële bewegingen).
- On-demand selfservice – er kan sprake zijn van een gedeelde IT-service binnen een organisatie, in welk geval het kenmerk betekenisloos wordt. Als u echter eigen IT-specialisten of applicatiebeheerders in bedrijfsonderdelen heeft, moet u een selfserviceportal inrichten. Conclusie - het kenmerk is optioneel en hangt af van de bedrijfsstructuur.
- Instant elasticiteit (snelle elasticiteit) – binnen een organisatie verliest het zijn betekenis vanwege de vaste set apparatuur voor het organiseren van een private cloud. In beperkte mate toepasbaar binnen interne nederzettingen. Conclusie - niet van toepassing voor een private cloud.
- Resource pooling – tegenwoordig zijn er vrijwel geen organisaties die geen gebruik maken van servervirtualisatie. Dienovereenkomstig kan dit kenmerk als automatisch vervuld worden beschouwd.
Vraag: Dus wat is uw private cloud? Wat moet een bedrijf kopen en implementeren om het te bouwen?
Antwoord: de private cloud is een transitie naar een nieuw administratief model van IT-Business interactie, dat voor 80% uit administratieve maatregelen en slechts 20% uit technologie bestaat.
Alleen betalen voor de verbruikte hulpbronnen en gemakkelijke toegang, zonder honderden miljoenen olie in kapitaaluitgaven te hoeven begraven, leidde tot een nieuw technologisch landschap en de opkomst van miljardairbedrijven. Moderne giganten Dropbox en Instagram verschenen bijvoorbeeld als startups op AWS zonder eigen infrastructuur.
Er moet afzonderlijk worden benadrukt dat tools voor het beheer van cloudservices veel indirecter worden, en dat de belangrijkste verantwoordelijkheid van de IT-directeur de selectie van leveranciers en kwaliteitscontrole wordt. Laten we eens kijken naar de uitdagingen van deze twee nieuwe verantwoordelijkheden.
Clouds zijn ontstaan als alternatief voor de klassieke zware infrastructuur met eigen datacenters en hardware en zijn bedrieglijk licht. Het is gemakkelijk om de cloud te betreden, maar de kwestie van het verlaten wordt meestal vermeden. Net als in elke andere sector streven cloudproviders ernaar bedrijven te beschermen en de concurrentie moeilijker te maken. Het enige serieuze concurrentiemoment doet zich pas voor tijdens de eerste selectie van een cloudserviceprovider, en dan zal de leverancier er alles aan doen om ervoor te zorgen dat de klant hem niet verlaat. Bovendien zullen niet alle inspanningen gericht zijn op de kwaliteit van de dienstverlening of het aanbod ervan. In de eerste plaats gaat het om het leveren van unieke diensten en het gebruik van niet-standaard systeemsoftware, waardoor het lastig is om over te stappen naar een andere aanbieder. Dienovereenkomstig is het bij het kiezen van een dienstverlener noodzakelijk om tegelijkertijd een transitieplan van deze leverancier te formuleren (in wezen een volwaardig DRP - disaster recovery plan) en na te denken over de architectuur van gegevensopslag en back-upkopieën.
Het tweede belangrijke aspect van de nieuwe verantwoordelijkheden van de IT-directeur is het bewaken van de kwaliteit van de dienstverlening van de leverancier. Bijna alle cloudproviders voldoen aan SLA’s volgens hun eigen interne maatstaven, wat een zeer indirecte impact kan hebben op de bedrijfsprocessen van de klant. En dienovereenkomstig wordt de implementatie van uw eigen monitoring- en controlesysteem een van de belangrijkste projecten bij het overbrengen van belangrijke IT-systemen naar een cloudprovider. Als we het onderwerp SLA voortzetten, is het noodzakelijk om te benadrukken dat de overgrote meerderheid van cloudproviders de aansprakelijkheid voor het niet nakomen van de SLA beperkt tot de maandelijkse abonnementsbetaling of tot een deel van de betaling. AWS en Azure geven bijvoorbeeld, als de beschikbaarheidsdrempel van 95% (36 uur per maand) wordt overschreden, een korting van 100% op de abonnementskosten, en Yandex.Cloud – 30%.
En natuurlijk mogen we niet vergeten dat wolken niet alleen worden gemaakt door mastodons van de Amazon-klasse en olifanten van de Yandex-klasse. Wolken kunnen ook kleiner zijn: zo groot als een kat of zelfs een muis. Zoals het voorbeeld van CloudMouse liet zien, stopt de cloud soms gewoon. U ontvangt geen compensatie, geen korting - u ontvangt niets anders dan totaal dataverlies.
In het licht van de bovengenoemde problemen bij de implementatie van hoogwaardige bedrijfskritische IT-systemen in cloudinfrastructuren is de afgelopen jaren het fenomeen ‘cloudrepatriëring’ waargenomen.
Tegen 2020 heeft cloud computing het hoogtepunt van de opgeblazen verwachtingen gepasseerd en is het concept op weg naar de teleurstelling (volgens de Gartner-hypecyclus). Volgens onderzoek и Tot 80% van de zakelijke klanten komt terug en is van plan ladingen uit de cloud terug te sturen naar hun eigen datacenters, om de volgende redenen:
- Verbeter de beschikbaarheid/prestaties;
- Kosten verlagen;
- Om te voldoen aan de eisen op het gebied van informatiebeveiliging.
Wat te doen en hoe alles “echt” is?
Het lijdt geen twijfel dat de wolken hier voor de lange termijn zijn. En elk jaar zal hun rol groter worden. We leven echter niet in de verre toekomst, maar in 2020 in een heel specifieke situatie. Wat te doen met clouds als je geen startup bent, maar een klassieke corporate klant?
- De cloud is in de eerste plaats een plaats voor diensten met onvoorspelbare of zeer seizoensgebonden belastingen.
- In de meeste gevallen zijn diensten met een voorspelbare, stabiele belasting goedkoper te onderhouden in uw eigen datacenter.
- Het is noodzakelijk om met clouds te gaan werken met testomgevingen en diensten met lage prioriteit.
- Het overwegen van het plaatsen van informatiesystemen in de cloud begint met het ontwikkelen van een methodologie om de cloud te verlaten naar een andere cloud (of terug naar uw eigen datacenter).
- Het plaatsen van een informatiesysteem in de cloud begint met het ontwikkelen van een back-upschema voor de infrastructuur die u beheert.
Bron: www.habr.com