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

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

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

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

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

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

Кто мы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обыкновенные сервисы, перенос которых не просит внесения конфигураций в архитектуру: 
EC2 (виртуальные серверы).

Расширенные сервисы, которые требуют портирования, но без смены технологии: 
RDS (PostgreSQL), ElastiCache (Redis) и Elastic Container Registry (Docker Registry).

Непортируемые сервисы (внутренние инструменты Amazon), которые требуют подмены с адаптацией на нашей стороне, а в неких вариантах правки кода у клиента: ECS (Elastic Container Service) и ELB (Elastic Load Balancing).

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 у нас ушло два с половиной месяца. Команда состояла из 3-х профессионалов: инженера по инфраструктуре и DevOps-инженера по контейнеризации с нашей стороны и DevOps-инженера со стороны клиента.

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

У 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-специалистов ко всему новенькому. Мотивируйте служащих возможностью прикоснуться к красивому будущему и разобраться с технологиями, которые станут мейнстримом через пару лет, а на данный момент дадут опыт, существенно повышающий стоимость их труда.

Источник: rb.ru

Рекомендованные статьи