Кэтрин Дэниелс - Философия DevOps. Искусство управления IT

Мы использовали Google App Engine (GAE) для создания и поддержки некоторых одноразовых проектов. По мере роста интенсивности использования GAE возникла необходимость перехода к среде AWS, в которой доступен более высокий уровень контроля.

В качестве примера подобного перехода можно привести наш микросервис обработки изображений, который называется ImageBoss. Этот сервис позволяет по запросу изменять размеры изображений, обрезать их. В результате вашим художникам не придется создавать слишком много вариантов каждого графического объекта. Первоначально этот микросервис был развернут на платформе GAE. При этом одновременно на каждом узле для Go было доступно лишь одно ядро. В результате были очень высоки эксплуатационные расходы. После перемещения этого сервиса на платформу AWS была получена оптимально настроенная среда приложения.

Хотя услуги AWS обходятся дороже услуг других облачных провайдеров, взамен пользователи получат отличный набор инструментальных средств. На вопрос о стоимости выполнения анализа с помощью AWS Гросс сказал следующее:

Если нам нужно будет перейти от AWS к другому провайдеру, нам придется найти замены для управляемых услуг, таких как SQS или DynamoDB. Затраты на выполнение подобных замен наверняка превысят возможную выгоду. К тому же наша рабочая нагрузка идеально вписывается в почасовую модель ценообразования AWS. В этом случае мы будем регулярно масштабировать узлы в течение рабочего дня. Это позволит обоснованно прогнозировать возникающие требования и в случае необходимости выполнять масштабирование при небольших затратах.

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

При рассмотрении существующих технологий, используемых в процессах выбора инструментов, задайте себе следующие вопросы.

• Какие средства абсолютно необходимы, а какие – желательны?

• Какие решения доступны прямо сейчас, а какие могут стать доступными в ближайшее время?

• Каким образом затраты на внедрение необходимых вам средств соотносятся с затратами на внедрение доступных средств?

Непрерывное влияние новых технологий

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

Гросс описал несколько проблем, с которыми столкнулась его команда в октябре 2013 года.

• Как правило, Django применялось для выполнения медленного неатомического развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания периодически случались сбои.

• Увеличение степени сложности развертывания. Новые приложения Go не могут быть развернуты при использовании существующих процессов. Для двоичных модулей и интерпретированного исходного кода имели место разные требования к поставке.

• Раздельное тестирование качества и процессов развертывания производства без каких-либо возможностей аудита.

• Различные среды разработки и непрерывной интеграции.

Гросс также описал дополнительные цели, которые преследовала его команда:

• переход от монолитного приложения к меньшим по размерам микросервисам;

• изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.

Как говорит Гросс:

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

Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой LXC-системе. Эту ситуацию мы изложили руководству команды разработчиков, чтобы получить «добро» на продолжение работы.