15 июня 2020 г.
Руководитель облачной платформы Mail.ru Cloud Solutions Илья Летунов рассказывает, чем цифровизация ИТ-инфраструктуры сегодня отличается от цифровизации в
Первая волна цифровизации
Что нового в 2020 году? Во-первых, многие, кто не мог перейти на облака в
Застревание в
Я расскажу, как сфокусироваться на точках роста.
Как перестать закупать много железа?
Закупки железа — длительная процедура, от согласования до введения в строй проходят месяцы. По сравнению с получением ресурсов в облаке за минуты это сильно замедляет вывод продуктов на рынок.
Раньше компании отказывались от облаков по требования безопасности. А иногда частная система оказывалась слишком сложна, чтобы просто мигрировать её в облако. К счастью, обе проблемы сейчас решаемы.
Но в плане безопасности облака настолько созрели, что тот же Gartner считает их безопаснее, чем частные ИТ-системы. Многие облака обеспечивают соблюдение ФЗ-152 или других локальных правил обращения с данными. Даже банки HSBC и JPMorgan Chase задействуют для хранения интенсивно растущего объёма данных публичные облака в рамках гибридных систем.
Построение подобных гибридных ИТ-систем, наполовину частных, наполовину в публичном облаке — это способ «мягкого перехода» к облакам. Это позволяет держать под полным контролем «ядро» системы, которое сложно мигрировать, и данные, которые вы не готовы отдать в облако. Периферийные же системы можно разместить в облаке. Например, тестировать приложения можно на «виртуальных смартфонах» вместо закупки парка физических — создавать их за минуты, сразу с нужными ОС и настройками, и оплачивать их только в время тестирования. Точно так же «на периферии» можно подключить ИИ к давно копившимся данным и найти полезные закономерности. В общем, гибриды позволяют получить многие плюсы облака без рискованной миграции «ядра» бизнеса.
Наконец, если использование публичного облака принципиально невозможно, некоторые провайдеры помогают компаниям построить и поддерживать собственное частное облако.
Что делать, если приложения падают под нагрузкой?
От внезапной нагрузки падают и сайты, и приложения. Для приложений на собственном оборудовании это значит, что не хватает мощности. Но от проблемы не застрахованы и приложения в облаке, если увеличение мощности под нагрузкой не автоматизировано и при аврале команда не успевает реагировать вручную.
Современные ИТ-системы автоматически меняют свою мощность (автомасштабируются) с помощью облака. Под нагрузкой система берёт дополнительные облачные мощности, а при падении нагрузки ресурсы высвобождаются, стоимость аренды сокращается.
Защита от глобальных сбоев подразумевает создание дублирующей ИТ-системы. В нулевых дата-центр дублировался физически, при его падении нагрузка переходила на запасной. Сегодня запасную систему дешевле делать в облаке, например — транспортная компания Transdev сократила расходы на аварийное восстановление на 73% за счёт перехода к таким решениям. При сбое облако просыпается и берёт нагрузку на себя. Такие решения называют системами облачной катастрофоустойчивости (disaster recovery as a service).
Для надёжного хранения данных используют объектные хранилища (S3-хранилища). Они подходят для любых данных — от архивов до тяжёлых исходников медиафайлов. Встроенное бэкапирование защищает данные в хранилище.
Для надёжности доступа также важна хорошая скорость: когда сайт тормозит при обращении многих пользователей — это всё равно, что он лежит. Объектные хранилища помогают не просто хранить, но и бесперебойно раздавать контент. Десятки тысяч человек могут одновременно смотреть видео на медиа-хостинге. Если бы видео лежало на обычном сервере, оно бы страшно тормозило. А объектные хранилища быстро раздают контент любого объёма практически под любой нагрузкой.
Объектные хранилища для надёжного хранения и раздачи контента используют такие известные компании, как Netflix, Airbnb, Newsweek, Canon и даже CERN.
Как ограничить увеличение расходов на ИТ?
Нагрузка на ИТ естественно растёт вместе с ростом бизнеса. За счёт эффекта масштаба рост расходов должен замедляться. Однако иногда расходы на инфраструктуру и штат администраторов растут линейно и даже быстрее. Проблема возникает при недостаточной автоматизации и недоиспользовании новых технологий.
Для простого управления инфраструктурой можно использовать средства типа Terraform и Ansible, которые позволяют даже в одиночку создавать и поддерживать нужное состояние ИТ-системы любой сложности. Главное, чтобы облачный провайдер поддерживал эти средства управления.
Чтобы снизить расходы и упростить наращивание мощностей, задействуйте встроенные возможности масштабирования облачных сервисов. Например, вы храните данные на дисках облачных серверов. Диски легко увеличить в любой момент, но всё равно за ними надо следить. Перенесите данные в объектное хранилище, которое автоматически масштабируется без вашего участия. Раздача видео из объектного хранилища позволяет рекомендательному видеосервису «Смотри» не беспокоиться о технической стороне масштабирования: хранилище готово к любому числу обращений пользователей.
Что делать, если ограничения развития продукта лежат в коде ИТ-системы?
На надёжность и лишние расходы также влияют особенности кода, то есть то, как построены приложения. В устаревшей монолитной архитектуре компоненты системы взаимосвязаны так, что при выходе из строя одного теряет работоспособность и перестаёт выдавать результат вся система.
Перенос монолитного приложения в облако уже даёт ряд плюсов: выше надёжность, можно создавать бэкапы для любых её частей, повысить доступность для пользователей. Но монолит всё ещё потребляет лишние облачные ресурсы по сравнению с приложениями в современной архитектуре.
Современные приложения состоят из автономных компонентов — микросервисов, которые соединены в конвейер. Каждый микросервис умеет работать сам по себе, без обязательной доступности остальных компонентов: при отсутствии доступа он просто накапливает очередь обработанных данных и передает их дальше, когда связь восстановится. В итоге микросервисные приложения готовы к временным отказам или просадкам производительности у их частей.
Микросервисы часто размещают в облаке, поэтому такие приложения называют cloud-native («облачнорождёнными»). В зависимости от нагрузки микросервисы умеют автоматически резервировать в облаке мощности и автоматически масштабироваться. Технически реализация всего этого связана с технологией контейнеров, в которую мы вдаваться не будем, но не удивляйтесь, почему от технической команды всё чаще звучит это слово — контейнеры.
Как проапгрейдиться без аврала и лишних расходов?
Что делать, если ИТ-системе нужен апгрейд? Переезд в облако без простоя с одновременной пересборкой приложений — сложная задача. Но этого слона можно съесть по частям:
- Сначала протестировать работу в облаке для отдельных проектов: тестирование, новые ИИ- и big data-технологии. Оценить финансовую эффективность по результату внедрения и понять, какую пользу от облака может получить остальная часть ИТ-системы.
- Если решили переносить в облако действующие процессы, можно сначала перенести их без пересборки, с небольшими доработками, чтобы получить базовые преимущества облака. У системы уже появится большая надёжность и доступность.
- Наконец, можно «пилить монолит», тоже по частям. В итоге система сможет управлять объёмом ресурсов, зарезервированных у провайдера, и сократит расходы на аренду.
На этом пути вам наверняка придётся общаться с облачными провайдерами, потому что нужные технологии проще всего получить именно в облаках. Кроме того, многие провайдеры выступают в роли ИТ-консультантов по внедрению.
Необязательно обращаться к глобальным вендорам, российские уже несколько лет предлагают полноценную линейку сервисов хорошего качества, а ваши эксперты будут общаться с провайдером на русском.
Пообщайтесь с несколькими провайдерами с участием вашего ИТ-директора. Пусть они расскажут, как они помогут снизить расходы и увеличить надёжность и производительность ИТ-системы. У вас будет хороший выбор.
Источник: Илья Летунов, руководитель облачной платформы Mail.ru Cloud Solutions
