DBA/Developer в AllStars-IT Ukraine, Microsoft Data Platform MVP – Євген працює з базами даних вже більше 12 років. Розробник за освітою, прийшов у сферу з інфраструктури, починав як системний адміністратор. На Data Talks #5: «Database Management: Cloud vs On-premise. Proprietary vs Open-source» Євген поділився досвідом та ідеями щодо майбутнього роботи з СУБД. Переглянути повний запис вебінару можна тут.
Спікер працює в компанії AllStars-IT Ukraine, яка в тому числі має великий проєкт в галузі Cyber Security. Крім того, Євген надає підтримку щодо баз даних великим сайт-проєктам, наразі серед них – онлайн-казино та ресурс по організації вебінарів.
За освітою – розробник. Крім активної практики в ІТ, викладає проєктування баз даних в НТУУ «КПІ ім. Ігоря Сікорського» (більше про професійну діяльність Євгена Недашківського тут).
Open-source vs. Proprietary. Критерії вибору
Якби стояла задача – запустити новий проєкт, що би обрав Євген? Відповідаючи на питання модератора (Тарас Кльоба), Євген назвав три критерії:
- Загальна архітектура програмного рішення.
- Бюджет. Зазвичай, ми йдемо в open-source, коли «немає грошей». В розумінні деяких людей, open-source – це «ми можемо якось зекономити», але часто це не так. Звичайно, ми дивимося на open-source, коли це стартап, або коли ми ріжемо кости. Але все треба рахувати.
- Стек технологій та експертиза, яка вже є в компанії. До прикладу, у штаті клієнта є 10 фахівців високого рівня з Oracle (або іншої технології). На це потрібно зважати, і не намагатися перетягнути компанію на інше рішення, якщо немає нагальної потреби.
Часто буває і так, що у компанію приходить архітектор, який має іншу експертизу. Людина, яка здатна «змусити» всіх, починаючи від власника, прийняти рішення дивитися в сторону іншої технології. Про таких людей можна сказати – те, що інші назвуть «костилем», він або вона скаже: «так і має бути, це best practice».
Коли би Євген Недашківський порекомендував пропріетарну базу даних?
Завжди! В цілому, навіть якщо ми говоримо не тільки про СУБД, то у пропріетарного програмного забезпечення (ПЗ) є ряд переваг.
Коли це open-source Євгену теж подобається подивитися в код, зрозуміти, як все працює під капотом, розібратися, подивитися на якість коду, як його писали… Але відкритий код відкриває і певні проблеми. Найперше – безпека.
Коли твій код можуть дивитися всі, хто завгодно, ти більш вразливий. Дуже часто у певного ПЗ є проблеми, про які не знають його розробники. Ці проблеми «широко відомі лише у вузькому колі професіоналів». – Якісь умовні бекдори, дірки, за допомогою яких здійснюється несанкціонований доступ до інформації, та з допомогою яких можна створити фейкове навантаження, що повністю покладе систему на певний час.
Плюс, важливо, коли в тебе є контакти підтримки, яка 24 години на добу готова допомогти… Якщо open-source рішення для клієнта не підтримує певна компанія (на умовах контракту), то проблема може не вирішуватися роками. А питання, опубліковане десь на форумі, буде лише збирати перегляди. Це проблема відкритого ПЗ. Якщо це пропріетарне ПЗ, ти просто піднімаєш слухавку або пишеш листа, і твоя проблема якось вирішується.
Чому і як компанії мігрують з open-source на proprietary?
Ситуація, яка дратує – це відомі проблеми в open-source, які ніхто не фіксить, оскільки у всіх є інші справи. Розробникам, в цілому, хочеться робити те, що цікаво (і це не завжди те, що треба). Так само і з розробкою open-source. Чистий open-source, на який не впливає ніякий консалтинг (компанія, що підтримує рішення для клієнта – ред.), дуже часто розвивається саме в тому напрямку, який не цікавий бізнесу, клієнту, а який цікавий розробнику.
До прикладу, людина збирає дані, тому що пише дисертацію, або просто розбирається з новою для себе технологією. Так, він/вона буде копирсатися в багах, але так звані «хотелки» клієнта вирішувати не буде. Це не його клієнти, і йому за це ніхто не платить.
На ентузіазмі деякі проєкти можуть триматися досить довго, доки не приходять нові ентузіасти… Але у загальному ентузіазму однієї людини найчастіше вистачає на рік-два-три, рідко – довше.
Наприклад, Лінус Торвальдс (створив Linux – ядро операційної системи GNU/Linux, самої розповсюдженої open–source ОС та найбільш популярної серверної ОС, – ред.). Скільки Торвальдс комітив коду напочатку і скільки зараз – це дві великі різниці.
Не варто бути наївними і вважати, що open–source Вам щось винен.
Якщо Ви – маленька компанія, у Вас немає бюджету на support, Ви не можете інвестувати в якогось консалтера, який зможе дописати Вам код, виправивши проблему або дописавши потрібний функціонал – то, нажаль, Ви в такій ситуації, де виходом є міграція на іншу СУБД, де цієї проблеми немає, або бажаний функціонал вже є.
Якщо порівнювати просто по функціоналу пропріетарне ПЗ та відкрите ПЗ, то частіше більше функціоналу у пропріетарного. Чому? – Вони мотивовані грошима, розробники кожного дня щось пишуть. Цикл розробки не закінчується ніколи. ПЗ постійно обростає фічами. Плюс, до чогось змушує саме законодавство – у пропріетарного ПЗ набагато більше функцій щодо захисту даних, ніж у відкритого.
Майбутнє відкритого та пропріетарного ПЗ – все розмивається і спрощується:
Коли ми говоримо про хмарні технології, де можна підняти собі instance або реляційну СУБД в декілька кліків, то мені здається, що все розмивається. І взагалі, можливо, скоро ми забудемо і SQL, і перестанемо оперувати термінами NoSQL, NewSQL…, особливо коли синтаксис іде до одного і того самого. Принаймні, розробники сьогодні намагаються, щоб людина, яка знає SQL, могла працювати з тією самою Mongo. Мені здається, це здоровий підхід. Все спрощується.
Cloud vs. On-premise
Євген прийшов з інфраструктури. Розробник за освітою і зараз багато займається девелопментом рішень, але починав як системний адміністратор, як help-desk, і добре знає, що таке маленький дата-центр всередині компанії.
Відчути різницю можна, коли ти вперше заходиш в величезні ангари Google, Amazon або Microsoft, де все (сервери – ред.) абсолютно однакове, де купа запасних частин, де знаходиться штат працівників, які з цим апаратним забезпеченням працюють вже декілька років, пройшли всі можливі тренінги… Можливо, там навіть є люди з боку вендора. Це величезна перевага хмарних дата-центрів. І ніякі гібридні хмари цю перевагу не перетягнуть.
В першу чергу, це величезна надійність. Там дійсно дотримуються SLA (Service Level Agreement – угода про рівень надання послуг, ред.). Плюс, дуже розумно обирається локація, щоб не було землетрусів, торнадо, було одразу три лінії електропостачання від різних електростанцій, щоб поруч були висококваліфіковані кадри, щоб там постійно хтось знаходився… Я пам’ятаю, як в першій компанії ми вирішували, де розташуємо сервери: «У нас є приміщення, де швабри стояли, там ми стійку і поставимо. Вентиляції немає – це кепсько. Давайте щось вигадувати».
Майбутнє – за хмарою
Але он-преміс залишиться. Він буде завжди. Буде тестування, будуть такі дані, які ми нікуди не зможемо діти. Можливо, Amazon, Google, Azure зайдуть в Україну невеличкими дата-центрами. Або ми станемо частиною Євросоюзу 😊. Можна вірити в світле майбутнє. Все дешевшає, і я бачу, що майбутнє за хмарою. Досвід мені це підказує.
Всі мої проєкти зараз або в клауді, або мігрують в клауд. Після розрахунків власниками, було вирішено, що хмара набагато зручніше і по грошам, і по розгортці систем, і по масштабуванню систем.
Хмара або он-преміс – так, що обрати?
Залежить від того, що ми плануємо. У довгостроковому періоді, якщо ми знаємо, що будемо працювати 5-10 років, нам вигідніше працювати з хмарою. Там не треба думати про електроенергію, вентиляцію, охолодження, обслуговування, про пачі…
Amazon, Google, Microsoft дають ще й можливість безкоштовно використати (спробувати) більшість технологій. Так, з мінімальним навантаженням, але ми можемо зробити MVP, proof of concept, подивитися, чи дійсно нове рішення працює, налаштуватися, перевірити… Є у них і програми для enterprise. Наприклад, у Майкрософта була програма для стартапів, коли Ви можете не платити, поки не вийдете на дохід. Є рішення і для студентів… Це круто!
Візьмемо простого розробника-початківця. Щоб писати код, йому треба щоб у нього, як мінімум, був його власний ноутбук, поставити туди ПЗ, налаштувати, зрозуміти, як створити новий проєкт, як зберегти код… Для людини без досвіду це дуже важко.
Найбільшим недоліком для України вважаю те, що для нас cloud – це дорого. І це все-таки інша мова. Документація написана англійською. Для когось це важко сприймається. Якби Amazon, Microsoft та Google були орієнтовані на Україну, у нас би і вся документація була перекладена, і дата-центри були місцеві. А поки що для нас і дорого, і за кордоном.
Хмара дорожче?
Коли ми самі створюємо рішення, то платимо багато грошей на початку. В хмарі це просто розтягнуто в часі.
Основний драйвер переходу в хмару за кордоном, наприклад, в США – це саме людський фактор – ми можемо не тримати додаткових людей в штаті, і вивільнити кошти для оренди серверів. Якщо зарплати в ІТ в Україні будуть зростати, то все більше людей будуть дивитися в сторону хмари.
Насправді, хмара – це не дорого. Просто ми дуже часто порівнюємо вартість обладнання та те, що нам пропонує хмара. Але в on-premise є ще купа додаткових витрат (те ж електропостачання та ін.), і про них треба пам’ятати при розрахунках.
Database as a Service (DBaaS)?
З мого досвіду, люди, які пішли в хмару, зробили це з мінімумом зусиль. Маємо: віртуальне середовище, і там – он-преміс. В компанії дуже часто є адміністратор бази даних, системні адміністратори, люди, які розбираються і в операційних системах, і в мережах, і в СУБД. І коли в тебе рішення он-преміс, нехай навіть в хмарі (інфраструктура як сервіс), в тебе більше контролю, ти більше можеш підтюнити, швидше розібратися в якихось проблемах, ніж це зробить support. З іншого боку, я бачу і той тренд, що компаніям, в яких такої експертизи не мають, простіше стартанути з Database as a Service.
Цікавий тренд – коли це тільки починалося, багато говорили: «О! Database as a Service – це круто. Там одна кнопка. Натиснули, і все піднялося. Вибрали, скільки грошей хочете платити, і воно працює. Адмін баз даних не потрібен. Архітектор – просто структуру написати…». Зараз є попит на таке: «Ок, мені подобається, як воно все працює, але я хочу щось там підтюнити». Наприклад, щоб паралелізм по-іншому працював, або дати на один запит більше пам’яті, тому що він не вміщується, або більше процесорів…
В результаті, хмарна СУБД як сервіс поступово обростає всіма цими налаштуваннями, які є в он-преміс СУБД. Плюс, з’являються додаткові модулі по аналітиці. І виходить, що – хочете класно працювати в хмарі, все одно прийдеться розбиратися і мати спеціаліста.
Для старту проєкту DBaaS – саме воно. Але якщо Ви ростете, навантаження і об’єми збільшуються, то, скоріш за все, доведеться думати про адміністратора БД (DBA), про тюнінг запитів, про тюнінг СУБД…
Чи буде завтра робота для DBA?
Хочу заспокоїти глядачів – без роботи ми не залишимося. Ця ніша продовжує існувати, вона не зменшується, але і не росте. Вона трансформується. Якщо раніше просто треба було вміти працювати з он-преміс СУБД, то тепер треба працювати з хмарною СУБД. Знати, як правильно її налаштувати, як правильно підібрати розмір, як її масштабувати, чи можна її масштабувати автоматично…
Вчимо скриптові мови, які дозволяють нам працювати з хмарними провайдерами і т.д. Сама професія еволюціонує. А код доводилося писати і раніше. Нікуди ти звідси не дінешся…
Щиро дякуємо Євгену Недашківському за час та досвід!
Приєднуйтеся до Data Talks на нашому YouTube-каналі SQL ua.
SQL.ua Data Academy
Advanced Data Teaching and Learning! 💎