NAB определила группы основных трехуровневых приложений, которые она намерена автоматически перенести в облако Microsoft Azure в рамках пятилетней сделки, обнародованной ранее сегодня.
Исполнительный директор enterprise technology Стив Дэй сказал ITnews, что банк провел последние шесть месяцев, используя “действительно подробный набор инструментов обнаружения”, чтобы наметить “какие потоки приложений мы имеем, идя откуда куда, что позволило нам сгруппировать приложения и посмотреть на движущиеся приложения как на группы.”
Необходимость перемещения приложений в группы является результатом тесной связи между частями стека приложений NAB.
Это означает, что подход NAB к работе с облачной миграцией на сегодняшний день, который в значительной степени включает в себя переархитирование и повторное формирование одного приложения за раз, хотя и в темпе, не подходит для этой цели.
“Мы будем перемещать приложения как группы, а не как отдельные приложения, и это важно из-за уровня интеграции, который мы имеем в приложениях на данный момент”, — сказал Дэй ITnews.
“Они очень тесно интегрированы, и поэтому пытаться перемещать их по одному … просто слишком сложно для нас на данном конкретном этапе.”
Банк планирует перенести 1000 приложений в Azure за 1000 дней; 700 из них-NAB, а 300-Bank of New Zealand (BNZ).
По словам Дэя, все они также являются “мейнстримом” и “обычно трехуровневыми”-или веб — приложениями.
Это приложения, необходимые для перехода в облако по таким причинам, как дополнительная отказоустойчивость и снижение эксплуатационных расходов.
“Речь идет [о перемещении] ваших типичных трехуровневых архитектур/готовых [приложений], которые одинаково хорошо работают в разных облаках”, — сказал Дэй.
— Тут и там есть крошечные вариации, но в целом все они одинаково поддерживают этот наименьший общий знаменатель.”
Ни в Azure или AWS льготные
Хотя сегодняшняя сделка была сообщена как смена караула — передача эстафеты NAB на облачных ит — предпочтениях для своей облачной миграции, — Дэй сказал, что на самом деле у банка нет предпочтений относительно того, где он размещает свои приложения и рабочие нагрузки.
Это было частично упомянуто в официальном заявлении NAB, в котором говорилось, что приложения, перенесенные в Azure, должны быть эффективно спроектированы, чтобы быть облачными агностиками-и поэтому не привязаны конкретно к Azure.
”Мы предпочитаем, чтобы мы были мультиоблачными и соответствовали рекомендациям, данным нам APRA [Австралийским Органом пруденциального регулирования], в том смысле, что мы не должны связывать успех NAB с какой-либо другой компанией”, — сказал Дэй.
— Очень важно, чтобы мы этого не делали.
“На самом деле речь идет о двух действительно замечательных партнерах, с которыми мы работаем, чтобы гарантировать, что наши приложения работают максимально устойчиво, а также сохраняют свою актуальность и позволяют нам внедрять инновации в темпе.”
То, как NAB работает над тем, где разместить свои приложения сейчас, определяется их относительной важностью, которая отражается в “семи различных процедурах”, называемых мультиоблачными процедурами или MCTS.
“Если, например, APRA классифицировали приложение в своем определении экстремального риска, то мы обычно строим в обоих облаках одновременно, тогда как для приложений с более низким риском, без которых мы могли бы жить в течение длительного периода времени, мы обычно просто строим [в] среде, которую, как мы знаем, мы можем переместить [из] в течение нескольких недель”, — сказал Дэй.
“Таким образом, с одного конца, то есть вы можете перестроить его, если вам нужно, вплоть до создания приложения в обоих облаках одновременно и запуска его активно-активно, а затем у нас есть целая куча промежуточных этапов.
“Каждая из этих различных процедур имеет разный дизайн в мультиоблачных инструментах, но это целая многооблачная плоскость управления, которую мы строим прямо через эти семь процедур.”
Варианты Мультиоблачной обработки NAB (MCT)
MCT1: Приложение не требует мульти-облака, потому что если бы приложение исчезло, это не имело бы значения. Дэй привел пример инструмента бронирования конференц-зала, который можно было бы легко заменить другой существующей системой.
MCT2 и MCT3: Приложения NAB могут жить без них в течение нескольких месяцев без какого-либо воздействия на наших клиентов. “Это может быть просто что-то, выполняющее ежегодную функцию”.
MCT4: Эти приложения каждый вечер резервируются во вторичное облако. Они также настроены на использование вторичного облака для производства, если это необходимо, но на самом деле оно не включено. “Если произойдет событие, мы включим это вторичное облако, восстановим его с помощью резервной копии, а затем сможем переориентировать службы данных с помощью DNS и других механизмов, чтобы иметь возможность запускать эту среду”, — сказал Дэй.
MCT5: Неизвестно.
MCT6: Приложения с активной доставкой журналов из одной среды в другую. Доставка журналов “ — это процесс автоматизации резервного копирования файлов журналов транзакций на основном сервере базы данных, а затем их восстановления на резервном сервере”, согласно Википедии. Дэй говорит: “У нас все еще отключена вторичная среда, но мы отправляем журналы во вторичную базу данных, которая всегда включена”. Восстановление из резервной копии может занять несколько часов, а не дней.
MCT7: Приложение настроено на запуск active-active, причем оба облака обрабатываются в режиме реального времени. “Транзакции и потеря одного [облака] на самом деле вообще не остановят сервисы. Это наши критические рабочие нагрузки, такие как бухгалтерские книги и другие среды, которые мы просто не могли позволить себе потерять”, — сказал Дэй.
