Як банк модернізував застарілі ІТ-системи та мігрував у «хмару»

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

Фінансовий сектор — колись лідер у використанні інформаційних технологій — ще до COVID-19 почав сповільнюватися у розвитку, хіба за незначними винятками. А коли почалася пандемія, ситуація для декого виявилася критичною. З’ясувалося, що навіть IT-фахівці банків, не кажучи про інших працівників цих установ, не можуть працювати віддалено. Питання про переведення організацій на дистанційний формат роботи доводилося вирішувати в авральному режимі. У багатьох випадках процеси в банках були орієнтовані на обслуговування клієнтів у відділеннях, а не дистанційно. І це при тому, що ІТ-технології мають достатньо рішень, щоб «бути онлайн».

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

Ця стаття буде цікавою працівникам IT-підрозділів банків, страхових і роздрібних компаній, які думають про модернізацію своїх IT-систем та їхню міграцію у хмару. Оскільки не всі дані можна мігрувати, то в статті основний акцент — на побудові гібридної хмари (приватної та публічної) за технологіями компанії IBM. Описані інструменти створено на open source продуктах і їх можна використовувати як локально, так і в інших публічних і приватних хмарах.

Чому трансформація — це важливо

За світовою статистикою, 3–4 роки тому тільки 10% компаній використовували хмари, нині ж ця цифра доходить до 90%. Водночас тільки 20% обчислювальних ресурсів перенесені у хмару.

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

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

Спілкуючись з колегами, котрі представляють українські банки та великі роздрібні компанії, я виділив основні причини, що гальмують процес трансформації. Тому вирішив поділитися надбаними знаннями з модернізації ландшафту IT-системи одного банку.

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

Соціально-бізнесові передумови

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

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

Тож нетехнічні передумови, що вимагають трансформації IT-систем, можна викласти у такому переліку:

  • клієнти не бажають відвідувати відділення банків;
  • нові бізнеси все частіше ґрунтуються на цифрових технологіях;
  • бізнес прагне бути гнучким і швидко адаптуватися під вимоги часу;
  • соціальні мережі увійшли в наше життя, і компанії намагаються знайти нові канали для просування своїх послуг клієнтам;
  • COVID-19 — новий фактор, який змушує пришвидшити трансформацію.

Перелік спеціально не впорядкований, оскільки кожна компанія і пов’язана з нею IT-система має свої цілі та свою історію розвитку. Залежно від цього організації матимуть свій порядок.

Технічні передумови

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

В основі лежить невідповідність IT-інфраструктури сучасним бізнес-викликам. Вже неодноразово йшлося про «тісноту» та перевантаженість сучасних ЦОД. Для класичного банку з історією характерним є ландшафт, в основі якого є монолітна або модульна автоматизована банківська система (АБС) від великих компаній- вендорів. А інколи й не одна.

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

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

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

Це призводить до проблем з продуктивністю, складнощів тестування, високої вартості підтримки та довгого терміну внесення змін. Варто згадати й CRM-системи, які існують в банках. Зазвичай це ті самі моноліти.

Усе це може стати серйозним бар’єром на шляху до цифрової трансформації.

У пошуках рішення

Рішення лежить на поверхні, але його не так просто реалізувати. Якщо не стоїть питання про перехід на кардинально нову систему чи архітектуру, то потрібно позбавити АБС непрофільних функцій і даних. А потім, коли буде можливість і потреба, рознести на слабопов’язані модулі та модернізувати інтеграційний інструментарій. На противагу важким локальним CRM-системам уже існує багато хмарних систем або систем, що розгортаються у власній інфраструктурі й потім легко можуть видалятися з IT-ландшафту.

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

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

На противагу цьому нині широко використовують мікросервісний підхід. Він передбачає велику кількість слабопов’язаних програм, в кожній із яких реалізовані свої бізнес-функції. Програми запускаються у власній інфраструктурі, взаємодіють через API. Кожна з них може бути змінена, протестована, розгорнута або масштабована з допомогою CI/CD та спеціалізованого середовища з управління мікросервісами.

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

Неякісні дані є одним з основних гальмівних факторів у впровадженні технології smart data. Це коли спершу отримуємо дані з трансакційних, облікових систем та DWH, а потім застосовуємо інструменти машинного навчання. Таким чином отримуємо таку собі павутину взаємопов’язаних факторів і суперечностей, які потрібно якось проаналізувати та вибрати дані.

Складність і багатовекторність вибору

IT стоїть перед складним вибором:

  • Інвестувати у старе, щоб не завалити бізнес?
  • Здійснити революцію та купити «коробку», яка «розв’яже усі проблеми»? Але такої коробки не існує. Знов-таки це вимагатиме часу, бюджету, спеціалістів, яких на ринку обмаль або вони дорого коштують...
  • Мобілізуватися й переписати програмний код повністю під нову платформу?

Чи не краще піти шляхом модернізації? Але тут теж можуть виникнути різні проблеми:

  • відсутність технічних навичок у працівників банку;
  • питання інформаційної безпеки;
  • застаріла інфраструктура;
  • періодичне затухання ініціатив трансформації при досягненні часткового успіху.

З одного боку, ради директорів тиснуть на IT-підрозділи щодо цифрової трансформації. А з іншого — численні проблеми заважають IT-підрозділам втілити її.

Приклад аналізу традиційного шляху модернізації IT-ландшафту компанії, а також питання, що виникають за результатами аналізу

Світові тренди говорять уже не просто про модернізацію шляхом міграції у хмару. Нині широко використовуються гібридні хмари, і деякі корпорації присутні одночасно в кількох хмарах, а також мають свої приватні. Тобто традиційний ландшафт інформаційних систем розбивається на кілька хмарних компонентів, а їхні складові можуть мігрувати з одного компонента до іншого, коли є така потреба. Адже всі застосунки відповідають принципам Cloud-native applications.

Часто розпочатий процес міграції не збігається з бізнес-цілями компанії. В такому разі він приречений на провал. Що робити? IT-директор повинен надати чітку стратегію трансформації. Її потрібно скоригувати так, щоб вона збігалася з бізнес-цілями компанії. І вже з готовим баченням спілкуватися із внутрішнім замовником. Основна мета — ідентифікувати найбільш зацікавлених клієнтів у цифровій трансформації та зрозуміти, які функції їм потрібні уже сьогодні.

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

Щоразу я переконуюся, що у співпраці з бізнес-замовниками краще віддавати перевагу сучасним підходам, які мотивують команди думати нестандартно та генерувати ідеї. Наша команда використовує комбінацію методів Design Thinking та IBM Garage for Cloud.

Додам, що важливо не глобалізувати задачі, особливо на початкових етапах, коли в командах замовників і виконавців поки немає достатнього досвіду, спрацьованості та впевненості у власних можливостях. І потрібно дотримуватися моделі MVP (моделі продукту мінімальної вартості).

Модернізація на прикладах

У цьому розділі опишу кроки модернізації IT-інфраструктури інформаційних систем банку.

Вибір стратегії модернізації

На малюнку нижче показано перший крок модернізації — «Побудова фундаменту». Після спілкування із замовником (банком) обрали такий підхід, коли IT-система послідовно, крок за кроком отримувала нові сучасні функції, не ламаючи наявних. І поступово застарілі функції відмирали, а нові стали здобувати своїх прихильників, тому що вже відповідали сучасним викликам і були реалізовані на сучасному технологічному рівні.

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

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

  • Приватна хмара побудована на базі Enterprise Kubernetes — платформа OpenShift.
  • Публічна хмара побудована на базі сервісів IBM Public Cloud.

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

А з IBM Cloud Paks для OpenShift ви можете швидко розширити його функціональність. Наприклад, з IBM Cloud Pak for Multicloud Management навіть у локальному ЦОД є можливість резервувати інфраструктуру, починаючи з підйому VM.

А з IBM Cloud Pak for Applications ви отримуєте вже готову інфраструктуру для розробки нових і модернізації наявних застосунків, DevOps-інструменти та моніторинг.

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

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

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

Другим кроком є «Широка трансформація», коли ми змінюємо бекенд-застосунки та розширюємо присутність клієнта в соціальних мережах. Більше починаємо використовувати сервіси IBM Public Cloud.

На малюнку нижче показано, як «сателіт 1» переробляється на мікросервісну архітектуру. Нові програми розробляються тільки на базі OpenShift.

Замовник є активним у соцмережах. Також обговорюється присутність банку у Viber, Telegram та інших платформах. Спектр банківських сервісів, з якими Watson Assistant інтегрований, почав швидко збільшуватися. Виникла потреби аналізу логів його роботи, щоб зрозуміти якість роботи чат-бота та аналізувати тренди. Тут починаємо застосовувати Watson Studio (Big Data з коробки) в комбінації з Jupyter Notebook або RStudio та IBM Cloud Object Storage.

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

Ви можете виставити ваш фінансовий чи інформаційний API через продукт API Gateway для публічного використання та отримувати з цього прибуток. Термін API economy є трендовим у світі.

IBM Cloud Functions — продукт з дуже широкими можливостями: від побудови мобільного back-end до виконання рутинних операцій за розкладом, як-от:

  • трансформація логів роботи чат-бота у щось більш прийнятне та їхній запис у базу даних;
  • отримання курсу НБУ або оновлення довідників НБУ тощо.

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

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

Крок «Нова реальність» ще в майбутньому, але основна його мета — максимально трансформувати програмну архітектуру так, щоб у локальному ЦОД залишити мінімум, в ідеалі тільки АБС, та звільнити її від надлишкових функцій. Всі інші сателіти потрібно конвертувати до мікросервісної архітектури.

А паралельно, мабуть, варто задуматися щодо присутності в кількох хмарах.

Побудова DevOps-процесів

Перш ніж почати активну розробку, потрібно побудувати процеси розробки з підтримкою DevOps. На малюнку показані:

  • Git-сумісний репозиторій програмного коду;
  • Docker — сумісний репозиторій (зовнішній відносно OpenShift);
  • SonarQube, який використовують для контролю якості коду, він відшукує закладки у вигляді паролів та API-Keys;
  • Jenkins уже присутній в OpenShift, тому його використовуємо як основний CI/CD-інструмент;
  • Storage, підключений до OpenShift.

Але з урахуванням того, що інфраструктура типова для Cloud Native app, побудовано єдиний процес для всіх вендорів, яких запрошуватиме банк. Тобто тепер такі питання, як «нам для розгортання потрібно три сервери Red Hat для кожного середовища», вже не мають виникати. Якщо прикладна система не відповідає сучасним вимогам, то, можливо, немає сенсу на неї витрачатися (звісно, окрім випадків, пов’язаних із регуляторними політиками, де вибору немає).

Приклад окремих рішень

На малюнку нижче зображена розгорнута гібридна архітектура чат-бота, інтегрованого з Telegram. З публічної мережі Telegram користувач потрапляє в мережу IBM Public Cloud і на інтеграційне рішення, створене на базі відомої бібліотеки Node-Red для інтеграції з Watson Assistant.

У процесі спілкування Watson Assistant статичну інформацію вибирає з IBM Cloud Object Storage або пропонує клієнту перейти на відповідну сторінку корпоративного сайту. Звернення до сервісів АБС відбувається через IBM Cloud Functions. Для захисту каналу між IBM Public Cloud і точкою виклику сервісів використовують IBM Secure Gateway. За ним стоїть API Gateway, де прописані правила маршрутизації запитів до АБС або сервісів інших провайдерів.

Для внутрішнього користувача побудований Web UI чат-бот на Vue.js та Node.js як back-end. Node.js використовує Watson SDK для спілкування з Watson Assistant, а Web UI більше сфокусований на презентації даних.

Усі компоненти, що містяться в банку, задеплоєні в OpenShift.

Label 1. Публічна мережа, через яку клієнти під’єднуються до чат-бота через соціальну мережу Telegram або мобільний застосунок

Label 2. Мережа IBM Public Cloud. В центрі розташовані Watson Assistant та інтеграційні компоненти

Label 3. Мережа між IBM Public Cloud і локальною мережею клієнта. Захист трафіку здійснюється за допомогою IBM Secure Gateway

Label 4. Приватна мережа клієнта on-premises

Label 5. Інтеграційна шина IBM Integration Bus

Label 6. Компоненти банківської системи та сервіси інших провайдерів

Label 7. Back-end та front-end корпоративного чат-бота, що звертається до Watson Assistant у Public Cloud

Замість висновку

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

👍НравитсяПонравилось5
В избранноеВ избранном5
Подписаться на тему «миграция»
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Не совсем понял где именно миграция в облако произошла, если верно уловил, вы взяли пару готовых фич(вроде чат бота) и проинтегрировали их с он-премом через vpn. Миграция это все-таки если бы вы взяли часть функционала той же АБС задиплоили в Клауде и засансетили заменённый функционал в он-прем с миграцией данных в облако. Где микросервисы при таком подходе тоже не ясно — ведь у вас похоже архитектурно это тот же ЕСБ интегрирующий по rpc пару достаточно независимых feature based компонент/систем — похоже на достаточно традиционную soa архитектуру,что делалась в банке и 15 лет назад когда о микросервисах ещё никто не слышал?

Если бы АБС была собственной разработки, то так бы и делали. Но заказчик решил не трогать АБС.
Лет за 10 АБС внешнего вендора обросла кучей сателлитов, которые перетянули на себя большую часть фронта и бека. Большая часть функций фронта уже исторически устарела, так как ориентирована на обслуживание клиентов в отделениях, да еще под специфические бизнес-процессы, которые сегодня нужно менять. На сегодняшний день большая часть этой функциональности уже устарела. Поэтому, функциональность приложений пересматривались и переписывалась под новые технологии.
А начали с фичей, потому что так хотел заказчик. Заказчик сам определяет, что ему важнее. Да, начали с простого. И что тут плохого. Заказчик получил функциональность, попробовал, понравилось — начал развивать.
А по поводу SOA архитектуры 15 лет назад в банках не буду спорить. Мне как то все больше клиент-сервер попадались.

не знал, что регуляторы разрешили не тратиться на «землю». интересно о «сливе» с облаков IBM какую сумму согласилось отстегивать?
Ведь не зря банковский сектор еще на «земле»

Уточните, пожалуйста, когда и есть ли ссылка на «уже нет»?
Очень нужно.
И есть ли практика защиты «на ковре» регулятора и других органов по таким решениям? (имеется в виду как личная практика, так и ссылки)
Спасибо
Просьба не ссылаться на то, что в мире давно уже с ИИ живет, и что это логично.

Есть. finance.liga.net/...​a-finsektora-do-2025-goda

И практика есть. Ссылок нет и не будет, по вполне понятным причинам.

надеюсь, Вы понимаете разницу между «утвердили стратегию», «Стратегия предусматривает», «регуляторы планируют» (!!!), «планируют активизировать» от «Приняли постановление №»
и... уж ... да... практика есть, когда приходит регулятор и задает вполне адекватные вопросы в понимании между «планируют» и «принято/реализовано»
и... нет... не понятны причины почему нет ссылок, если «Уже нет»

Ссылки, Законы и Поставления или есть или нет. Все остальное — похоже на то, как юрист рассказывает программисту как код писать.
п.с. Регулятор только недавно разрешил идентификацию по виде с очень большим скрипом. Ну и не забываем, что есть еще госспецсвязь. (или участие госспецсвязи тоже вопросы?)

Лично я своими руками делал инфраструктуру в облаке для банка, который прошел PCI DSS, получил гарантию МПС Visa и лицензию НБУ.
Нужна консультация — обращайтесь. Публично вы ничего не получите кроме общих советов.

В смысле Банк все делал на свой страх и риск, без Законов и Постановлений (знаем парочку таких Банков).
иначе не понятны общие фразы без ссылок на документы, где «НБУ Разрешил»
Консультировать в чем? Как построить, — имеем достаточно компетенций и ресурсов.
Предполагалось, что если есть громкое заявление, что Банк мигрировал в Банк, то хотелось бы узнать не технические моменты, а как «НБУ разрешил», если нет официальных бумаг.

Предполагал, что такие как Альфа-Банк, ПУМБ уже давно (лет 5 уже) работают с облаками со своими приложениями, которые никакого отношения не имеют к «Банк модернизировал и мигрировал в облака»

Спасибо за развернутый ответ.

Все по закону. Изучайте документацию НБУ и найдете сами. Или оплачивайте услугу юристу и он найдет за вас. Или берите консалтинг у того, кто нашел и сделал — и получите готовое решение.
Выбор за вами.

В світі банківський сектор давно вже не «на землі».

а еще в мире суды работают, и есть богатые страны на песке (без колоссальных ресурсов, которые есть в Украине)...
и в мире уже давно не ликвидируют банковскую систему ВСЕЙ страны, чтоб набить пару карманов. и представьте себе — в мире суды работают, нормально функционируют все государственные органы, которые что-то делают требуя оплату, а не требуют оплату чтоб ничего не делать...
и так можно продолжать до бесконечности с людьми оторванными от реальности Украины и сравнивающие комара со слоном.

А что за такие ресурсы у нас есть?

Чи була міграція персональних даних в хмару? Які були з цим проблеми в зв’язку з укр закондавством і як це вирішувалося?

тобто ніякої анонімізації не було в скопі?

Какая еще анонимизация в банке? С криптой перепутали? :)

Потрібна може бути згідно GDPR, PCI DSS, Закону про Персональні дани і взагалі Служби Безпеки банків часто забороняють зберігати персональні користувачів на сторонніх серверах.

1. GDPR не работает в Украине.
2. Облачные провайдеры являются вендорами сервисов под эти стандарты безопасности
Например, тот-же IBM имеет: www.ibm.com/cloud/compliance

Если что, то я достаточно давно делал инфраструктуру на украинский диджитал банк, который успешно прошел PCI-DSS. Так что знаю, о чем говорю.
Просто я делал на AWS, а с IBM у меня очень небольшой опыт, так что очень интересно что там такое есть для безопасности.

мы тоже прошли PCI-DSS 2 года назад и только благодаря полной анонимизации персданных. Пользовались AWS. Так что тоже имеем богатый опыт, в том числе с громким высказыванием «НБУ разрешил»

Молодцы! Теперь осталось взять Level 1 и пройти QSA.

Нам это не нужно. Вы не внимательно читаете, что написано.
на сколько я понимаю, то мы молодцы уже как очень давно по облачным решениям, в отличие от специалистов, которые вот только сейчас к этому приходят и до конца не понимают как все устроено в Украине.

Да так же как и везде — есть нормы, которым надо соответствовать и процедуры, которые проверяют это, и аудиторы выполняющие проверку.
Если у вас все соответствует — то тогда ОК.

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

Щодо серйозного підходу до безпеки:

AWS вже пропонує Nitro Enclaves для безпечних обчислень і експериментує з гібридом контейнерів і віртуальних машин (Firecrackers).

Хотілося бы почути з перших уст, чи є щось аналогічне у IBM, або хоча б може у ближніх планах?

Ну, якщо копнути трошки в історію, то можна знайти, что AWS, Google, IBM, OpenStack майже одночасно стартували схожі проекти:
— AWS Firecracker;
— IBM Nabla;
— OpenStack Kata Containers
— Google: gVisor

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

Паша, отличная статья! С дебютом на DOU!

В статье, на мой взгляд, очень бегло освещен процесс, как монолитный динозавр превращается в микросервисного дракона. Сначала неизбежно приходится декомпозировать монолит. И как показывает практика, такой модульный динозавр уже даёт внушительный прирост по перформансу и возможностям расширения. Только так, только эволюционный подход. Революционный, когда рядом с существующей монолитной системой начинаем параллельно разворачивать микросервисную — обречён на провал и на то, что новая система станет пятой ногой для динозавра, то есть частью последнего...

Спасибо, Вадим. Как раз и предполагался эволюционный подход

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

Эта статья не предполагает рассмотрения вопросов безопасности, а одним предложением на этот вопрос не ответишь. Если включить сюда безопасность — то еще 3 таких статьи можно написать. Вопрос запомнил, будет возможность, постараюсь осветить.

Увы, но без этого ваша статья как борщ без буряка — постные щи (ничего личного).

Ну так Рождественский пост же сейчас :))

Надеемся, после праздников автор нас порадует спец. материалом.

Вообще 100%, финтех предполагает мысли о безопасности на уровне паранойи на всех этапах, и особенно — на этапе построения архитектуры...

Дякую, гарна стаття!

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