Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
33. Почему immutable вас никуда не приведет
• Runtime vs Buildtime (в какой-то момент время билда ПРЕВЫШАЕТ
время работы контейнера)
• в моей системе время сборки 40минут + время замены через
терраформ
• у Akamai деплой новой конфигурации порядка 50минут
34. Почему микросервисы похоронят вашу компанию
Мы внедряем микросервисы, чтобы:
• позволить распределенным командам разрабатывать части
приложений
• деплоить части приложений независимо друг от друга
• деплоить без остановки приложения
• масштабировать части приложения быстро и независимо
47. Почему микросервисы похоронят вашу компанию
«В сложных системах поведение агентов приводит к
неожиданным результатам для всей системы»*
*Про сложность позже
53. Почему микросервисы похоронят вашу компанию
• 11 дней потребовалось C****F***e,
чтобы достать IP-адрес из блеклиста
• 41 день потребовался компании
A****I, чтобы избавиться от двойного слеша в
конце URL
• 13дней потребовалось компании
A****n, чтобы починить сеть в Сингапуре после
выхода из строя кабеля
62. Почему ваша система слишком сложна
• bogdar: понимание происходящего может приходить не сразу
• bogdar: а работать должно было вчера
• Среднее покрытие кода тестами на моих проектах 0.23%
Каждый контейнер становится уникальным
что вводит элемент неожиданности
КАЖДАЯ КОМАНДА СБОРКИ МОЖЕТ ОТКАЗАТЬ
ВЫ НИКОГДА НЕ ПРОВЕРЯЛИ ИХ ВСЕ
Я буду рассказывать об обычной небольшой организации, о том что не нужно увлекаться дорогостоящими и сложными решениями, когда достаточно простых и проверенных
Я буду рассказывать об обычной небольшой организации
если спросить любого девопса где на графике нормального распределения находится его компания, он точно укажет место - с правого края
Я буду рассказывать об обычной небольшой организации
если спросить любого девопса где на графике нормального распределения находится его компания, он точно укажет место - с правого края
На самом деле мой опыт показывает, что большинство организаций сталкиваются примерно с теми же самыми проблемами и развиваются по одинаковому сценарию. Поэтому цель моего сегодняшнего выступления убедить вас в этом
Решили минимизировать задержки, сделав географически разнесенную инсталляцию
Потом мы решили что какие-то рынки нам дороже остальных, а на какие-то можно не обращать внимания
Ну а потом бизнес решил выделить часть компании в отдельное бизнес-подразделение со своим оперированием
На картинке типичный пример использования Docker. На самом деле нужно определиться, вы использует докер как систему управления пакетами или как систему управления виртуальными машинами?
Как обычно развиваются события? Прямо перед выкаткой важной фичи, про которую вам забыли рассказать, появляется программист.
И показывает вамм докерфайл. Вы радостно делаете
И ничего не работает
Тут обычно отваливаются желающие использовать дата-контейнры
Проблема контекста для команды ADD
Хардкоженные ключи в докерфайлах, а также переменные. В данном случае все безобидно, но никто не мешает программистам творчески улучшить, особенно когда процессы CI/CD будут автоматизированны
А еще докер очень хорош, чтобы переложить ответственность на программистов.
Вот почему
Типичный "immutablе" сегодня выглядит так
вносим изменения в кукбуки
деплоим кукбуки в шеф-сервер
запускаем пакер для нужной роли
деплоим новые инстансы терраформом
скейлим ап-даун или прибиваем старые инстансы
это не работает. sorry to say that.
софт бажный. терраформ однажды даже удалил продакшн базу (нет, это не компания Gliffy)terraform plan и terraform apply делают разные вещи. я видел rspec для терраформа, но пока все это допишутограничение scope делает не совсем то что ожидалосьпакер не работает в пределах МИНОРНОЙ версии(последний пример - неподгружающиеся ключи шефа в 0.9/0.10.1
На самом деле
микросервисы сложнее
поэтому микросервисы менее гибки
микросервисы менее защищены
и менее стабильны
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Расскажу немного про типовую архитектуру типового приложения
Облако и autodiscovery
Типичный список проблем с autodiscovery
Не там: по умолчанию эластик ищет в регионах по своим внутренним убеждениям. Программисты подняли в одном из регионов кластер и к нему начал цепляться эластик при сборке
Облако и autodiscovery
Типичный список проблем с autodiscovery
Не там: разновидность не там, с которой мы столкнулись при форке компаний – эластик использовал старые ключи, в результате чего в новой компании эластики присоединялись к старому кластеру
Облако и autodiscovery
Правила фильтрации (теги, SG)
Серьезная проблема с фильтрацией по секьюрити группам, если кластер ищет не там и вы не фильтруете явно, то отладка будет весьма затруднена
Облако и autodiscovery
Типичный список проблем с autodiscovery
Не там
Еще одна разновидность не там – изначально архитектурно была выбрана неправильная сеть для дискавери или коммуникации внутри кластера, достаточно часто так и случается. Очень опасно что иногда приходится переделывать вообще все, например если изначально было несколько VPC
Пример из жизни, есть какой-то сторонний сервис или сервис, который делает другая команда разработчиков
Вы обнаруживаете какие-то ограничения, которые плохо ложатся в вашу архитектуру. Например на этот сервис авторы могли внести только 10 ip-адресов в ACL
Разновидность этой проблеым – при переходе в облако вы начинаете зависить от компаний, предоставляющих сервис
Последняя причина, которую вы можете увидеть на слайде - финансовая
Это затраты на инфраструктуру и вы даже не представляете как просто достичь этих цифр
Расскажу немного про типовую архитектуру типового приложения
проблема #2 в том как мы отлаживаем: трассировка, логи, tcpdump
Простой пример что нас ждет, если мы захотим посмотреть а что же все-таки происходит внутри приложения
Вы серьезно? Кассандра чтобы посмотреть логи на проекте с 10000 кликами в месяц?
Коала сегодня натружена
В результате автоматизации бардака получается автоматизированный бардак
Разработчики жаловались, что девопсы их тормозят. Оказалось что разработчики деплоят не так и много!
время первого деплоя на стейджинг в районе 10 часов
время последнего деплоя в районе 16 часов