Люди и не должны понимать ООП
За десятки лет концепции она не только не смогла стать сколько-нибудь массовой, но и обросла рудиментами императивщины и другими придатками из совершенно других областей, превратившись в неудобоваримого монстра.
Так бывает, когда маложизнеспособные концепции по методу мартышка-и-очко пытаются без разбора прикладывать к чему угодно, по принципу "технология отчаянно ищет себе хоть какое-нибудь применение".
Справедливости ради, стоит отметить, что ООП привнесла немало полезного, например, концепции композиции (вместо наследования) и RAII, позволившие уменьшить количество целого класса ошибок (и породивших новые проблемы, разумеется).
Суть, однако же, в том, что хоть сколько-нибудь сложное ПО практически невозможно представить (и увидеть на практике) с чистой архитектурой, чистым кодом, без указателей и кастов.
Справедливости ради, стоит отметить, что такие черты (traits, да, не побоимся этого слова) присущи совершенно другой парадигме программирования.
Собственно, в чем суть проблемы. Программы пишутся для того, чтобы их понимали прежде всего компьютеры.
Люди - да, должны их читать и понимать.
Но - совершенно не все на свете люди.
Почему программисты, по роду своей деятельности, призванные понимать любой код на своих языках (и обладающие таким инструментом, как комментарии) ноют и жалуются на читаемость - ускользает вообще от всех.
Ну и, что совершенно очевидно ветеранам индустрии, оная описала полный круг и плавно вернулась к чистой императивщине на Си. Как оказалось, этого необходимо и достаточно для того, чтобы написать практически какой угодно алгоритм.
За десятки лет концепции она не только не смогла стать сколько-нибудь массовой, но и обросла рудиментами императивщины и другими придатками из совершенно других областей, превратившись в неудобоваримого монстра.
Так бывает, когда маложизнеспособные концепции по методу мартышка-и-очко пытаются без разбора прикладывать к чему угодно, по принципу "технология отчаянно ищет себе хоть какое-нибудь применение".
Справедливости ради, стоит отметить, что ООП привнесла немало полезного, например, концепции композиции (вместо наследования) и RAII, позволившие уменьшить количество целого класса ошибок (и породивших новые проблемы, разумеется).
Суть, однако же, в том, что хоть сколько-нибудь сложное ПО практически невозможно представить (и увидеть на практике) с чистой архитектурой, чистым кодом, без указателей и кастов.
Справедливости ради, стоит отметить, что такие черты (traits, да, не побоимся этого слова) присущи совершенно другой парадигме программирования.
Собственно, в чем суть проблемы. Программы пишутся для того, чтобы их понимали прежде всего компьютеры.
Люди - да, должны их читать и понимать.
Но - совершенно не все на свете люди.
Почему программисты, по роду своей деятельности, призванные понимать любой код на своих языках (и обладающие таким инструментом, как комментарии) ноют и жалуются на читаемость - ускользает вообще от всех.
Ну и, что совершенно очевидно ветеранам индустрии, оная описала полный круг и плавно вернулась к чистой императивщине на Си. Как оказалось, этого необходимо и достаточно для того, чтобы написать практически какой угодно алгоритм.
Первое Правило Ремонтника
Первое Правило Ремонтника гласит - никогда не отговаривай клиента самому попробовать починить. Такая попытка увеличивает итоговый ценник на ремонт самое меньшее в десять раз (x10).
Это правило касается не только ремонтов, и не только реальной сферы. А также - впрямую и непосредственно - ИТ.
Любые миграции, консолидации, оптимизации производительности, любые сколько-нибудь сложные проекты и разработки - это правило действует всегда.
Оно является, своего рода, фактором естественного отбора.
Основывается данное правило на том простом и очевидном факте, что профессионалы, имея бОльший опыт и, как правило, значительно бОльшую экспертизу, при прочих равных, всегда бьют любителей.
Наемный менеджмент, однако, от этого правила отнюдь не страдает - они тратят не свои деньги.
Страдает владелец (владельцы) бизнеса.
Однако, находясь в своей башне из слоновой кости, они редко бывают в курсе, что на самом деле поделывают их подчиненные.
Нежелание вникать, в конечном итоге, и приводит к всем известному результату - скупой платит дважды, жадный теряет трижды.
Не будем заканчивать фразу - концовка всем известна.
Первое Правило Ремонтника гласит - никогда не отговаривай клиента самому попробовать починить. Такая попытка увеличивает итоговый ценник на ремонт самое меньшее в десять раз (x10).
Это правило касается не только ремонтов, и не только реальной сферы. А также - впрямую и непосредственно - ИТ.
Любые миграции, консолидации, оптимизации производительности, любые сколько-нибудь сложные проекты и разработки - это правило действует всегда.
Оно является, своего рода, фактором естественного отбора.
Основывается данное правило на том простом и очевидном факте, что профессионалы, имея бОльший опыт и, как правило, значительно бОльшую экспертизу, при прочих равных, всегда бьют любителей.
Наемный менеджмент, однако, от этого правила отнюдь не страдает - они тратят не свои деньги.
Страдает владелец (владельцы) бизнеса.
Однако, находясь в своей башне из слоновой кости, они редко бывают в курсе, что на самом деле поделывают их подчиненные.
Нежелание вникать, в конечном итоге, и приводит к всем известному результату - скупой платит дважды, жадный теряет трижды.
Не будем заканчивать фразу - концовка всем известна.
Вы не мониторите то, о чем не знаете
В IT cуществует достаточное количество шкафов со скелетами, в которые вообще никто не заглядывает.
Даже если знает об их существовании (например, число аллокаций памяти в секунду).
Один из таких шкафов, как ни странно, DNS.
За последние годы все привыкли обмазываться мониторингами всего и вся. Почти. Тут так принято.
Ни на секунду не задумываясь о такой вещи, как количество DNS-запросов в исходящем трафике (даже - и особенно - с учетом постепенного расползания чрезвычайно неэкономичного DoH).
Откройте для себя NetFlow.
Возможно - всего лишь возможно - вас сильно удивит, насколько огромную долю в трафике составляет DNS (даже 10-14 лет назад доля составляла от 40%).
CDN ни в малейшей степени не способствует сокращению этой доли трафика, даже с учетом приближенности крупных публичных DNS к пользователям. Среднее количество ссылок на веб-странице, требующее резолва, составляет от 100 до 300 доменов с поддоменами, зачастую имеющими отдельные A- и CNAME-записи.
На практике, мало кто измерял эту фоновую деятельность (клиентские DNS-кэши обычно имеют смехотворные размеры) и никто не задумывается, насколько кэширующие рекурсивные DNS способны снизить лейтенси и уменьшить исходящий трафик.
Если не вдаваться в подробности, внутрисетевой кэширующий рекурсор может выполнять не только оптимизацию внешнего DNS-трафика. Существующие реализации имеют также локальные зоны, что позволяет также кэшировать внутрисетевые резолвы, что, с учетом всеобщей тяги к сотням и тысячам серверов и кластерных нод, совершенно не является лишним, в рамках оптимизационной стратегии.
Резюмируя вышесказанное, подобно безопасности - оптимизация производительности это не продукт, а процесс.
Который, в идеале, должен идти непрерывно.
В IT cуществует достаточное количество шкафов со скелетами, в которые вообще никто не заглядывает.
Даже если знает об их существовании (например, число аллокаций памяти в секунду).
Один из таких шкафов, как ни странно, DNS.
За последние годы все привыкли обмазываться мониторингами всего и вся. Почти. Тут так принято.
Ни на секунду не задумываясь о такой вещи, как количество DNS-запросов в исходящем трафике (даже - и особенно - с учетом постепенного расползания чрезвычайно неэкономичного DoH).
Откройте для себя NetFlow.
Возможно - всего лишь возможно - вас сильно удивит, насколько огромную долю в трафике составляет DNS (даже 10-14 лет назад доля составляла от 40%).
CDN ни в малейшей степени не способствует сокращению этой доли трафика, даже с учетом приближенности крупных публичных DNS к пользователям. Среднее количество ссылок на веб-странице, требующее резолва, составляет от 100 до 300 доменов с поддоменами, зачастую имеющими отдельные A- и CNAME-записи.
На практике, мало кто измерял эту фоновую деятельность (клиентские DNS-кэши обычно имеют смехотворные размеры) и никто не задумывается, насколько кэширующие рекурсивные DNS способны снизить лейтенси и уменьшить исходящий трафик.
Если не вдаваться в подробности, внутрисетевой кэширующий рекурсор может выполнять не только оптимизацию внешнего DNS-трафика. Существующие реализации имеют также локальные зоны, что позволяет также кэшировать внутрисетевые резолвы, что, с учетом всеобщей тяги к сотням и тысячам серверов и кластерных нод, совершенно не является лишним, в рамках оптимизационной стратегии.
Резюмируя вышесказанное, подобно безопасности - оптимизация производительности это не продукт, а процесс.
Который, в идеале, должен идти непрерывно.
Не задумываясь
Почему шаурмячная использует кубер?
Потому, что может.
То, что индустрия подвержена горячечным влияниям "от кутюр" - в общем, не новость.
"Не задумываясь" - это девиз индустрии. И всегда им был.
Сесть и подумать, что, в общем, киты решали свои собственные, местечковые китовые проблемы - которые суть проблемы китов, но отнюдь не мои проблемы; что надо б оглянуться, не увидеть надпись Google над своим ресепшеном, одуматься - такое в принципе мало кому приходит в голову.
О чем есть отличная поговорка - "Что крестьяне - то и обезьяне".
Почему ФБ не использует Git? Может быть, потому, что он им никуда не впился? И он не решает их реальные проблемы? А просто использовать "Потому, что можем" нормальные инженеры считают нецелесообразным?
Что делает нормальный инженер, встретив реальную проблему?
Правильно, он ее решает наиболее эффективным образом.
Что делает айтишник, выдумав на ровном месте несуществующую проблему?
Он тащит очередной баззворд к себе в шаурмячную. Вместо того, чтобы пойти с несуществующей проблемой к профильному профессионалу - к психотерапевту.
Как итог, мы имеем докеры-куберы-микросервисы-кластеры-CI/CD-ансиблы-и другие слова везде и всюду.
И, дабы заточить карандаш, берем пару мельничных жерновов.
А потом рыдаем об управлении ненужной сложностью.
Вам не кажется, что можно было без всего этого? В подавляющем большинстве массовых случаев?
Руководители - призванные направлять - почему-то в упор не видят Resume Driven Development.
О возможности вертикального масштабирования просто умолчим, строительство ДЦ размером с футбольные поля это Большой Бизнес. За слова "вертикальное масштабирование", конечно, не закажут - но остракизму подвергнут, бей неолуддита.
Не является ли это следствием того, что в индустрию ринулись люди, вообще не имеющие инженерных дипломов и о системных подходах и инженерии имеющие лишь весьма отдаленное представление? Диплом с молотками - он не просто корочка и не просто пять потерянных лет. В это время в головы вбиваются подходы, стратегии и методы решения инженерных задач. Без которых индустрия вырождается в бездумное клепание сайтиков по Айджайлу.
К слову, об игнорировании инженерии - отличным примером является так называемый батискаф "Титан". Как и последний боинг, который MAX. Ничего, не страшно сесть в то и другое? Нет? Это ваши собратья-айджайлисты-кутюрье клепали. Надо любить их работу, не так ли? Она ведь и ваша, в значительной степени.
Игнор инженерии заканчивается, зачастую, весьма плохо и очень болезненно. А вы сами решайте - вам к умным или к красивым.
PS. Вы, конечно же, слышали про версионность библиотек. И про кодирование этой самой версионности в мэйкфайлах. Наверняка вы слышали и про то, что это еще autotools умеют. И не надо никакого cmake. Ведь слышали? Ведь правда? Спрашивается - ну и зачем тогда докер? А CI/CD, когда техдолг захлестывает, как цунами?
Почему шаурмячная использует кубер?
Потому, что может.
То, что индустрия подвержена горячечным влияниям "от кутюр" - в общем, не новость.
"Не задумываясь" - это девиз индустрии. И всегда им был.
Сесть и подумать, что, в общем, киты решали свои собственные, местечковые китовые проблемы - которые суть проблемы китов, но отнюдь не мои проблемы; что надо б оглянуться, не увидеть надпись Google над своим ресепшеном, одуматься - такое в принципе мало кому приходит в голову.
О чем есть отличная поговорка - "Что крестьяне - то и обезьяне".
Почему ФБ не использует Git? Может быть, потому, что он им никуда не впился? И он не решает их реальные проблемы? А просто использовать "Потому, что можем" нормальные инженеры считают нецелесообразным?
Что делает нормальный инженер, встретив реальную проблему?
Правильно, он ее решает наиболее эффективным образом.
Что делает айтишник, выдумав на ровном месте несуществующую проблему?
Он тащит очередной баззворд к себе в шаурмячную. Вместо того, чтобы пойти с несуществующей проблемой к профильному профессионалу - к психотерапевту.
Как итог, мы имеем докеры-куберы-микросервисы-кластеры-CI/CD-ансиблы-и другие слова везде и всюду.
И, дабы заточить карандаш, берем пару мельничных жерновов.
А потом рыдаем об управлении ненужной сложностью.
Вам не кажется, что можно было без всего этого? В подавляющем большинстве массовых случаев?
Руководители - призванные направлять - почему-то в упор не видят Resume Driven Development.
О возможности вертикального масштабирования просто умолчим, строительство ДЦ размером с футбольные поля это Большой Бизнес. За слова "вертикальное масштабирование", конечно, не закажут - но остракизму подвергнут, бей неолуддита.
Не является ли это следствием того, что в индустрию ринулись люди, вообще не имеющие инженерных дипломов и о системных подходах и инженерии имеющие лишь весьма отдаленное представление? Диплом с молотками - он не просто корочка и не просто пять потерянных лет. В это время в головы вбиваются подходы, стратегии и методы решения инженерных задач. Без которых индустрия вырождается в бездумное клепание сайтиков по Айджайлу.
К слову, об игнорировании инженерии - отличным примером является так называемый батискаф "Титан". Как и последний боинг, который MAX. Ничего, не страшно сесть в то и другое? Нет? Это ваши собратья-айджайлисты-кутюрье клепали. Надо любить их работу, не так ли? Она ведь и ваша, в значительной степени.
Игнор инженерии заканчивается, зачастую, весьма плохо и очень болезненно. А вы сами решайте - вам к умным или к красивым.
PS. Вы, конечно же, слышали про версионность библиотек. И про кодирование этой самой версионности в мэйкфайлах. Наверняка вы слышали и про то, что это еще autotools умеют. И не надо никакого cmake. Ведь слышали? Ведь правда? Спрашивается - ну и зачем тогда докер? А CI/CD, когда техдолг захлестывает, как цунами?
Виртуализация не бесплатна
Причем вопреки этому и этому исследованию, она не бесплатна не только для x86, а вообще для любых процессорных архитектур.
Волшебной пули не существует и маркетинговые заявления, будто бы гипервизоры вносят околонулевой оверхед, в действительности не более, чем маркетинговые заявления.
К огромному сожалению, за все 16+ лет существования многоядерных процессоров и более, чем странному их развитию, не удалось не только создать тредовую ОС (все до единого ядра существующих ОС - асинхронные на коллбэках), но и создать сколько-нибудь обширную прослойку тредового ПО.
Справедливости ради, заметим, что далеко не все задачи эффективно параллелятся. В этой связи вообще представляется нецелесообразным уход от модели SMP, в силу того, что единственным, по существу, способом хоть сколько-нибудь эффективной утилизации многоядерных ЦПУ (исключая небольшой процент вычислительных задач и задач потоковой обработки данных) является запуск большого числа слабосвязанных процессов. По сути, та самая виртуализация.
Увы - законы физики обойти невозможно и оверхед при виртуализации существует, существовал и существовать будет. Его не способны победить даже легковесные контейнеры.
Этот факт хорошо известен программистам, пишущим по-настоящему высокопроизводительный код; когда буквально пара лишних ассемблерных команд в горячем месте просаживает производительность на 20-80%.
Для тех, кто до сих пор этого не понял - закон Мура упёрся в потолок совсем не вчера. Время писать эффективный код пришло давным-давно, и никакое горизонтальное масштабирование не спасёт гигантов мысли (кстати, оно в принципе ортогонально наращиванию ядер процессоров, что, в общем, было понятно на берегу - к сожалению, далеко не всем).
Индустрия сама себя загнала в ловушку в силу полного и абсолютного отсутствия дальновидности и какого бы то ни было стратегического видения.
И единственный выход из нее - это полный и безоговорочный отказ от порочной концепции TTM и возврат к медленной и мучительной разработке высококачественного (тредового) кода высококвалифицированными программистами.
Другого способа перестать греть воздух апокалиптическими ДЦ, обмолачивающими экстремально неэффективный код, просто не существует.
Несколько фактов на закуску. Эффективных стратегий MPP не существует, в силу данного факта многоядерные системы тонут в lock contention, о чем большинство не задумывается, не замечает и, зачастую, даже не догадывается. Само существование многоядерников (с по-настоящему большим количеством ядер) в принципе перпендикулярно концепции горизонтального масштабирования и закону Амдаля-Уэра и свидетельствует лишь о том, что никто не знает, как еще можно ускорить выполнение той массы предельно неэффективного кода, который уже написан. Переписывать все это, разумеется, не вариант. Отсюда это засилье виртуализации в сочетании с попытками попутно решить пару-тройку проблем, связанных с общей некомпетентностью. Судорожные попытки nVidia/AMD/Intel усидеть одновременно на двух стульях вертикального и горизонтального масштабирования, рожая странных уродцев в не менее странных архитектурах упираются одновременно в TDP и отсутствие качественной софтверной поддержки. Особенно живописно выглядит одноядерный турбобуст Интел и разнотипныe ядра Apple.
Индустрия в тупике, из которого теперь просто и легко не выйти. В лучшем случае - это будет страшно дорого и ужасно больно.
Причем вопреки этому и этому исследованию, она не бесплатна не только для x86, а вообще для любых процессорных архитектур.
Волшебной пули не существует и маркетинговые заявления, будто бы гипервизоры вносят околонулевой оверхед, в действительности не более, чем маркетинговые заявления.
К огромному сожалению, за все 16+ лет существования многоядерных процессоров и более, чем странному их развитию, не удалось не только создать тредовую ОС (все до единого ядра существующих ОС - асинхронные на коллбэках), но и создать сколько-нибудь обширную прослойку тредового ПО.
Справедливости ради, заметим, что далеко не все задачи эффективно параллелятся. В этой связи вообще представляется нецелесообразным уход от модели SMP, в силу того, что единственным, по существу, способом хоть сколько-нибудь эффективной утилизации многоядерных ЦПУ (исключая небольшой процент вычислительных задач и задач потоковой обработки данных) является запуск большого числа слабосвязанных процессов. По сути, та самая виртуализация.
Увы - законы физики обойти невозможно и оверхед при виртуализации существует, существовал и существовать будет. Его не способны победить даже легковесные контейнеры.
Этот факт хорошо известен программистам, пишущим по-настоящему высокопроизводительный код; когда буквально пара лишних ассемблерных команд в горячем месте просаживает производительность на 20-80%.
Для тех, кто до сих пор этого не понял - закон Мура упёрся в потолок совсем не вчера. Время писать эффективный код пришло давным-давно, и никакое горизонтальное масштабирование не спасёт гигантов мысли (кстати, оно в принципе ортогонально наращиванию ядер процессоров, что, в общем, было понятно на берегу - к сожалению, далеко не всем).
Индустрия сама себя загнала в ловушку в силу полного и абсолютного отсутствия дальновидности и какого бы то ни было стратегического видения.
И единственный выход из нее - это полный и безоговорочный отказ от порочной концепции TTM и возврат к медленной и мучительной разработке высококачественного (тредового) кода высококвалифицированными программистами.
Другого способа перестать греть воздух апокалиптическими ДЦ, обмолачивающими экстремально неэффективный код, просто не существует.
Несколько фактов на закуску. Эффективных стратегий MPP не существует, в силу данного факта многоядерные системы тонут в lock contention, о чем большинство не задумывается, не замечает и, зачастую, даже не догадывается. Само существование многоядерников (с по-настоящему большим количеством ядер) в принципе перпендикулярно концепции горизонтального масштабирования и закону Амдаля-Уэра и свидетельствует лишь о том, что никто не знает, как еще можно ускорить выполнение той массы предельно неэффективного кода, который уже написан. Переписывать все это, разумеется, не вариант. Отсюда это засилье виртуализации в сочетании с попытками попутно решить пару-тройку проблем, связанных с общей некомпетентностью. Судорожные попытки nVidia/AMD/Intel усидеть одновременно на двух стульях вертикального и горизонтального масштабирования, рожая странных уродцев в не менее странных архитектурах упираются одновременно в TDP и отсутствие качественной софтверной поддержки. Особенно живописно выглядит одноядерный турбобуст Интел и разнотипныe ядра Apple.
Индустрия в тупике, из которого теперь просто и легко не выйти. В лучшем случае - это будет страшно дорого и ужасно больно.
Данные, лежащие в облаке - не ваши данные
Удивительно, но до сих пор почти ни до кого так и не дошло, что данные, лежащие в облаке - не ваши данные, подобно тому, как сервер, стоящий где-то в датацентре - не ваш сервер.
Причем если с сервером еще можно одуматься, забрать, перевезти в свою серверную, переустановить - то данные, единожды утекшие, перестают быть вашими данными однажды и навсегда. Причем узнать об этом можно далеко не сразу.
По поводу серверов - известен лишь один вендор и лишь одна ОС (1, не сбейтесь со счета), позволяющая программно заблокировать USB- и прочие порты на подключение лишь одного внешнего устройства со вполне определенным серийным номером либо отключить порты полностью. И этот вендор и эта ОС не сказать, чтобы безумно популярны в наши дни. Помимо того, что об этом свойстве даже в кругу почитателей оного вендора мало кто знает. Это касательно вашего сервера вне вашего физического контроля.
Что касается данных, хранимых гдетотам по подписке, на устройствах, которые вообще вам не принадлежат, находятся абсолютно вне вашего физического контроля и защищены лишь честным словом провайдера... надо быть очень доверчивым либо очень глупым (что в данном контексте равнозначно), чтобы на это повестись и начать тратить опексы.
Хотя все это было известно и до настоящего времени, как оказалось, когнитивное искажение не давало понять этих простейших вещей более пятнадцати лет. То самое искажение, когда человек разбирается в какой-то одной узкой области, и внезапно начинает считать, что он и в остальных областях прекрасно разбирается.
Увы и ах, но "Не задумываясь" - истинный девиз индустрии.
Удивительно, но до сих пор почти ни до кого так и не дошло, что данные, лежащие в облаке - не ваши данные, подобно тому, как сервер, стоящий где-то в датацентре - не ваш сервер.
Причем если с сервером еще можно одуматься, забрать, перевезти в свою серверную, переустановить - то данные, единожды утекшие, перестают быть вашими данными однажды и навсегда. Причем узнать об этом можно далеко не сразу.
По поводу серверов - известен лишь один вендор и лишь одна ОС (1, не сбейтесь со счета), позволяющая программно заблокировать USB- и прочие порты на подключение лишь одного внешнего устройства со вполне определенным серийным номером либо отключить порты полностью. И этот вендор и эта ОС не сказать, чтобы безумно популярны в наши дни. Помимо того, что об этом свойстве даже в кругу почитателей оного вендора мало кто знает. Это касательно вашего сервера вне вашего физического контроля.
Что касается данных, хранимых гдетотам по подписке, на устройствах, которые вообще вам не принадлежат, находятся абсолютно вне вашего физического контроля и защищены лишь честным словом провайдера... надо быть очень доверчивым либо очень глупым (что в данном контексте равнозначно), чтобы на это повестись и начать тратить опексы.
Хотя все это было известно и до настоящего времени, как оказалось, когнитивное искажение не давало понять этих простейших вещей более пятнадцати лет. То самое искажение, когда человек разбирается в какой-то одной узкой области, и внезапно начинает считать, что он и в остальных областях прекрасно разбирается.
Увы и ах, но "Не задумываясь" - истинный девиз индустрии.
Рак разъедающий
Легаси - это то, что мы не понимаем, понимать и поддерживать не хотим и вообще это NIH. А рефакторинг не нужен, родной!
В действительности, вы не туда смотрите. Фундамент метастазирования индустрии мало того, что заложен не вчера - он практически непобедим и болеет совсем не только ИТ.
Фундаментальных проблем две и они системные.
Первая - менеджмент. Целями менеджмента являются две вещи - больше хэдкаунта, больше бюджетов - больше значимости. Карьерный рост (менеджера), KPI, бонусы - вот это вот всё. Оптимизация - в смысле сокращения хэдкаунта и бюджетов - которая имеет смысл с точки зрения собственников - наемному менеджеру ортогональна. Собственники, однако, на другой планете живут - пока худо-бедно что-то крутится, прибыль - какая-никакая - идет - им глубочайшим образом плевать, что там под капотом творится. Надо купить полтысячи серверов? Да и пофиг, это всего лишь деньги. Пока их хватает. Оптимизация? Рефакторинг? Да на кой?! Тайм ту маркет - вот что важно, нужно и значимо. А пользователи - да куда они денутся-то, с подводной лодки. Все так делают. Рыночек выбирает между плохо и очень плохо.
Вторая - исполнители. То, что software engeneering это, в первую очередь, engeneering - всем плевать. Инженерный ВУЗ - не нужен. Он не учит тому, что надо исполнителям - а именно, ремесленничеству (всеобщий плачь Ярославны о том, почему в инженерных ВУЗах учат какой-то абстрактной ненужной хрени, а не нажимать кнопки и пользоваться инструментами - привет, МУИТ!). Никто не видит главного - инженерия это подходы к решению задач в условиях ограничений. Вертикальное масштабирование? Оно не модно и не нужно. Слишком сложна-сложна-сложна. Проще навалить в горизонталь несколько сот серверов, обмазать очередями, гонять по сети гигабайты, вытереть ноги об Амдаля и Уэра. Архитектура? А куда это? Кроссплатформенность? Нинужна, есть докеры и куберы. Адище зависимостей? Упс, ну и что? Чотаковата? Все так делают. И менеджер рад, когда ИТ департамент шавермячной - две сотни человек на четыре сотни серверов в облаках. И инженерам без дипломов и малейшего представления, что такое инженерия, есть, чем заняться.
Чтобы хотя бы попытаться побороть эти две проблемы, Конана-Варвара и даже Геракла определенно будет маловато. Даже Илон слишком мелковат по своим масштабам и эксцентричности, чтобы поотрубать все головы этой Лернейской Гидре.
Рыночек порешал. Все побежали - и я побежал.
Именно поэтому - слова "техдолг", "рефакторинг", "оптимизация" (под которой понимают в самом лучшем случае поиск волшебного параметра, а в худшем - э, заменим HDD на SSD, подсыпем корочек процессорных, принесем чемодан плашек памяти - вот и вся оптимизация) в индустрии матерные.
А всё, что мы не будем рефакторить, убирая техдолг - автоматически идет в категорию "легаси". А мы не будем ничего рефакторить, изобретая тысячи уважительных причин, потому что не хотим (в первую очередь) и не умеем (во вторую).
Finally, ну и, как и всегда и со всех сторон - человеческая природа непобедима. Гром не грянет - мужик не перекрестится. До тех пор, пока не полыхнет - меняться ничего не будет, потому что незачем. Причина более, чем уважительная - "не сломалось - не чини".
А менеджмент и дальше будет языками зачёсывать, что-де, надо быть проактивными, решать проблемы прежде, чем они в полный рост встанут.
Нет, Гэри.
Пока метастазы не пойдут - никто и не почешется.
Легаси - это то, что мы не понимаем, понимать и поддерживать не хотим и вообще это NIH. А рефакторинг не нужен, родной!
В действительности, вы не туда смотрите. Фундамент метастазирования индустрии мало того, что заложен не вчера - он практически непобедим и болеет совсем не только ИТ.
Фундаментальных проблем две и они системные.
Первая - менеджмент. Целями менеджмента являются две вещи - больше хэдкаунта, больше бюджетов - больше значимости. Карьерный рост (менеджера), KPI, бонусы - вот это вот всё. Оптимизация - в смысле сокращения хэдкаунта и бюджетов - которая имеет смысл с точки зрения собственников - наемному менеджеру ортогональна. Собственники, однако, на другой планете живут - пока худо-бедно что-то крутится, прибыль - какая-никакая - идет - им глубочайшим образом плевать, что там под капотом творится. Надо купить полтысячи серверов? Да и пофиг, это всего лишь деньги. Пока их хватает. Оптимизация? Рефакторинг? Да на кой?! Тайм ту маркет - вот что важно, нужно и значимо. А пользователи - да куда они денутся-то, с подводной лодки. Все так делают. Рыночек выбирает между плохо и очень плохо.
Вторая - исполнители. То, что software engeneering это, в первую очередь, engeneering - всем плевать. Инженерный ВУЗ - не нужен. Он не учит тому, что надо исполнителям - а именно, ремесленничеству (всеобщий плачь Ярославны о том, почему в инженерных ВУЗах учат какой-то абстрактной ненужной хрени, а не нажимать кнопки и пользоваться инструментами - привет, МУИТ!). Никто не видит главного - инженерия это подходы к решению задач в условиях ограничений. Вертикальное масштабирование? Оно не модно и не нужно. Слишком сложна-сложна-сложна. Проще навалить в горизонталь несколько сот серверов, обмазать очередями, гонять по сети гигабайты, вытереть ноги об Амдаля и Уэра. Архитектура? А куда это? Кроссплатформенность? Нинужна, есть докеры и куберы. Адище зависимостей? Упс, ну и что? Чотаковата? Все так делают. И менеджер рад, когда ИТ департамент шавермячной - две сотни человек на четыре сотни серверов в облаках. И инженерам без дипломов и малейшего представления, что такое инженерия, есть, чем заняться.
Чтобы хотя бы попытаться побороть эти две проблемы, Конана-Варвара и даже Геракла определенно будет маловато. Даже Илон слишком мелковат по своим масштабам и эксцентричности, чтобы поотрубать все головы этой Лернейской Гидре.
Рыночек порешал. Все побежали - и я побежал.
Именно поэтому - слова "техдолг", "рефакторинг", "оптимизация" (под которой понимают в самом лучшем случае поиск волшебного параметра, а в худшем - э, заменим HDD на SSD, подсыпем корочек процессорных, принесем чемодан плашек памяти - вот и вся оптимизация) в индустрии матерные.
А всё, что мы не будем рефакторить, убирая техдолг - автоматически идет в категорию "легаси". А мы не будем ничего рефакторить, изобретая тысячи уважительных причин, потому что не хотим (в первую очередь) и не умеем (во вторую).
Finally, ну и, как и всегда и со всех сторон - человеческая природа непобедима. Гром не грянет - мужик не перекрестится. До тех пор, пока не полыхнет - меняться ничего не будет, потому что незачем. Причина более, чем уважительная - "не сломалось - не чини".
А менеджмент и дальше будет языками зачёсывать, что-де, надо быть проактивными, решать проблемы прежде, чем они в полный рост встанут.
Нет, Гэри.
Пока метастазы не пойдут - никто и не почешется.
Документацию пишут только трусы
Благими намерениями, меж тем, устлана дорога известно куда.
Вроде бы, все всё понимают - за все хорошее и против всего плохого.
Но даже README за 20+ лет никто не удосужился начать прилично писать.
Один простой пример.
Практически ни в одном ридми к опенсурсным пакетам нет такой простой и очевидной вещи, как списка требуемых зависимостей - в самом начале, до того, как начинают идти команды
Соответственно, об отсутствующих зависимостях вы узнаёте лишь тогда, когда make начинает гавкать при сборке на отсутствие хидеров, библиотек, неполных описаний структур, отсутствующих или несовместимых функциях, и тому подобных радостях сисадминов. Что происходит почти всегда, если надо что-то нетривиальное собрать из исходников - просто потому, что мэнтайнеры не посчитали достойным включения в репо. Или включили, но собрали на своё усмотрение. Или собрали, но криво. Сто причин.
Знакомая ситуация, не так ли?
При этом всеми обгавканный autoconf вполне себе умеет в проверку наличия депендентов, хидеров, функций, а код можно писать с ветвлениями, позволяющими ему собираться на чем угодно и при почти любых установленных наборах зависимостей (привет докерофилам). Посмотрите, например, портабельный OpenSSH. Или любой другой пакет (да, их исчезающе мало), написанный командами натуралов. Без всяких докеров и куберов.
Однако не будем отвлекаться. Вернемся к минимальной документации, к ридми.
Всем известно, что программисты ненавидят писать документацию (и даже комментарии к коду, что еще можно было бы простить).
Однако, если ты делаешь свою работу - даже если ее никто никогда не увидит, копеешный пет-проектик на гитхабе для самоутверждения - надо делать ее хорошо. Это "хорошо" включает в себя более-менее приличный ридми, который должен объяснять почти все и отвечать на большинство вопросов, могущих возникнуть на этапах сборки и базового применения пакета.
Если ты не можешь такую работу прилично делать от начала и до конца - возможно, за нее вообще не стоит браться.
Вчитываться в код и разбираться, почему работает так, а не иначе, почему не собирается на платформе XXXX - будет совсем не каждый.
Более того, это и нужно далеко не каждому.
Следовательно, даже если это противоречит концепциям айджайла-скрама, даже если документацию никто, в конечном итоге, не откроет - ее надо писать.
Завязаны шнурки или нет.
PS. Согласно так же всеми оплёванной концепции водопада, "кодирование, тестирование и документирование выполняется одновременно". Отцы-основатели тоже понимали, что программисты документировать не любят и надо, по-возможности, поймать их на берегу и заставить-таки писать.
Благими намерениями, меж тем, устлана дорога известно куда.
Вроде бы, все всё понимают - за все хорошее и против всего плохого.
Но даже README за 20+ лет никто не удосужился начать прилично писать.
Один простой пример.
Практически ни в одном ридми к опенсурсным пакетам нет такой простой и очевидной вещи, как списка требуемых зависимостей - в самом начале, до того, как начинают идти команды
configure && make && make install.Соответственно, об отсутствующих зависимостях вы узнаёте лишь тогда, когда make начинает гавкать при сборке на отсутствие хидеров, библиотек, неполных описаний структур, отсутствующих или несовместимых функциях, и тому подобных радостях сисадминов. Что происходит почти всегда, если надо что-то нетривиальное собрать из исходников - просто потому, что мэнтайнеры не посчитали достойным включения в репо. Или включили, но собрали на своё усмотрение. Или собрали, но криво. Сто причин.
Знакомая ситуация, не так ли?
При этом всеми обгавканный autoconf вполне себе умеет в проверку наличия депендентов, хидеров, функций, а код можно писать с ветвлениями, позволяющими ему собираться на чем угодно и при почти любых установленных наборах зависимостей (привет докерофилам). Посмотрите, например, портабельный OpenSSH. Или любой другой пакет (да, их исчезающе мало), написанный командами натуралов. Без всяких докеров и куберов.
Однако не будем отвлекаться. Вернемся к минимальной документации, к ридми.
Всем известно, что программисты ненавидят писать документацию (и даже комментарии к коду, что еще можно было бы простить).
Однако, если ты делаешь свою работу - даже если ее никто никогда не увидит, копеешный пет-проектик на гитхабе для самоутверждения - надо делать ее хорошо. Это "хорошо" включает в себя более-менее приличный ридми, который должен объяснять почти все и отвечать на большинство вопросов, могущих возникнуть на этапах сборки и базового применения пакета.
Если ты не можешь такую работу прилично делать от начала и до конца - возможно, за нее вообще не стоит браться.
Вчитываться в код и разбираться, почему работает так, а не иначе, почему не собирается на платформе XXXX - будет совсем не каждый.
Более того, это и нужно далеко не каждому.
Следовательно, даже если это противоречит концепциям айджайла-скрама, даже если документацию никто, в конечном итоге, не откроет - ее надо писать.
Завязаны шнурки или нет.
PS. Согласно так же всеми оплёванной концепции водопада, "кодирование, тестирование и документирование выполняется одновременно". Отцы-основатели тоже понимали, что программисты документировать не любят и надо, по-возможности, поймать их на берегу и заставить-таки писать.
Latency vs throughput, часть 1
Как известно, это два разных показателя производительности и две разных стратегии оптимизации. Причем ортогональные, в большинстве случаев.
За latency принято считать скорость отклика от поступления запроса до начала ответа сервера. В терминологии реляционных баз данных, это хинт оптимизации FIRST_ROWS. В базах данных, оптимизатор выбирает алгоритмы выполнения таким образом, чтобы строки как можно скорее начали выбираться и поступать клиенту. Обычно это алгоритмы типа nested loops, с квадратичной сложностью. Узким местом является сам алгоритм и его производительность, которая и ограничивает темп прокачки данных и, в целом, время выполнения запроса.
Througput, в противовес latency, ограничен лишь пропускной способностью железа. В реляционных БД это хинт ALL_ROWS, нацеленный на общее время выполнения запроса, а не на скорость его отклика и зависящий, в основном, от пропускной способности железа по IO. Оптимизатор выбирает алгоритмы типа hash join, имеющие сложность O(n log n) и им подобные. Узким местом является потребляемая память и пропускная способность железа.
Одновременно эти два показателя являются чрезвычайно труднодостижимыми - лишь очень дорогое и высококлассное железо способно достигнуть их одновременно. С точки зрения алгоритмики, это вообще принципиально недостижимо.
По этой причине, многие программные решения имеют взаимоисключающий параметр (как logbias в ZFS или хинты глобальных целей оптимизатора СУБД Oracle), когда приходится делать выбор - что важнее, latency или throughput.
Если говорить об аллокациях памяти, то, в силу специфики алгоритмов, аллокаторы влияют в наибольшей степени именно на latency. В общем случае, именно там в процессе выполнения запроса, от начала и до конца, выполняется масса аллокаций памяти. Для алгоритмов throughput, память, как правило, выделяется в виде shared (в СУБД) или private buffers один раз и переиспользуется до конца запроса.
Именно поэтому аллокаторы практически никак не влияют на IO bound операции.
Следует иметь в виду также вот что. Микросервисные системы - на 3/4 являются IO bound. Сетевые операции - это IO. С одной стороны, latency для них как бы важна. С другой - IO всегда упирается в hardware throughput. С точки зрения практики, это означает, что микросервисы всегда лимитированы сетью и почти не поддаются нормальным методам оптимизации. Причем даже в тех случаях, если коммуникации осуществляются по loopback, никаких чудес не происходит и это по-прежнему сетевой IO.
С точки зрения оптимизации производительности, микросервисы являются заведомо проигрышной архитектурой. С практической невозможностью связать разрозненные части системы через прямой обмен в памяти, сериализацией-десериализацией и другими прелестями межсетевых обменов. И принципиальной невозможностью каких-либо вменяемых оптимизационных методов, кроме наращивания мощностей и пропускной способности каналов связи.
Производители железа пьют до синевы в своих офисах за здоровье девопсов, соорудивших этот портал в Ад.
Справедливости ради, стоит отметить, что сетевой IO и раньше был проблемой, во времена монолитов и старфайров. Это, в частности, одна из причин, почему распределенные системы не получили широкого распространения - из-за непредсказуемой латентности. В силу чего для IO вообще и сетевого IO в частности резервировались отдельные процессоры, занимавшиеся только и исключительно вводом-выводом. И было такое, почти забытое ныне понятие, как "сбалансированная конфигурация".
В этой связи, было очевидно плохой идеей создание архитектур и подходов, многократно наращивающих этот самый ввод-вывод.
Как и было неоднократно сказано ранее - архитектурные ошибки обходятся максимально дорого и их практически невозможно исправить.
Как известно, это два разных показателя производительности и две разных стратегии оптимизации. Причем ортогональные, в большинстве случаев.
За latency принято считать скорость отклика от поступления запроса до начала ответа сервера. В терминологии реляционных баз данных, это хинт оптимизации FIRST_ROWS. В базах данных, оптимизатор выбирает алгоритмы выполнения таким образом, чтобы строки как можно скорее начали выбираться и поступать клиенту. Обычно это алгоритмы типа nested loops, с квадратичной сложностью. Узким местом является сам алгоритм и его производительность, которая и ограничивает темп прокачки данных и, в целом, время выполнения запроса.
Througput, в противовес latency, ограничен лишь пропускной способностью железа. В реляционных БД это хинт ALL_ROWS, нацеленный на общее время выполнения запроса, а не на скорость его отклика и зависящий, в основном, от пропускной способности железа по IO. Оптимизатор выбирает алгоритмы типа hash join, имеющие сложность O(n log n) и им подобные. Узким местом является потребляемая память и пропускная способность железа.
Одновременно эти два показателя являются чрезвычайно труднодостижимыми - лишь очень дорогое и высококлассное железо способно достигнуть их одновременно. С точки зрения алгоритмики, это вообще принципиально недостижимо.
По этой причине, многие программные решения имеют взаимоисключающий параметр (как logbias в ZFS или хинты глобальных целей оптимизатора СУБД Oracle), когда приходится делать выбор - что важнее, latency или throughput.
Если говорить об аллокациях памяти, то, в силу специфики алгоритмов, аллокаторы влияют в наибольшей степени именно на latency. В общем случае, именно там в процессе выполнения запроса, от начала и до конца, выполняется масса аллокаций памяти. Для алгоритмов throughput, память, как правило, выделяется в виде shared (в СУБД) или private buffers один раз и переиспользуется до конца запроса.
Именно поэтому аллокаторы практически никак не влияют на IO bound операции.
Следует иметь в виду также вот что. Микросервисные системы - на 3/4 являются IO bound. Сетевые операции - это IO. С одной стороны, latency для них как бы важна. С другой - IO всегда упирается в hardware throughput. С точки зрения практики, это означает, что микросервисы всегда лимитированы сетью и почти не поддаются нормальным методам оптимизации. Причем даже в тех случаях, если коммуникации осуществляются по loopback, никаких чудес не происходит и это по-прежнему сетевой IO.
С точки зрения оптимизации производительности, микросервисы являются заведомо проигрышной архитектурой. С практической невозможностью связать разрозненные части системы через прямой обмен в памяти, сериализацией-десериализацией и другими прелестями межсетевых обменов. И принципиальной невозможностью каких-либо вменяемых оптимизационных методов, кроме наращивания мощностей и пропускной способности каналов связи.
Производители железа пьют до синевы в своих офисах за здоровье девопсов, соорудивших этот портал в Ад.
Справедливости ради, стоит отметить, что сетевой IO и раньше был проблемой, во времена монолитов и старфайров. Это, в частности, одна из причин, почему распределенные системы не получили широкого распространения - из-за непредсказуемой латентности. В силу чего для IO вообще и сетевого IO в частности резервировались отдельные процессоры, занимавшиеся только и исключительно вводом-выводом. И было такое, почти забытое ныне понятие, как "сбалансированная конфигурация".
В этой связи, было очевидно плохой идеей создание архитектур и подходов, многократно наращивающих этот самый ввод-вывод.
Как и было неоднократно сказано ранее - архитектурные ошибки обходятся максимально дорого и их практически невозможно исправить.
Latency vs throughput, часть 2
Означает ли вышесказанное, что тюнить бессмысленно, в том числе микросервисы?
Нет, не означает.
На практике, оптимизация производительности в целом имеет ошибочное целеполагание.
А именно, в вольном пересказе с менеджерского - "Мы сейчас найдем васю или своих подпряжем, чтобы они за самый мелкий прайс, по остаточному принципу, сделали втереть или вправить или еще что-нибудь. Волшебный параметр, там, найдут, не знаю - они ж специалисты".
В самых лучших традициях Джеймса Уатта с его 1001 долларом и кувалдой.
Как правило, такое происходит, когда тюнить, даже в правильном исполнении, уже поздно и нужно экстренно тушить пожар - когда мониторинги горят красным цветом и истошно вопят.
Первое и самое главное - в большинстве случаев совершается три огромные ошибки:
1. Тюнинг фрагментарен. А именно, и его первая часть - сбор и анализ статистики, и вторая - собственно оптимизация - предельно точечны и, либо покрывают лишь небольшие фрагменты системы либо оставляют достаточно белых пятен по принципу "База Постгрес тормозить не может, аминь!"
Если вы не наблюдаете (тот самый термин "observability") систему сколько-нибудь полно, вы не можете ее поведение анализировать и, следовательно, эту систему тюнить.
2. Тюнинг хаотичен. Те, кто его выполняет, не руководствуются какой бы то ни было системой (пусть даже самой плохонькой) или методом и просто хаотично кидаются на видимые ботлнеки (даже на секунду не задумываясь о законе ограничений Голдрата) и пытаются их устранить, в надежде в одной итерации весь тюнинг и закончить - что является еще одной серьезной ошибкой. Крутить одновременно несколько ручек - плохая стратегия, надеяться одним ударом достичь всех целей тюнинга - еще более плохая стратегия. Такие подходы обычно заканчиваются либо тем, что оптимизация упирается в необходимость точечных или глобальных изменений архитектуры или кода; либо тем, что тюнинг прерывается в соответствии с поговоркой "Сделай плохо а потом верни, как было".
Однако существующие методики тюнингов транзактабельны - то есть, вы либо доводите тюнинг до конца, либо целиком откатываете и больше за него не беретесь. По крайней мере, в текущем виде.
3. Тюнинг реактивен. В точку - о нем задумываются, когда уже слишком поздно. В этом случае не получится ни дешево, ни безболезненно - будет страшно дорого и ужассссно больно. Как запущенный случай парадонтоза в стоматологии - только удалять и протезировать 18 зубов. И потом все равно придется перестроенную до основания систему тюнить. Снова. Чтобы избежать повторения ситуации.
Может показаться, что процесс оптимизации абсолютно контринтуитивен. Это, вообще говоря, не вполне верно.
Вторая проблема тюнингов - они об архитектуре в бОльшей степени, чем кажется. Конкретно - необходимо видеть архитектуру системы в целом, ясно понимать ее функционирование под капотом - от начала и до конца, от поступления данных извне до записи логов. И, кроме этого, обладать сверхспособностью детализации с высоты птичьего полета до любой, самой мелкой детали.
Дьявол - в деталях. В оптимизации бывают как огромные проблемы, настолько крупные и видимые, что их никто не замечает - так и маленькие детальки, обладающие, однако, огромным влиянием на поведение систем. Например, один маленький мьютекс. В горячем месте. И его достаточно, чтобы положить огромную систему на лопатки. Всю, целиком. Хоть монолитную, хоть распределенную.
Помноженное на кучу микросервисов, все это приводит к идее, что реактивный тюнинг, в случае распределенных архитектур, контрпродуктивен. И необходимо последовательно, методично и обдуманно, шаг за шагом выполнять необходимые шаги, придерживаясь хоть каких - но методов - для всей системы в целом.
Означает ли вышесказанное, что тюнить бессмысленно, в том числе микросервисы?
Нет, не означает.
На практике, оптимизация производительности в целом имеет ошибочное целеполагание.
А именно, в вольном пересказе с менеджерского - "Мы сейчас найдем васю или своих подпряжем, чтобы они за самый мелкий прайс, по остаточному принципу, сделали втереть или вправить или еще что-нибудь. Волшебный параметр, там, найдут, не знаю - они ж специалисты".
В самых лучших традициях Джеймса Уатта с его 1001 долларом и кувалдой.
Как правило, такое происходит, когда тюнить, даже в правильном исполнении, уже поздно и нужно экстренно тушить пожар - когда мониторинги горят красным цветом и истошно вопят.
Первое и самое главное - в большинстве случаев совершается три огромные ошибки:
1. Тюнинг фрагментарен. А именно, и его первая часть - сбор и анализ статистики, и вторая - собственно оптимизация - предельно точечны и, либо покрывают лишь небольшие фрагменты системы либо оставляют достаточно белых пятен по принципу "База Постгрес тормозить не может, аминь!"
Если вы не наблюдаете (тот самый термин "observability") систему сколько-нибудь полно, вы не можете ее поведение анализировать и, следовательно, эту систему тюнить.
2. Тюнинг хаотичен. Те, кто его выполняет, не руководствуются какой бы то ни было системой (пусть даже самой плохонькой) или методом и просто хаотично кидаются на видимые ботлнеки (даже на секунду не задумываясь о законе ограничений Голдрата) и пытаются их устранить, в надежде в одной итерации весь тюнинг и закончить - что является еще одной серьезной ошибкой. Крутить одновременно несколько ручек - плохая стратегия, надеяться одним ударом достичь всех целей тюнинга - еще более плохая стратегия. Такие подходы обычно заканчиваются либо тем, что оптимизация упирается в необходимость точечных или глобальных изменений архитектуры или кода; либо тем, что тюнинг прерывается в соответствии с поговоркой "Сделай плохо а потом верни, как было".
Однако существующие методики тюнингов транзактабельны - то есть, вы либо доводите тюнинг до конца, либо целиком откатываете и больше за него не беретесь. По крайней мере, в текущем виде.
3. Тюнинг реактивен. В точку - о нем задумываются, когда уже слишком поздно. В этом случае не получится ни дешево, ни безболезненно - будет страшно дорого и ужассссно больно. Как запущенный случай парадонтоза в стоматологии - только удалять и протезировать 18 зубов. И потом все равно придется перестроенную до основания систему тюнить. Снова. Чтобы избежать повторения ситуации.
Может показаться, что процесс оптимизации абсолютно контринтуитивен. Это, вообще говоря, не вполне верно.
Вторая проблема тюнингов - они об архитектуре в бОльшей степени, чем кажется. Конкретно - необходимо видеть архитектуру системы в целом, ясно понимать ее функционирование под капотом - от начала и до конца, от поступления данных извне до записи логов. И, кроме этого, обладать сверхспособностью детализации с высоты птичьего полета до любой, самой мелкой детали.
Дьявол - в деталях. В оптимизации бывают как огромные проблемы, настолько крупные и видимые, что их никто не замечает - так и маленькие детальки, обладающие, однако, огромным влиянием на поведение систем. Например, один маленький мьютекс. В горячем месте. И его достаточно, чтобы положить огромную систему на лопатки. Всю, целиком. Хоть монолитную, хоть распределенную.
Помноженное на кучу микросервисов, все это приводит к идее, что реактивный тюнинг, в случае распределенных архитектур, контрпродуктивен. И необходимо последовательно, методично и обдуманно, шаг за шагом выполнять необходимые шаги, придерживаясь хоть каких - но методов - для всей системы в целом.
Latency vs throughput, часть 3
Вернемся к тому, с чего начали. К latency.
Что представляет сегодня огромная часть систем? Массу распределенных мелких кусочков, обменивающихся - чем? - правильно, текстом. JSON over HTTP(S) по сети.
Может показаться - ачотаковата? Все так делают.
Увы.
Оставив в стороне текст, посмотрим глубже. Что есть обработка текстов?
Правильно - это строки. Строки - это динамические контейнеры. На куче. В современном мире - крупные контейнеры. Зачастую, 64к или даже более.
Миллионы аллокаций в секунду (как правило) при копированиях, парсинге, поисках-заменах (посмотрите, сколько реаллокаций может сделать replace() из string).
SGI Ropes не просто так придумали и собственные реализации-обертки поверх C-strings тоже пишутся не просто так. Кто слышал о Ropes? Поднимите руки. Никто? Как же так, Карл? Может, на SO натыкались на упоминание? Оно там одно. Нет, и там не видели?
Самым правильным, конечно же, было бы глобально минифицировать обмены (и киты это очень часто и делают - могут себе позволить) использованием бинарного протокола, верно? И сеть меньше грузится, и с байтами оперировать проще, чем со строками по 64к. protobuf - не просто так Гугл выдумал. Казалось бы, вот то здравое зерно, которое реально стоило бы позаимствовать у китов.
Взамен того, что маленькой такой компании - не Локхид-Мартину, не имеющей масштабов Гугла, не нужно абсолютно.
Однако же, нет. Мы будем гонять тексты терабайтами по сети и обрабатывать их построчно (вы же не знаете иного способа обработки текстов, верно? И никто не знает). Почему? "Потому, что можем".
Усугубляется эта ситуация, конечно же, оверкоммитом. Когда вы до обращения к памяти на запись знать не знаете - выделилась она или нет, на самом-то деле.
Строки. Плюс оверкоммит.
Вот и вся лейтенси. Она становится непредсказуемой.
Пропускная же способность имеет физический предел, определяемый возможностями оборудования и кодом, который на нем крутится - да, алгоритмы тоже имеют пропускную способность.
И, зачастую, кроме попыток распараллеливания (здравствуй, NVMe), радикально ее улучшить сложно или очень дорого (здравствуй, 10 Gb Ethernet и 40 Gb Infiniband - упс, простите, на инфинибэнд не хватило, вот вам Ethernet 40 Gb и даже о джамбо-фреймах слышал далеко не каждый девопс. FC-AL? Да мы и не слышали никогда о таком, в нашей малюсенькой такой компании на 200+ сотрудников, верно?).
На таком фоне, если оглянуться вокруг, недостатки монолитов как-то меркнут.
Однако, факт в том, что необходимости оптимизации все вышесказанное не отменяет.
И - да, подобно безопасности, оптимизация производительности не продукт, а процесс.
Зачастую, принципиально противоречащий краеугольной концепции TTM.
Альтернатива, однако же, много хуже. Наращивать вычислительные мощи до бесконечности не получится.
Вернемся к тому, с чего начали. К latency.
Что представляет сегодня огромная часть систем? Массу распределенных мелких кусочков, обменивающихся - чем? - правильно, текстом. JSON over HTTP(S) по сети.
Может показаться - ачотаковата? Все так делают.
Увы.
Оставив в стороне текст, посмотрим глубже. Что есть обработка текстов?
Правильно - это строки. Строки - это динамические контейнеры. На куче. В современном мире - крупные контейнеры. Зачастую, 64к или даже более.
Миллионы аллокаций в секунду (как правило) при копированиях, парсинге, поисках-заменах (посмотрите, сколько реаллокаций может сделать replace() из string).
SGI Ropes не просто так придумали и собственные реализации-обертки поверх C-strings тоже пишутся не просто так. Кто слышал о Ropes? Поднимите руки. Никто? Как же так, Карл? Может, на SO натыкались на упоминание? Оно там одно. Нет, и там не видели?
Самым правильным, конечно же, было бы глобально минифицировать обмены (и киты это очень часто и делают - могут себе позволить) использованием бинарного протокола, верно? И сеть меньше грузится, и с байтами оперировать проще, чем со строками по 64к. protobuf - не просто так Гугл выдумал. Казалось бы, вот то здравое зерно, которое реально стоило бы позаимствовать у китов.
Взамен того, что маленькой такой компании - не Локхид-Мартину, не имеющей масштабов Гугла, не нужно абсолютно.
Однако же, нет. Мы будем гонять тексты терабайтами по сети и обрабатывать их построчно (вы же не знаете иного способа обработки текстов, верно? И никто не знает). Почему? "Потому, что можем".
Усугубляется эта ситуация, конечно же, оверкоммитом. Когда вы до обращения к памяти на запись знать не знаете - выделилась она или нет, на самом-то деле.
Строки. Плюс оверкоммит.
Вот и вся лейтенси. Она становится непредсказуемой.
Пропускная же способность имеет физический предел, определяемый возможностями оборудования и кодом, который на нем крутится - да, алгоритмы тоже имеют пропускную способность.
И, зачастую, кроме попыток распараллеливания (здравствуй, NVMe), радикально ее улучшить сложно или очень дорого (здравствуй, 10 Gb Ethernet и 40 Gb Infiniband - упс, простите, на инфинибэнд не хватило, вот вам Ethernet 40 Gb и даже о джамбо-фреймах слышал далеко не каждый девопс. FC-AL? Да мы и не слышали никогда о таком, в нашей малюсенькой такой компании на 200+ сотрудников, верно?).
На таком фоне, если оглянуться вокруг, недостатки монолитов как-то меркнут.
Однако, факт в том, что необходимости оптимизации все вышесказанное не отменяет.
И - да, подобно безопасности, оптимизация производительности не продукт, а процесс.
Зачастую, принципиально противоречащий краеугольной концепции TTM.
Альтернатива, однако же, много хуже. Наращивать вычислительные мощи до бесконечности не получится.
TheCacheWorks pinned «Рак разъедающий Легаси - это то, что мы не понимаем, понимать и поддерживать не хотим и вообще это NIH. А рефакторинг не нужен, родной! В действительности, вы не туда смотрите. Фундамент метастазирования индустрии мало того, что заложен не вчера - он практически…»
Пять, шесть - Фредди всех вас хочет съесть
С нумерацией версий в индустрии уже много лет творится какое-то безумие.
Общепринятая схема всегда была следующей:
Мажорная версия - минорная версия - патч - фикс.
X.X.X.X. Плюс-минус.
И всегда было по номеру версии более-менее ясно, чего ожидать от обновления.
NB. Изменение мажорной версии на единицу означало просто тектонические изменения. Во всяком случае, должно означать.
Что мы имеем сейчас? Маркетологическую чушь. "Мама, я добавил темную тему! Увеличим мажорную версию, ура!"
"Мы добавили новую свистоперделку сбоку - мажорная версия увеличивается, гип-гип!"
Нумерология - наука о чиселках.
Доходит до абсурда.
Такая нечеловечески сложная вещь, как Оракл - десятки миллионов строк кода - щелкает вообще мажорные версии через две или три. Что? Это должно означать, что бОльшая часть кода переписана? Как бы не так. Это просто маркетинг и ничего более - "Мы прикрутили AI - неважно, куда - плюс три мажорных версии".
Вероятно, Ларри на старости лет выжил из ума.
Файрфокс 126 версии. Ребята, у вас как с кукушечкой, вообще? Все хорошо? Что, вы кардинально перелопатили весь код снизу доверху? Или хотя бы переписали его бОльшую часть? Серьезно поменяли алгоритмы? Что?
LibreOffice. Была нормальная схема нумерации. Бац - и в 2024м 7.6.X внезапно делает скачок на 17 мажорных версий. Семнадцать, Карл. Это должно означать 17 крупных переделок? Нет, ничего подобного. Мы просто теперь каждый год будем увеличивать мажорный номер, по номеру года. Ненуачо? Все же так делают. Нормально же. Стильно - модно - молодежно.
Заповедники, где осталась прежняя, сколько-нибудь логичная, схема нумерации - можно по пальцам одной руки пересчитать. Буквально.
А вы что хотите делайте. Хотите - ченджлоги читайте. Хотите - верьте им.
Блажен, кто верует.
С нумерацией версий в индустрии уже много лет творится какое-то безумие.
Общепринятая схема всегда была следующей:
Мажорная версия - минорная версия - патч - фикс.
X.X.X.X. Плюс-минус.
И всегда было по номеру версии более-менее ясно, чего ожидать от обновления.
NB. Изменение мажорной версии на единицу означало просто тектонические изменения. Во всяком случае, должно означать.
Что мы имеем сейчас? Маркетологическую чушь. "Мама, я добавил темную тему! Увеличим мажорную версию, ура!"
"Мы добавили новую свистоперделку сбоку - мажорная версия увеличивается, гип-гип!"
Нумерология - наука о чиселках.
Доходит до абсурда.
Такая нечеловечески сложная вещь, как Оракл - десятки миллионов строк кода - щелкает вообще мажорные версии через две или три. Что? Это должно означать, что бОльшая часть кода переписана? Как бы не так. Это просто маркетинг и ничего более - "Мы прикрутили AI - неважно, куда - плюс три мажорных версии".
Вероятно, Ларри на старости лет выжил из ума.
Файрфокс 126 версии. Ребята, у вас как с кукушечкой, вообще? Все хорошо? Что, вы кардинально перелопатили весь код снизу доверху? Или хотя бы переписали его бОльшую часть? Серьезно поменяли алгоритмы? Что?
LibreOffice. Была нормальная схема нумерации. Бац - и в 2024м 7.6.X внезапно делает скачок на 17 мажорных версий. Семнадцать, Карл. Это должно означать 17 крупных переделок? Нет, ничего подобного. Мы просто теперь каждый год будем увеличивать мажорный номер, по номеру года. Ненуачо? Все же так делают. Нормально же. Стильно - модно - молодежно.
Заповедники, где осталась прежняя, сколько-нибудь логичная, схема нумерации - можно по пальцам одной руки пересчитать. Буквально.
А вы что хотите делайте. Хотите - ченджлоги читайте. Хотите - верьте им.
Блажен, кто верует.
