5 Праблемы з выхадам у воблака - і як іх вырашыць

Мы жывем у воблачным свеце. Вы наўрад ці можаце прачытаць тэхналагічны блог альбо схадзіць на канферэнцыю, не пачуўшы пра ўсе перавагі тэхналогій і архітэктур, якія карыстаюцца воблакам, напрыклад, кантэйнеры, мікрасэрвісы і функцыі без сервера.

Тым не менш, сярод усіх хваляванняў з нагоды выхаду ў воблаку, можна лёгка праігнараваць праблемы, якія ўзнікаюць пры пераходзе са спадчыны, маналітных прыкладанняў да стратэгіі, характэрнай для воблака. Гэтыя праблемы можна пераадолець, але толькі ў тым выпадку, калі вы будзеце вырашаць іх як частку вашай роднай воблачнай міграцыйнай стратэгіі.

З гэтай мэтай давайце разгледзім пяць самых распаўсюджаных хмарных праблем, а таксама стратэгіі іх пераадолення.

Што такое роднае воблака?

Па-першае, слова пра тое, што на самой справе азначае "воблака".

З ажыятажам вакол усяго "воблака", "воблака" роднае часам выкарыстоўваецца людзьмі для абазначэння любога тыпу тэхналогій і стратэгій, якія яны лічаць сучаснымі. З гэтага пункту гледжання, абласное воблака аказваецца проста чарговым адносна бессэнсоўным модным словам.

З іншага боку, калі інвеставаць з пэўным і абмежаваным сэнсам, родная воблака - гэта карысны тэрмін і паняцце. Нам падабаецца вызначэнне CNCF, якое падкрэслівае "слаба звязаныя сістэмы" і ўстойлівасць як характарыстыкі хмарных вылічэнняў. Вызначэнне CNCF таксама паказвае на пэўны і абмежаваны спіс тэхналогій і архітэктур - "кантэйнеры, службовыя сеткі, мікрасэрвісы, нязменная інфраструктура і дэкларатыўныя API" - як прыклады тэхналогій, якія прадстаўляюцца воблака.

Для мэт гэтага артыкула мы будзем прытрымлівацца вызначэння CNCF як абласнога. Зараз давайце абмяркуем канкрэтныя праблемы, якія ўзнікаюць пры выкарыстанні тэхналогій і стратэгій, падобных да апісаных вышэй.

Праблемы з прыняццем роднай воблака

1) Устойлівае захоўванне дадзеных

Адной з распаўсюджаных праблем шматлікіх воблачных тэхналогій з'яўляецца настойлівае захоўванне дадзеных. Кантэйнеры, безсерверныя функцыі і прыкладанні, разгорнутыя з выкарыстаннем нязменнай інфраструктурнай мадэлі, звычайна не маюць магчымасці пастаянна захоўваць дадзеныя ўнутры сябе, таму што пры закрыцці прыкладання ўсе ўнутраныя дадзеныя знішчаюцца.

Вырашэнне гэтай праблемы патрабуе пераасэнсавання падыходаў да захоўвання дадзеных, развязаўшы іх з прыкладаннямі і хост-асяроддзямі. Замест таго, каб захоўваць дадзеныя ў прыкладным асяроддзі, працоўныя працэсы ў воблачным рэжыме захоўваюць іх вонкава і выстаўляюць дадзеныя ў якасці службы. Затым працоўныя нагрузкі, якія павінны атрымаць доступ да дадзеных, падлучаюцца да іх так, як яны будуць падлучацца да любой іншай службы.

Такі падыход - які прадугледжаны рознымі інструментамі, як томы ў Кубернэце - мае дзве перавагі. У дадатак да магчымасці пастаяннага захоўвання дадзеных для прыкладанняў, якія самі па сабе не распрацаваны, каб яны былі настойлівымі, гэта таксама дазваляе лёгка падзяляць адзін пул захоўвання паміж некалькімі прыкладаннямі або службамі.

2) Інтэграцыя паслуг

Воблачныя прыкладання звычайна складаюцца з набору розных паслуг. Такі размеркаваны характар ​​- гэта тое, што дапамагае зрабіць іх маштабаванымі і гнуткімі ў параўнанні з маналітамі.

Але гэта таксама азначае, што нагрузка на носьбіты воблака мае яшчэ шмат якія рухаюцца частак, якія для дасягнення поспеху трэба злучыць разам.

Збольшага, інтэграцыя паслуг - гэта праблема, з якой распрацоўнікі могуць звяртацца падчас стварэння прыкладанняў, якія падтрымліваюць воблака. Яны павінны забяспечыць належны памер кожнай службы; лепшая практыка - стварыць розныя паслугі для кожнага тыпу функцыянальнасці ў межах нагрузкі, а не спрабаваць прымусіць адну службу рабіць некалькі рэчаў. Важна таксама пазбягаць дадання паслуг толькі таму, што вы можаце. Перад тым, як унесці больш складанасці ў ваша прыкладанне ў выглядзе іншай службы, пераканайцеся, што служба дасягнула пэўнай мэты.

Акрамя архітэктуры самога прыкладання, эфектыўная інтэграцыя паслуг таксама залежыць ад выбару правільных метадаў разгортвання. Магчыма, кантэйнеры з'яўляюцца найбольш відавочным спосабам разгортвання некалькіх сэрвісаў і аб'яднання іх у адзін аб'ём працы, але ў некаторых выпадках беспраблемныя серверныя функцыі або бесканцерныя прыкладанні, падлучаныя API, могуць быць больш эфектыўнымі спосабамі разгортвання службы.

3) Кіраванне і кантроль

Чым больш службаў вы працуеце ў рамках прыкладання, тым складаней назіраць і кіраваць імі. Гэта сапраўды таму, што звязана не з вялікай колькасцю паслуг, якія вам трэба будзе адсочваць, але і таму, што гарантаванне здароўя прыкладанняў патрабуе маніторынгу адносін паміж службамі, а не толькі самімі службамі.

Затым, каб паспяхова кантраляваць і кіраваць паслугамі ў воблачным асяроддзі, неабходны падыход, які дазваляе прадказаць, як збой у адной службе адаб'ецца на іншых, а таксама зразумець, якія збоі найбольш важныя. Дынамічная базавая падрыхтоўка, якая азначае замену статычных парогаў на тыя, якія пастаянна пераглядаюць прыкладныя асяроддзі, каб вызначыць, што нармальна, а што такое анамалія, таксама мае вырашальнае значэнне.

4) Пазбяганне блакавання воблака

Рызыкі блакавання не характэрныя толькі для воблака; яны могуць паўстаць практычна з любога тыпу тэхналогій, і яны дзесяцігоддзямі ўяўляюць пагрозу спрыту. Аднак у выпадку воблачных прыкладанняў ці архітэктуры пагроза стаць занадта залежнай ад канкрэтнага пастаўшчыка паслуг або хмары можа быць асабліва вялікай, з-за лёгкасці, з якой рабочыя нагрузкі могуць быць разгорнуты такім чынам, што яны патрабуюць канкрэтнага паслуга з пэўнай воблака.

На шчасце, змякчыць гэты рызыка блакавання хмары дастаткова проста, пакуль вы плануеце наперад. Прытрымліваючыся стандартаў на базе супольнасці (напрыклад, тых, якія прапагандуе OCCI), гэта шмат што зробіць для таго, каб вы маглі зручна перамяшчаць свае працоўныя нагрузкі з аднаго воблака на другое. Акрамя таго, калі вы плануеце, якія хмарныя сэрвісы вы будзеце выкарыстоўваць, каб перайсці на воблака, падумайце, ці ёсць у любой з разглядаемых вамі паслуг функцыі, якія сапраўды унікальныя і не даступныя ў іншых аблоках. Калі яны здараюцца, пазбягайце гэтых функцый, бо яны могуць заблакаваць вас.

Напрыклад, пэўныя мовы і рамкі, якія падтрымліваюцца безсервернымі вылічальнымі платформамі розных грамадскіх аблокаў, некалькі адрозніваюцца. Напрыклад, AWS Lambda падтрымлівае Go, але Azure гэтага не робіць. З гэтай прычыны вам было б разумна пазбягаць напісання функцый без сервера ў Go. Нават калі вы плануеце выкарыстоўваць AWS для іх размяшчэння першапачаткова, гэтая залежнасць у будучыні ўскладніць пераход на іншае воблака. Прытрымвайцеся такой мовы, як Java, на якую вы можаце спакойна паспрачацца, будзе падтрымлівацца ўсюды.

5) Стварэнне прыкладанняў, якія працуюць у воблачным дастаўцы

Па вызначэнні, хмарныя прыкладанні працуюць у воблаку. У той час як воблака можа быць альбо публічнай хмарай, альбо прыватнай, унутранай або гібрыднай воблака, якая працуе ў асяроддзі вашай арганізацыі, гэта азначае нязменную інфраструктуру і працэсы кіравання хмарай. Але многія трубаправоды для дастаўкі прыкладанняў па-ранейшаму працуюць у асноўным у традыцыйных мясцовых умовах, якія, магчыма, не былі мутнымі або нязграбнымі пры інтэграцыі з прыкладаннямі і службамі, якія працуюць у грамадскіх аблоках ці ў кантэйнерах.

Гэта стварае праблему ў некалькіх адносінах. Першы заключаецца ў тым, што разгортванне кода з лакальнага асяроддзя ў мясцовае асяроддзе можа прывесці да затрымкі. Іншае заключаецца ў тым, што распрацоўка і тэставанне на мясцовым узроўні абцяжарвае перайманне вытворчых умоў, што можа прывесці да нечаканага паводзінаў прыкладанняў і пасля яго разгортвання.

Самы эфектыўны спосаб пераадолець гэтыя перашкоды - гэта перамясціць трубаправод CI / CD у воблачнае асяроддзе - не толькі для таго, каб атрымаць выгаду ад нязменнай інфраструктуры і маштабаванасці воблака і іншых выгод, але і каб імітаваць умовы вытворчасці і наблізіць ваш трубаправод - столькі ж як можна - да вашых прыкладанняў. Такім чынам, код пішацца бліжэй да таго, дзе ён разгорнуты, што робіць разгортванне больш хуткім. Таксама лягчэй раскручваць выпрабавальную сераду, ідэнтычную вытворчай.

У той час як распрацоўка, якая цалкам заснавана на хмарнай прасторы, падыходзіць не ўсім, і некаторыя распрацоўшчыкі аддаюць перавагу знаёмству і спагадлівасці мясцовых ідэнтыфікатараў над хмарнымі, паспрабуйце забяспечыць, каб вашы трубаправоды CI / CD працавалі ў воблачным асяроддзі, наколькі гэта магчыма.

Выснова

Незалежна ад таго, як вы яго круціце, пераходжанне ў воблака цяжка. У параўнанні са старымі праграмамі, дакладныя прыкладання, якія карыстаюцца воблакам, з'яўляюцца больш складанымі і маюць значна больш месцаў, дзе ўсё можа ісці не так. З улікам гэтага, праблемы з вылічальнай воблачнасцю могуць быць пераадолены - і рэалізацыя стратэгій, якія дазваляюць вырашаць гэтыя праблемы, мае ключавое значэнне для разблакіроўкі спрыту, надзейнасці і маштабаванасці, якую могуць забяспечыць толькі архітэктуры, якія падтрымліваюць воблака.