В последнее время на Twitter чуть ли не из каждого утюга льется критика(1,2,3) по поводу оверинжиниринга. Даже некоторые вполне технически подкованные люди заявляют, что Твиттер можно было бы поддерживать вообще одному - мол, "подумаешь, твиты хостить, 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 микросервисах.
Комментарии (82)
excoder
26.11.2022 18:21+68В компании, поставляющей в течение последних 40 лет сложнейший софт для моделирования производственных процессов, продуктами которых пользуются большинство крупных промышленных предприятий мира, с офисами по всему земному шару, чуть менее 1.5 тысячи сотрудников всего. В Твиттере до увольнений, сколько там? К 10'000 было? Полагаю, развесистая сеть микросервисов просто отражает раздутость компании, где наверняка многие, скажем так, не очень много работают, и прикрываются ненужной сложностью, созданной для того, чтобы их должности были нужны.
barloc
26.11.2022 19:09+10В первом случае экономика реальная - завязанная на физическое производство, во втором виртуальная, на вертолетных деньгах. И мерило успешности у виртуальных компаний из разряда "у нас работает 10 000 человек, а у нас 100 000", или у нас 1000 микросервисов в 10 000 контейнерах.
MaryRabinovich
27.11.2022 13:15+4Гм. У них мерило успешности - число подписчиков. Большинство крупных промышленных предприятий мира и близко не догоняет количеством миллионы подписчиков Твиттера и подобных. Т.е., у этой компании с 40-летним стажем заказчиков несопоставимо меньше.
Т.е., возможно, сложность ПО у компаний, делающих сложнейший софт для моделирования производственных процессов, другая.
Опять же, если они чем-то заняты уже 40 лет, у них килотонна легаси в монолите. Может, они бы и рады разбить его на микросервисы, но это ж отдельная боль.
PrinceKorwin
26.11.2022 19:33+3Мне кажется, что цифра в 10к микросервисах это включая все инстансы. Тогда она начинает выглядеть более реальной.
Asen Автор
26.11.2022 19:46+7"Раздутость" - это слишком общий термин. "В компании, поставляющей сложнейший софт для моделирования производственных процессов" может просто не быть такого же числа процессов и клиентов, которые есть у Twitter - от того и 1.5 тысячи сотрудников хватает с головой для поддержки деятельности на должном уровне. Иметь 1 процесс, требующий серьезных навыков программирования, не эквивалентно по числу микросервисов множеству процессов, не требующих серьезных навыков программирования.
excoder
26.11.2022 22:08+6На каждый город Земли по программисту? И это если предположить, что 8 миллиардов пользуются Твиттером :)
А что это, например, за менеджеры продукта в Твиттере? Ну какие там продукты? На каждый сдвиг пикселя по менеджеру? Была байка, что в Твиттере в день в среднем работают по 15 минут. Теперь уже не уверен, что это только байка.
denis-isaev
27.11.2022 01:08+1Продукту мало стать популярным, нужно еще им оставаться, для чего нужна работа с аудиторией, борьба с конкурентами, взаимодействия с регулирующими органами, социальные проекты и т.д.
chervital
27.11.2022 13:39Мы все ещё говорим про Ит-персонал? И про микросервисы?
mtskf
27.11.2022 18:42+2Для глобальных компаний задача соответствия законодательству всех стран в которых они работают очень сложна, и это зачастую выливается в сложные технические решения.
Для каких-то клиентов нельзя логировать какие-то данные. Для других в случае возникновения проблем с VOIP необходимо отправлять incident report правительственному органу. Третьи имеют право требовать удаление своих данных (а из некоторых систем вроде Hive в лоб сделать это нереально).
И таких проблем очень много, костыли в коде не масштабируются, приходится делать те самые "микросервисы" которые будут решать эти проблемы глобально. Невозможность даунтайма, легаси системы разработанные без учета подобного регулирования и другие проблемы типичные для больших компаний тоже добавляют проблем.
kazimir17
26.11.2022 21:30+2Это так работает да, меня в свое время поразило, что у простого сетевого магазина одежды Khols - ИТ отдел около 600 человек, это не считая кучи людей на аутсорсе.
DarthVictor
27.11.2022 00:03В компании, поставляющей в течение последних 40 лет сложнейший софт для моделирования производственных процессов, продуктами которых пользуются большинство крупных промышленных предприятий мира, с офисами по всему земному шару, чуть менее 1.5 тысячи сотрудников всего.
А у этих "большинства крупных промышленных предприятий мира" сколько ещё людей пользуется "сложнейшим софтом для моделирования производственных процессов", сколько человек работает с другим софтом и сколько и человек работает в IT-подразделении в целом?
Так то и у Твиттера непосредственно за отправку твитов отвечает процентов 10 всего IT подразделения.
ultraElephant
27.11.2022 07:27+7Производить или поставлять софт и осуществлять эксплуатацию геораспределённого продукта работащего 24/7/365 - это разные условия ведения бизнеса и требования к штату/инфраструктуре.
Предоставлять б2б решения и предоставлять публичный (геораспределённый работащий 24/7/365) сервис на 200+ миллионов клиентов - это, опять же, разные условия ведения бизнеса и требования к штату/инфраструктуре.
Посмотрите на операторов связи и их штат. У них условия ведения бизнеса похожие. В том же at&t 200000 людей без учёта подрядчиков.
excoder
27.11.2022 13:06-3Вы сравнили достаточно примитивный веб-сайт, пусть и высоконагруженный, с оператором связи? Не могу с таким сравнением согласиться.
ultraElephant
27.11.2022 13:18+5Что вы подразумеваете под "примитивный вебсайт"? Тут (на хабре) люди который раз покругу обсасывают как отмасштабировать е-комерс уровня магазинароматических масел под чёрную патницу, так что бы респонс был как обычно, а к конкурентам клиенты уйдут. А единого решения которое подошло всем бы по затратам и доступности реализации так до сих пор и нет.
А вы тут архитектуру сервиса до "примитивный вебсайт" низводите в котором 200кк+ активных клиентов (+ ещё столько же , а то и больше незарегестрированых зрителей, в том числе и через встраивание в другие веб сайты), видео/аудио бродкаст, постинг в куда большей степени что "сунуть в корзину", плюс ещё разная рекламная аналитика распределённая по регионам. Не надо так.
Там где кончается вертикальное масштабирование любое "примитивное" заканчивается тоже.
excoder
27.11.2022 19:06Интересно, а каким образом масштаб архитектуры кореллирует с количеством сотрудников? То есть, чтобы отмасштабировать поиск в 1000 раз, нужно в 50 раз больше человек? Я понимаю, например, такие сервисы как Gmail, AWS и т.д. Масштаб — такой же мировой, но функционала — море. Поэтому и понятен рост персонала.
А в Твиттере что же? Хорошая архитектура масштабирования не будет просить кратного роста сотрудников, а особенно программистов, это просто нелогично. А если взять функции, то в Твиттере их весьма немного и они годами не меняются. По сравнению с Gmail, Твиттер — это достаточно примитивный веб-сайт.
Уже не говорю о том, что в 2014 году, когда FB приобрёл WhatsApp, в последнем работало менее 50 человек. На тот же момент в Твиттере — 3,500 человек. А во всём Google — около 50'000. На этот же момент в Youtube было менее 3'000 человек, хотя видеоконтент по сервировке будет как-то посильнее коротких текстовых сообщений, при сохранении всех остальных вопросов (реклама, таргетирование и пр.). Как по мне, эти цифры не бьются.
excoder
27.11.2022 19:08-1Интересно, а каким образом масштаб архитектуры кореллирует с количеством сотрудников? То есть, чтобы отмасштабировать поиск в 1000 раз, нужно в 50 раз больше человек? Я понимаю, например, такие сервисы как Gmail, AWS и т.д. Масштаб — такой же мировой, но функционала — море. Поэтому и понятен рост персонала.
А в Твиттере что же? Хорошая архитектура масштабирования не будет просить кратного роста сотрудников, а особенно программистов, это просто нелогично. А если взять функции, то в Твиттере их весьма немного и они годами не меняются. По сравнению с Gmail, Твиттер — это достаточно примитивный веб-сайт.
Уже не говорю о том, что в 2014 году, когда FB приобрёл WhatsApp, в последнем работало менее 50 человек. На тот же момент в Твиттере — 3,500 человек. А во всём Google — около 50'000. На этот же момент в Youtube было менее 3'000 человек, хотя видеоконтент по сервировке будет как-то посильнее коротких текстовых сообщений, при сохранении всех остальных вопросов (реклама, таргетирование и пр.). Как по мне, эти цифры не бьются.
ultraElephant
27.11.2022 20:20+1Рост сотрудников не кратный, но так или иначе при возрастании объёмов будет рости и штат. Так же будут появляться новые команды, потому что твитер образца 2014 это не твитер образца 2006 и не whatsapp у которого на тот момент была только пересылка текстовыйх и аудио сообщений (на момент 2014го года у твиттера уже была своя рекламная сеть, система платежей в тестовом виде). Да, у WA рэйт сообщений был куда выше (55 миллиардов в день на момент 2015, когда у твитера 0.5 миллиардов твитов на момент 2014го), однако WA не было необходимости хранить все эти сообщения и показывать их буквально каждому желающему в интернете.
WA изначально хостился на облках, в основном AWS. Даже сейчас, спустя 8 лет покупкой фэйсбука, веерные аварии AWS отключают WA по разным регионам, твиттер хостился всегда на коло и своих ЦОДах, что сразу же накладывает требования на наличие своих длинных рук на местах, большего штата сетевиков, специалистов по закупу и ахошников разных мастей (предвидя вопрос "а чо они не в облаках тоже, а то ж сайт фонарный на кой ему свой цод" напомню, что твиттер выстрелил в 2006ом году, когда кругом был шаред хостинг и дорогущщие V/DPS, после, скорее всего, продолжали множить работующую схему, что бы (лол) не раздувать штат на переходный период он-прем/коло -> облако)
По поводу AWS. Сейчас конкретно в AWS по оценкам LinkedIn работает около 50к сотрудников (https://howigotjob.com/business-model/number-of-employees-at-aws/), но AWS часть большой компании, которая берёт на себя таки вещи как бух учёт, кадровое дело, (возможно) материально снабжение и многие другие вещи которые делают бизнес возможным, а труд работников комфортным. Твиттер же насчитывает(л) 10к со всеми этими ребятами благодаря которым на каждом рабочем месте появляются комфортные столы, новые компьютеры, а зарплата приходит вовремя и в срок.
themen2
27.11.2022 16:30-3Так сделай такой же, в чем проблема? Вы же вроде эксперт по сложнейшему промышленному софту.... Детский сад, ну
iu3564
27.11.2022 15:13+1а чего так анонимно о компании, название в студию, публика оценит и скажет сколько там лишних 40 лет собирали. Я склонен думать что в любом бизнесе важны продажи , а количество сотрудников , сложность архитектуры и софта до лампочки, сегодня уволили завтра наняли, софт переписали/улучшили/ухудшили, все это процесс и это нормально.
themen2
27.11.2022 16:27Что это за компания? Вы поставляете десктопный софт? Ну так копий Microsoft word тоже можно продать 100 миллиардов. Ворд же лезет в сеть и не создаёт нагрузку.
Ну е-мое, пора бы уже перестать путать теплое с мягким)
Stas911
28.11.2022 01:10Это вообще не показатель. Полно мелких контор, которые широко известны в своей области, но при этом обходятся еще более скромными командами в несколько десятков человек.
excoder
26.11.2022 18:25Вот например, как живётся сотрудникам другого известного гиганта: https://twitter.com/litcapital/status/1585006752046538753
DmitriiPisarenko
26.11.2022 19:04+6Вспоминается широко известный в узких кругах ролик про боль Галактуса (3 мин.).
barloc
26.11.2022 19:08Я может чего не понимаю, но вроде ты выбираешь на кого подписаться. Тогда в чем может быть проблема с твоей лентой новостей - откуда боты?
aelaa
26.11.2022 23:31+1Попробуйте иметь меньше 50 подписок - половина ленты будет заполнена прекрасным контентом, который Вам не хотелось бы видеть вообще никогда
mentin
27.11.2022 03:29У меня там заметно меньше 50. Есть много дополнительного контента, где-то треть которого мне интересна, две трети просто нейтральный мусор не вызывающий раздражения. А главное - количество дополнительного контента определяется тем как часто я хожу в Твиттер. Если пару раз в неделю, то ничего лишнего, только подписки, а если каждый час - то он начинает добавлять чтобы было что-то новое. Так что опять зависит от пользователя.
Ну и как Маск его купил, количество рекламы сильно увеличилось, и сам Маск стал регулярно появляться в ленте, чего раньше не замечалось.
BlackMokona
27.11.2022 09:41+1Ну и как Маск его купил, количество рекламы сильно увеличилось
А все в один голос кричат, что все рекламодатели разбежались
mentin
27.11.2022 09:56Эти два утверждения не противоречат друг другу :). Разбежались, реклама однообразная (и скорее всего дешёвая, раз конкуренции за место нет), но её много.
BlackMokona
27.11.2022 10:11Про удешевление рекламы Твиттера новостей тоже не видел
mentin
27.11.2022 10:26+1Мне встретился блог, компания как раз оставила в Твиттере рекламу потому что дёшево, политика их не интересует. Но когда перестал работать фильтр спама и хейта, их количество в комментариях зашкалило, жалобы в Твиттер не работали, а их account team оказался полностью сокращён - забили и тоже ушли.
BlackMokona
27.11.2022 10:43Количество хейта снизилось на 30% по сравнению со временем до Маска. И нет эти системы не сломались
mrguardian
26.11.2022 19:38На вопрос так и не ответили. В оригинальном твите было про 1000 микросервисов в приложении под андроид. Так вот, зачем андроид приложению, отображающему ленту твитов взятую с сервера 1000 микросервисов?
mentin
27.11.2022 03:43+5В твитте имелось в виду не 1000 микро-сервисов в приложении под Андроид, а что приложение якобы посылает 1200 RPC к 1000 микро-сервисам в датацентре Твиттера. Хотя 1200 RPC оказалось бредом, в чем мог убедиться любой вооруженный сетевым трейсером.
DinoZavr2
26.11.2022 20:09процесс борьбы с ботами (aka антиспам) - кто-то думает, что его нет, а он есть.
Был*. Его сегодня временно убрали для переустановки процессов из-за сбоя по большому количеству ботов, которые обошли систему. Вроде-бы поставят на место в течении часа.
Mikhail1972
26.11.2022 20:27я бы смотрел не на количество сервисов, а на количество их обновлений и целесообразность этих обновлений. вплоть до приостановки не критичных обновлений на переходный период.
myxo
26.11.2022 20:38+29статью, которую теперь можно использовать как аргумент в будущих спорах — почему простые, но популярные сервисы нуждаются в своих 1000 микросервисах.
Но ведь на вопрос вы так и не ответили. Вы просто привели кучу функций (некоторые из которых вообще не относятся к инфре сайта), которые выполняет компания. Да, твиттер не просто api для базы данных, но тут даже если на каждую приведенную функцию сделать с десяток микросервисов, все равно число будет отличаться на порядок.
Я твитерскую внутреннюю кухню, конечно, не знаю, но обычно бывает так, что сайт приносит много денег, набирают большое количество программистов, которые пишут на разных стеках и соответственно приходится делать микросервисы. Через несколько лет это становится неподдерживаемым, но деваться некуда, рефакторить сложно (половина сервисов уже потеряла хозяев и никто не знает как они работают), причем чем дольше оттягивается, тем сложнее. Появляются дубликаты сервисов, которые «написаны правильно, в отличие от той фигни». При этом от старых что-то зависит, поэтому «объявим deprecated, через пару месяцев (хаха) довыпилим». Приходит следующее поколение и «хм, вроде все так делают, чем мы хуже?».
Вот лично я уверен, что большинство сервисов там — никому не нужное легаси. Просто ни у кого не было достаточно ресурсов, чтобы основательно это почистить. За рефакторинг же KPI не растет
ps.можно отказаться от процесса «сбора логов и метрик» и полагаться на жалобы от пользователей в тех.поддержке
Я не сомневаюсь в ваших способностях по реверсу, но большой сайт вы явно не обслуживали. Метрики — это самое последнее что должно упасть. Пользователи могут страдать, но metrics must flow.
Samedi_Da_Kapa
26.11.2022 23:23А можно чуть больше деталей для тех кто в микросервисах не силен?
Всегда, когда заходит речь о микросервисах, я слышу определение из разряда "две недели разработки" или "не больше 10к строк кода". И для меня это если честно немного - даже если это без тестов. Но у нас тесты пишутся и поэтому я так прикидываю, чисто эмпирически 10к строк кода это примерно 5к строк тестов(у нас примерно такое соотношение - 1:1)
А 5к строк кода, если там не суперсложная логика и не минифицирован код, то это неделя на погружение и потом месяц переписать в одно лицо.
И вот тут у меня вопрос - в чем проблема поддерживать тогда микросервисы в нормальном состоянии? Или там уже не микросервисы?
BugM
26.11.2022 23:29+3Эта работа должна в фирме цениться. KPI, премии и вот это вот все. И на смежников должен быть способ надавить. Мол мы тут переписали по новому, пожалуйста за следующий квартал мигрируйте на новое. Совместимость со старым 97%, вот описание в каких местах она сломалась. Если не поможет обращайтесь поможем. 100% совместимости не бывает, все понятно.
Если ничего этого не было, то кто будет заниматься переписыванием? Зачем оно надо? Проще рядом новый кусок сделать. Это быстрее даст какую-то фичу в проде и премии всем участвующим.
Есть типовой способ обеспечить такое. Завести технарей повыше в вертикаль управления и распределения денег. И пусть они там с менеджерами договариваются о приоритетах и распределении плюшек среди разработчиков. Было это сделано в Твиттере или нет мне не известно.
circuitbreaker
26.11.2022 23:34Проблема не поддерживать, проблема развивать. Если попытаться формализовать проблему на пальцах, то маркетинг (развитие продукта, владельцы бюджета, заказчики фич) регулярно валят новые маркетинговые запросы на доработку продукта. В режиме нон-стоп продакт овнеры и продакт архитекты разбирают эти запросы и растаскивают по своим продуктам или закрепленными за ними компонентами. За компонентами закреплено по несколько команд и продакт овнер раскидывает по ним фичи, внедрение которых может включать доработку уже существующих сервисов или создание новых.
В код постоянно вносятся изменения и растет-копится технический долг. Это черная дыра технических доделок, которые невозможно продать заказчику, которые или невозможно было предусмотреть заранее или это ожидаемый этап развития, когда надо сменить архитектуру итп. Кодеры кранчат на этот техдолг, в итоге нездоровая история, которую если не контролировать, то она может порвать продукт в кашу.
myxo
27.11.2022 00:24-2Все по своему понимают что такое микросервис, числа могут сильно разнится. Например если мы хотим уменьшить их число вдвое, взяв ваши числа нужно (5 недель * 500) / 48 ~= 52 человекогода. Не каждый менеджер сможет доказать необходимость такой работы.
Нетфликс, кстати, в свое время оказались в подобной ситуации, но они все-таки сели все переписывать и в течении года у них практически никаких фичей не выходилоSamedi_Da_Kapa
27.11.2022 01:18+3Абстрактно - да, 52 человекогода это очень много. Но чисто если взять в рамках твиттера - это мало.
Предположим, что у нас есть 500 программистов моего уровня. Предположим, что неделя работы такого программиста обходится фирме в 3000$ со всеми сопутствующими расходами - офис, налоги, зарплата, зарплата саппорт персонала.
5 недель * 3000$ * 500 = 7 500 000$
Даже если я ошибся на порядок в своей оценке, то выглядит как будто эти 52 человекогода стоят 75 миллионов. На фоне всей сделки выглядят не очень большой суммой.
В итоге: актуальный код, полное погружение в текущее состояние и фичефриз всего на полтора месяца. Что будет выглядеть логично после сделки.
dph
27.11.2022 03:41+7В микросервисных продуктах сложность продукта уходит из самих сервисов в их взаимодействие. Но так как за то, что "между сервисами" никто обычно не отвечает, то и продукт очень быстро начинает портится. Чем больше сервисов - тем, обычно, быстрее.
DrGluck07
27.11.2022 11:28+2Идеальный пост выглядел бы так:
Почему Твиттеру нужны 1000 микросервисов?
Никто не знает.
pyrk2142
26.11.2022 22:18+60ИМХО, все может быть гораздо проще: бывает тупо выгодно плодить огромное количество проектов и создавать гору бесполезных сервисов просто потому, что под это можно создать команду, а потом и группу команд, чтобы стать уже довольно влиятельным менеджером. Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное, а потом уже проще: ты владелец 10 сервисов, на которые что-то завязано, ставь сам себе цели, сам их достигай, завязывай на свои сервисы больше систем, в итоге станешь почти незаменимым руководителем серьезного проекта, которого сможет выгнать только очень жесткий менеджер. Нанимаешь таких же программистов, ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все, вы выглядите успешнее, чем большая часть разработчиков и менеджеров компании, которые таким не занимаются. Высший пилотаж - завязать кучу неважных сервисов друг на друга так, чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития. Так и появляются команды, увольнения которых никто не заметил, и горящие за свой проект разработчики, у которых он за 6 лет почему-то начинает тормозить все сильнее и сильнее.
yellow-elephant
26.11.2022 22:39+6Очень годный комментарий, лучше самой статьи.
circuitbreaker
26.11.2022 23:17-3Специфический комментарий, описывает ситуацию, применимую больше к НКО или госкомпании. В коммерческих компаниях инициатором развития своего продукта является маркетинг, никаких проектов там нет, Твиттер, это продуктовая компания. Появлению сервиса предшествуют корпоративные хороводы десятков разноуровневых, иногда конфликтующих между собой, иногда джуниоров, иногда спецов, маркетинг->бизнес аналитики->солюшен архитекторы продакт овнеры и девелоперы с тестерами все участвуют в обсуждении необходимости новой фичи, это дает понимание команде, как её лучше внедрить, тестерам - на чем расставлять акценты при тестировании итд. Это ещё надо очень постараться найти бюджет, набрать и удержать такую толпу балбесов, чтобы развивать десять никому не нужных сервисов.
Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное
У заказчика новых продуктовых фич, которые могут породить новые сервисы, этот процесс формализован. NPV, IRR, ROI всё это считается в бизнес-кейсе развития продукта. Если сильно упростить: коммерческая компания не может себе позволить развивать ненужные сервисы и скрыть растраты бюджета на это не выйдет. Ненужный сервис тебе просто зарубят прямо на всяких кикоффах и питчингах, так как ты не сможешь сказать, сколько бабла ты инвесторам сделаешь на нем, как это рассказывает маркетинг. А если расскажешь - тебе прийдется это бабло из фичи (и порожденных нею новых сервисов) высосать к концу отчетного периода. Без маркетинговой потребности в развитии продукта новый сервис создать не выйдет по одной простой причине: деньги никто не даст.
ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все
и выглядите успешнее, чем
которые таким не занимаются
Эээ, ну откровенный глум же. Все ставят планы которые подходят руководству, и этот мифический менеджер-пройдоха тоже отчитывается своему руководству за деньги деньгами, за расходы доходами, ну. Причем тут премии, которые все получают согласно колдоговору или индивидуальному договору (для топов), а также выступления на непонятных мероприятиях - неясно.
чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития
Какой-то зашоренный критерий важности. Есть совершенно разные процессы, не все из них внутри твиттера являются хайлоад, у многих разный профиль трафика, есть наверняка и пару запросов в сутки которые обслуживают, тем не менее, важные. И могут быть простыми, не требующими квалификации. Но они должны составлять легитимный, используемый заказчиком в своих экономически измеряемых бизнес-процессах компонент продукта.
Так и появляются команды, увольнения которых никто не заметил.
Какая-то Нарния, если честно. Команда разработчиков, это мягко говоря недешёвое удовольствие, которое очень влетает в копеечку уже в первый месяц их работы и рекуррентно влетает в ту же копеечку каждый последующий месяц, с необходимостью её периодического (пусть и раз в год-два) повышения..
kazimir17
26.11.2022 23:40+21Прочитав ваш комментарий может сложиться впечатление, что любая коммерческая компания работает как некий абсолютно рациональный коллективный разум который в своих решениях опирается исключительно на факты и метрики, однако в реальности так никогда не бывает: метрики могут представить в нужном ключе, может сказаться фактор личных связей в руководстве, нормально выкинуть несколько миллионов денег и лет на проект просто потому что кому-то что-то показалось, и т.п. Я работал во множестве компаний как зарубежных так и российских и по опыту могу сказать что большинство принимаемых решений иррациональны, просто такова природа людей.
circuitbreaker
27.11.2022 00:09+3коллективный разум который в своих решениях опирается исключительно на факты и метрики, однако в реальности так никогда не бывает: метрики могут представить в нужном ключе
Мы наверное о каких-то разных метриках говорим, давайте сразу уточним. Есть метрики, собираемые с самих микросервисов, есть аггрегированные метрики, собираемые с бизнес-процессов, в которых участвуют эти самые микросервисы, есть аггрегации бизнес-процессов в более высокоуровневые вплоть до совета директоров (для взаимодействия с ними уже тоже есть специальные микросервисы, как бы смешно это ни звучало) и на определенных уровнях эти метрики превращаются в деньги, а в другой колоночке стоят планы. Как только планы проседают - начинается декомпозиция этих метрик вплоть до конкретных бизнес-процессов или задействованных в них компонентах ПО/микросервисах, которые всю малину держателям бюджета портят.
нормально выкинуть несколько миллионов денег и лет на проект
В компаниях, оперирующих определёнными порядками бюджетов выкинуть несколько миллионов денег и лет на невыстреливший R&D это не "нормально", а "ппц, как легко отделались".
просто потому что кому-то что-то показалось
Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
На разных этапах развития продукта бизнес-кейс считается в разных приближениях. После первого года продакшена бизнес-кейс становится наиболее точным, однако взлетит/не взлетит однозначно видно уже после первых пары апдейтов (раз в три месяца). Он может перестать сходиться сразу после запуска, тогда фичу вырезают или проект закрывают.
"просто кому-то что-то показалось" - если в бизнесе допускается такое принятие решений, бизнес долго не просуществует.
по опыту могу сказать что большинство принимаемых решений иррациональны
Я работаю в телекоме с 2001, в мобильном с 2008, сейчас в разработке managed kubernetes продукта для телеком операторов. По опыту, могу сказать что в подавляющем большинстве случаев, когда мне казалось, что кто-то принял иррациональное решение, в результате оказывалось, что я не владел достаточным объемом информации и/или опыта, и/или принятых обязательств, которые имелись в момент принятия решения у принимающего.
kazimir17
27.11.2022 00:27+7Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
И тем не менее в данный момент мы наблюдаем ситуацию когда из Твиттера уволили значительное количество специалистов под которых ранее были выделены бюджеты. А значит либо их наняли под влиянием иррациональных решений (или по злому умыслу) и это прекрасно прошло 100500 кругов согласований или же в данный момент их уволили иррациональным решением и это тоже прошло все согласования.
circuitbreaker
27.11.2022 03:10+2либо их наняли под влиянием иррациональных решений (или по злому умыслу)
или же в данный момент их уволили иррациональным решением
Это ложная дихотомия. На самом деле, ничего нерационального скорее всего нет ни в первом, ни во втором решениях - оба эти действия совершены радикально на разных этапах становления Твиттера и принимались с учётом совершенно разных вводных.
Смею предположить, что перед поднятием ставки ФРС Маск не угадал с кредитами, попытался соскочить, когда понял, как сильно рентабельность этого кредита понизится, но не вышло. На мой скромный взгляд, Маск перешёл к простому плану Пи (или Пэ) - людоедское урезание костов по всем возможным направлениям, децимация сервисов и персонала, печенек и work/life баланса, чтобы выдоить из неудачной покупки побыстрее максимум. О удалении ненужного речь идёт только в контексте "под нож всё то, что из нужного у нас ненужнее всего".
При всём этом, проблема рефакторинга процесса взаимодействия приложения из-за кучи (фигурально выражаясь "тысяч и тысяч") RPC запросов, может даже к одному и тому же микросервису, возможно таки и стоит и решать её возможно действительно надо. Решением может быть даже переработка архитектуры ресурсов с rpc на rest и тогда не понадобится ловить колбеки rpc. Количество запросов станет не "тысяча", а "сотни", допустим, но это не камень преткновения настолько серъёзный, чтобы СЕО лез и пытался его разрешить. СЕО должен иметь команду, в которой есть другие люди, которые этим непублично займутся без него. Вся эта публичная возня конкретно с архитектурой и кодом больше похожа на классический маскопиар.
BugM
27.11.2022 03:12+3Невозможно выдоить 40 миллиардов из Твиттера за сколь либо разумный срок. Маск это отлично понимает. Не подходит.
dph
27.11.2022 03:45+3Да ладно, сплошь и рядом в крупных телекомах делали и делают полную фигню, несмотря на все комитеты. Собственно, в телекомах бардак еще больший, чем в банках и куда больший, чем в средних продуктовых компаниях (где, кстати, тоже крайне редко считают ROI для проектов, там вообще чуть-чуть другой подход к развитию).
vkni
27.11.2022 00:10+1большинство принимаемых решений иррациональны
Они не иррациональны, а очень даже разумны. См коммент на два уровня выше. Просто не надо воспринимать контору как единый субъект, тогда не получится следствия "люди — идиоты".
Вообще, кмк, в социологии результат "люди = идиоты" должен немедленно вести к отбраковке модели. Это вернейший признак того, что что-то не учтено.kazimir17
27.11.2022 00:31+4Люди не идиоты, но они всегда принимают решения в условиях ограниченности/ложности информации, на основании своего уникального и не релевантного прошлого опыта и под воздействием других таких же людей. Просто потому, что иначе никак: информация всегда неполна, опыт у каждого свой, есть фактор личных отношений.
circuitbreaker
27.11.2022 03:24-1Всё же
в условиях ограниченности/ложности информации, на основании своего уникального и не релевантного прошлого опыта и под воздействием других таких же людей
Решения можно принимать не только иррационально, но и рационально. Чем больше бизнес принимает иррациональных решений, тем короче и беднее живёт.
vkni
27.11.2022 17:24Основной пойнт тут в том, что интересы конторы и человека из конторы, как правило, сильно отличаются. Например, у рядового Васи конечный интерес — устать меньше, потратить времени меньше, получить максимальное вознаграждение.
dph
27.11.2022 03:46Люди не идиоты, но обычно принимают решение вне зоны своей компетентности.
vkni
27.11.2022 17:21+2Это "рациональное решение в условиях недостатка информации". При этом очень важно понимать, что интересы конторы целиком и интересы конкретного человека скорее всего очень сильно отличаются.
aaa_bbb
28.11.2022 08:25Не надо забывать, что Твиттер торгуемая на бирже компания. И для биржевых инвесторов могут быть важны совсем другие метрики и методы их раздувания. Далек от фундаментального анализа компаний, но возможно стабильно растущий штат или инфраструктура как раз способ раздуть эти "инвесторские" метрики
kazimir17
26.11.2022 23:10Именно, только я уверен это почти всегда происходит не по злому умыслу, а просто как результат борьбы со сложностью через нарезку маленьких сервисов и размывания экспертизы по разным командам.
acordell
27.11.2022 14:30+1О... да! Все так и есть! В пресловутом зеленом банке таких псевдоэффективных людей больше половины. Как две вселенные прямо. Одни "криворукие дебилы" стоящие за спинами у людей на конвейере и держащие на своем здоровье реальные процессы, а другие "божественные созидатели", что переманили за 500 грейд к себе цвет очередного разорившегося юникорна и творящие какой-нибудь AI по анализу рыночных трендов, турбулентного движения денежных масс и эффективности сотрудников.
Редко-редко, но случается, когда "небожителя" со свитой сажают-таки на боевой участок, со словами "ну вот, дебилы, сейчас ОНИ тут все поправят, и всех вас научат", но, после годика абсолютно бестолковых исследований и совещаний, вся эта когорта стройными рядами уходит в какой-нибудь синий банк, со словами "ах, наши таланты тут совсем не были востребованы", после чего "дебилы" возвращаются ровно к той же точке явления к ним чуда с небес.
circuitbreaker
26.11.2022 22:44+2Может я конечно сильно поверхностно вник в этот оверхайп, поэтому прошу тряпками по лицу не бить, но впервые вник в картинку и понял, что тут путаница. На первый взгляд прищуренным глазом кор архитектура указана вплоть до сервисов и там их, не вникая в подсчёты, изображено порядка 30-40. Предположим, вокруг кор архитектуры есть еще 15-20 значимых компонентов пусть по 15 сервисов каждый максимум (это вряд ли, но твиттер дядя большой), это примерно 350 микросервисов максимум. Ну и может есть какой-то фреймворк общих компонентов, где пилятся базовые версии допустим половины из этих 350 - всего пусть будет ну 600 от силы, 200 из которых существуют только в дев-песочнице. Вывод: если там где-то и есть 1000 микросервисов, то это видать обгрызки недомиграции с какого-то легаси, которые надо догрызать-домигрировать дабы избежать сосуществования старой и новой версии одного и того же сервиса.
Но вроде как в оригинале речь шла про 1000 RPC calls from app to backend, а не про 1000 microservices. Это уже совсем другого плана проблема, хотя и тоже архитектурная. Переписывание приложения может решить эту проблему, если она действительно существует и не лежит концептуально в корне этой core архитектуры на 30-40 микросервисов.
Fen1kz
27.11.2022 01:58-1Я тоже не особо слежу, но ваш комментарий заставил меня понять, что фразы "1000 микросервисов"-то и не было, а соответственно все комменты сейчас спорят ни о чем =( Зря читал, получается.
Про "1000 RPC calls from app to backend" его уже опровергли, что запрос выполняется один
Diamos
27.11.2022 06:05+12«Без 1000 микросервисов никак» — говорили они.
«Вы не понимаете, это другое» — говорили они.
Я просто процитирую ex-главного инженера SpaceX Томаса Мюллера, создателя серии ракетных двигателей Merlin, давшего интереснейшее интервью:Один из наших подписчиков спрашивает: «Каково это работать с Илоном Маском? Какой он начальник и как он выходит из офиса?»Представьте себе, группа людей сидит в комнате, все ищут решение определённой задачи. И все говорят (образно): «Нам надо налево». А Илон скажет: «Нет, нам надо направо». Вот так он мыслит. Он говорит: «Ребята вы выбираете лёгкий путь, а нам нужен трудный путь».
Да, я видел как нас это ранило раньше, как у нас от этого «подгорало», но я также помню, что даже когда работа велась вопреки всеобщему недоверию, результат оправдывал ожидания Илона. Этот способ был более трудным, но в конце, становилось понятно, что он и был правильным решением. Одной из таких вещей был двигатель Merlin 1D. Илон был недоволен ценой, ранее я говорил, каким дорогим двигателем он получался. [Я сказал,] «Единственный способ достичь этого – избавиться от всех этих вентилей. Потому что из-за них двигатель получается очень сложным и дорогим». И как это можно сделать? И я сказал: «Ну, в маленьких двигателях мы бы использовали форсунку с встроенным отсечным клапаном, но никто не делал этого в больших двигателях. Это очень сложно». А он в ответ: «Значит мы должны использовать форсунку с встроенным отсечным клапаном. Объясни как это работает». Я сделал несколько эскизов, и он заявил: «Вот то, что нам нужно, вот что мы должны сделать». И я посоветовал ему отказаться от этого. Я сказал, что это будет слишком сложно, это не поможет снизить стоимость до требуемого уровня. Но он твёрдо принял решение сделать форсунку с встроенным отсечным клапаном. Так что мы взяли и разработали этот двигатель. И это было сложно. Мы взорвали много оборудования. И мы пробовали сотни различных комбинаций, чтобы заставить его работать, но мы сделали так, чтобы всё заработало. У меня всё ещё есть тот начальный эскиз, который я делал. Это было пугающим для меня, понимание того, как это работает! Но использовав форсунку с встроенным отсечным клапаном, мы отказались от главных вентилей: проще говоря, вы вращаете насосы и давление растёт, под давлением открываются топливные форсунки, позволяя выйти кислороду первым, а затем выходит горючее. Всё, что вам нужно, это «поджигающая» смесь. И если она у вас есть, она запустит реакцию. И это не будет тяжёлым стартом. Это избавило нас от проблемы, когда мы использовали два вентиля: вентиль кислорода очень холодный и очень тугой, он не хочет двигаться. А это тот самый вентиль, который нужно открыть первым. И если вы стравливаете топливо – это называется тяжёлым стартом. У нас есть старая поговорка: «когда вы запускаете ракетный двигатель, запуск может пойти по тысяче сценариев и только один из них правильный». И если последовательность действий проходит по правильному сценарию, то вы избавляетесь от 900 неправильных сценариев. Мы сделали этот двигатель очень надёжным, снизили массу и стоимость. И всё это благодаря правильному подходу.
Теперь у нас есть самый дешёвый, самый надёжный двигатель в мире. Это один из примеров того, как ведёт себя Илон – он всегда говорит, что мы должны стремиться к физическим пределам.
Для тех, кому лень читать простыню:Фома НеверующийТомас Мюллер (с командой таких же неверующих Фом) по принуждению Маска занялся снижением стоимости производства двигателя Merlin и для достижения этой цели был вынужден отказаться от традиционного подхода, применив никем доселе не используемое в двигателе такого размера инженерное решение. «Теперь у нас есть самый дешёвый, самый надёжный двигатель в мире».
Др. словами, они существенно упростили двигатель, что привело к снижению себестоимости и повышению надежности. Тоже самое сейчас происходит и с двигателем Raptor. Подобный подход Маск применяет везде: ракеты летают «на линуксе», без дорогущей радиационно стойкой электроники, садятся на баржи, двигатели не коксуются от сжигания керосина при многократном использовании, крыльчатки турбонасосного агрегата не растрескиваются и не разрушают двигатель (что им пророчили специалисти NASA), 27 двигателей Falcon Heavy не входят в резонанс и не разрушают ракету и т.д. и т.п. Довольно наивно надеяться, что именно с Твиттером Маск облажается и всё перестанет нормально работать, учитывая то, что производство и запуск ракет и космических аппаратов, разработка к ним ПО и электроники — на порядок более сложная инженерная задача, чем написание и поддержка Твиттера.
DikSoft
27.11.2022 08:53+2Если следовать этой логике, то тут напрашивается предложение от Маска: "а нафига вы тут наупрощали с кучей микросервисов, связи между которыми стали фактически неуправляемыми и тащат нас вниз? Делайте сложнее, но надёжнее!"
Было бы интересно посмотреть на такой сценарий.
BlackMokona
27.11.2022 09:50+1Сложнее не результат, сложнее сама разработка. Т.е мы потратили в 10 раз больше трудочасов на разработку кода, но он работает намного эффективнее, чем код который получается обычным методом.
rtemchenko
27.11.2022 10:54+2Ключевой момент - целенаправленно инвестировать в исследование этих сложных путей.
В разработке софта в целом, и Калифорнийском Биг Теке в частности, царит культура "выкатить побыстрее, пофиг как". Даже фундаментальные инвестиции разбазариваются на создание очередного стильного модного фреимворка, который медленнее предыдущих.
DikSoft
27.11.2022 11:49Так именно поэтому и интересно. Может и мифов про суперсилу микросервисов для всего и везде станет поменьше.
alixa
27.11.2022 11:24Разрабатывал одну CRM для застройщика, в ней было очень много фич, клиент на vb6, логика в MS-SQL на T-SQL, также были сервисы на c# (api и интеграции), отчетность Reporting Services и Olap. В ней было все (Портал, СЭД, CRM и т.д.) система поддерживалась двумя сотрудниками. Недавно поработал у большого застройщика, функций было чуть больше (еще стройка немного была захвачена), зато было огромное количество продуктов и технологий, под сотню ИТ специалистов.
Все руководители вечно жаловались, что им не хватает ИТ специалистов и постоянно расширяли штат, система при этом становилась все хуже и хуже.
Tim_23
27.11.2022 14:34+1процесс цензурирования - мало кто хочет видеть непристойный контент в своей ленте, иначе разбегутся
Кроме политического цензурирования в последние года 2-3 я лично ничего не видел. А вот непристойный контент там присутствует. Причем как чисто словесный, так и картиночный(и видео), и никто его не цензурирует. Если с этим не справлялись 10000 человек, то вообще непонятно чем они занимались.
К примеру в инстаграме подобного вида контент , даже мат блокируется эффективно.
solneniukot
28.11.2022 08:25Было бы интересно сравнить команду Твиттера с другими командами, да например с тем же Телеграммом.
Enfriz
28.11.2022 15:25процесс управления тестированием и качеством (QA) - чтобы ежедневно не терять пользователей из-за низкого качества своего продукта
Не работает, видимо :)
sena
.
OlegTar
Очень емко, но информативно!