IaaS супраць PaaS на прыкладзе SQL у Azure

Вельмі часта перад архітэктарамі стаіць выбар паміж Infrastructure-as-a-Service (IaaS) і Platform-as-a-Service (PaaS). Калі не паглыбляцца ў дэталі, то IaaS vs. PaaS – гэта выбар паміж "я сам мяняю аліву і фільтры ў аўтамабілі" і "лепш паеду да афіцыйнага дылера". Першае азначае большую свабоду дзеянняў (можна і "нітру" паставіць!) пры большай ступені адказнасці, а другое – наадварот, дэлегаванне адказнасці і неабходнасць трымаць сябе ў вызначаных рамках. Варта адзначыць, што карыстанне "PaaS-сэрвісам" верагодна пакіне больш часу для кіравання аўтамабілем.  

Спачатку Cloud правайдары рабілі толькі IaaS-прапановы, такія як віртуальныя машыны (VM). Але цягам часу стала зразумела, што ў малых і сярэдніх бізнесаў звычайна не хапае сродкаў, каб заплаціць і за распрацоўку праграмы, і за падтрымку інфраструктуры. Час на рэалізацыю таксама каштуе дорага, бо варта быць early-to-market. З гэтай нагоды пачалі з’яўляцца рашэнні, якія дэлегавалі частку абавязкаў правайдару і, такім чынам, ашчаджалі каштоўны час на распрацоўку. Сёння на прыкладзе SQL Server разглядзім, сучасныя прапановы Azure.

SQL Server на VM (IaaS). Калі вы ў IT працуеце больш за 5 гадоў, то вы дакладна бачылі такое рашэнне, бо раней толькі так і рабілі. На звычайную віртуальную машыну самастойна ўсталёўвалі паўнавартасны SQL Server і карысталіся поўным набор фіч базы даных, уключаючы SQL Jobs, SSRS, SQL Aliases, Windows AD і г.д.

Калі мы ідзем шляхам IaaS, то мусім наладзіць 2 дадатковыя працэсы:

• Адміністраванне SQL.
• Адміністраванне VM.

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

Azure SQL (PaaS). Як я ўжо адзначаў, мы дэлегуем частку абавязкаў правайдару (гл. табліцу ніжэй). Напрыклад, можна забыцца на віртуальную машыну і яе падтрымку. Таксама з прыемнага нам даецца апошняя версія SQL Server, якая будзе аўтаматычна абнаўляцца. Azure гарантуе дасяжнасць базы (SLA) мінімум 99.99% часу, які можна падымаць вышэй за кошт убудаваных сродкаў availability (напрыклад Zone-redundancy). То бок пытанне палепшыць SLA будзе ўпірацца толькі ў грошы, але ніяк не ў тэхнічныя скілы каманды.

Відавочна, што заплаціць за гэта даводзіцца абмежаваным функцыяналам, таму мы мусім зверыцца з табліцамі сумяшчальнасцяў. Але па маім досведзе гэта даволі спецыфічныя рэчы. Напрыклад, SSRS, які ў 2023 годзе сустрэнеш не часта. Ці SQL Jobs, якія больш распаўсюджаныя, але ў той жа час іх лёгка перанесці на Azure Functions. Я вяду да таго, што ў большасці выпадкаў адсутнасць тых ці іншых фіч у Azure SQL не стане блокерам.

У Azure SQL ёсць яшчэ адзін важны нюанс. Рэч у тым, што ў адрозненні ад IaaS мы вызначаем рэсурсы (ядры і памяць) на кожную базу паасобку і, адпаведна плацім таксама per-database. То бок, калі мы захочам дадаць новую базу ў той жа сервер, мы павялічым кошт сістэмы (у IaaS варыянце кошт не павялічыцца). Зразумела, што мы будзем больш гнуткімі і эфектыўнымі пры выкарыстанні рэсурсаў.

 Адзначу, што Azure SQL у сваю чаргу мае некалькі разнастайнасцяў (DTU-based vs. Core-based), але гэта ўжо асобная тэма. Вось тут я распавядаў пра Core-based Serverless; пачытайце калі прапусцілі.

Azure SQL Managed Instance (MI). Як вы можаце здагадацца, ён займае месца пасярэдзіне паміж першым і другім рашэннямі, наследуючы перавагі і недахопы абодвух. SQL MI – гэта паўнавартасны SQL Server, але ў параўнанні з IaaS рашэннем мы не маем доступу да віртуалкі, на якую ён усталяваны. Такім чынам, у нас больш няма галаўнога болю звязанага з патчамі і падтрымкай аперацыйнай сістэмы, як і ў Azure SQL. У той жа час усе фічы SQL Server дасяжныя для выкарыстання (насамрэч амаль усе). Рэсурсы выдзяляюцца на ўвесь сервер, а не паасобку па базах – то бок як і ў IaaS. Гэта будзе перавагай для вялікіх праектаў. Але як звычайна ёсць і trade-offs.

• Высокі кошт, асабліва для надзейных рашэнняў з redundancy і SLA, які па маім досведзе перавышае эквівалентныя рашэнні.
• На нас застаецца адказнасць за Routing Tables, то бок на даволі нізкім узроўні мы мусім паглыбляцца ў сапорт сеткі і адказваць за яе бяспеку.
• Максімальны памер базы толькі 16Tb. Гэта найгоршы паказчык сярод тройкі (у PaaS гэта 100Tb).
• Адсутнасць Windows AD, Database Mirroring і некалькіх іншых фіч SQL Server. Спіс значна меншы ў параўнанні з Azure SQL, але сумяшчальнасць не 100%.  

Як выбраць паміж трыма варыянтамі? На жаль, самым правільным будзе адказ "it depends". Канчатковае рашэнне залежыць ад шэрагу фактараў, але я хачу выдзяліць некалькі распаўсюджаных сцэнароў, якія вам дапамогуць.

SQL Server on VM (IaaS) будзе добрым варыянтам для:

1. Міграцый баз даных з on-premise ці з іншых аблокаў as-is.
2. Сістэмаў, дзе патрэбны поўны кантроль над інфраструктурай і ёсць каманда, гатовая рабіць гэтую працу.
3. Вялікіх сістэмаў, патрабаванні якіх выходзяць за рамкі PaaS прапаноў. Напрыклад, базы большыя за 100Tb, 80+ ядраў на базу і г.д.
4. Сістэмаў, дзе задэкларавана поўная сумяшчальнасць з SQL Server (напрыклад, legacy сістэмы, якія "лепш не чапаць").

Azure SQL MI зможа канкураваць з IaaS у выпадку 1, які я прывёў вышэй. Варта звярнуць на MI ўвагу, калі міграцыя ў Cloud разглядаецца толькі як першы крок інтэграцыі і рэ-дызайну экасістэмы. Але ў цэлым няма відавочнага сцэнара, калі Managed Instance будзе стоадсоткава правільным выбарам. Для мяне ён застаецца часовым рашэннем, з далейшым пераходам у PaaS.

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