Истории успеха клиентов Mail.ru Cloud Solutions

Wunderman Thompson: как мы искали подходящий хостинг для Microsoft-продуктов, а вышли на облачные сервисы

Последние двадцать лет Wunderman Thompson пыталось уйти от своего железа и его обслуживания. О метаниях между сервисами и платформами, и о том, как Kubernetes только с третьей попытки оправдал ожидания, рассказывает Григорий Никонов, управляющий директор агентства Wunderman Thompson.
Компания
Wunderman Thompson
Отрасль
Digital-агентство
Проектов
более 2000
Технологии в облаке
Григорий Никонов
Григорий Никонов
Управляющий директор агентства Wunderman Thompson

Предыстория: мы сами занимались железом для хостинга

Wunderman Thompson — старейшее диджитал-агентство России. С 1997-го мы разрабатываем сайты, копим экспертизу и успели превратиться в 360°-агентство, которое занимается всем на свете. И точно так же с конца 90-х мы верны продуктам Microsoft. Если бы не они, наша «облачная» история была бы другой.

Нам нравится Microsoft и то, что он много лет создает для веб-разработки. Но у его продуктов был один серьезный минус: в конце 90-х под них было проблематично найти адекватный хостинг, а разные UNIX’ы не подходили под наши задачи. И мы сделали самое сложное из возможного: построили собственный хостинг. Десять стоек в специальном помещении, серверы Compaq (еще до того, как этот бренд выкупил HP), три смены инженеров — у нас были все атрибуты компании, которая работает по-взрослому.

Со временем мы сменили физический location на colocation, но все равно остались стойки с серверами, которые нам приходилось обслуживать. А потом мы поняли, что больше не хотим заниматься железом, администрировать и апгрейдить его. Нам как рекламному агентству это стало неинтересно. Но мы не могли поставить в этой истории точку, так как на наших серверах хостились клиентские сайты (BMW, MTV-Россия и много других), которые мы разрабатывали.

Мы снова приняли важное решение, но на этот раз окунулись в виртуализацию. Тогда главными игроками на рынке виртуализации были продукты VMware. Мы поставили их на несколько серверов, которые у нас оставались — со временем плотность мощности выросла, и железа стало меньше. Вроде бы, все хорошо, но нам не хотелось заниматься даже этими машинами. Что было делать?

Ищем хостинг, чтобы делегировать по-максимуму

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

В то время в России появились первые услуги по аренде виртуальных машин за адекватную цену и с адекватным SLA (без него в дорогих проектах никуда). Здесь начался наш путь к облакам.

Вначале мы познакомились с DataLine…

Нас устроили условия этого провайдера, и мы переехали в его облако. Там мы поднимали Microsoft-решения на VMware, но все равно наши штатные инженеры многое делали руками. Получается, даже в облаке мы не ушли от рутины, которая нам сильно не нравилась.

Потом с Azure…

Параллельно развивалась наша история с Microsoft. То, что мы делали с 2002 года, в 95 % случаев работало именно на технологиях этой компании. А это своя экосистема, свои методы публикации, база данных, диагностические и мониторинговые инструменты — отдельный мир, который требовал особенного подхода.

Когда на горизонте появился Azure, мы сразу перенесли туда часть наших решений. Это удобно:

  • не нужно наперед заказывать физические серверы. Ресурсов выделяется столько, сколько нужно сейчас;
  • все отлично скейлится. Когда нужны дополнительные ресурсы, мы получаем их мгновенно;
  • в облаке уже есть широкий набор софта — просто бери и работай.
  • Но был один минус: потребители наших решений находились в РФ, а ближайший сервер Azure — в Голландии. Тогда еще не было федеральных законов, которые бы нас ограничивали, но был трафик, который уходил за пределы России, чтобы потом вернуться обратно. Вскоре наше сотрудничество с Azure завершилось.

Мы зашли в тупик, так как снова не смогли найти хорошее, подходящее под наши запросы решение. А еще мы сильно нуждались в инструментах вроде Puppet, Ansible и Chef, которые позволяют разворачивать инфраструктуру под заказ. Но их не было или они требовали доработки.

А еще с .NET Core

В июне 2016 года случилось чудо (как нам тогда показалось): вышла модульная платформа .NET Core от Microsoft. К тому времени мы накопили большое количество библиотек, которые переходили из одного проекта в другой. Это было удобно: разработчики просто брали и, не задумываясь, использовали нужную библиотеку в новом проекте. В .NET Core мы могли использовать эти библиотеки еще и на UNIX. Пусть с небольшими оговорками, но это работало.

Мы начали экспериментировать с .NET Core под Linux и поняли, что нас устраивает почти все: работа платформы, обновления, команда, которая за этим стоит. У Microsoft полностью изменился подход к разработке их продуктов, и это тоже радовало. Нам открывался мир, в котором мы могли использовать облака в том виде, какими их задумали в Amazon’е. Мы уже собирались разворачивать инфраструктурные виртуальные машины, чтобы потом на них под Linux запускать наши приложения. Но рынок снова подкинул нам что-то новенькое.

Как мы тестировали микросервисную архитектуру с Docker’ом

Его начали активно развивать и продвигать, а так как мы постоянно искали альтернативные варианты, то решили посмотреть и на него тоже. Изучили и поняли: это же здорово! Docker открывает много возможностей для реализации микросервисной архитектуры. Контейнеризация с помощью Docker’а предполагает, что приложения разбиваются на отдельные компоненты с зависимостями, и потом эти компоненты можно легко разворачивать благодаря их полной стандартизации. Это позволяет абстрагировать приложения от хоста, упростить масштабирование, легко управлять версиями и зависимостями. Docker помог бы нам упростить подготовку хост-системы и отказаться от 120 Linux-образов для разных задач — достаточно одного, на котором разворачивается Docker.

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

Мы наконец-то нашли Kubernetes!

Это произошло случайно: наш сотрудник поделился ссылкой на описание Kubernetes в рабочем чате. Подкупило то, что в Kubernetes для Service discovery используется DNS, да и сам Service discovery работает «из коробки». Это был мощнейщий wow-фактор! Вторым аргументом стало то, как Kubernetes раздает дисковое пространство. Теперь можно сформировать специальный объект, пойти и с помощью него получить нужный кусочек дисковой памяти. Инженеру не нужно помнить, откуда этот фрагмент взялся и кто его создал.

Тогда казалось, что Kubernetes — это самая настоящая магия. Вначале мы подняли его вручную, локально в нашем приватном облаке. На это ушло полтора месяца, но по-настоящему ничего так и не заработало. Кое-как наши администраторы поддерживали его жизнеспособность, но этот вариант нас не устраивал. С другой стороны, мы понимали: технология-то классная, но совершенно не адаптированная к такому простому использованию. По крайней мере, наша команда оказалась к ней не готова. Специалисты, которые долгое время работали с монструозными, но предсказуемыми продуктами Microsoft, привыкли многие операции выполнять парой щелчков мыши. В Kubernetes было иначе: чтобы поднять кластер, нужно набрать 10 команд и все равно не понятно, сработают они или нет.

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

Мы завели у себя 10 нод, установили Tectonic, протестировали его на паре проектов — все отлично работало. Но снова возникла проблема: у Tectonic’а хорошо с внутренними обновлениями, но нам снова приходилось самим поддерживать кластер. А еще десяти нод оказалось слишком много для наших задач, а «подрезать» ресурсы мы не умели. Больше того — боялись это делать, так как в кластере уже находились проекты на проде. Да, разработчикам все нравилось: они работали по понятным инструкциям. Но мы переплачивали за неиспользуемые мощности, а это не нравилось финотделу.

Тем временем в мире появились облачные платформы с удобным скейлингом и оплатой только за потребляемые ресурсы: Google Cloud, Amazon и уже знакомый нам Azure. Мы обращались в «Яндекс» со своими проблемами, искали другие альтернативы в России, но так ничего и не нашли.

Что мы ожидали от облачной платформы

Мы снова отправились на поиски, и теперь у нас были четкие критерии выбора облачной платформы:

  • не занимаемся инфраструктурой кластера;
  • платим только за те ресурсы, которые реально потребляем;
  • она отлично работает с продуктами Microsoft;
  • у нее есть базовый набор инструментов, включая balancer и backup;
  • серверы провайдера находятся на территории РФ (152–ФЗ).

Мы по-прежнему ожидали, что все будет работать на Kubernetes. Наконец-то это случилось: оказалось, что подходящую нам виртуальную инфраструктуру предлагает команда Mail.ru Cloud Solutions (MCS).

Переезд в облако MCS: от пилота до продакшена

Тестировать работу Kubernetes в облаке MCS мы начали на пилотном проекте — сайте нашего рекламного агентства. Это на нем мы обычно обкатываем новые технологии, которые потом внедряем на клиентских продуктах. Плюс нам хотелось тестировать именно на реальном проекте, который работает под нагрузкой. Здесь мы сделали первый вывод: туризм и эмиграция — разные вещи. Тех вольностей, которые мы могли себе позволить в собственном кластере, на чужой площадке не было. Когда мы поняли это на примере нашего сайта, то начали думать в правильном направлении.

И скоро мы получили первые выгоды.

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

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

Как мы мигрировали пилотный проект…

Сайт агентства мы перенесли в облако MCS ровно за один день. Чтобы понять, как так получилось, нужно знать предысторию. С самого начала мы уделяли внимание не только тому, что разрабатываем, но тому, как мы это делаем (Continuous Integration и другие подобные дисциплины). Благодаря этому во всех проектах реализована централизованная система хранения версий с build-планами, в которых подробно описан порядок сборки. Все это пригодилось во время миграции. Мы просто сменили адрес, ввели логин и пароль к новому кластеру, щелкнули по кнопке и сайт заработал на новом месте.

… и вслед за ним — клиентский

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

Впечатления от облака MCS: экономический эффект и не только

Прозрачное ценообразование. Если в общем кластере нам было сложно подсчитать, сколько ресурсов уходило на конкретного клиента, то в облаке MCS все проще: мы понимаем, во сколько нам обходится кластер, и легко распределяем эту сумму между клиентами.

Отзывчивая техподдержка. С Telegram-чатом просто приятно работать. Мы не только быстро получаем ответы, но и позволяем себе «забывать» информацию с низким приоритетом. Зачем помнить то, о чем можно спросить и тебе точно ответят?

Удобная площадка для всего на свете. Мы можем выбирать те ресурсы и те сервисы, которые нам нужны. Для этого мы не идем к десяти разным поставщикам, а получаем все в одном месте.

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

О планах на будущее

Следующий шаг после Kubernetes — machine learning (ML) в прикладном значении. Мы хотим заниматься ML не ради науки, а ради наших клиентов: придумывать для них интересные вещи, в которых можно задействовать нейронные сети (например, находить зависимости между людьми). Еще одно интересное направление — Computer Vision. В MCS уже этим занимаются, и мы тоже хотим попробовать его для своих задач.

Наш «облачный» путь оказался достаточно длинным. Мы начали с поиска подходящего хостинга под Microsoft-разработки и инфраструктуры, которая «съедала» много специалистов, денег и времени, а пришли к тому, что полностью делегировали инфраструктуру и теперь получаем ресурсы по требованию в облаке MCS, используя Kubernetes.

По пути мы сделали несколько выводов

  • Для новых проектов облачная инфраструктура — единственное разумное решение.
  • Мигрировать в Kubernetes не страшно, а наоборот, легко и безболезненно.
  • Перенести в облако можно даже живые проекты, работающие под нагрузкой.
  • В разработке нужно отходить от шаблонов и смотреть на более гибкие инструменты.
  • У облачного провайдера важны не только технологии и надежность, но и отзывчивая техподдержка.
Хотите попробовать сервисы MCS?
20 лет
опыта поддержки высоконагруженных сервисов
100+ млн
пользователей по всему миру
5 лет
экспертизы развития облачной инфраструктуры