Хмара, війна і 12 волонтерів. Як EPAM бекапив дані українських університетів на сервери AWS

Після повномасштабного вторгнення українським університетам потрібно було перемістили свої дані у «хмару» — це допомогло б зберегти інтелектуальний потенціал країни у разі фізичного знищення будівель і серверів. Цим масштабним проєктом займалися спеціалісти EPAM, за що отримали відзнаку на Першій премії DOU.

Про те, як це відбувалося, чому сисадміни не завжди розуміють можливості «хмари» і як налаштування серверів AWS зменшило витрати удвічі, вони розповіли в цьому інтерв’ю. Обережно, багато технічних деталей!

У розмові взяли участь спеціалісти харківського офісу EPAM:
Денис Гриньов, керівник освітніх програм в EPAM Ukraine;
Михайло Хижняк, Service Delivery Manager;
Андрій Костромицький, EPAM Chief Talent Development Specialist & AWS Ambassador.

Денис Гриньов, керівник освітніх програм в EPAM Ukraine

«Дані університетів, які зберігалися просто в будівлях на серверах, потрібно було врятувати». Про те, як почалася співпраця

Денис Гриньов: Приблизно 15 років тому ми стали вперше контактувати з університетами Києва, Харкова і Львова. Ми шукали таланти у вишах і пропонували їм пройти співбесіду, влаштовували для них окремі зустрічі, курси. Наступним етапом стало створення спільних прикладних лабораторій. Університети були зацікавлені. По-перше, найкращих студентів ми працевлаштовували. По-друге, актуалізували програми навчання разом з активними викладачами. У доковідний час у нас діяли лабораторії в близько 30 університетах. Потім ми перейшли в онлайн, наразі укладені меморандуми про співпрацю з близько 50 університетами України.

З повномасштабним вторгненням росії ми постали перед новими викликами. Я, Михайло й Андрій були у Харкові. Це був час, коли ми, люди, шукали безпеки. Але й дані університетів, які зберігалися просто в будівлях на серверах, потрібно було врятувати.

На другий тиждень повномасштабної війни Харківський університет радіоелектроніки прийшов із запитом: «Денисе, чи можете ви якимось чином зберегти наші дані?». Після першого дзвінка ми почали комунікувати і з іншими вишами. Спрацювало сарафанне радіо. Пізніше опублікували в ЗМІ мій контакт з пропозицією допомоги.

Я згадую квартиру у Львові на Сихові, куди ми евакуювалися з Харкова, і як постійно надходили дзвінки із закладів освіти. Була велика кількість запитів, і ми не знали, скільки університетів ще звернеться. Не розуміли, які в нас ресурси, потужності, скільки буде волонтерів, хто буде ухвалювати рішення.

Ми знайшли в EPAM проєкт з акаунтом AWS, на який могли тимчасово перенести дані університетів. Запропонували вишам зосередитись на даних дистанційного навчання, які зберігалися в Moodle. Це освітня система, яку використовують більшість закладів в Україні. Наша ідея полягала в тому, щоб спочатку зробити бекап-копію даних Moodle, а потім продублювати її в клауді. Дані Moodle мали бути активними паралельно як на серверах, де вони були, так і в «хмарі». Якби щось трапилось з однією з копій, інша залишалася б активною. Ми знайшли тимчасове рішення проблеми. Воно і зараз залишається тимчасовим, хоча і масштабувалось.

У нас в підтримці є університети із західних регіонів, але на той момент ми з ними домовились, що даємо пріоритет зверненням з Херсона, Бердянська тощо. Був випадок, коли сисадмін з Бердянська вийшов з окупації просто з жорстким диском, і ми звідти взяли всі дані.

Михайло Хижняк: Бердянський педагогічний університет навіть зізнався, що якби не наша допомога, вони б уже закрилися, бо не змогли б працювати. А було й таке, що сисадмін вилазив на сосну в полі й передавав нам дані з телефону.

«Витратили 200–300 тисяч доларів». Про те, скільки спеціалістів залучено, за чий кошт втілили ініціативу та скільки вона заощадила

Михайло Хижняк: Спочатку в нас було два координатори всередині EPAM і 12 волонтерів на тимчасовій основі. Потім долучився я. На піку команда налічувала до 20 технічних фахівців. Зараз цим займається тільки дві людини. Інколи нам допомагали експерти, коли було щось складне, наприклад, Solutions-архітектори.

Денис Гриньов: Ми розуміли, що витрати певний час тимчасово лежатимуть на EPAM. Усі ці сервери та середовища розміщені на акаунті EPAM, але увесь час Amazon, за що їм велика вдячність, надають нам кредити. Пізніше вони дали знижку до 20%. На сьогодні університети досі не оплачують цей сервіс. Але це в наших планах як наступний крок.

Михайло Хижняк: Ті університети, які платитимуть самостійно, матимуть знижку 20%. Вона залишається актуальною, хоча ми поки що не знаємо, як технічно її застосувати.

Ми не можемо надати точних цифр щодо того, у скільки коштів обійшлася ініціатива, адже у нас їх немає. Ми знаємо витрати на «хмару» за весь цей час, але там є нюанси, пов’язані з витратами на експерименти, а також на неоптимізовану інфраструктуру на початку. Плюс наша зарплата. Загалом станом на сьогодні на це витратили 200–300 тисяч доларів. Більша частина цієї суми — це інфраструктура.

Щодо того, скільки потенційно це заощадило, то в нас немає даних про можливі втрати у разі найгіршого сценарію. Як і даних щодо того, скільки університети витрачали на це раніше. Але я можу надати розрахунки, які ми робили для ХНУРЕ. Вони дали запит на сервер з певною конфігурацією. Ми знайшли такий сервер у великого провайдера виділених серверів. Там він коштував близько 220 доларів на місяць, і це без бекапів. У AWS такий сервер з бекапами коштує 650 доларів на місяць, якщо його крутити 24/7 і повністю завантажувати. Але навантаження в університетів нерівномірне. Пік навантаження припадає на час пар, а от ввечері виш майже не використовує сервер. Плюс є канікули, вихідні.

Денис Гриньов: Після того як команда Михайла більш ефективно налаштувала сервери в AWS, вони стали коштувати дешевше на 40–50%.

Михайло Хижняк: Якщо зробити вертикальне масштабування, витрати зменшуються до 300 доларів на місяць. Вертикальне масштабування передбачає виділення більшої або меншої кількості ресурсів за розкладом. Ви можете докинути пам’яті чи додати процесор на машину. У «хмарі» це робиться у декілька кліків. У «хмарах» типу AWS оплата йде за фактичне використання.

Горизонтальне масштабування — це коли ви додаєте контейнери, машини, а коли вони вам не потрібні, вимикаєте. Вертикальне масштабування зазвичай передбачає певний незначний даунтайм. Горизонтальне масштабування може йти без даунтайму.

Ми підрахували, що з горизонтальним масштабуванням, якби невеликі сервери підіймалися за потреби, ми могли б довести цю суму до 150–200 доларів у перерахунку на місяць. Ми рахуємо за 12 місяців, бо платимо за інфраструктуру нерівномірно. На канікулах менше, ніж у період сесій. Тобто за 150 доларів можемо отримати сервер з бекапами, що дає можливість підняти сервер в іншому місці, якщо щось станеться в датацентрі. Це значно краще, ніж голий сервер, який може впасти в будь-який момент і залишити нас ні з чим.

Через рік після старту ініціативи ми дивилися на основні хмарні провайдери України для порівняння. Там сервер такої конфігурації коштує від 300 до 380 доларів на місяць. Але це без вертикального масштабування. Ми навіть не знаємо, чи можуть більшість хмарних провайдерів в Україні робити вертикальне масштабування автоматично за розкладом, а не вручну. Я думаю, що в українських провайдерів зрештою теж буде дешевше.

«Сисадміни не завжди розуміють можливості „хмари“». Про архітектуру та технічні складнощі

Михайло Хижняк: Ми використовували чотири варіанти роботи з університетами.

  1. Перший — це зберігання бекапів. Ми надавали місце, і вони там складали свої образи, дані як опцію останньої надії, але продовжували далі працювати з університетських серверів.
  2. Другий варіант — холодний резерв. Ми раз перенесли інфраструктуру, відтестували її на новому місці, але не стали на неї перемикати користувачів. Просто погасили й на вимогу університетів, коли у них були якісь зміни, підіймали, синхронізували, тестували, а потім вимикали, щоб вона не використовувала багато коштів.
  3. Третій варіант — гарячий резерв. Переносили все і тестували без перемикання, а потім автоматично синхронізували дані. Зазвичай рішення були простими, бо сисадміни університетів не люблять перейматися складними речами. На початку війни ми робили синхронізацію 1–2 рази на день для більшості вишів, але потім перейшли на більші паузи в 1–2 тижні. Саму інфраструктуру залишали увімкнутою, але на мінімальних ресурсах, оскільки навантаження на неї не було. Якби щось відбулося з локальною інфраструктурою університету, ми могли дуже швидко перемкнутися і майже без втрати даних забезпечити роботу.
  4. Четвертий варіант — повний переїзд. Бердянський педагогічний університет і ХНУРЕ переїжджали повністю. Університети з центральних регіонів частіше користувалися лише місцем під бекапи. Вони розуміли, що грошей на всіх не вистачить і намагалися зменшити нам бюджет. Це було дуже круто.

В останніх трьох варіантах ми перемикали домени на Route53 — сервіс DNS в AWS, щоб мати змогу швидко перемкнути інфраструктуру на нове місце.

Зазвичай до переїзду в «хмару» сисадміни університетів цікавилися, що саме вони можуть перенести. Про те, як це робити і які будуть обмеження після переїзду, деякі навіть не запитували. Беріть звідси й несіть швидше, бо невідомо, що буде.

Були цікаві історії, коли університети, користуючись можливістю, приносили майже все. А потім з’ясовували, який бюджет, і відмовлялися.

Денис Гриньов: Бувало, що університет хотів, наприклад, зберегти базу даних відділу кадрів. Ми орієнтувалися на обсяг. Якщо він був дуже великим, то зосереджувались тільки на дистанційному навчанні. Якщо була змога, брали й щось додаткове.

Михайло Хижняк: Після переїзду найчастіше потрібно було щось донести в «хмару». До нас зверталися із питаннями, чому щось припинило працювати. Декілька університетів запитували зворотний бекап, коли з хмарних серверів дані переїжджали на їхню локальну інфраструктуру. Це допомагало заощадити бюджет.

Інколи не було навіть системних адміністраторів. Наприклад, колись сисадмін щось налаштував, пішов, і на його місце нікого не призначили. Тоді ми працювали з бібліотекарями та викладачами.

Ще часом у сисадмінів велике навантаження, купа дрібної роботи, тому не завжди вони готові братися, якщо ми пропонуємо зробити щось краще.

Була також проблема з тим, що сисадміни не завжди розуміють можливості «хмари». Більшість системних адміністраторів в університетах мислять як люди, які звикли працювати із «залізом». Вони не завжди розуміють, що можуть щось взяти, використати, а потім цього позбутися. Натомість думають: ось ми взяли, а тепер хай стоїть і працює, навіть якщо воно не потрібно. На початку доводилось витрачати багато часу, щоб з’ясувати, що і навіщо їм потрібно.

Наприклад, ми отримували запит на сервер на 24 CPU і 128 Gb пам’яті. Ми запитуємо: «Навіщо вам таке?». Отримуємо відповідь: «А у нас стоїть такий сервер». Дивимось на нього, а він наполовину не завантажений. З’ясувалося, що їм такий сервер взагалі не потрібен.

Друга технічна проблема полягала в тому, що більшість університетів не мають трекінгу ресурсів. Вони не знають, наскільки ресурси завантажені. Немає історії, яка б дала змогу зрозуміти, що і як вони навантажують. Тому ми спочатку несли все, як є, а потім за фактичним використанням обрізали ресурси.

Окрема проблема — це застарілі операційні системи та застосунки. Наприклад, п’ять років тому щось поставили, і так воно досі стоїть. Працює — не чіпай.

Труднощі виникали із самописним програмним забезпеченням. Якийсь студент щось написав, воно запрацювало, він це віддав і все. Той студент уже випустився, і ніхто не знає, як воно працює та що робить.

Створювали проблеми й плагіни Moodle, написані під один інстанс, тобто їх неможливо масштабувати. Коли його писали, адмін вважав, що це працюватиме лише на одній машині на одному вебсервері, тому варіантів поставити його паралельно на дві машини вже немає. Коли сисадміни університетів кажуть, що вони без такого плагіну обійтися не можуть, а замінників немає або вони дуже дорогі, це ускладнює горизонтальне масштабування.

Ще університети не завжди вчасно робили оновлення, залишали відкритими порти. В EPAM є багато сканерів, які перевіряють безпеку. І коли ми щось приносили, наступного дня могла прийти купа критичних сповіщень, з якими треба було розібратися протягом тижня. Якщо в університеті ще й не було сисадміна, доводилося лізти на сервер і методом тика з’ясовувати, як воно працює.

Ми прагнули оновити все, що можна було, не поваливши університетські акаунти. Хоча іноді зробити всі оновлення було неможливо, наприклад, якщо була залежність від певного програмного забезпечення.

Важливо було виділяти ресурси під фактичне використання. Було багато замін дисків на дешевші. Нерідко ми з’ясовували, що частину інформації замість SSD можна зберігати на HDD, що дешевше. Застосовували горизонтальне і вертикальне масштабування. Інколи на канікули вручну вимикали сервери, що не були потрібні. Робили й захист від DDoS-атак, адже вони виїдали купу ресурсів.

Деяких специфічних технічних компетенцій нам бракувало, зокрема ми не мали досвіду роботи з Moodle. Як він налаштований, що у нього всередині. Що потрібно для того, щоб він працював нормально.

Інколи від нас потрібні були рішення, які можуть ухвалювати люди з дуже глибоким знанням баз даних, якого у девопсів зазвичай немає. Не завжди вдавалося знайти такого спеціаліста, тож доводилося розбиратися самим. Якби це була комерційна ініціатива, ми знайшли б DBA, який би нам все зробив, але йшлося про волонтерську допомогу.

Ми зверталися до AWS, щоб вони нам пояснили, як працюють промокоди та Cost Explorer, тобто як вони рахують кошти з усіма цими промокодами. З технічним питанням ми звертались до AWS один раз, коли розбирались з горизонтальним масштабуванням Moodle на ХНУРЕ. Solutions-архітектор з боку AWS швидше, ніж ми, дійшов висновку, що нам бракує горизонтального масштабування для одного з плагінів і треба міняти плагін. Допоміг досвід.

Андрій Костромицький, EPAM Chief Talent Development Specialist & AWS Ambassador

«Якщо когось цікавлять швидкі гроші, то йти треба точно не в DevOps». Про професію системного інженера й те, яких фахівців бракує

Андрій Костромицький: Systems Engineer — це професія, де необхідний рівень можна отримати тільки завдяки тривалому практичному досвіду. Є вдосталь тих, хто вважає, що вони достатньо знають, але насправді мають початковий, базовий рівень. Можна підняти сервер у «хмарі» і вважати себе хмарним спеціалістом, але цього вже недостатньо. Технології розвиваються, складність зростає, і вимоги до фахівців на всіх рівнях від Junior до Senior постійно підвищуються.

Звичайно, є менше фахівців, які можуть налаштувати ШІ в «хмарі», ніж тих, хто робить звичайні речі. Ще один популярний напрям — Data. Обробка та аналіз даних, Big Data. Таких спеціалістів теж мало. Але й попит на них значно менший, ніж, скажімо, на класичного Cloud & DevOps спеціаліста.

Щодо конкретних клаудів, то у мене є враження, що навчальні матеріали від Azure почали впроваджувати в навчальні програми українських університетів раніше, а останніми роками активно додають AWS.

Михайло Хижняк: Але це нічого не говорить про якість спеціалістів. Раніше можна було орієнтуватись на сертифікації, а нині не всі за них беруться та не всі їх складають.

Андрій Костромицький: До речі, в межах однієї AWS можна виділити різні напрями, а саме спеціалісти з безпеки, архітектори рішень, розробники та ще багато інших.

DevOps — це не просто набір інструментів та знань, це культура. Хоча без інструментів ніяк і потрібно опанувати їх. Але варто розуміти також мережі, програмування. Буває, що доводиться вивчити нову мову за два тижні. На велику команду може бути 1–2 девопси, тож на девопсі лежить велика відповідальність. Він має вміти подбати про процес розробки та делівері на продакшені, максимально все автоматизувати. Потім потрібно оптимізувати, зменшувати витрати, підвищувати надійність. Це широке коло знань і технологій, а також вміння обережно комунікувати складні питання, щоб ніхто не образився.

Михайло Хижняк: Один з найскладніших моментів для інженера — це зрозуміти, що гроші є ще одним виміром ефективності роботи. Бо більшість не розуміє, чому вони взагалі мають турбуватись про витрати. Це можна порівняти з подачею води за абонентською платою або за лічильником. Якщо інженери не рахують гроші, можна спіймати великі суми. Раніше гроші були для керівника, а зараз будь-який інженер може додати тисячу доларів в момент. Інколи складно пояснити людям, що це тепер також міра їхньої ефективності.

Андрій Костромицький: Крім грошей, є ще швидкість виходу на ринок, складність підтримки, підхід до моніторингу. Наприклад, можна налаштувати моніторинг, який показуватиме все, але скільки на це буде витрачено часу та коштів? З багатьох чинників треба вміти вибрати оптимальне рішення.

Михайло Хижняк: Так, суть не в тому, щоб економити кошти, а в тому, щоб обрати оптимальний варіант з погляду користі та витрат. Наприклад, хай буде на 10 доларів дорожче, але воно працюватиме надійно.

Андрій Костромицький: Новачкам не варто розраховувати, що за кілька місяців вони опанують цей напрям з нуля та будуть готові до роботи в продакшені. Якщо когось цікавлять швидкі гроші, то йти треба точно не в DevOps.

Якщо говорити про те, що саме потрібно вивчати, то, по-перше, це мережі, бо це основа. Якщо не буде розуміння, як працюють мережеві сервіси та глобальна мережа, буде складно рухатись до більш складних питань.

По-друге, сервери та Linux, операційні системи типу Unix. Ще краще, якщо людина знає, як працюють Windows-сервери. Без розуміння, як працює всередині операційна система, буде складно.

По-третє, скриптинг. Щоб автоматизувати деякі процеси, потрібно писати скрипти, починаючи з Bash, далі Python, потім за потреби інші мови: Groovy, Ruby.

По-четверте, контейнеризація. Контейнери широко використовуються, тому треба знати, як працює Docker. Подивитися Kubernetes.

По-п’яте, CI/CD. Опанувати хоча б безплатний Jenkins. Додати до CI/CD тестування. Ознайомитись з інструментами, які використовують автоматизатори. Всередині їх налаштує автоматизатор, але DevOps повинен це інтегрувати в один робочий пайплайн.

Звісно, Git. Це для будь-кого в IT необхідно, як для офісного працівника Word.

І нарешті клауд, куди ми будемо все це деплоїти наприкінці делівері. Топові клауди — це AWS, Azure, Google Cloud. Можна почати з одного. В клауді треба знати сервери, контейнери, безсерверні рішення, сховища, бази даних, мережеві сервіси, інструменти, моніторинг, логування, різні архітектурні патерни та найкращі практики, економіку клауду та багато іншого.

«Закупівлі через тендери несумісні з „хмарами“». Про проблеми та плани

Денис Гриньов: Проєкт зі збереження даних університетів у «хмарі» триває. Нині найбільшою перешкодою для зростання є правові аспекти. Ми стикнулися з тим, що університети не можуть укласти прямий договір з AWS, тому що є обмеження оплати в еквіваленті у валюті.

Михайло Хижняк: Проблема в тому, що закупівлі через тендери несумісні з «хмарами». «Хмари» — це завжди витрати за фактом. Потрібно — використовуєш, не потрібно — не використовуєш. А тендер — це зобов’язання використати фактичну суму. Виходить так, що університети не можуть укласти договір з AWS, Microsoft або іншим хмарним провайдером, бо не знають, скільки грошей на це піде. Якщо буде потрібно сплатити більше, то до них прийде контрольно-ревізійна служба і запитає, що вони собі думають. Якщо витратять менше, буде те саме. Тому виші не дуже хочуть під це підписуватись.

Друга проблема в тому, що AWS, Microsoft і Google не беруть участі в тендерах безпосередньо. Потрібен посередник, а це знову ж таки корупційний ризик. Ми знайшли некомерційного посередника, але все одно університети бояться, бо для них це може бути потенційною проблемою. А якщо немає договору, який пройшов через тендер, то не можна дати доручення казначейству перевести гривні з рахунку університету в долари, щоб розрахуватись. При цьому доларовий облік у вишах — це окрема бухгалтерія і купа проблем зі звітами.

Хоча університетам було б вигідніше працювати з «хмарою» напряму, ніж брати сервери як «залізо» чи працювати з українськими хмарними провайдерами. Я сподіваюся, що одного дня українські провайдери зможуть конкурувати з AWS, але поки що вони не дотягують до його рівня. Сервісів у AWS більше, а вартість нижча.

В Європі 2019 року створили консорціум OCRE (Open Clouds for Research Environments). Університети об’єдналися і зробили один тендер на всі «хмари» для всіх університетів, який виграв OCRE. Там все прозоро в плані витрат, і більшість закладів можуть користуватися «хмарою». В них це іде як витрати на електроенергію, тобто якщо сьогодні потрібно більше, вони більше платять. 2022 року OCRE закінчився, з 2023-го влився у GÉANT.

В Україні ж ухвалили закон про хмарні ресурси, зробивши ще гірше для університетів. Тепер університет повинен закуповувати хмарні ресурси не просто через тендер, а ще й у постачальника з реєстру, якого ще немає, і ніхто не знає, хто буде в цьому реєстрі.

Денис Гриньов: Якщо говорити про наші плани, то, по-перше, продовжуємо технічно, по-друге, шукаємо рішення технічних блокерів, по-третє, продовжуємо навчати студентів. Близько 180 тисяч студентів навчаються в університетах, дані яких були перенесені в межах ініціативи. Це близько 20% від усіх студентів в Україні.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному4
LinkedIn



23 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую працівникам EPAM.
Але це позор системи. Маленькі зарплатні, велика текучка, непродуманність(відустуність взагалі такої) архітектури та відсутність централізованноі політики і ось маємо результат бардаку

Зберігання критичних даних у вигляді бекапів у хмарі ідея хороша, і синхронізувати їх один раз в тиждень. А ось крутити в хмарі надто дорого. Дешевше буде крутити в себе на локальних ресурсах. Якщо станеться щось критичне то дешевше буде купити б/у сервер і налагодити на ньому роботу.
Як мені здається, треба будувати власні клауди в університетах на базі openstack об’єднувати їх в мультихмару(кластер з університетських серверів) і тоді відключення одного чи декількох серверів не буде проблемою.

Дешевше буде крутити в себе на локальних ресурсах.
Якщо станеться щось критичне то дешевше буде купити б/у сервер і налагодити на ньому роботу.Як мені здається, треба будувати власні клауди в університетах на базі openstack об’єднувати їх в мультихмару(кластер з університетських серверів) і тоді відключення одного чи декількох серверів не буде проблемою.

1) Ви рахували ціну чи це чуйка? Ви точно не забули ціну розробки, ціну саппорту (адміни ж не безкоштовно будуть те все підтримувати)? Амортизацію хардвару, можливість вчасної закупки того хардвару (треба через тендери і з доставкою в Україну)?
Треба розуміти, що це не вийде звалити на студентів та викладачів, це має бути нормальний ІТ проект з командою, що над ним працює не лише по вихідним.
А ще в КПІ наприклад цікаво реалізований ФінОпс, підозрюю, що в інших універах теж.

2) Власне доступність та ризики. Ця тема почалась з початком повномасштабки, відключення прильоти. Що робити харківським вишам, якщо у них все залізо в Харкові? А якщо виш київський, але в датацентр прилетіло?

В майбутньому, після війни, якщо в універах накопичаться необхідні компетенції, власні датацентри можливо і будуть гарним рішенням. Зараз хмари закривають більше проблем аніж створюють. Фактично єдиний їх недолік — неоптимізованість універських систем до роботи в клауді, але вирішення цієї проблеми значно менш ризиковане ніж спроба побудувати надійну локальну інфраструктуру.

Звичайно нічого безкоштовного не буває, я це бачу як одни з проектів який буде створено за допомоги грандової підтримки МОН або іноземних донорів. Розробити на базі двох університетів написати документацію, і якщо хтось хоче то вже є люди які допоможуть і розкажуть, дадуть документацію. На це піде багато часу, але це непогана інивистиція, вона дозволить ефективніше використовувати фізичні ресурси в майбутньому.

Теоретично на нескінченному проміжку часу можливо все.
На практиці:

я це бачу як одни з проектів який буде створено за допомоги грандової підтримки МОН або іноземних донорів

Вперед, спробуйте вибити це фінансування. МОН якщо дасть, то мало і з великою ймовірністю через тендери, які виграють контори, що вміють вигравати тендери (а не робити результат) :)

Розробити на базі двох університетів написати документацію

Ще зар: знайдіть експертизу в універах. Проблема в тому, що якщо людина шарить в побидові клаудів, то у неї вже є робота де вона заробляє, а універ — то скоріше хоббі і пріоритети будуть відповідні.

По факту, те що ви кажете можливо лише при побудові знизу. Тобто є команда, що робить такі реферальні проекти і йде просувати це в МОН та впроваджувати в універи (які будуть цьому пручатись). Спочатку зробіть, а потім отримаєте фінансування.

І поки ви акуратно проігнорували проблему прильотів та відключень. Нагадую, що у нас вибито купу генеруючих спроможностей і ця зима буде дуже весела.

Публічні хмари роблять великі знижки для державних проектів в Україні, іноді аж до безкоштовного користування на час воєнного стану + 6 місяців, та й після знижки явно будуть (якщо це після буде взагалі). Тому локально дешевше не буде.

Ми намагалися знайти якісь знижки але вони є тільки в розмовах, насправді отримати їх для державної структури практично неможливо. Можливо у вас є якісь деталі, буду дуже вдячний за більш детальну інформацію що за провайдер надає та які умови...

Ми намагалися знайти якісь знижки але вони є тільки в розмовах, насправді отримати їх для державної структури практично неможливо.

КПІ наче якось домовився на перший рік війни, але навіть це по факту через «особисті зв’язки».
Звернення від нді, яке явно не буде великим споживачем, були послані нах.

Просто для інформованості:
А від імені кого ви звертались? Теоретично якраз цим мало б займатись мінцифри та мон.

Ну і epam партнер aws, тому нічого іншого окрім позитивних текстів у бік хмар я б і не чекав.

Ну і epam партнер aws, тому нічого іншого окрім позитивних текстів у бік хмар я б і не чекав.

Можно то же самое написать в сторону гугля, будет аналогично

Хмари були вигідні до 2022, потім різко все хмарне почало рости в ціні. AWS вигідний бізнесу, коли його софт в хмарі дає х2 витрат на хмару, а краще х3, тому той же Монобанк живе в aws і витримує DDoSи. Але що стосується бекапів та хостингу софту для універів — це дуже спірно, бо цей софт не приносить дохід, а тільки витрати.

Вангую, що в коменти прийде ще не одна людина, котра вам напише ± те ж саме.

Починаючи з 2023 дуже багато хто з великих бізнесів перейшли чи переходять на власний парк серверів, орендованих чи придбаних це вже інша історія, але факт є факт. У DHH в твіторі цілі треди на цю тему, і я згоден з ним, що цінність хмар з уст маркетологів і продажників явно переоцінена. Знижки дають і кредити щоб затягнути в хмари, а потім було дорожче бізнесу злізти з них.

Дело в том, что Azure и AWS они сертифицированы украинским правительством, еще при Порохе, и туда можно данные заливать, а вот другие клауды нет. Не забывайте что университеты это все равно ДЕРЖУСТАНОВЫ, и там все очень жестко.

Я десь читав ще у 2021, що вже тоді можна було сайти хостити в хмарах не тільки Azure/AWS. Та і взагалі, після взлому Київстару довіри йому і Azure ніякої. На мою скромну думку, якщо руки з правильного місця ростуть, то vps у hetzner може бути дуже витривалою без оцих всих aws, бо як відомо більшість сайтів держустанови написані «лівою ногою» розробників та майже ніхто з персоналу не тримає ці сайти в актуальному стані з заплатками на cms/etc., ба більше — такі сайти ломаються через людей і їх доступ в 95% мені відомих випадків.

PS: Сертифікація — як на мене це більше до теми «треба аби було», але не є необхідністю для тієї ж Joomla+apache+mysql.

Я десь читав ще у 2021, що вже тоді можна було сайти хостити в хмарах не тільки Azure/AWS

Ага на серваке под закрытой дверью, с дядей который их будет охранять))

Чекайте, тобто

більшість сайтів держустанови написані «лівою ногою» розробників

, але саме у нашого інженера

руки з правильного місця ростуть

?

Починаючи з 2023 дуже багато хто з великих бізнесів перейшли чи переходять на власний парк серверів,

Ну, я вижу чуть наоборот, но это, видимо, случайность и исключение из правил :)

А серйозно, накидайте прикладів прикладів контор (в ідеалі з описом їх кейсів, але можна і просто назви), що перешли з клаудів назад в он-прем.
Я зміг згадити хіба Дропбокс. Але точно були ще якість.

В контексті теми про універи буде цікаво подумати як ці кейси накладаються на кейси універів.

І ось ще з графіками та цифрами результат:
world.hey.com/...​g-cloud-exit-faq-20274010

Стаття в цілому цікава, але вона не має багато «прикладів на яких можна було б навчитись», там в основному відповіді на стандартний маркетинг клаудів, і відповіді, що зводяться до «візьміть кваліфікованих спеціалістів і зробіть нормально» (на жаль в нашому світі цей підхід дуже важко реалізувати :) )

Між іншим історія про чорну п’ятницю певною мірою мапиться на патерни використання універів — всім на все пох (тобто використання інфраструктури біля 0), але в певні дати (дадлийни здач, вибору предметів і тд) йде значно вище навантаження.

Каста навпаки, перейшла з он-према на AWS у 22 році.

До 22 на своєму залізі була, але не переїжджала з клауду. :) Ну і в 22 році тільки через обстріли інфри це сталося, це не про гроші була історія.

Підписатись на коментарі