Comments 83
.
В компании, поставляющей в течение последних 40 лет сложнейший софт для моделирования производственных процессов, продуктами которых пользуются большинство крупных промышленных предприятий мира, с офисами по всему земному шару, чуть менее 1.5 тысячи сотрудников всего. В Твиттере до увольнений, сколько там? К 10'000 было? Полагаю, развесистая сеть микросервисов просто отражает раздутость компании, где наверняка многие, скажем так, не очень много работают, и прикрываются ненужной сложностью, созданной для того, чтобы их должности были нужны.
В первом случае экономика реальная - завязанная на физическое производство, во втором виртуальная, на вертолетных деньгах. И мерило успешности у виртуальных компаний из разряда "у нас работает 10 000 человек, а у нас 100 000", или у нас 1000 микросервисов в 10 000 контейнерах.
Гм. У них мерило успешности - число подписчиков. Большинство крупных промышленных предприятий мира и близко не догоняет количеством миллионы подписчиков Твиттера и подобных. Т.е., у этой компании с 40-летним стажем заказчиков несопоставимо меньше.
Т.е., возможно, сложность ПО у компаний, делающих сложнейший софт для моделирования производственных процессов, другая.
Опять же, если они чем-то заняты уже 40 лет, у них килотонна легаси в монолите. Может, они бы и рады разбить его на микросервисы, но это ж отдельная боль.
Мне кажется, что цифра в 10к микросервисах это включая все инстансы. Тогда она начинает выглядеть более реальной.
Вы просто не видели внутреннюю кухню больших компаний : )
твиттер в 17м году репортил "hundreds of thousands of servers". т.е. можно закладываться на миллионы инстансов.
"Раздутость" - это слишком общий термин. "В компании, поставляющей сложнейший софт для моделирования производственных процессов" может просто не быть такого же числа процессов и клиентов, которые есть у Twitter - от того и 1.5 тысячи сотрудников хватает с головой для поддержки деятельности на должном уровне. Иметь 1 процесс, требующий серьезных навыков программирования, не эквивалентно по числу микросервисов множеству процессов, не требующих серьезных навыков программирования.
На каждый город Земли по программисту? И это если предположить, что 8 миллиардов пользуются Твиттером :)
А что это, например, за менеджеры продукта в Твиттере? Ну какие там продукты? На каждый сдвиг пикселя по менеджеру? Была байка, что в Твиттере в день в среднем работают по 15 минут. Теперь уже не уверен, что это только байка.
Продукту мало стать популярным, нужно еще им оставаться, для чего нужна работа с аудиторией, борьба с конкурентами, взаимодействия с регулирующими органами, социальные проекты и т.д.
Мы все ещё говорим про Ит-персонал? И про микросервисы?
Для глобальных компаний задача соответствия законодательству всех стран в которых они работают очень сложна, и это зачастую выливается в сложные технические решения.
Для каких-то клиентов нельзя логировать какие-то данные. Для других в случае возникновения проблем с VOIP необходимо отправлять incident report правительственному органу. Третьи имеют право требовать удаление своих данных (а из некоторых систем вроде Hive в лоб сделать это нереально).
И таких проблем очень много, костыли в коде не масштабируются, приходится делать те самые "микросервисы" которые будут решать эти проблемы глобально. Невозможность даунтайма, легаси системы разработанные без учета подобного регулирования и другие проблемы типичные для больших компаний тоже добавляют проблем.
Это так работает да, меня в свое время поразило, что у простого сетевого магазина одежды Khols - ИТ отдел около 600 человек, это не считая кучи людей на аутсорсе.
В компании, поставляющей в течение последних 40 лет сложнейший софт для моделирования производственных процессов, продуктами которых пользуются большинство крупных промышленных предприятий мира, с офисами по всему земному шару, чуть менее 1.5 тысячи сотрудников всего.
А у этих "большинства крупных промышленных предприятий мира" сколько ещё людей пользуется "сложнейшим софтом для моделирования производственных процессов", сколько человек работает с другим софтом и сколько и человек работает в IT-подразделении в целом?
Так то и у Твиттера непосредственно за отправку твитов отвечает процентов 10 всего IT подразделения.
Производить или поставлять софт и осуществлять эксплуатацию геораспределённого продукта работащего 24/7/365 - это разные условия ведения бизнеса и требования к штату/инфраструктуре.
Предоставлять б2б решения и предоставлять публичный (геораспределённый работащий 24/7/365) сервис на 200+ миллионов клиентов - это, опять же, разные условия ведения бизнеса и требования к штату/инфраструктуре.
Посмотрите на операторов связи и их штат. У них условия ведения бизнеса похожие. В том же at&t 200000 людей без учёта подрядчиков.
Вы сравнили достаточно примитивный веб-сайт, пусть и высоконагруженный, с оператором связи? Не могу с таким сравнением согласиться.
Что вы подразумеваете под "примитивный вебсайт"? Тут (на хабре) люди который раз покругу обсасывают как отмасштабировать е-комерс уровня магазинароматических масел под чёрную патницу, так что бы респонс был как обычно, а к конкурентам клиенты уйдут. А единого решения которое подошло всем бы по затратам и доступности реализации так до сих пор и нет.
А вы тут архитектуру сервиса до "примитивный вебсайт" низводите в котором 200кк+ активных клиентов (+ ещё столько же , а то и больше незарегестрированых зрителей, в том числе и через встраивание в другие веб сайты), видео/аудио бродкаст, постинг в куда большей степени что "сунуть в корзину", плюс ещё разная рекламная аналитика распределённая по регионам. Не надо так.
Там где кончается вертикальное масштабирование любое "примитивное" заканчивается тоже.
Интересно, а каким образом масштаб архитектуры кореллирует с количеством сотрудников? То есть, чтобы отмасштабировать поиск в 1000 раз, нужно в 50 раз больше человек? Я понимаю, например, такие сервисы как Gmail, AWS и т.д. Масштаб — такой же мировой, но функционала — море. Поэтому и понятен рост персонала.
А в Твиттере что же? Хорошая архитектура масштабирования не будет просить кратного роста сотрудников, а особенно программистов, это просто нелогично. А если взять функции, то в Твиттере их весьма немного и они годами не меняются. По сравнению с Gmail, Твиттер — это достаточно примитивный веб-сайт.
Уже не говорю о том, что в 2014 году, когда FB приобрёл WhatsApp, в последнем работало менее 50 человек. На тот же момент в Твиттере — 3,500 человек. А во всём Google — около 50'000. На этот же момент в Youtube было менее 3'000 человек, хотя видеоконтент по сервировке будет как-то посильнее коротких текстовых сообщений, при сохранении всех остальных вопросов (реклама, таргетирование и пр.). Как по мне, эти цифры не бьются.
Интересно, а каким образом масштаб архитектуры кореллирует с количеством сотрудников? То есть, чтобы отмасштабировать поиск в 1000 раз, нужно в 50 раз больше человек? Я понимаю, например, такие сервисы как Gmail, AWS и т.д. Масштаб — такой же мировой, но функционала — море. Поэтому и понятен рост персонала.
А в Твиттере что же? Хорошая архитектура масштабирования не будет просить кратного роста сотрудников, а особенно программистов, это просто нелогично. А если взять функции, то в Твиттере их весьма немного и они годами не меняются. По сравнению с Gmail, Твиттер — это достаточно примитивный веб-сайт.
Уже не говорю о том, что в 2014 году, когда FB приобрёл WhatsApp, в последнем работало менее 50 человек. На тот же момент в Твиттере — 3,500 человек. А во всём Google — около 50'000. На этот же момент в Youtube было менее 3'000 человек, хотя видеоконтент по сервировке будет как-то посильнее коротких текстовых сообщений, при сохранении всех остальных вопросов (реклама, таргетирование и пр.). Как по мне, эти цифры не бьются.
Рост сотрудников не кратный, но так или иначе при возрастании объёмов будет рости и штат. Так же будут появляться новые команды, потому что твитер образца 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к со всеми этими ребятами благодаря которым на каждом рабочем месте появляются комфортные столы, новые компьютеры, а зарплата приходит вовремя и в срок.
Так сделай такой же, в чем проблема? Вы же вроде эксперт по сложнейшему промышленному софту.... Детский сад, ну
а чего так анонимно о компании, название в студию, публика оценит и скажет сколько там лишних 40 лет собирали. Я склонен думать что в любом бизнесе важны продажи , а количество сотрудников , сложность архитектуры и софта до лампочки, сегодня уволили завтра наняли, софт переписали/улучшили/ухудшили, все это процесс и это нормально.
Что это за компания? Вы поставляете десктопный софт? Ну так копий Microsoft word тоже можно продать 100 миллиардов. Ворд же лезет в сеть и не создаёт нагрузку.
Ну е-мое, пора бы уже перестать путать теплое с мягким)
Это вообще не показатель. Полно мелких контор, которые широко известны в своей области, но при этом обходятся еще более скромными командами в несколько десятков человек.
развесистая сеть микросервисов просто отражает раздутость компании
Вот например, как живётся сотрудникам другого известного гиганта: https://twitter.com/litcapital/status/1585006752046538753
Я может чего не понимаю, но вроде ты выбираешь на кого подписаться. Тогда в чем может быть проблема с твоей лентой новостей - откуда боты?
Например, если смотреть новости по хештегу.
Попробуйте иметь меньше 50 подписок - половина ленты будет заполнена прекрасным контентом, который Вам не хотелось бы видеть вообще никогда
У меня там заметно меньше 50. Есть много дополнительного контента, где-то треть которого мне интересна, две трети просто нейтральный мусор не вызывающий раздражения. А главное - количество дополнительного контента определяется тем как часто я хожу в Твиттер. Если пару раз в неделю, то ничего лишнего, только подписки, а если каждый час - то он начинает добавлять чтобы было что-то новое. Так что опять зависит от пользователя.
Ну и как Маск его купил, количество рекламы сильно увеличилось, и сам Маск стал регулярно появляться в ленте, чего раньше не замечалось.
Ну и как Маск его купил, количество рекламы сильно увеличилось
А все в один голос кричат, что все рекламодатели разбежались
Эти два утверждения не противоречат друг другу :). Разбежались, реклама однообразная (и скорее всего дешёвая, раз конкуренции за место нет), но её много.
Про удешевление рекламы Твиттера новостей тоже не видел
Мне встретился блог, компания как раз оставила в Твиттере рекламу потому что дёшево, политика их не интересует. Но когда перестал работать фильтр спама и хейта, их количество в комментариях зашкалило, жалобы в Твиттер не работали, а их account team оказался полностью сокращён - забили и тоже ушли.
Ну вот и на Хабре новость. Как бы законы рынка Маск пока не отменил
https://habr.com/ru/news/t/703602/
На вопрос так и не ответили. В оригинальном твите было про 1000 микросервисов в приложении под андроид. Так вот, зачем андроид приложению, отображающему ленту твитов взятую с сервера 1000 микросервисов?
похоже за тем же, зачем фейсбуку 100000 методов в приложении для андроида
В твитте имелось в виду не 1000 микро-сервисов в приложении под Андроид, а что приложение якобы посылает 1200 RPC к 1000 микро-сервисам в датацентре Твиттера. Хотя 1200 RPC оказалось бредом, в чем мог убедиться любой вооруженный сетевым трейсером.
процесс борьбы с ботами (aka антиспам) - кто-то думает, что его нет, а он есть.
Был*. Его сегодня временно убрали для переустановки процессов из-за сбоя по большому количеству ботов, которые обошли систему. Вроде-бы поставят на место в течении часа.
статью, которую теперь можно использовать как аргумент в будущих спорах — почему простые, но популярные сервисы нуждаются в своих 1000 микросервисах.Но ведь на вопрос вы так и не ответили. Вы просто привели кучу функций (некоторые из которых вообще не относятся к инфре сайта), которые выполняет компания. Да, твиттер не просто api для базы данных, но тут даже если на каждую приведенную функцию сделать с десяток микросервисов, все равно число будет отличаться на порядок.
Я твитерскую внутреннюю кухню, конечно, не знаю, но обычно бывает так, что сайт приносит много денег, набирают большое количество программистов, которые пишут на разных стеках и соответственно приходится делать микросервисы. Через несколько лет это становится неподдерживаемым, но деваться некуда, рефакторить сложно (половина сервисов уже потеряла хозяев и никто не знает как они работают), причем чем дольше оттягивается, тем сложнее. Появляются дубликаты сервисов, которые «написаны правильно, в отличие от той фигни». При этом от старых что-то зависит, поэтому «объявим deprecated, через пару месяцев (хаха) довыпилим». Приходит следующее поколение и «хм, вроде все так делают, чем мы хуже?».
Вот лично я уверен, что большинство сервисов там — никому не нужное легаси. Просто ни у кого не было достаточно ресурсов, чтобы основательно это почистить. За рефакторинг же KPI не растет
ps.
можно отказаться от процесса «сбора логов и метрик» и полагаться на жалобы от пользователей в тех.поддержкеЯ не сомневаюсь в ваших способностях по реверсу, но большой сайт вы явно не обслуживали. Метрики — это самое последнее что должно упасть. Пользователи могут страдать, но metrics must flow.
А можно чуть больше деталей для тех кто в микросервисах не силен?
Всегда, когда заходит речь о микросервисах, я слышу определение из разряда "две недели разработки" или "не больше 10к строк кода". И для меня это если честно немного - даже если это без тестов. Но у нас тесты пишутся и поэтому я так прикидываю, чисто эмпирически 10к строк кода это примерно 5к строк тестов(у нас примерно такое соотношение - 1:1)
А 5к строк кода, если там не суперсложная логика и не минифицирован код, то это неделя на погружение и потом месяц переписать в одно лицо.
И вот тут у меня вопрос - в чем проблема поддерживать тогда микросервисы в нормальном состоянии? Или там уже не микросервисы?
Эта работа должна в фирме цениться. KPI, премии и вот это вот все. И на смежников должен быть способ надавить. Мол мы тут переписали по новому, пожалуйста за следующий квартал мигрируйте на новое. Совместимость со старым 97%, вот описание в каких местах она сломалась. Если не поможет обращайтесь поможем. 100% совместимости не бывает, все понятно.
Если ничего этого не было, то кто будет заниматься переписыванием? Зачем оно надо? Проще рядом новый кусок сделать. Это быстрее даст какую-то фичу в проде и премии всем участвующим.
Есть типовой способ обеспечить такое. Завести технарей повыше в вертикаль управления и распределения денег. И пусть они там с менеджерами договариваются о приоритетах и распределении плюшек среди разработчиков. Было это сделано в Твиттере или нет мне не известно.
Проблема не поддерживать, проблема развивать. Если попытаться формализовать проблему на пальцах, то маркетинг (развитие продукта, владельцы бюджета, заказчики фич) регулярно валят новые маркетинговые запросы на доработку продукта. В режиме нон-стоп продакт овнеры и продакт архитекты разбирают эти запросы и растаскивают по своим продуктам или закрепленными за ними компонентами. За компонентами закреплено по несколько команд и продакт овнер раскидывает по ним фичи, внедрение которых может включать доработку уже существующих сервисов или создание новых.
В код постоянно вносятся изменения и растет-копится технический долг. Это черная дыра технических доделок, которые невозможно продать заказчику, которые или невозможно было предусмотреть заранее или это ожидаемый этап развития, когда надо сменить архитектуру итп. Кодеры кранчат на этот техдолг, в итоге нездоровая история, которую если не контролировать, то она может порвать продукт в кашу.
Нетфликс, кстати, в свое время оказались в подобной ситуации, но они все-таки сели все переписывать и в течении года у них практически никаких фичей не выходило
Абстрактно - да, 52 человекогода это очень много. Но чисто если взять в рамках твиттера - это мало.
Предположим, что у нас есть 500 программистов моего уровня. Предположим, что неделя работы такого программиста обходится фирме в 3000$ со всеми сопутствующими расходами - офис, налоги, зарплата, зарплата саппорт персонала.
5 недель * 3000$ * 500 = 7 500 000$
Даже если я ошибся на порядок в своей оценке, то выглядит как будто эти 52 человекогода стоят 75 миллионов. На фоне всей сделки выглядят не очень большой суммой.
В итоге: актуальный код, полное погружение в текущее состояние и фичефриз всего на полтора месяца. Что будет выглядеть логично после сделки.
В микросервисных продуктах сложность продукта уходит из самих сервисов в их взаимодействие. Но так как за то, что "между сервисами" никто обычно не отвечает, то и продукт очень быстро начинает портится. Чем больше сервисов - тем, обычно, быстрее.
Идеальный пост выглядел бы так:
Почему Твиттеру нужны 1000 микросервисов?
Никто не знает.
ИМХО, все может быть гораздо проще: бывает тупо выгодно плодить огромное количество проектов и создавать гору бесполезных сервисов просто потому, что под это можно создать команду, а потом и группу команд, чтобы стать уже довольно влиятельным менеджером. Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное, а потом уже проще: ты владелец 10 сервисов, на которые что-то завязано, ставь сам себе цели, сам их достигай, завязывай на свои сервисы больше систем, в итоге станешь почти незаменимым руководителем серьезного проекта, которого сможет выгнать только очень жесткий менеджер. Нанимаешь таких же программистов, ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все, вы выглядите успешнее, чем большая часть разработчиков и менеджеров компании, которые таким не занимаются. Высший пилотаж - завязать кучу неважных сервисов друг на друга так, чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития. Так и появляются команды, увольнения которых никто не заметил, и горящие за свой проект разработчики, у которых он за 6 лет почему-то начинает тормозить все сильнее и сильнее.
Очень годный комментарий, лучше самой статьи.
Специфический комментарий, описывает ситуацию, применимую больше к НКО или госкомпании. В коммерческих компаниях инициатором развития своего продукта является маркетинг, никаких проектов там нет, Твиттер, это продуктовая компания. Появлению сервиса предшествуют корпоративные хороводы десятков разноуровневых, иногда конфликтующих между собой, иногда джуниоров, иногда спецов, маркетинг->бизнес аналитики->солюшен архитекторы продакт овнеры и девелоперы с тестерами все участвуют в обсуждении необходимости новой фичи, это дает понимание команде, как её лучше внедрить, тестерам - на чем расставлять акценты при тестировании итд. Это ещё надо очень постараться найти бюджет, набрать и удержать такую толпу балбесов, чтобы развивать десять никому не нужных сервисов.
Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное
У заказчика новых продуктовых фич, которые могут породить новые сервисы, этот процесс формализован. NPV, IRR, ROI всё это считается в бизнес-кейсе развития продукта. Если сильно упростить: коммерческая компания не может себе позволить развивать ненужные сервисы и скрыть растраты бюджета на это не выйдет. Ненужный сервис тебе просто зарубят прямо на всяких кикоффах и питчингах, так как ты не сможешь сказать, сколько бабла ты инвесторам сделаешь на нем, как это рассказывает маркетинг. А если расскажешь - тебе прийдется это бабло из фичи (и порожденных нею новых сервисов) высосать к концу отчетного периода. Без маркетинговой потребности в развитии продукта новый сервис создать не выйдет по одной простой причине: деньги никто не даст.
ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все
и выглядите успешнее, чем
которые таким не занимаются
Эээ, ну откровенный глум же. Все ставят планы которые подходят руководству, и этот мифический менеджер-пройдоха тоже отчитывается своему руководству за деньги деньгами, за расходы доходами, ну. Причем тут премии, которые все получают согласно колдоговору или индивидуальному договору (для топов), а также выступления на непонятных мероприятиях - неясно.
чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития
Какой-то зашоренный критерий важности. Есть совершенно разные процессы, не все из них внутри твиттера являются хайлоад, у многих разный профиль трафика, есть наверняка и пару запросов в сутки которые обслуживают, тем не менее, важные. И могут быть простыми, не требующими квалификации. Но они должны составлять легитимный, используемый заказчиком в своих экономически измеряемых бизнес-процессах компонент продукта.
Так и появляются команды, увольнения которых никто не заметил.
Какая-то Нарния, если честно. Команда разработчиков, это мягко говоря недешёвое удовольствие, которое очень влетает в копеечку уже в первый месяц их работы и рекуррентно влетает в ту же копеечку каждый последующий месяц, с необходимостью её периодического (пусть и раз в год-два) повышения..
Прочитав ваш комментарий может сложиться впечатление, что любая коммерческая компания работает как некий абсолютно рациональный коллективный разум который в своих решениях опирается исключительно на факты и метрики, однако в реальности так никогда не бывает: метрики могут представить в нужном ключе, может сказаться фактор личных связей в руководстве, нормально выкинуть несколько миллионов денег и лет на проект просто потому что кому-то что-то показалось, и т.п. Я работал во множестве компаний как зарубежных так и российских и по опыту могу сказать что большинство принимаемых решений иррациональны, просто такова природа людей.
коллективный разум который в своих решениях опирается исключительно на факты и метрики, однако в реальности так никогда не бывает: метрики могут представить в нужном ключе
Мы наверное о каких-то разных метриках говорим, давайте сразу уточним. Есть метрики, собираемые с самих микросервисов, есть аггрегированные метрики, собираемые с бизнес-процессов, в которых участвуют эти самые микросервисы, есть аггрегации бизнес-процессов в более высокоуровневые вплоть до совета директоров (для взаимодействия с ними уже тоже есть специальные микросервисы, как бы смешно это ни звучало) и на определенных уровнях эти метрики превращаются в деньги, а в другой колоночке стоят планы. Как только планы проседают - начинается декомпозиция этих метрик вплоть до конкретных бизнес-процессов или задействованных в них компонентах ПО/микросервисах, которые всю малину держателям бюджета портят.
нормально выкинуть несколько миллионов денег и лет на проект
В компаниях, оперирующих определёнными порядками бюджетов выкинуть несколько миллионов денег и лет на невыстреливший R&D это не "нормально", а "ппц, как легко отделались".
просто потому что кому-то что-то показалось
Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
На разных этапах развития продукта бизнес-кейс считается в разных приближениях. После первого года продакшена бизнес-кейс становится наиболее точным, однако взлетит/не взлетит однозначно видно уже после первых пары апдейтов (раз в три месяца). Он может перестать сходиться сразу после запуска, тогда фичу вырезают или проект закрывают.
"просто кому-то что-то показалось" - если в бизнесе допускается такое принятие решений, бизнес долго не просуществует.
по опыту могу сказать что большинство принимаемых решений иррациональны
Я работаю в телекоме с 2001, в мобильном с 2008, сейчас в разработке managed kubernetes продукта для телеком операторов. По опыту, могу сказать что в подавляющем большинстве случаев, когда мне казалось, что кто-то принял иррациональное решение, в результате оказывалось, что я не владел достаточным объемом информации и/или опыта, и/или принятых обязательств, которые имелись в момент принятия решения у принимающего.
Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
И тем не менее в данный момент мы наблюдаем ситуацию когда из Твиттера уволили значительное количество специалистов под которых ранее были выделены бюджеты. А значит либо их наняли под влиянием иррациональных решений (или по злому умыслу) и это прекрасно прошло 100500 кругов согласований или же в данный момент их уволили иррациональным решением и это тоже прошло все согласования.
либо их наняли под влиянием иррациональных решений (или по злому умыслу)
или же в данный момент их уволили иррациональным решением
Это ложная дихотомия. На самом деле, ничего нерационального скорее всего нет ни в первом, ни во втором решениях - оба эти действия совершены радикально на разных этапах становления Твиттера и принимались с учётом совершенно разных вводных.
Смею предположить, что перед поднятием ставки ФРС Маск не угадал с кредитами, попытался соскочить, когда понял, как сильно рентабельность этого кредита понизится, но не вышло. На мой скромный взгляд, Маск перешёл к простому плану Пи (или Пэ) - людоедское урезание костов по всем возможным направлениям, децимация сервисов и персонала, печенек и work/life баланса, чтобы выдоить из неудачной покупки побыстрее максимум. О удалении ненужного речь идёт только в контексте "под нож всё то, что из нужного у нас ненужнее всего".
При всём этом, проблема рефакторинга процесса взаимодействия приложения из-за кучи (фигурально выражаясь "тысяч и тысяч") RPC запросов, может даже к одному и тому же микросервису, возможно таки и стоит и решать её возможно действительно надо. Решением может быть даже переработка архитектуры ресурсов с rpc на rest и тогда не понадобится ловить колбеки rpc. Количество запросов станет не "тысяча", а "сотни", допустим, но это не камень преткновения настолько серъёзный, чтобы СЕО лез и пытался его разрешить. СЕО должен иметь команду, в которой есть другие люди, которые этим непублично займутся без него. Вся эта публичная возня конкретно с архитектурой и кодом больше похожа на классический маскопиар.
Да ладно, сплошь и рядом в крупных телекомах делали и делают полную фигню, несмотря на все комитеты. Собственно, в телекомах бардак еще больший, чем в банках и куда больший, чем в средних продуктовых компаниях (где, кстати, тоже крайне редко считают ROI для проектов, там вообще чуть-чуть другой подход к развитию).
большинство принимаемых решений иррациональны
Они не иррациональны, а очень даже разумны. См коммент на два уровня выше. Просто не надо воспринимать контору как единый субъект, тогда не получится следствия "люди — идиоты".
Вообще, кмк, в социологии результат "люди = идиоты" должен немедленно вести к отбраковке модели. Это вернейший признак того, что что-то не учтено.
Люди не идиоты, но они всегда принимают решения в условиях ограниченности/ложности информации, на основании своего уникального и не релевантного прошлого опыта и под воздействием других таких же людей. Просто потому, что иначе никак: информация всегда неполна, опыт у каждого свой, есть фактор личных отношений.
Всё же
в условиях ограниченности/ложности информации, на основании своего уникального и не релевантного прошлого опыта и под воздействием других таких же людей
Решения можно принимать не только иррационально, но и рационально. Чем больше бизнес принимает иррациональных решений, тем короче и беднее живёт.
Основной пойнт тут в том, что интересы конторы и человека из конторы, как правило, сильно отличаются. Например, у рядового Васи конечный интерес — устать меньше, потратить времени меньше, получить максимальное вознаграждение.
Люди не идиоты, но обычно принимают решение вне зоны своей компетентности.
Не надо забывать, что Твиттер торгуемая на бирже компания. И для биржевых инвесторов могут быть важны совсем другие метрики и методы их раздувания. Далек от фундаментального анализа компаний, но возможно стабильно растущий штат или инфраструктура как раз способ раздуть эти "инвесторские" метрики
Это абсолютно нормальная ситуация для любой крупной структуры.
А персонаж комиксов Уолли появился благодаря наблюдению за НКО?
Именно, только я уверен это почти всегда происходит не по злому умыслу, а просто как результат борьбы со сложностью через нарезку маленьких сервисов и размывания экспертизы по разным командам.
О... да! Все так и есть! В пресловутом зеленом банке таких псевдоэффективных людей больше половины. Как две вселенные прямо. Одни "криворукие дебилы" стоящие за спинами у людей на конвейере и держащие на своем здоровье реальные процессы, а другие "божественные созидатели", что переманили за 500 грейд к себе цвет очередного разорившегося юникорна и творящие какой-нибудь AI по анализу рыночных трендов, турбулентного движения денежных масс и эффективности сотрудников.
Редко-редко, но случается, когда "небожителя" со свитой сажают-таки на боевой участок, со словами "ну вот, дебилы, сейчас ОНИ тут все поправят, и всех вас научат", но, после годика абсолютно бестолковых исследований и совещаний, вся эта когорта стройными рядами уходит в какой-нибудь синий банк, со словами "ах, наши таланты тут совсем не были востребованы", после чего "дебилы" возвращаются ровно к той же точке явления к ним чуда с небес.
Может я конечно сильно поверхностно вник в этот оверхайп, поэтому прошу тряпками по лицу не бить, но впервые вник в картинку и понял, что тут путаница. На первый взгляд прищуренным глазом кор архитектура указана вплоть до сервисов и там их, не вникая в подсчёты, изображено порядка 30-40. Предположим, вокруг кор архитектуры есть еще 15-20 значимых компонентов пусть по 15 сервисов каждый максимум (это вряд ли, но твиттер дядя большой), это примерно 350 микросервисов максимум. Ну и может есть какой-то фреймворк общих компонентов, где пилятся базовые версии допустим половины из этих 350 - всего пусть будет ну 600 от силы, 200 из которых существуют только в дев-песочнице. Вывод: если там где-то и есть 1000 микросервисов, то это видать обгрызки недомиграции с какого-то легаси, которые надо догрызать-домигрировать дабы избежать сосуществования старой и новой версии одного и того же сервиса.
Но вроде как в оригинале речь шла про 1000 RPC calls from app to backend, а не про 1000 microservices. Это уже совсем другого плана проблема, хотя и тоже архитектурная. Переписывание приложения может решить эту проблему, если она действительно существует и не лежит концептуально в корне этой core архитектуры на 30-40 микросервисов.
Если следовать этой логике, то тут напрашивается предложение от Маска: "а нафига вы тут наупрощали с кучей микросервисов, связи между которыми стали фактически неуправляемыми и тащат нас вниз? Делайте сложнее, но надёжнее!"
Было бы интересно посмотреть на такой сценарий.
Ключевой момент - целенаправленно инвестировать в исследование этих сложных путей.
В разработке софта в целом, и Калифорнийском Биг Теке в частности, царит культура "выкатить побыстрее, пофиг как". Даже фундаментальные инвестиции разбазариваются на создание очередного стильного модного фреимворка, который медленнее предыдущих.
Уверен, он вычистит конюшни и всё будет лучше, чем прежде.
Разрабатывал одну CRM для застройщика, в ней было очень много фич, клиент на vb6, логика в MS-SQL на T-SQL, также были сервисы на c# (api и интеграции), отчетность Reporting Services и Olap. В ней было все (Портал, СЭД, CRM и т.д.) система поддерживалась двумя сотрудниками. Недавно поработал у большого застройщика, функций было чуть больше (еще стройка немного была захвачена), зато было огромное количество продуктов и технологий, под сотню ИТ специалистов.
Все руководители вечно жаловались, что им не хватает ИТ специалистов и постоянно расширяли штат, система при этом становилась все хуже и хуже.
процесс цензурирования - мало кто хочет видеть непристойный контент в своей ленте, иначе разбегутся
Кроме политического цензурирования в последние года 2-3 я лично ничего не видел. А вот непристойный контент там присутствует. Причем как чисто словесный, так и картиночный(и видео), и никто его не цензурирует. Если с этим не справлялись 10000 человек, то вообще непонятно чем они занимались.
К примеру в инстаграме подобного вида контент , даже мат блокируется эффективно.
Было бы интересно сравнить команду Твиттера с другими командами, да например с тем же Телеграммом.
процесс управления тестированием и качеством (QA) - чтобы ежедневно не терять пользователей из-за низкого качества своего продукта
Не работает, видимо :)
Почему Твиттеру нужны 1000 микросервисов