Рост вылічальных магутнасцяў і развіццё тэхналогій віртуалізацыі платформы x86 з аднаго боку, і распаўсюджванне ІТ-аўтсорсінгу з другога боку прывялі да канцэпцыі utility computing (ІТ як камунальная паслуга). Чаму б не плаціць за ІТ гэтак жа, як за ваду ці электрычнасць - роўна столькі і роўна тады, калі гэта трэба, і не больш.
У гэты момант і з'явілася канцэпцыя хмарных вылічэнняў – спажыванне ІТ паслуг з «аблокі», г.зн. з нейкага знешняга пула рэсурсаў, не клапоцячыся аб тым, як і адкуль бяруцца гэтыя рэсурсы. Гэтак жа, як мы не клапоцімся аб інфраструктуры помпавых станцый водаканала. Да гэтага моманту была прапрацавана і іншы бок канцэпцыі - а менавіта паняцце ІТ-паслуг і як імі кіраваць у рамках ITIL / ITSM.
Быў распрацаваны цэлы шэраг азначэнняў аблокаў (хмарных вылічэнняў), але пры гэтым не варта ставіцца да іх як да праўды ў апошняй інстанцыі - гэта толькі спосаб фармалізаваць спосабы падавання utility computing.
- «Воблачныя вылічэнні - гэта тэхналогія размеркаванай апрацоўкі дадзеных, у якой кампутарныя рэсурсы і магутнасці падаюцца карыстачу як Інтэрнэт-сэрвіс» Вікіпедыя
- «Воблачныя вылічэнні ўяўляюць сабой мадэль для забеспячэння зручнага сеткавага доступу да агульнага пулу наладжвальных вылічальных рэсурсаў (напрыклад, сетак, сервераў, сістэм захоўвання дадзеных, прыкладанняў і паслуг) па патрабаванні, якія можна хутка вылучыць і падаць з мінімальнымі кіраўнічымі намаганнямі або мінімальным умяшаннем з боку пастаўшчыка паслуг» NIST
- «Воблачныя вылічэнні – гэта парадыгма забеспячэння сеткавага доступу да маштабаванага і гнуткага пулу размеркаваных фізічных ці віртуальных рэсурсаў, якія прадстаўляюцца ў рэжыме самаабслугоўвання і адмініструюцца па патрабаванні» ISO/IEC 17788:2014. Information technology - Cloud computing - Overview and vocabulary.
Паводле 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 з нулявой уласнай інфраструктурай.
Неабходна асобна падкрэсліць, што прылады кіравання хмарнымі паслугамі становяцца значна больш апасродкаванымі, а ключавым абавязкам ІТ дырэктара становіцца падбор пастаўшчыкоў і кантроль якасці. Давайце разгледзім праблематыку гэтых двух новых абавязкаў.
З'явіўшыся як альтэрнатыва класічнай цяжкай інфраструктуры з уласнымі ЦАД і жалезам, аблокі зманліва лёгкія. У воблака лёгка ўвайсці, але вось пытанне выйсця звычайна абыходзіцца бокам. Як і ў любой іншай галіне хмарныя правайдэры імкнуцца да абароны бізнэсу і ўскладненні канкурэнцыі. Адзіны сур'ёзны канкурэнтны момант узнікае толькі пры першасным выбары пастаўшчыка хмарных паслуг, а далей пастаўшчык прыкладзе максімум намаганняў, каб заказчык ад яго не сышоў. Прычым далёка не ўсе намаганні будуць накіраваны на якасць паслуг або іх асартымент. Першым чынам, гэта пастаўка ўнікальных паслуг і выкарыстанне нестандартнага сістэмнага ПА, які абцяжарвае пераход да іншага правайдэра. Адпаведна, пры выбары пастаўшчыка паслуг неабходна адначасова фармаваць план пераходу ад гэтага пастаўшчыка (па сутнасці паўнавартасны DRP – disaster recovery plan) і прадумваць архітэктуру захоўвання дадзеных і рэзервовых копій.
Другі важны аспект новых абавязкаў ІТ дырэктара - кантроль якасці паслуг ад пастаўшчыка. Практычна ўсе хмарныя правайдэры выконваюць SLA па ўласных унутраных метрыках, што можам мець вельмі апасродкаванае значэнне да бізнес-працэсаў заказчыка. І адпаведна ўкараненне ўласнай сістэмы маніторынгу і кантролю становіцца адным з ключавых праектаў пры пераносе значных ІТ сістэм да хмарнага правайдэра. Працягваючы тэму SLA неабходна падкрэсліць, што абсалютная большасць хмарных правайдэраў абмяжоўваюць адказнасць за невыкананне SLA у месячны абаненцкі плацёж або ў долю ад плацяжу. Напрыклад, AWS і Azure пры перавышэнні парога ў даступнасці ў 95% (36 гадзін у месяц) зробяць 100% скідкі да абаненцкай платы, а Яндэкс.Хмара - 30%.
Ну і вядома ж, не трэба забываць, што аблокі бываюць не толькі ў выкананні мастадонтаў класа Amazon і сланоў класа Яндэкса. Аблокі бываюць і паменш - памерам з котку, ці нават мыш. Як паказаў прыклад CloudMouse, часам воблака проста бярэ і заканчваецца. Вы не атрымаеце ні кампенсацыі, ні скідкі - вы не атрымаеце нічога, акрамя татальнай страты дадзеных.
З прычыны названых вышэй праблем з рэалізацыяй ІТ сістэм высокага класа бізнес крытычнасці ў хмарных інфраструктурах у апошнія гады назіраецца з'ява "хмарнай рэпатрыяцыі".
Да 2020 году для хмарных вылічэнняў пройдзены пік разадзьмутых чаканняў і канцэпцыя знаходзіцца на шляхі да канавы расчараванняў (згодна з хайп цыклу Гартнер). Згодна з даследаваннямі и да 80% карпаратыўных заказчыкаў вяртаюць і плануюць вяртаць нагрузкі з аблокаў ва ўласныя ЦАДы па прычынах:
- Павысіць даступнасць / прадукцыйнасць;
- Скараціць выдаткі;
- Для адпаведнасці патрабаванням ИБ.
Што ж рабіць і як усё "насамрэч"?
Няма ніякіх сумневаў, што аблокі прыйшлі сур'езна і надоўга. І з кожным годам іх роля будзе ўзрастаць. Аднак мы жывем не ў далёкім будучыні, а ў 2020 году ў суцэль вызначанай сітуацыі. Што ж рабіць з аблокамі, калі вы не стартап, а класічны карпаратыўны заказчык?
- Аблокі - гэта перш за ўсё месца для сэрвісаў з непрадказальнай або ярка выяўленай сезоннай нагрузкай.
- У большасці выпадкаў сэрвісы з прадказальнай стабільнай нагрузкай танней утрымоўваць ва ўласным ЦАД.
- Пачынаць працу з аблокамі неабходна з тэставых асяроддзяў і нізкапрыярытэтных сэрвісаў.
- Разгляд размяшчэння інфармацыйных сістэм у воблаку пачынаецца з распрацоўкі методыкі выхаду з аблокі ў іншае воблака (або назад ва ўласны ЦАД).
- Размяшчэнне інфармацыйнай сістэмы ў воблаку пачынаецца з распрацоўкі схемы рэзервовага капіявання ў кантраляваную вамі інфраструктуру.
Крыніца: habr.com