Философия DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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