Почему Твиттеру нужны 1000 микросервисов
Core-Архитектура Twitter от Илона Маска
В последнее время на Twitter чуть ли не из каждого утюга льется критика по поводу оверинжиниринга. Даже некоторые вполне технически подкованные люди заявляют, что Твиттер можно было бы поддерживать вообще одному — мол, «подумаешь, твиты хостить, 80% всех микросервисов ему не нужны».
На самом же деле Twitter — это далеко не только набор 140-символьных текстовых постов (для простоты можно оставить и это ограничение, которое уже давно было снято), а внезапно целая экосистема с налаженными процессами, которые волей-неволей появляются, если ваша аудитория превысила несколько миллионов пользователей. Вот лишь некоторые примеры таких процессов:
процесс управления информационной безопасностью — чтобы бизнес не прикрыли из-за очередной утечки пользовательских данных
процесс управления инфраструктурой — на самом деле не важно, хостите вы текстовые посты, измеряемые байтами или гигабайтные видео (а в твиттах можно размещать и медиа объекты), если ваша аудитория разбросана по континентам, а DAU измеряется миллионами — подход всегда примерно одинаковый
процесс управления тестированием и качеством (QA) — чтобы ежедневно не терять пользователей из-за низкого качества своего продукта
процесс управления релизами и выкатками (aka CI\CD) — когда у вас более 1 микросервиса, между ними появляются зависимости друг от друга, которые проще заскриптовать, чем делать вручную каждый раз
процесс сбора логов и метрик — без обратной связи со своим продуктом в продакшне далеко не уедешь, да и не поймешь, что пользователям нравится, а что не нравится
процесс технической поддержки пользователей — для тех, кто сталкивается с неизвестными багами либо не понимает, как пользоваться сетью
процесс управления рекламой — не так-то просто настроить нейронную сеть для хорошей лидогенерации (один только подпроцесс сбора качественной телеметрии от пользователей чего стоит — годы «экспериментов» с микросервисами)
процесс борьбы с ботами (aka антиспам) — кто-то думает, что его нет, а он есть. Суммарное число забаненных ботов этой социальной сети уже в разы превышает число реальных пользователей. Представляете, что было бы, если на каждого пользователя Twitter приходилось 1–2 бота?
процесс предоставления API для сторонних разработчиков — чтобы хотя бы не все, кто хочет взаимодействовать с Twitter программно, плодили ботов
процесс цензурирования — мало кто хочет видеть непристойный контент в своей ленте, иначе разбегутся
процесс поддержки 100 OpenSource проектов в красивом состоянии, чтобы сообщество не поливало грязью, не отбивая тем самым желание новых специалистов устраиваться на работу
процесс совершенствования методологий разработки и правил оформления кодовой базы — чтобы через год разработчики не перестали быть способны поддерживать код своих предков
процесс управления документацией — чтобы на вопрос «сколько у вас микросервисов?» всегда был свежий ответ
И это лишь часть «окольных» процессов, не касающихся непосредственно разработки кода «ядра» Twitter (движок поиска, фронтенд и его оптимизация под разные устройства, генерация фида, постинг и хранение твитов и т.д). А что уж говорить про неайтишные процессы (HR, compliance, юристы).
На большинство из перечисленных процессов нужны свои микросервисы. И как бы странно это не звучало, но их количество благоприятно влияет на качество процессов. Грубый пример: можно отказаться от процесса «сбора логов и метрик» и полагаться на жалобы от пользователей в тех.поддержке — критические проблемы, может, и получится так устранять, но предупреждать их возникновение — едва ли — это уже совсем другой уровень качества процесса.
Также нужно понимать, что разработать сервисы куда проще, чем потом поддерживать их качество на должном уровне — для этого требуются отлаженные процессы и следование им. Грубо говоря, наколбасить можно за один вечер, а вот потом собирать все недочеты и внедрять их в уже работающую систему — дело кропотливое и нервозное. Наверное, именно поэтому нанятый Илоном Маском «хакер» Geohot для исправления проблем с поиском в Twitter не хочет задерживаться в Twitter дольше 12 недель:
Очень интересно будет понаблюдать за дальнейшей судьбой Twitter. Как по мне Twitter ждет один из двух сценариев: либо постепенное обратное наращивание штата в процессе осознания новым владельцем сложности системы, либо же упрощение до такой степени, что в принципе встанет вопрос о целесообразности существования компании. Первый вариант развития событий кажется наиболее вероятным.
Целью этой статьи было показать, что за простой функциональностью может скрываться множество взаимосвязанных технологических процессов, требующих «кода». Выбрасывание любого из таких процессов не представляется возможным для компаний вроде Twitter (пишите в комментариях, если с этим утверждением не согласны).
На этом хочу завершить данную короткую статью, которую теперь можно использовать как аргумент в будущих спорах — почему простые, но популярные сервисы нуждаются в своих 1000 микросервисах.
