Перевод https://codeascraft.com/2018/01/04/selecting-a-cloud-provider/

Etsy.com и большинство наших связанных сервисов были размещены в самообслуживаемых центрах обработки данных, с тех пор, когда был запущен первый сайт Etsy в 2005 году. Ранее в этом году мы решили оценить миграцию в наше облачное решение. В то время решение о запуске собственного оборудования в центрах обработки данных было правильным, но инфраструктура как сервис (IaaS) и платформа как сервис (PaaS) сильно изменились за прошедшие годы. Пришло время переоценить наши решения. Недавно мы объявили, что выбрали Google Cloud Platform (GCP) в качестве нашего облачного провайдера и очень рады, что так сделали. Так, знаменуется сдвиг к Etsy от надежности инфраструктуры до лучшего в своем классе поставщика услуг. Этот сдвиг позволяет нам сократить расходы времени на поддержание нашей собственной инфраструктуры и увеличить время на стратегические функции и услуги, которые улучшают рынок Etsy.

Хотя мы используем термин vendor (поставщик, рус.), ссылаясь на поставщика облачных решений, мы рассматривали это как нечто большее, чем простой процесс выбора поставщика. Мы вступаем в партнерство и долгосрочные отношения. Поставщик, которого мы выбрали, станет основной частью нашей успешной изначальной миграции, а также партнером в долгосрочной масштабируемости и доступности нашего сайта и услуг. Это не было решением, которое мы хотели принять без тщательного рассмотрения и анализа. Эта статья покажет вам процесс, по которому мы проверили и в конечном итоге отобрали партнера. Мы не собираемся рассказывать о том, почему мы решили перейти на облачный хостинг-провайдер, и не будем освещать бизнес-цели, которые мы установили для оценки успеха этого проекта.

От одного до множества

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

Мы начали с определения восьми крупных проектов, включая путь продакшена (производства, рус.) для сайта, поисковые службы сайта, продкшен системы поддержки, такие как ведение логов, и бизнес-системы Tier 1, как Jira. Затем мы разделили эти проекты на свои компонентные проекты — MySQL и Memcached, например, как часть производственного пути. К концу этой практики мы определили более 30 подпроектов. Чтобы определить требования к каждому из этих подпроектов, нам необходимо было собрать экспертные знания по всей организации. Ни один человек или проектная команда не могли точно или своевременно собрать все эти требования. Например, нам нужно было не только знать допустимость латентности наших баз данных MySQL, но и требования к хранилищу данных для API для создания и удаления данных. Чтобы помочь собрать все эти требования, мы использовали модель RACI для определения прав собственности на подпроект.

RACI

Модель RACI используется для выявления ответственного, подотчетного, консультативного и информированного персонала для каждого подпроекта. Мы использовали следующие определения:

• Ответственный — это человек, который в конечном итоге несет ответственность за завершение проекта или инициативы.
• Подотчетный — это человек, которому R подотчетен, и кто должен одобрить работу, прежде чем она будет закончена.
• Консультативные – Эти люди могут предоставить данные, которые окажутся полезны при завершении проекта.
• Информированные – Это люди, которые должны быть информированы или уведомлены о ходе проекта, но при этом не должны одобрять какой-либо шаг или артефакт.

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

Архитектурный обзор

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

Мы определили, что для правильной оценки различных облачных провайдеров требуется понимание желаемого конечного состояния различных частей нашей системы. Например, наше текущее обеспечение выполняется в наших центрах совместного размещения, используя пользовательский набор инструментов в качестве автоматизации для создания серверов из «голого металла» и виртуальных машин (VM). Мы также используем роли и рецепты Chef, применяемые поверх готовых серверов из «голого металла» и виртуальных машин. Мы определили несколько ключевых целей для выбора инструмента для создания инфраструктуры в облаке, включая: большую гибкость, подотчетность, безопасность и централизованное управление доступом. Наша команда разработчиков оценила несколько инструментов по этим целям, обсудила их, а затем предложила новые рабочие процессы в обзоре архитектуры. В заключение команда предложила использовать Terraform в комбинации с Packer для создания базовых образов ОС.

В конечном итоге мы провели 25 архитектурных обзоров для основных компонентов нашей системы и сред. Мы также провели 8 дополнительных семинаров для некоторых компонентов, которые, по нашему мнению, требуют более глубокого обзора. В частности, мы рассмотрели системы бэкэнд, связанные с созданием страниц etsy.com (a.k.a.), с большей фокусировкой на ограничениях времени ожидания и режимах отказа. Эти архитектурные обзоры и семинары привели к набору требований, которые мы могли бы использовать для оценки различных облачных вендоров.

Как же это сочетается

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

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

Экспериментирование

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

Поэтому мы провели эксперимент, позволяющий запускать пакетные задания на GCP с использованием Dataproc и Dataflow. Мы извлекли ряд уроков из этой практики, в том числе о том, что некоторые из услуг GCP все еще находятся в альфа-выпуске и не подходят для требуемых рабочих нагрузок и SLA. Это было первое из многих подобных решений, которые нам нужно будет принять: использовать облачный сервис или создать собственный инструмент. В этом случае мы решили внедрить Airflow на виртуальных машинах GCP. Чтобы помочь нам принять эти решения, мы оценили приоритет различных критериев, таких как поддержка поставщиков услуг, независимость поставщика и влияние этого решения на другие команды.

На эти вопросы нет правильного ответа. Мы считаем, что эти вопросы и критерии необходимо определить для каждой группы, чтобы рассмотреть их и принять наилучшее решение. Мы также не прочь пересмотреть эти решения в будущем, когда у нас будет больше информации, или альфа и бета-проекты будут в общем доступе (GA).

Совещания

В течение пяти месячного курса мы встречались с командой Google несколько раз. На каждой из этих встреч были четко определены цели, начиная от коротких общих представлений членов команды и заканчивая глубокими погружениями на целый день по различным темам, таким как использование контейнерных услуг в облаке. Более того, для предоставления ключевой информации, эти встречи также укрепили общую инженерную культуру между Etsy и Google.

Мы также встретились с определенными клиентами, чтобы обсудить, что они узнали, мигрируя в облако и о том, что нужно ожидать от нашего «путешествия». Время, проведенное с этими компаниями, было невероятно полезным и продемонстрировало удивительно открытую культуру, которая широко распространена среди технологических компаний в Нью-Йорке.

Мы также встретились с ключевыми совладельцами в рамках Etsy, чтобы проинформировать их о нашем прогрессе и предложить их вклад в ключевые директивные решения, например, такие, как сбалансировать смягчение финансового риска с учетом дисконтированной ценности затрат. Это позволило всем ЛПР познакомиться с процессами и нивелировало вероятность неприятных сюрпризов на этапе финального принятия решения.

Решение с большой буквы «Р»

К этому моменту у нас было тысячи данных от совладельцев, поставщиков и инженерных команд. Мы использовали инструмент, называемый матрицей решений, который используется для оценки проблем с несколькими критериями решения. Этот инструмент помог организовать и расставить приоритеты этих данных так, что можно было бы использовать их для беспристрастной оценки предложений каждого вендора. Наша матрица решений содержала более 200 факторов с приоритетом 1400 и оценила более 400 баллов.

Этот процесс начался с определения общих функциональных требований. Мы определили отношения, стоимость, простоту использования, сервисы с добавленной стоимостью, безопасность, местоположения и возможности подключения в качестве семи областей функционального требования высокого уровня. Затем мы перечислили каждое из 200 + требований клиентов (клиентов, относящихся к инженерным группам и совладельцам) и взвесили их по принципу, насколько хорошо каждое из них поддерживает общие функциональные требования.

Мы использовали шкалу 0, 1, 3, 9, чтобы указать уровень поддержки. Например, требование клиента к «поддержки автомасштабирования» было оценено в 9 баллов за стоимость (поскольку это помогло бы снизить затраты за счет динамического масштабирования наших вычислительных кластеров), 9 за удобство использования (поскольку это не дало бы нам возможности для ручного вращения VM), 3 за дополнительные услуги (так как это дополнительная услуга, предлагаемая помимо базового вычисления и хранения, но она не очень сложна) и 0 за поддержку других функциональных требований. Несколько инженерных команд провели углубленную оценку и взвешивание этих факторов. Четкие приоритеты стали отображаться в виде нелинейной шкалы весов, которая заставляет слишком консервативных оценщиков принимать жесткие решения по тем вопросам, которые реально имеют значение.

Затем мы использовали эти взвешенные требования для ранжирования предложений каждого поставщика. Мы снова использовали шкалу 0, 1, 3, 9 для оценки того, насколько каждый облачный поставщик соответствовал этим требованиям. Продолжая наш пример «поддержки автомасштабирования», мы поставили каждому поставщику облаков 9 за соответствие этому требованию полностью тем, что все поставщики, которых мы оценивали, предоставили поддержку автомасштабирования вычислительных ресурсов в качестве встроенных функций. Общая сумма баллов для каждого поставщика достигла более 50 000 баллов, а GCP превысила остальные более чем на 10%.

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

Это только начало

Теперь начинается веселье и работа. Этот процесс занял у нас более 5 месяцев с полноправным техническим проектным менеджером, десятками инженеров, а также несколькими юристами, финансовым персоналом и экспертами по поиску, которые работают частично или в некоторых случаях полный рабочий день. Излишне говорить, что это не было малозначимым усилием, а на самом деле только началом многолетнего проекта перехода на GCP. У нас есть строгий график проведения нашей миграции примерно за два года. Мы сделаем это, продолжая при этом сосредотачиваться на инновационных функциях продукта и минимизации риска в течение переходного периода. Мы сгораем от нетерпения опробовать все возможности, которые дает переход на GCP, и мы особенно рады этому трансформационному изменению, которое позволяет нам больше сосредоточиться на основных стратегических услугах для рынка Etsy, сотрудничая с лучшим в своем классе вендором.