АБАЖУРЫ | Azure

Нядаўна паспрабаваў скарыстацца Python там, дзе не варта было. Пачытаць пра пакуты можна тут 👈. #cosmosdb #python [Read me in ENG here]

Вітаю, сябры! Неспадзявана Microsoft заняўся рэбрэндынгам Azure Active Directory. Ці варта клапаціцца? Я сабраў першыя думкі ў артыкул. #azuread [Read me in ENG here]

На гэтым тыдні я падрыхтаваў яшчэ адзін лонг рыд. На гэты раз не пра AI, а пра даволі просты інструмент winget. Ці слушна, што просты = карысны? Пачытайце тут. #winget #packagemanagement [Read me in ENG here]

Вітаю, сябры. Дзякуй за пілюлі на маім папяэднім пасце! Як і дамаўляліся, я напісаў артыкул пра мае змаганні з Azure AI Studio. Прыемнага чытання! #ai #azureaistudio https://telegra.ph/YAk-ne-rashyc-sapra%D1%9Ednuyu-prablemu-z-dapamogaj-Azure-OpenAI-%D1%96-zastacca-%D1%9E-gumory-06-27

Вітаю, сябры. Нарэшце апублікаваныя вынікі традыцыйнай штогадовай апытанкі Stack Overflow Survey 2023. Для мяне гэта напамін таго, як хутка ляціць час, бо ў мінулым годзе я таксама пісаў пра яе. Паглядзець графікі і ўглыбіцца ў дэталі можна тут, а я тэзісна раскажу, што прыцягнула маю ўвагу. 1. Дадаўся новы раздзел з нечаканай назвай AI. Як паказвае статыстыка, 44% распрацоўшчыкаў карысталіся AI tools у сваёй працы цягам года, а 30% не карысталіся і не збіраюцца. Запомнім гэтыя лічбы – у наступным годзе варта праверыць тэндэнцыю. Мой прагноз, што яны застануцца на месцы +- 5 працэнтных пунктаў – пасля маланкавага росту любая тэхналогія дасягае піку сваіх магчымасцяў, таму чакаю выхад на плато ў бліжэйшы год. Дарэчы, нядаўна я паспрабаў рашыць сапраўдную кліенцкую задачу з дапамогай Azure OpenAI і ChatGPT. Ці будзе вам цікава пачытаць лонг-рыд, як я гэта рабіў? Калі так – пастаўце значок пілюлі, ці напішыце ў каментар. Калі набярэцца 15 рэакцый, то абавязкова напішу падрабязны артыкул цягам тыдня. 2. У раздзел Technology - Databases упершыню патрапіў Cosmos DB. 51% дэвелапераў сярод тых, хто працаваў з космасам, хацеў папрацаваць з ім у будучыні. Прыблізна такі ж узровень даверу маюць, напрыклад, DynamoDB (50%), Mongo (55%), SQL Server (55%). Сярод лідараў без зменаў з мінулага году – PostgreSQL (71%) і Redis (70%). 3. Добрыя вынікі ў гэтым годзе паказаў .NET (5+) – рост даверу з 68 да 70% сярод тых, хто з ім працаваў. Дарэчы з .NET 8 ужо можна гуляцца, а рэліз запланаваны на лістапад. 4. Новая мова Zig займае першае месца ў раздзеле Top Paying Techologies. На жаль, не магу нічога сказаць пра яе, бо чую ўпершыню. Пераможца мінулага года Clojure скаціўся на 5 месца, прапусціўшы наперад Erlang, F# і Ruby. Stackoverflow Survey – добры індыкатар індустрыі, якому я давяраю ўжо шмат гадоў. Шчыра раю пачытаць яго і зверыцца з вашымі доўгатэрміновымі планамі. Магчыма, вы знойдзеце для сябе натхненне, ці проста добра прабавіце час. #stackoverflowsurvey

Я працягваю аглядаць найбольш цікавыя навіны з канферэнцыі Microsoft Build. Сённяшні пост прысвечаны Cosmos DB Time To Live (TTL). TTL - гэта найбольш папулярны ўзор кіравання занятай дыскавай прасторай. Хутчэй за ўсё вы чулі пра яго, працуючы з кэшамі - ад стандартнага key-value у памяці машыны да болей складаных рашэнняў, такіх як Redis ці Memcached. Калі вызначаны час жыцця (TTL) сканчваецца, даныя аўтаматычна выдаляюцца (гл. малюнак). Тым не менш знайсці рэляцыйную базу з натыўнай падтрымкай TTL даволі складана. І гэта зразумела – хіба хтосьці захоча выдаляць запісы каскадам у розных табліцах? Вядома, што распрацоўшчыкі хочуць больш кантролю, калі трэба рэалізаваць нешта падобнае, таму TTL няма ў SQL Server, MySQL, PostreSQL і г.д. Зусім іншая справа NoSQL базы даных. Тут дакументы з'яўляюцца самадастатковымі кавалкамі даных, таму і TTL пасуе лепей. Як вынік, папулярныя рашэнні NoSQL, напрыклад, AWS Dynamo, MongoDB, Cassandra і г. д., ужо даўно падтрымліваюць TTL. У гэтым сэнсе Cosmos DB дагэтуль заставаўся аутсайдарам. Цяпер, калі фіча выйшла ў свет, у мяне ўзнікла пытанне, як механізм вызвалення памяці карэлюе з абмежаваннямі RU. У папярэднім пасце я расказваў, што Cosmos DB вяртае памылку Too Many Requests пры перавышэнні ліміту. Аперацыіі DELETE па TTL ні ў чым не адрозніваюцца ад звычайных SELECT/UPDATE/INSERT і таксама патрабуюць RU. Ці ёсць верагоднасць, што мая праграма можа завіснуць, калі ў фоне запусціцца масавае выдаленне па TTL? Дакументацыя кажа, што калі Cosmos DB запускае ачыстку на падставе TTL і выяўляе, што вольных RU недастакова, то фізічнае выдаленне запісаў затрымліваецца. Але самі даныя больш не бачныя праз запыты – атрымліваецца нешта накшталт soft delete. Выглядае на тое, што негатыўнага ўплыву не будзе, але я ўсё ж рэкамендую выкарыстоўваць TTL разам з Burst Capacity, каб дакладна не вычарпаць увесь RU. Паспрабуйце наступнае: запытайце вашага кліента пра Retention Policy. Як доўга тыя ці іншыя даныя мусяць існаваць у сістэме? Выкарыстоўвайце TTL (у Cosmos DB ці ў іншай базе), каб наладзіць такую палітыку ўтрымання даных. #cosmodb #operationalexcellence [Read me in ENG here]

Я ўжо адзначаў, што Microsoft Build 2023 прайшоў пад хэштэгам AI, але анонсаў перспектыўных фіч для іншых сэрвісаў было нямала. Сёння раскажу пра Burst Capacity для Cosmos DB. Фірмовая база Azure адрозніваецца ад класічных рэляцыйных баз, и не толькі таму что гэта NoSQL. Для яе існуе штучная метрыка прадукцыйнасці – Request Units (RU), дзе 1 RU – гэта кошт чытання дакумента памерам 1 Kb па яго ID (калі дакладней па камбінацыі ID і PartitionKey). Чым складаней запыт, тым больш RU ён будзе каштаваць: UPDATE будзе даражэйшы за SELECT, а SELEСT + LIKE даражэйшы за point read. Варта адзначыць, што паралельны запуск аперацый не павялічвае іх кошт паасобку – RU проста сумуюцца. Пры праектаванні я заўсёды пачынаю з разлікаў, колькі RU у секунду (RU/s) патрэбна сістэме. Спецыяльны калькулятар ад Azure аўтаматызуе працэс і ў выніку атрымліваецца нейкая лічба, напрыклад 100 RU/s. Падкрэслю яшчэ раз, што так мы вызначаем прадукцыйнасць (throughput) базы і яе кошт. Калі мы перавысім гэты ліміт, напрыклад у пэўную секунду спатрэбіцца спажыць 110 RU, то космас вяртае памылку 429 (Too Many Requests). Менавіта па гэтай прычыне ў існуючых праектах у слоі базы даных амаль заўсёды сустракаецца самапісны retry logic. Але разам са з’яўленнем Burst Capacity сітуацыя, я лічу, зменіцца. Новая фіча дазваляе назапашваць невыкарыстаныя RU. Напрыклад, калі база на 100 RU/s стаіць без працы 5 хвілін, то яна назапасіць 100 RU/s x 300 секунд = 30 000 дадатковых RU. Такі запас можна спажыць з максімальнай хуткасцю 3000 RU/s, то бок павялічыць прапускную здольнасць базы ў 30 разоў на цэлыя 10 секунд! Раней не было гатовага рашэння, каб вытрымаць нагрузку, якая перавышае “намінальную” так моцна. Даводзілася: - Ці плаціць значна больш, - Ці вынайсці сваё кола, ускладняючы сістэму. З Burst Capacity верагоднасць атрымаць 429 памылку зніжаецца, што значыць больш responsive UI для карыстальніка. А калі ваш графік нагрузкі мае рваны характар, то і ашчаджэнне сродкаў будзе каласальным. #cosmosdb #performance [Read me in ENG here]

Do Legendary Shit! Гэта галоўны заклік, які прагучаў падчас канферэнцыі Microsoft Build 2023. Такім чынам кампанія падкрэслівае маштаб таго прагрэсу, які прайшоў штучны інтэлект за адзін год. Перамены, што адбываюцца сёння і якія магчымасці яны адчыняюць, варта параўноўваць з такой вяхой у сучаснай гісторыі, як вынаходніцтва інтэрнэту. Як можна было чакаць, большая частка аб’яваў была звязана з AI. Таксама хачу адзначыць павялічаную колькасць дакладаў і круглых сталоў пра Cosmos DB (у параўнанні з мінулым годам). Асабліва мне спадабаліся Q&A сессіі з прадстаўнікамі кампаній, якія паспяхова ўнядрылі гэта NoSQL рашэнне ад Azure. У наступных постах я больш падрабязна спынюся на самых перспектыўнах навінках, а пакуль падзялюся з вамі сваім шорт-лістам са спасылкамі на відэа. 1. Windows Copilot. Памятаеце знакамітую скрэпку з Microsoft Office 97? З чэрвеня ў Windows будзе ўбудаваны Copilot – ваш персанальны ChatGPT дапаможнік. Паглядзець прэзентацыю можна тут з 48 хвіліны. 2. Azure AI Studio. Калі першы пункт майго спіса – пра персанальнае карыстанне штучнага інтэлекта, то Azure AI Studio – гэта магчымасць для кампаній натрэніраваць ChatGPT на сваіх даных. Глядзець тут з 25-й хвіліны. 3. Scott Hanselman у 2018 годзе меў рацыю, задаючы пытанне: “Чаму ў Windows ёсць performance рэжым для гульняў, але няма падобнага рэжыму для распрацоўшчыкаў?”. Учора на канференцыі ён стаў першым, хто паспрабаваў новы фічы для аптымізацыі нашай штодзённай працы. Шчыра раю паглядзець гэта (увага - прысутнічае гумар). #msbuild23 [Read me in ENG here]

Вітаю, сябры! Я вырашыў стварыць у канале серыю апытанак, дзе прапаную вам прыняць архітэктурнае рашэнне. Галоўныя мэты наваўвядзення наступныя: 1) Дадаць крыху інтэрактыву ў канал. Так будзе весялей :) 2) Даць вам магчымасць замацаваць веды, бо звычайна проста прачытаць не значыць засвоіць. Пачнем з простага пытання пра Azure Storage Account. Правільны ці неправільны адказ вы пабачыце адразу, а тлумачэнне я апублікую каментам цягам дня. [Read me in ENG here]

Кіраванне рознымі файламі з’яўляецца важным пытаннем пры праектаванні, бо кожным кавалкам даных карыстаюцца па-рознаму. Напрыклад, фота ў сацсетцы заўсёды ў цэнтры ўвагі – іх трэба паказваць у лентах і профілях, іх можна выдаляць і рэдагаваць. З іншага боку, PDF-файл з пацверджаннем аплаты, сгенераваны інтэрнэт-банкінгам, хутчэй за ўсё будзе спампаваны толькі аднойчы. У Azure ёсць некалькі варыянтаў, як будзе працаваць сховішча – Hot, Cool і Archive. Варта параўнаць іх паміж сабой наступнымі параметрамі: 1) Кошт за 1 Gb аб’ёму. 2) Кошт за аперацыю чытання. 3) Кошт за аперацыю запісу. Hot мае самы высокі кошт за аб’ём даных, але самыя танныя аперацыі чытання/запісу. Як вы маглі здагадацца, ён падыходзіць для “гарачых” даных, якімі актыўна карыстаюцца – напрыклад, відэа ў YouTube. Cool, наадварот, больш дэмакратычны па кошце за гігабайты (прыблізна на 25%), але мае удвая даражэйшы кошт за чытанне/запіс. Гэты tier варта абраць у тым выпадку, калі данымі карыстаюцца зрэдку, напрыклад файлы квіткоў ці чэкаў. Нарэшце Archive мае самы нізкі кошт за аб’ём (у 20 разоў меншы за Hot), аднак ёсць нюанс – вашыя файлы не будуць дасяжныя ў рэальным часе. У Hot і Cool на ўзроўні жалеза файлы ляжаць на хуткіх SSD/HDD дысках, а ў archive – іх запісываюць на магнітныя ленты, што патрабуе шмат фізічнай працы ад супрацоўнікаў дата-цэнтра. Таму аднаўленне даных з Archive tier займае некалькі дзён. Але хутка трыа Hot/Cool/Archive стане квартэтам – Azure выпусцілі ў прэв’ю новы Cold tier. Ён мусіць заняць месца паміж Cool і Archive і, такім чынам, дадаць крышачку больш гнуткасці пры выбары плану. Ён накіраваны на такія сцэнары выкарыстання, калі файл запісваюць аднойчы і ў большасці выпадкаў не кранаюць, пры тым што сам файл павінен быць анлайн (напрыклад бэкапы). Адзначу, што Cool тут не вельмі пасаваў з-за свайго даволі высокага кошту за аб’ём даных. Такім чынам, я планую пасля рэлізу карыстацца новым планам для бэкапаў і логаў, што дазволіць ашчадзіць сродкі на сховішча. Думаю, што Cool застанецца для сцэнароў, калі даныя трэба кранаць хоць некалькі разоў за жыццёвы цыкл. #storageaccount #costsaving [Read me in ENG here]

MSBuild – гэта галоўная канфэрэнцыя, якую Microsoft праводзіць для распрацоўшчыкаў адзін раз на год. Я ўпэўнены, што падрыхтоўка да яе моцна нагадвае вельмі важны “рэліз”, калі ў апошні момант чыняцца багі і даробліваюцца фічы. Таму наўрад ці ў першай палове траўня нам варта чакаць новых абнаўленняў у Azure – іх хутчэй будуць прыхоўваць да канферэнцыі 😊. Канферэнцыя адбудзецца 23-25 траўня. Дастаткова зарэгістравацца на сайце, каб паўдзельнічаць анлайн (бескаштоўна). Калі вы ніколі не ўдзельначалі ў MSBuild ці іншых анлайн канферэнцыях, вось некалькі прычынаў паспрабаваць: - зразумець, ці пасуе вам такі фармат. - атрымаць зніжку на Azure Cloud экзамены (хутчэй за ўсё прыйдзецца прайсці які-небудзь просты challenge). - лепш разумець сучасны кантэкст і трэнды ў тэхналогіях. Я сачыў за канферэнцыяй у мінулым годзе і застаўся задаволены колькасцю цікавых навінаў – быў і запуск MAUI, і інтэграцыя Functions з Azure SQL, і г.д. Спадзяюся, што і гэтым разам Microsoft не расчаруе. У любым выпадку я традыцыйна буду асвятляць падзеі ў канале. #news #msbuild23 [Read me in ENG here]

Калі вы шукаеце, якую PaaS SQL базу даных выбраць, то ў Azure такіх варыянтаў тры: Azure SQL, Azure Database for PostgreSQL і Azure MySQL. Я ўпэўнены, што над паляпшэннямі для Azure SQL працуе нашмат больш інжэнераў чым над астатнімі базамі, бо гэта “родны” SQL Server. Тым не менш, рэлевантныя фічы выходзяць і для open-source рашэнняў. Сёння я хачу звярнуць вашую ўвагу на новую фічу для PostgreSQL – Read replicas. Цяпер стала магчымым наладзіць аўтаматычную рэплікацыю даных у другасны сервер, які будзе дасяжны для read-only аперацый. Яго можна размясціць як у асноўным рэгіёне і, такім чынам, рэалізаваць сапраўдны CQRS – калі аперацыі на запіс і чытанне разводзяцца па розных серверах (гл. малюнак). Ці як мінімум проста крыху вызваліць асноўную базу ад часткі аперацый чытання. Другі варыянт – усталяваць рэпліку ў іншым рэгіёне, каб павысіць надзейнасць сістэмы – у выпадку трасцы рэгіянальнага маштабу ў вас будзе працуючая база з апошнімі (ці амаль апошнімі) данымі. Будзе з чаго пачаць disaster recovery! Адзначу, што рэплікацыя з’яўляецца асінхроннай, то бок даныя абнаўляюцца з затрымкай, якая залежыць ад шэрагу фактараў. Але калі вы не аперуеце тэрабайтамі даных, то хутчэй за ўсё гэта будуць секунды ці нават менш. У любым выпадку патэнцыйны лаг варта ўлічваць пры праектаванні. #news #reliability #postgresql #cqrs [Read me in ENG here]

Нарэшце ў мяне ёсць нагода напісаць пра гарызантальнае маштабаванне (horizontal scaling), бо ў Azure Functions (Consumption і Premium) з’явілася новая фіча – Target-Based Scaling. Нагадаю, што “маштабавацца гарызантальна” значыць ствараць новыя копіі праграммы, каб справіцца з павялічанай нагрузкай. Карыстальнікі Azure Functions, App Services, віртуальных машын і многіх іншых сэрвісаў воблака даўно карыстаюцца такой магчымасцю. Для гэтага дастаткова наладзіць правіла росту, напрыклад, “калі ў чарзе 1000 паведамленняў, стварыць 4 новыя функцыі”. У прыкладзе вышэй мы хардкодзім крок павялічэння колькасці фунцый – 4. А што калі паведамленняў у чарзе будзе 1200, 1600 ці 2000? Ствараць новыя правілы на кожны выпадак? Target-Based Scaling рашае праблему, бо з ёй крок маштабавання вылічваецца аўтаматычна. Дынамічная формула падкліку выглядае наступным чынам: Патрэбная колькасць функцый = бягучая дліна чаргі / колькі рэчаў апрацуе адна функцыя. У прыкладзе вышэй, на 1000 паведамленняў мы выстаўлялі 5 функцый (1+4), то бок адна функцыя здольная апрацаваць 200 рэчаў (гл. малюнак). Гэты параметр і трэба задаць у наладах маштабавання. Адзначу, што Target-Based Scaling сумяшчальны выключна з чэргамі паведамленняў: Service Bus, Storage Queue, Event Hub і CosmosDb (triggers). Але і гэтага дастаткова, каб стварыць вельмі гнуткую scaling стратэгію, якая будзе адпавядаць вашым інтарэсам. #news #performance #scaling #functions [Read me in ENG here]

Вітаю, сябры! Напярэдадні я паспяхова здаў іспыт AZ-104 Azure Administrator. Было зразумела, што давядзецца плённа папрацаваць, каб падрыхтавацца да экзамену, таму вельмі крута нарэшце дасягнуць сваёй мэты. З радасцю буду надалей дзяліцца з вамі актуальнымі ведамі і досведам ў маіх пастах, на воркшопах і курсах. #stories #certification [See translation to ENG in comments]

Вітаю, сябры! Абажурам ужо больш за год, і мне прыемна бачыць, як беларускамоўная IT прастора напаўняецца новым і якасным кантэнтам, а яе аўдыторыя павольна, але рэгулярна пашыраецца. Сёння хачу звярнуць вашу ўвагу на тэлеграм-канал, прысвечаны front-end распрацоўцы – Беларускі франтэнд і іншая трасца. Тут вы знойдзеце апошнія навіны гэтай сферы, пытанні для падрыхтоўкі да інтэрв’ю, карысныя прыклады коду і шмат іншага. Пашырайма беларускамоўны IT разам!

Любы карыстальнік інтэрнэту пастаянна спампоўвае штосьці сабе на камп'ютар ці тэлефон: фота, відэа, дакументы, гульні і г.д. Аднак пад бяспечным файлам можа хавацца шкодная праграма, якая пераўтворыць ваш дэвайс у ферму для здабычы крыпты. Пры праэктаванні воблачнай сістэмы мы нясем тыя самыя рызыкі, на якія не варта заплюшчваць вочы. Тым больш, што праблема рашаецца як і ў дамашнім асяроддзі – антывірусам. Для віртуальных машын у Azure рапрацоўшчыкі карысталіся Microsoft Defender – было дастаткова усталяваць пашырэнне для VM і вы атрымлівалі абарону ад вірусаў. Аднак такое рашэнне не пакрывала галоўнага – Storage Account, які вельмі часта з’яўляецца асноўным сховішчам файлаў. Напрыканцы сакавіка адбыўся рэліз Microsoft Defender for Storage. Як зразумела з назвы, новае рашэнне імкнецца зачыніць крыўдную хібу (гл. малюнак). Акрамя сканавання ўсіх тыпаў файлаў на вірусы, вы атрымліваеце Activity Monitoring – аналіз карыстальнікаў сховішча, які дазваляе выявіць залішнія правы і падазроную актыўнасць. На жаль, Microsoft Defender for Storage працуе толькі з цалкам публічнымі Storage Account і тымі, што дазваляюць доступ праз VNet (whitelisting). Мне падаецца, што з боку Microsoft было б добра прапанаваць нешта і для больш ізаляваных экасістэмаў, але відавочна гэта не іх мэтавая аўдыторыя на дадзены момант. Тым не менш я планую ўключаць новае рашэнне там, дзе магчыма. Асабліва ў праэктах, дзе security знаходзіцца на першым плане. #security #antivirus #storageaccount [See translation to ENG in comments]

На мінулым тыдні маю ўвагу прыцягнуў Azure Data API Builder – гэта open-source праэкт, які дазваляе без напісання бэкэнд коду ставарыць паўнавартасны REST і GraphQL API для баз даных (гл. малюнак). У падарунак ідуць сартыроўка, фільтрацыя і paging. На дадзены момант праграма спалучаецца з асноўнымі рашэннямі Azure – Cosmos DB, Azure SQL, Postgresql. Адзінае, што трэба ад распрацоўшчыка – гэта дэкларатыўна замапіць табліцы на рэсурсы (аб'екты) REST, якімі будзе карыстацца кліент. Атрымоўваецца нешта накшталт ORM, але абстрагуецца праграма цалкам, а не толькі слой даных. Калі патрэбна адкрыць кліенту некалькі табліц базы даных, то Azure Data API Builder можа зэканоміць шмат часу. На сённяшні дзень Azure Data API Builder інтэгруецца са Static Website – PaaS рашэннем Azure для хостынгу франтэнду. Гэта перспектыўнае спалучэнне, якое можа спрацаваць у простых бізнес даменах. Калі неабходна больш складаная логіка (якую сродкамі Data API Builder рэалізаваць немагчыма), на дамамогу прыйдуць Azure Functions, з якімі Static Website таксама інтэгруецца. Калі вы не карыстальнік Static Website, то вам спатрэбіцца стварыць інфраструктуру для Azure Data API Builder. Адзінай песпектыўнай опцыяй па кошце будзе Azure Container Instances, з яго тарыфікацыяй па часе працы. Безумоўна гэты праэкт не варта разглядаць як адзінае рашэнне слою даных. Але ў спалучэнні з іншымі Azure сэрвісамі можа заняць сваю нішу. #staticwebsite #dataapibuilder #aci [See translation to ENG in comments]