You are currently viewing Macquarie Bank приближается к масштабу в облачной миграции

Macquarie Bank приближается к масштабу в облачной миграции

  • Post author:
  • Post category:Финансы

Последние два года Macquarie Bank потратил на поиск путей преодоления “дисэкономии масштаба”, с которой он столкнулся при увеличении числа команд, развертывающих приложения в облаке.

Владелец платформы Kubernetes и заместитель директора Джейсон О’Коннелл сказал на недавнем собрании OpenShift Commons в Бостоне, что стандартизация способа развертывания OpenShift позволила банку привлечь больше команд и приложений, не занимая слишком много времени или внутренних ресурсов.

Розничные цифровые банковские платформы Macquarie Bank работают на платформе «платформа как услуга», состоящей из контейнерной платформы Red Hat OpenShift, размещенной в инфраструктуре AWS.

Банк также тестирует альтернативу OpenShift в новом сервисе Google Anthos, что может быть связано с его ранее заявленным желанием работать в мультиоблачных средах, включая облачную платформу Google (GCP).

Два года назад банк перенес свои первые приложения в OpenShift — и, следовательно, в облако — “поэтому все наше внимание в то время было сосредоточено на том, чтобы начать производство и убедиться, что у нас все стабильно и работает”, — сказал О’Коннелл.

“После этого мы хотели перейти к масштабированию OpenShift и предложить его для каждой команды в организации, чтобы убедиться, что любая команда может использовать его для миграции в облако.

“Таким образом, Openshift стал основной частью нашей стратегии миграции облаков.”

Однако по мере того, как банк вкладывал все больше средств в облако, он начал видеть, что определенные затраты — например, те, которые несет команда платформы, поддерживающая и переносящая приложение в облако, — увеличиваются, в то время как банк ожидал, что эти затраты сократятся.

“Когда мы впервые вышли в производство [с OpenShift], мы довольно хорошо осваивали новые приложения, так что наши затраты снижались”, — сказал О’Коннелл.

— Но все стало замедляться по мере того, как мы набирали все больше и больше команд.

“Изначально мы работали вместе с продуктовыми командами над внедрением их приложений. Позже, когда мы расширились до организации, мы имели дело с командами, которые даже не находятся в одном здании, не говоря уже о той же стране, и которые менее зрелы в своем понимании [контейнеров].

— Для них все было в новинку, и это значит, что мы сильно замедлились.

— Это неэкономия масштаба. На самом деле нам нужна экономия масштаба. Мы хотим сделать так, чтобы мы могли взять на борт 10-20 команд или перейти от 300 заявок к 500 заявкам, плавно и без трений.

— Ему не нужна команда платформы … дополнительные ресурсы для того, чтобы использовать все больше и больше приложений. Так вот к чему мы стремимся.”

О’Коннелл сказал, что процесс миграции и развертывания приложений в облаке уже сильно автоматизирован, но автоматизация осуществляется на основе “каждого приложения”.

“Команды использовали свои собственные сценарии развертывания, и все стало очень запутанным. Вместо того чтобы все делали что-то по-разному, мы начали говорить:” вы должны делать все одинаково», — сказал он.

“То, что мы действительно хотели, — это повторное использование. Мы не просто хотим автоматизировать — мы хотим автоматизировать его один раз для всех и заставить команды повторно использовать эти сценарии.

“Итак, мы сказали, что будет один способ, которым вы будете выполнять развертывание, и мы собираемся написать эти сценарии.”

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

“Хотя все команды думают, что они делают что-то по-разному, мы на самом деле поняли, что 90 процентов приложений, которые мы запускаем, являются микросервисами Spring Boot, и они на самом деле очень, очень похожи”, — сказал О’Коннелл.

— Поэтому нам пришлось заставить команды стандартизироваться.”

Банк также создал стандартизированные “услуги возможностей” , которые все команды могут использовать в своих проектах.

“Это такие вещи, как управление секретами, которые мы переносим в хранилище [HashiCorp], чат — боты, CI/CD с Дженкинсом, Knative-это основные возможности”, — сказал О’Коннелл.

“в OpenShift очень легко установить некоторые из этих инструментов за пять минут, и команды разработчиков и продуктовые команды хотят это сделать. but…it это означает, что мы потеряем стандартизацию и контроль, и все может стать запутанным.

“Поэтому мы говорим, что любая служба возможностей, которую запускает наша команда, мы строим ее должным образом, мы делаем ее многоквартирной, мы обращаемся к безопасности/контролю/рискам, и мы строим ее для всех, чтобы использовать.”

О’Коннелл также подчеркнул важность элементов управления для создания масштабируемой среды на основе OpenShift.

В Macquarie Bank органы управления управляют такими функциями, как управление доступом пользователей и управление ресурсами.

“Будучи банком, мы нуждаемся в контроле над всеми этими вещами, и контроль, который вам нужен, находится на разных уровнях”, — сказал он.

“Я не могу вдаваться во все элементы управления, за исключением того, что если вы хотите масштабируемую платформу, любой элемент управления, который вы вводите, вам нужно сосредоточиться на опыте разработчика.

“Вам нужно, чтобы ваш контроль был бесфрикционным, автоматизированным и самоуправляемым [потому что] если вы заблокируете развертывание в день выпуска для команды, и они не знают почему, они придут в команду платформы-мою команду — и вызовут большой шум, а затем будет много работы, чтобы их разблокировать.”

О’Коннелл привел пример объема работы, который был затрачен на определение единой системы управления — вокруг команд, которые запрашивают больше процессора и памяти для своих приложений.

Некоторые аспекты контроля были сосредоточены на “сдерживающих факторах”, побуждающих запрашивать больше системных ресурсов, без учета ресурсоемких аспектов приложения.

“Мы говорим:” Если вы превышаете свои возможности, мы собираемся предотвратить ваше развертывание, поэтому блокируем вас до тех пор, пока вы не приведете его [обратно] под контроль — это сдерживающий фактор, чтобы заставить [команду] придерживаться контроля», — сказал О’Коннелл.

“Чтобы гарантировать, что они оптимизируются, нам нужен обратный платеж. Поэтому, если они просят больше процессора и памяти, они получают плату. Если вы не делаете возвратный платеж, они просто просят все больше и больше.

“Нам нужно, чтобы они могли самостоятельно управлять, поэтому мы даем им возможность автоматической очистки в nonprod, чтобы они могли сказать: «эти среды разработчиков, они будут очищаться каждую ночь», или «эти среды длятся дольше» и так далее.”

О’Коннелл сказал, что если команде действительно нужно больше вычислений, контроль означает, что распределение может быть “самоутверждено, поэтому им не нужно привлекать команду [платформ].”

Команды могли видеть свое текущее использование вычислений на панели мониторинга самообслуживания.

“У нас также есть электронная почта, и мы просто создаем чат-ботов, предупреждающих, чтобы, когда они приближаются к своим пределам, мы предупреждали их, чтобы они знали, что они не будут заблокированы в производстве, им было дано достаточно предупреждений до этого”, — сказал О’Коннелл.

“Таким образом, только для этого одного элемента управления, чтобы сделать его бесшовным и без трения, нам нужно на самом деле построить шесть различных компонентов и приложений только для управления контролем использования ресурсов.”

Банк заявил, что теперь у него есть 42 команды, которые коллективно развернули 306 приложений в облаке через OpenShift.