Растежът на изчислителната мощност и развитието на виртуализационните технологии на x86 от една страна, и разпространението на ИТ аутсорсинга от друга страна, доведоха до концепцията на utility computing (ИТ като комунална услуга). Защо да не плащаме за ИТ като за вода или електричество – точно толкова и точно тогава, когато е необходимо, и не повече.
В този момент се появи концепцията за облачни изчисления – потребление на ИТ услуги от „облака“, т.е. от външен пул ресурси, без да се тревожим как и откъде идват тези ресурси. Както не се тревожим за инфраструктурата на водоснабдителните станции. Вече бе разработена и друга страна на концепцията – именно понятието за ИТ услуги и как да ги управляваме в рамките на ITIL / ITSM.
Бе разработен цял ред определения за облаците (облачните изчисления), но не трябва да се отнасяме към тях като към последна истина – това са само начини за формализиране на начина на предоставяне на utility computing.
- «Облачните изчисления са технологии за разпределена обработка на данни, при които компютърните ресурси и мощности се предоставят на потребителя като интернет услуга» Wikipedia
- «Облачните изчисления представляват модел за осигуряване на удобен мрежови достъп до общ пул от конфигурируеми изчислителни ресурси (например мрежи, сървъри, системи за съхранение на данни, приложения и услуги) при поискване, които могат бързо да се разпределят и предоставят с минимални управленски усилия или минимално намеса от страна на доставчика на услуги» NIST
- «Облачните изчисления са парадигма за осигуряване на мрежови достъп до скалируем и адаптивен пул от разпределяеми физически или виртуални ресурси, предоставяни в режим на самообслужване и администрирани по заявка» ISO/IEC 17788:2014. Информационни технологии — Облачни изчисления — Преглед и речник.
Според NIST съществуват три основни вида облаци:
- IaaS – Infrastructure as a Service — Инфраструктура като услуга
- PaaS – Platform as a Service — Платформа като услуга
- SaaS — Software as a Service — Софтуер като услуга
За напълно опростено разбиране на разликата, нека разгледаме модела Pizza-as-a-Service:
NIST определя следните необходими черти на ИТ услугата, позволяващи да се счита за облачна.
- Универсален мрежов достъп (broad network access) – услугата трябва да има универсален мрежов интерфейс, който да позволява свързване и ползване на услугата практически от всеки с минимални изисквания. Пример – за да използвате електрическата мрежа 220В, е достатъчно да се свържете към всеки стандартен контакт (вилка), който не се променя, независимо дали става дума за чайник, прахосмукачка или лаптоп.
- Измеримост на услугата (measured service) – ключова характеристика на облачната услуга е измеримостта на услугата. Връщайки се към аналогията с електричеството – ще платите точно толкова, колкото сте потребили, с минимална грануларност, дори до разходите за един път завиране на чайник, ако през целия месец сте били у дома само веднъж и сте изпили чаша чай.
- Самостоятелно конфигуриране на услуги по заявка (on demand self service) – облачният доставчик предоставя на клиента възможност за разумно конфигуриране на услугата, без необходимост от взаимодействие със служителите на доставчика. За да завирите чайник, съвсем не е необходимо предварително да се свързвате с Енергийния сектор и да ги предупреждавате и получавате разрешение. От момента, в който къщата е свързана (договора е сключен), всички потребители могат самостоятелно да разполагат с предоставената мощност.
- Моментална еластичност (rapid elasticity) – облачният доставчик предоставя ресурси с възможност за моментално увеличаване / намаляване на мощността (в определени разумни рамки). Веднага щом чайникът е включен – доставчикът незабавно предоставя в мрежата 3 кВт мощност, а веднага щом е изключен – намалява подаването до нула.
- Обединяване на ресурси в пул (resource pooling) – вътрешните механизми на доставчика на услуги позволяват обединяване на отделни генериращи мощности в общ пул (басейн) ресурси с последващо предоставяне на ресурсите като услуга на различни потребители. Включително чайник, нас най-малко ни интересува от коя конкретна електрическа станция идва мощността. И всички останали потребители потребяват тази мощност заедно с нас.
Важно е да се разбере, че описаните по-горе характеристики на облака не са произволни, а са логичен извод от концепцията за utility computing. И публичната услуга трябва да притежава тези характеристики в рамките на концепцията. При несъответствие на някоя от характеристиките, услугата не става по-лоша и не става "токсична", просто престава да бъде облачна. А кой каза, че всички услуги трябва да са облачни?
Защо говоря за това отделно? През последните 10 години, откакто се появи определението на NIST, имаше много спорове относно "истинската облачност" според определенията. В САЩ все още понякога се използва в съдебната сфера формулировката "съответства на буквата на закона, но не на духа" — и в случая с облачните изчисления, основното е именно духът, ресурси под наем с два клика на мишката.
Необходимо е да се отбележи, че посочените 5 характеристики са приложими за публичното облако, но при преминаване към частно, повечето от тях стават опционални.
- Универсален мрежови достъп (broad network access) – в рамките на частното облако организацията напълно контролира както генериращите мощности, така и клиентите-потребители. По този начин тази характеристика може да се счита за автоматично изпълняваща се.
- Измеримост на услугата (measured service) – това е ключовата характеристика на концепцията utility computing, заплащане в зависимост от потреблението. Но как да заплати организацията сама на себе си? В този случай става разделяне на генерирането и потреблението вътре в компанията, ИТ става доставчик, а бизнес подразделенията са потребителите на услугите. И взаимозачетът се осъществява между подразделенията. Възможни са два режима на работа: chargeback (при реални взаимозачети и движение на финансови средства) и showback (под формата на отчети за потребление на ресурси в рубли, но без движение на средства).
- Самостоятелно конфигуриране на услуги по искане (on demand self service) – вътре в организацията може да има обща ИТ служба, и в този случай характеристиката губи смисъл. Въпреки това, при наличие на собствени ИТ специалисти или администратори на приложения в бизнес подразделенията, е необходимо да се организира портал за самообслужване. Изводът е, че характеристиката е опционална и зависи от структурата на бизнеса.
- Мгновенна еластичност (rapid elasticity) – в рамките на организацията губи смисъл поради фиксираността на набора от оборудване за изграждане на частно облако. Може ограничено да се прилага в рамките на вътрешните разчетни отношения. Извод – за частно облако не е приложимо.
- Обединение на ресурсите в пул (resource pooling) – днес почти не съществуват организации, които да не прилагат сървърна виртуализация. Следователно можем да считаме, че тази характеристика се изпълнява автоматично.
Въпрос: Какво всъщност е вашето частно облако? Какво трябва да купи и внедри компанията, за да го изградите?
Отговор: частното облако е преход към нова административна модел на взаимодействие между ИТ и бизнеса, който на 80% се състои от административни мерки и само на 20% от технологии.
Плащането само за потребените ресурси и лесният достъп, без необходимостта от инвестиране на няколко стотин милиона за капиталови разходи, доведоха до нов технологичен ландшафт и появата на компании-милиардери. Например, съвременните гиганти Dropbox и Instagram се появиха като стартъпи на AWS с нулева собствена инфраструктура.
Необходимо е отделно да подчертаем, че инструментите за управление на облачните услуги стават значително по-опосредствани, а ключовата отговорност на ИТ директора става избора на доставчици и контрол на качеството. Нека разгледаме проблематиката на тези две нови отговорности.
Появявайки се като алтернатива на класическата тежка инфраструктура с собствени центрове за данни и хардуер, облаците изглеждат заблуждаващо леки. Лесно е да влезете в облака, но въпросът за излизането обикновено остава настрана. Както във всяка друга индустрия, облачните доставчици се стремят да защитят бизнеса си и да затруднят конкуренцията. Единственият значим конкурентен момент възниква единствено при първоначалния избор на доставчик на облачни услуги, а след това доставчикът ще положи максимални усилия, за да предотврати оттеглянето на клиента. И не всички усилия ще са насочени към качеството на услугите или тяхното разнообразие. Преди всичко, става дума за предоставяне на уникални услуги и използване на нестандартен софтуер, което затруднява преминаването към друг доставчик. Съответно, при избора на доставчик на услуги, е необходимо едновременно да се формулира план за преминаване от този доставчик (в същността си пълен план за възстановяване след бедствие) и да се проектира архитектура на съхранение на данни и резервни копия.
Вторият важен аспект на новите задължения на ИТ директора е контролът върху качеството на услугите от доставчика. Практически всички облачни доставчици спазват SLA според собствените си вътрешни метрики, което може да има изключително опосредствано значение за бизнес процесите на клиента. И съответно, внедряването на собствена система за мониторинг и контрол става един от ключовите проекти при прехвърлянето на значими ИТ системи към облачния доставчик. Продължавайки темата за SLA, необходимо е да се подчертае, че абсолютното мнозинство от облачните доставчици ограничават отговорността си за неизпълнение на SLA до месечната абонаментна такса или до процент от плащането. Например, AWS и Azure при надвишаване на прага на достъпност от 95% (36 часа на месец) ще направят 100% отстъпка от абонаментната такса, а Яндекс.Облако – 30%.
Ну и, разбира се, не трябва да забравяме, че облаците не са само в изпълнението на мастодонти като Amazon и слонове като Яндекс. Има и по-малки облаци – с размери на котка или дори мишка. Както показа примерът CloudMouse, понякога облакът просто свършва. Няма да получите никакво обезщетение, никаква отстъпка – няма да получите нищо, освен тотална загуба на данни.
Въпреки посочените по-горе проблеми с внедряването на ИТ системи с висок клас на бизнес критичност в облачните инфраструктури, в последните години се наблюдава явление на "облачна репатриация."
До 2020 година облачните изчисления достигнаха върха на преувеличените очаквания, а концепцията навлиза в канавката на разочарованията (според хайп цикъла на Гартнър). Според изследванията и до 80% от корпоративните клиенти върнат и планират да върнат натоварванията си от облацата обратно в собствените си ЦОД поради следните причини:
- Повишаване на наличността / производителността;
- Съкращаване на разходите;
- За съответствие с изискванията за информационна безопасност.
Какво да правим и как всичко "наистина" е?
Няма съмнение, че облаците дойдоха, за да останат. И с всяка изминала година тяхната роля ще нараства. Но ние не живеем в далечното бъдеще, а в 2020 година в съвсем конкретна ситуация. Какво да правим с облаците, ако не сте стартап, а класически корпоративен клиент?
- Облаците са преди всичко място за услуги с непредвидимо или ярко изразено сезонно натоварване.
- В повечето случаи услугите с предвидимо стабилно натоварване са по-евтини за поддържане в собственото ЦОД.
- Работата с облаци трябва да започне с тестови среди и нископриоритетни услуги.
- Разглеждането на разполагането на информационни системи в облака започва с разработването на методика за преместване от облака в друг облак (или обратно в собственото ЦОД).
- Разполагането на информационна система в облака започва с разработването на схема за резервно копиране в инфраструктурата, която контролирате.
Източник: habr.com
