Колонки

Как выжать пользу из кризиса и переманить клиента с облака Amazon

Колонки
Константин Кирсанов
Константин Кирсанов

генеральный директор ООО «Позитивные системы»

Ольга Лисина

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

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

Константин Кирсанов, генеральный директор ООО «Позитивные системы», рассказывает, как его команда решила воспользоваться ситуацией и замахнулась на разработку и запуск «альтернативы Amazon» для крупной компании. И что из этого вышло.

Как выжать пользу из кризиса и переманить клиента с облака Amazon
Присоединиться

Кто мы

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

Как правило, мы обслуживаем инфраструктуру клиентов и/или решения, которые они переводят в наши ДЦ. Несмотря на то что у крупных системных интеграторов обычно есть свои облака, они выбирают наши сервисы, потому что это позволяет им существенно снизить себестоимость проектов и повысить скорость их реализации.


Шаг 1. Выбор новой технологии

Когда начался кризис, мы задумались о том, какие новые продукты или услуги можем предложить и как их позиционировать. Хотелось выгодно использовать карантинное время для внутреннего R&D и создать задел на будущее, запустив перспективные направления деятельности. 

Наш выбор пал на контейнеризацию приложений — Docker/Kubernetes.

Сферу контейнеризации по ее важности и степени влияния на IT можно сравнить с технологиями виртуализации, которые внедрялись 10–15 лет назад. Изобретенная сотрудниками Google технология контейнеризации доступна как open source с 2015 года. Основное ее преимущество — простота и скорость развертывания, управления и масштабирования сложных IT-систем и, как следствие, возможность «не админам» управлять необходимым набором системных компонентов.


Shutterstock / dennizn


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

На данный момент контейнеризацию предлагают такие крупнейшие облачные провайдеры, как Amazon, Azure, Mail.ru и «Яндекс». Ее внедрение требует значительных инвестиций в технологии, оборудование и персонал и потому по силам лишь крупным технологическим компаниям.

Этим обусловлены и высокие ценники на услугу: при низкой стоимости «входного билета» сервис становится очень дорогим по мере разрастания системы и вовлеченности клиента. 

Высокая цена на услуги крупных провайдеров полностью оправдана: их платформы до такой степени удобны и автоматизированы, что переехать с них в свой ДЦ или на сервер обычного поставщика без проблем и потерь — непростая задача.

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


Шаг 2. Поиск клиента

Сложную IT-систему нельзя поставить «просто так, чтобы посмотреть» — для ее развертывания необходим реальный проект реального клиента.

Мы начали искать компанию, которая захотела бы сделать совместный пилотный проект и на выгодных условиях перенести его к нам в ДЦ. В обычной ситуации это практически невыполнимая задача — крупная и/или технологичная компания не будет менять поставщика просто потому что «это дешевле».

«Еще ни один CIO не был уволен за то, что купил IBM», то есть если система работает, но за большую цену — это приемлемо, а если цена низкая, но не работает ничего — неприемлемо совсем.

Но коронакризис — время чудес.

Мы написали в пять знакомых технологических компаний индустрии online travel, наиболее сильно пострадавшей в сложившейся ситуации. Из пяти ответили трое, двое продолжили диалог, а компания Level.Travel — один из крупнейших в России сервисов бронирования туров онлайн — приняла наше предложение. 

В компании используется Kubernetes и множество сервисов Amazon. Этим и был обусловлен наш взаимный интерес: первоначальные расчеты показывали, что мы сможем предложить клиенту аналогичный сервис по цене примерно в три раза дешевле.


Шаг 3. Подготовка

Готовясь к реализации проекта, мы совместно с инженерами компании-клиента разделили все используемые ими AWS на четыре группы:

  1. Простые сервисы, перенос которых не требует внесения изменений в архитектуру:  EC2 (виртуальные серверы).
  2. Расширенные сервисы, которые требуют портирования, но без смены технологии:  RDS (PostgreSQL), ElastiCache (Redis) и Elastic Container Registry (Docker Registry).
  3. Непортируемые сервисы (внутренние инструменты Amazon), которые требуют замены с адаптацией на нашей стороне, а в некоторых случаях правки кода у клиента: ECS (Elastic Container Service) и ELB (Elastic Load Balancing).
  4. Out-Of-The-Scope сервисы, которые мы решили оставить на Amazon: Amazon CloudFront (технически сложный перенос CDN и необходимость существенных изменений кода при минимальной экономии затрат), Route 53 (Managed DNS) и S3. Эти сервисы значительно влияют на доступность в разных географических регионах, и в нашем случае создавать их аналоги было нецелесообразно.


Шаг 4. Пилот

Первоначальная архитектура пилота включала в себя только open source, так как мы хотели минимизировать расходы на лицензирование ПО. Для управления кластером k8s выбрали Rancher. Виртуализацию внедрили на OpenStack, используя встроенные в него возможности для реализации функциональности PV.

Однако в процессе мы столкнулись со слишком высокими трудозатратами на развертывание, сопровождение и настройку open source ПО под требования клиента.

После тестирования нескольких вариантов технического решения мы решили использовать комбинированную модель внедрения Kubernetes: одна часть компонентов — open source, другая — коммерческие продукты.

Мы использовали NSX-T для функциональности Ingress Controller, а функциональность PV реализовали с помощью плагина Trident, используя нашу систему хранения.


Шаг 5. Переезд

На работу по «пересозданию» облака Amazon и перенос на него Level.Travel у нас ушло два с половиной месяца. Команда состояла из трех специалистов: инженера по инфраструктуре и DevOps-инженера по контейнеризации с нашей стороны и DevOps-инженера со стороны клиента.

При миграции мы, как поставщики, вложили в проект свой опыт в инфраструктуре, железе и виртуализации, а наш партнер — опыт эксплуатации систем контейнеризации и управления облаком.


Shutterstock / Blackboard


У Kubernetes высокие требования к производительности, а Amazon не раскрывает аппаратную конфигурацию облака. Поэтому мы подбирали похожую конфигурацию экспериментально. Сейчас это 4-процессорные серверы (48 физических ядер / 96 c HT) с 512 Гб памяти, подключенные к общей системе хранения NetApp. Внутренняя сеть 10 Гб и внешний канал 1 Гб.

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


Сложности

К сожалению, не обошлось без сбоев: в пилотной фазе проекта после первой недели работы система мониторинга выявила переполнение логического LUN. Ошибка, возникшая из-за конфигурации системы хранения, привела к 20-минутному простою кластера. Для продуктивной работы системы в требования к дисковому пространству были внесены поправки — при этом время восстановления, прописанное для пилота по SLA, не было превышено. 

Анализируя причину ошибки, мы поняли, что не учли фундаментальную разницу в подходе к управлению IT-системами для внутренней службы IT и для крупных корпоративных клиентов и новых «облачных» компаний и ориентировались на знакомые паттерны, не применимые в данном случае. 

Взаимодействие между подрядчиком и заказчиком не всегда складывается по классической схеме, где планирование и capacity management происходят совместно, а клиент, который привык работать с облаком, часто воспринимает его как источник безграничных ресурсов — и к этому нужно быть готовыми. 

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


Итоги

Сейчас Level.Travel перевел в наше облако как продуктивный кластер, на котором работает сайт, так и все среды разработки и тестирования. 

Планируют ли они вернуться на Amazon?

Ключевой параметр, по которому оценивают работу подрядчика, — устойчивость и непрерывность в оказании услуг. Если в ближайшие 2–3 месяца мы обеспечим uptime и требуемую производительность, нашему партнерству ничего не угрожает.

Мы рады, что наша вынужденная самоизоляция не пропала даром и принесла новое направление деятельности, крупного клиента и заманчивые перспективы роста. Благодаря запуску такого большого онлайн-проекта мы извлекли множество уроков и готовы делиться полученным опытом. 

 
Как достичь максимума при использовании Kubernetes

  • Удобство, которое дает кластер, требует большого количества вычислительных ресурсов: это заметный overhead технологии. Целесообразно использовать k8s лишь в тех случаях, когда выгоды от автоматизации Continuous Integration / Continuous Delivery (CI/CD) и автомасштабирования перевешивают затраты на потребляемые ресурсы облака. Не стреляйте из пушки по воробьям.
  • Технологический стек должен поддерживать контейнеризацию. Перенести в контейнеры legacy-технологии довольно сложно, и вы не получите существенных преимуществ, используя монолитные приложения типа PHP + MySQL. Ваше приложение должно предусматривать горизонтальное масштабирование by design.
  • Жизненный цикл контейнера подчиняется принципам CI/CD: это подход, который позволяет командам разработчиков приложений качественно писать новые версии ПО и публиковать их быстрее и чаще. Если ваша реальность — это много тестовых сред, проведение экспериментов и постоянные релизы, контейнеризация — ваша «серебряная пуля». Использование k8s позволит существенно уменьшить time to market для ваших IT-продуктов.
  • Чем сложнее технологии, тем дороже инженеры. Контейнеризация — не исключение. Для развития технологии вам понадобятся не просто системные администраторы, а DevOps-инженеры — редкий и дорогой зверь на рынке труда (впрочем, аутсорсинг никто не отменял).
  • Подбирая людей на проекты, используйте врожденную тягу IT-специалистов ко всему новому. Мотивируйте сотрудников возможностью прикоснуться к прекрасному будущему и разобраться с технологиями, которые станут мейнстримом через несколько лет, а сейчас дадут опыт, значительно повышающий стоимость их труда.

Фото на обложке: Shutterstock / aorpixza

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Бизнес в облаках: как построить сервис виртуальной телефонии в эпоху мессенджеров
  2. 2 Краткая история облачных технологий
  3. 3 «Передавать данные в облако здорово, но, возможно, наступит день, когда вы захотите их оттуда вернуть». Топ-менеджмент Veeam Software о развитии компании
FutureFood
Кто производит «альтернативную» еду
Карта