Люди и не должны понимать ООП
За десятки лет концепции она не только не смогла стать сколько-нибудь массовой, но и обросла рудиментами императивщины и другими придатками из совершенно других областей, превратившись в неудобоваримого монстра.
Так бывает, когда маложизнеспособные концепции по методу мартышка-и-очко пытаются без разбора прикладывать к чему угодно, по принципу "технология отчаянно ищет себе хоть какое-нибудь применение".
Справедливости ради, стоит отметить, что ООП привнесла немало полезного, например, концепции композиции (вместо наследования) и 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 в частности резервировались отдельные процессоры, занимавшиеся только и исключительно вводом-выводом. И было такое, почти забытое ныне понятие, как "сбалансированная конфигурация".
В этой связи, было очевидно плохой идеей создание архитектур и подходов, многократно наращивающих этот самый ввод-вывод.
Как и было неоднократно сказано ранее - архитектурные ошибки обходятся максимально дорого и их практически невозможно исправить.
