Модернізація хмарних банківських архітектур (Стів Морган)

Перевидано Платоном

читають: 0

Modernising Cloud Based Banking Architectures (Steve Morgan) PlatoBlockchain Data Intelligence. Vertical Search. Ai.

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

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

Щоб досягти ефективної цифрової трансформації, ось що вам слід розглянути щодо модернізації хмарних банківських архітектур.

Мікросервісні архітектури

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

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

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

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

Оркестровка водіння

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

Сьогодні стандарт Kubernetes є провідною системою оркестровки, а в поєднанні з діаграмами Helm — колекцією файлів, що описують пов’язаний набір ресурсів Kubernetes — дозволяє ІТ-менеджерам фінансових служб розробляти компоненти програми як послуги (AaaS) і самостійно керувати цими програмами. . На відміну від сервісно-орієнтованих архітектур, архітектура AaaS дозволяє кожній службі використовувати власні служби додатків і шлюз API. Це забезпечує незалежність і меншу взаємозалежність від інших обчислювальних ресурсів.

Підхід на основі єдиної моделі

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

Розробка додатків «на основі моделі» або «з низьким кодом» забезпечує виняткову продуктивність і співпрацю між бізнес-командами та технологічними командами. Створено на базі локальної або хмарної сервісної платформи, незалежно від того, чи вважається функція програми частиною інтелектуальної автоматизації (також відомої як автоматизація цифрових процесів або DPA), управління бізнес-процесами (BPM), збору та керування даними чи інші функції, моделі можна змішувати та налаштовувати відповідно до потреб підприємства. Це забезпечує однакову поведінку програм незалежно від базової архітектури.

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

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

То чому б не просунути їх обох разом у симфонію?