AWS Business Growth - о фундаментальных сдвигах роли ИТ

На днях прошла технологическая конференция AWS Business Growth Conference для руководителей высшего звена предприятий. Кроме докладов ведущих специалистов AWS и ее партнеров, участникам были представлены реальные корпоративные кейсы и организован виртуальный тур по хабу AWS и сетям. Примечательно, что конференция проходила в двух форматах: off-line и on-line.

Участникам были предложены доклады, которые включали такие темы, как миграция корпоративного хранилища данных в облако с учетом требований законодательств относительно локализации данных, грамотное обеспечение обработки данных в облаке, обеспечение устойчивого функционирования бизнеса посредством Amazon Workspaces. Мы сосредоточимся на двух выступлениях.

Тема, которой был посвящен доклад директора корпоративной стратегии AWS Люка Хеннекенса (Luc Hennekens), - как в действительности развиваются корпоративные ИТ в эпоху цифровой трансформации.

Заказчики сегодня видят фундаментальный сдвиг роли ИТ в корпорациях. Этот сдвиг представляет заманчивые возможности как для организаций, так и для ИТ-профессионалов. Чтобы лучше понять суть этого процесса, выступающий начал с описания ситуации, которая сложилась в последние 20 лет, когда организации фокусировались на построении и использовании ИТ-систем для развития бизнеса.

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

Но иногда случалось действительно интересное - возникновение чисто цифровых бизнесов. Различие в этих организациях было в том, что технология в них играла центральную роль в продуктах или сервисах с самого начала. Всем, конечно, известны истории Netflix, Amazon, PayPal, Uber. Все эти организации строились с использованием облачных технологий и Интернета.

Что наблюдается теперь у заказчиков AWS из большинства традиционных организаций? Все они смотрят на то, как могут применить технологию к своим основным продуктам и сервисам, используя передовые облачные решения так же, как и пионеры цифровизации. Причины, по которым они это делают, многочисленны. Одна из них в том, что поведение потребителей радикально изменилось в последние несколько лет. Современный потребитель ожидает взаимодействия посредством цифровых каналов. Он постоянно находится в этой среде, в различных социальных сетях. И, конечно, компании должны реагировать на это. Другой причиной, почему более традиционные компании начали теперь интегрировать цифровые технологии со своим основным бизнесом, является то, что глобальные рынки становятся более доступными благодаря такому подходу. И, наконец, технологии значительно понизили барьеры для выхода на рынок и наблюдается конкурентное давление новых игроков, которого не было еще несколько лет назад. Конечно, цифровые технологии позволяют быть намного более гибким, и таким образом организации могут лучше понимать своих заказчиков, их нужды, и не только понимать, но также лучше и быстрее на них реагировать.

Люк Хенненкенс: «Глобальные рынки становятся более доступными благодаря цифровым продуктам и сервисам»

Технология не является единственно используемой для помощи бизнесу, но становится важной частью опыта заказчика работы с продуктом или сервисом. Сдвиг фокуса от менеджмента возможностей основного офиса к совместному созданию продуктов и сервисов в бизнесе также значит, что культуру, инструменты и навыки ИТ организаций нужно адаптировать. Для современных CIO это значит, что уменьшается объем работы по администрированию. Они, скорее, становятся антрепренерами, которые являются частью основного бизнеса. Это предоставляет возможность для ИТ организаций стать намного ближе к коммерческому заказчику. Но есть и оборотная сторона - происходящие перемены также означают, что предсказуемость в поставках конечных продуктов будет намного ниже, потому что заказчик решает, что ему нравится, а что не нравится.

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

Другой вещью, которая должна измениться, является архитектура. Возвращаясь к ИТ за последние 20 лет, где покупки в больших предприятиях осуществлялись, главным образом, пакетами «с полки», и эти пакеты были затем интегрированы с существующим ландшафтом, возникла также необходимость в миграции бизнес-данных, а затем построении интерфейсов к существующим приложениям. Делая так, нужно было брать на себя обязательства по лицензированию частных технологий, что требовало больших инвестиций для длительных периодов времени. И было важно принять правильное решение, потому нужные функции были предопределены. Таким образом, раз вы купили определенный пакет ПО, вы получаете его функциональность, и раз у вас есть ПО, вы идете на рынок и подписываете многомиллионную сделку с системными интеграторами для связи новых приобретенных приложений с существующей средой.

Эта модель требовала очень интенсивного планирования, подготовки и длительных циклов доставки. Это не работает совсем, когда создаются продукты для заказчиков, или когда улучшаются сервисы для них, или взаимодействие непосредственно с заказчиками выполняется «на лету». В этой ситуации необходимо двигаться быстрее. Компании полностью переосмысливают, как должна выглядеть их ИТ-архитектура. И наиболее успешные строят архитектуры не вокруг приложений, а вокруг данных. Таким образом, вместо того, чтобы оставлять для каждого приложения управление данными, в которых оно нуждается, и затем строить интерфейсы между всеми этими приложениями, сами данные помещают в центр архитектуры. Затем создаются лишь наборы разделяемых данных для разных типов потребления. Таким образом, все, что нужно знать про внутренний и внешний мир, заключается в том, чтобы соединить вместе эти озера данных почти независимых от приложений. Затем строятся небольшие модули и часто функциональность, запускаемую по событию, что иногда называют микросервисами. Большое различие здесь в том, что взамен наличия одного стабильного приложения, которое не изменяется, за исключением некоторой модификации по требованию заказчика, создается архитектура, которая меняется постоянно, когда модули добавляются, удаляются или изменяются. Как следствие, можно выбирать из постоянно растущего набора новейших БД, типов серверных машин, структур обучения, IoT-платформ и других технических сервисов без длительного согласования лицензий или специфики какой-то частной технологии, и платить только тогда, когда все это используется.

Одна из причин, по которой все это делается - возможность быстро интегрировать самые последние технологии. Сегодня современные организации начинают непрерывный процесс создания инноваций продуктов, сервисов и опыта заказчиков. Они делают это, объединяя самые последние и наилучшие технологии «как сервис» в сложную и постоянно развивающуюся функциональность. Ясно, что этот способ работы в этом новом мире будет сосуществовать со старым довольно длительное время и не заменит его мгновенно. Все эти изменения требуют времени.

Также можно видеть, что есть две большие проблемы для заказчиков, которые трансформируются. Первая заключается в том, что архитектура, ориентированная на приложения, остается основной для бизнес-операций. Эти приложения являются все еще основными, они создают и управляют большими объемами данных, которые ориентированы на архитектуру ЦОД. Сложность увеличивается до такой степени, что большинство ИТ-департаментов организаций заключают, что фундаментальное упрощение их архитектуры слишком дорого или слишком сложно, чтобы стать реальной возможностью. Здесь AWS и облачные технологии могут помочь, поскольку есть сервисы, позволяющие компаниям сократить усилия и стоимость, требуемые для управления их бизнес-приложениями, посредством миграции в облачную инфраструктуру. Это делает управление намного легче, надежнее, снижает стоимость и повышает безопасность. Заказчики могут купить реляционную БД, полностью управляемый сервис в облаке. И это не значит, что они должны полностью реконструировать свое приложение, просто эта БД располагается в облаке, управляемом, скажем, AWS. Это позволяет более простым способом закрыть многие бреши безопасности в ЦОД заказчика. Вторая проблема больше относится к культуре и организации, потому что новый подход меняет фокус и способ работы. Многочисленное ИТ-сообщество годами адаптировалось к миру снижения рисков без прерывания активности бизнеса и администрирования работы подрядчиков. Много ИТ-профессионалов со временем все более и более смещались от технологии к бизнесу, и все же комбинация технологических знаний и знания бизнеса действительно составляет их ценность для организаций.

Ключевые выводы: будущее ИТ предприятий заключается в подходящем складе ума, тренинге персонала и наборе инструментов

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

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

Пожалуй, самой оптимальной облачной архитектурой является гибридная, когда облака разворачиваются на площадке заказчика и у облачного провайдера. Поэтому выбор стратегии для гибридного облака является важным для бизнеса. О том, как это можно сделать с использованием сервисов AWS, рассказал СТО HeleCloud Уолтер Хек (Walter Heck).

Уолтер Хек: «Преимуществом полного отделения ЦОД заказчика и облака AWS является высокая безопасность»

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

Первая - это полное отделение. Сетевая активность отсутствует. Позволяется только одна вещь - публичный доступ из ЦОД к AWS и наоборот. Этот подход имеет целый ряд преимуществ. Одно из них — высокая безопасность, потому что можно запретить по умолчанию весь трафик, и только если нужны определенные коммуникации, можно открыть канал.

Разделение AWS и ЦОД

Второй стратегией является создание своего рода сетевого доступа между двумя сайтами. Это может быть сделано с помощью VPN или посредством прямого соединения. И с этого момента заказчик имеет неплохое и легкое соединение между приложениями, которые работают в его ЦОД, и приложениями в AWS. Здесь есть и обратная сторона - большой рост количества объектов, которые используют это соединение, особенно, когда оно не падает. Конечно, можно сделать это соединение высокодоступным, и имеется целая связка решений этой задачи, но для многих приложений можно спросить себя, действительно ли есть потребность в том, чтобы одно приложение «говорило» с другим через объединенную сеть. Такой сценарий является общим при увеличении и перемещении рабочей нагрузки. И это первый шаг во многих сценариях.

Немного проще, тем временем, третья стратегия. Это облако VMware в AWS, иногда обозначаемое как VMC on AWS. Как правило, имеются аппаратные средства в AWS, на которых работает ПО заказчика в его облаке VMware. Эти ресурсы соединены с аппаратными средствами заказчика в ЦОД, и заказчик с техническими знаниями может перемещать ВМ из ЦОД в AWS без всяких затруднений.

Четвертая стратегия является полностью противоположной предыдущей. Это использование AWS везде как аванпоста и EKS (Elastic Kubernetes Service) и ECS (Elastic Container Service). Аванпосты являются в основном стойками с аппаратурой AWS, которые заказчик размещает в своем ЦОД. Теперь есть аппаратура AWS, находящаяся в ЦОД заказчика, которой он может управлять с помощью консоли AWS.

Также вполне интересными и полезными являются решения, когда есть среда, где заказчику необходимо выполнить множество обработок, которые могут быть сделаны локально. Например, есть заказчики, у которых есть камеры в медицинских учреждениях, осуществляющие мониторинг палат с пациентами или проверяющие с помощью алгоритмов машинного обучения, не упал ли кто-нибудь с кровати. Также есть задачи, которые с помощью машинного обучения могут регистрировать, выполнял ли медперсонал на месте какие-либо действия. Очевидно, этот алгоритм машинного обучения мог бы работать в AWS. Но для этого необходимо все записанные с камер видео переслать в AWS, проанализировать их, затем избавиться от видео и хранить только сигналы тревоги. Но это огромный объем данных за очень короткий отрезок времени. Поэтому, устанавливается аппаратура в каждом медучреждении, чтобы выполнять обработку локально. При этом используются алгоритмы машинного обучения для анализа видео, удаления видео и соединения со средой AWS, чтобы удостовериться в корректности извещений. Другой случай, когда можно это применить, — рабочие нагрузки с малой латентностью. Таким образом, если нужно что-то настолько близкое к действию, насколько это возможно, тогда нагрузки с малой латентностью могут хорошо выполняться с помощью аванпостов. Они, в общем, довольно дорогие, так что это не является стратегией типа "давайте перенесем все наши ЦОД на аванпосты и будем иметь ЦОД, которым мы можем управлять полностью. Это в действительности специализированное решение, подобное упомянутому выше.

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

Еще один аспект, который действительно важен для обдумывания, это долгосрочная перспектива. Возможно потребуется поначалу принять какое-то краткосрочное решение, потому что нужно двигаться и времени нет, или есть другие причины сделать это, например, финансовые ресурсы. Но также стоит продумать как проект будет развиваться. В этом плане AWS очень удобен, поскольку позволяет начать с малого и дальше продолжить рост по мере необходимости.

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

Все доклады прозвучавшие на AWS Business Growth Conference вы можете посмотреть на видеозаписи мероприятия.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365