ИТ в 2021 все еще не инженерная дисциплина, а магия и искусство.
Вы конечно спросите - не съехал ли ты с глузду, болезный?
Казалось бы, развитие компьютерной техники, математических методов, алгоритмов. Вся мощь электроники доказывает мою неправоту. Однако же есть больной момент в понимании что такое ИТ.
ИТ - это не алгоритм, и не С++, и не b-дерево и быстрая сортировка. ИТ - это все то, что находится с той стороны розетки, ведущей в интернет.
И вот здесь с инженерной дисциплиной становится все не так красиво. Сколько вам надо серверов, сколько коммутаторов и какая скорость на порту, чтобы работала ваша новая модная клевая ИТ система?
Разработчики применили все возможные алгоритмы, все самые клевые и модные технологии. Infrastructure as a code, все дела. А какой процессор должен стоять в этих серверах? Чем глубже я погружаюсь в девопсию формата 20-21, тем более я убеждаюсь, что разрыв между железом и кодерами только увеличивается.
"Мы посовещались и я решил, что мы сделаем 6 электрически развязанных сегментов передачи данных". Итог - на стойку с 8 серверами 12 коммутаторов.
И ведь какое дело, я даже не спорю, может быть так и надо в этом случае. Но где ваш расчет, где формулы и цифры?
Почему вы применили такую схему резервного копирования? Почему, почему, почему?
Инженерное ИТ начинается с формулирования задачи, выраженной в цифрах. Далее все оставшиеся цифры в проекте должны выводиться либо строго из заданных (формулами), либо с применением некоторых формальных аксиом (экспертной оценки, принятой на веру).
Но это не происходит - нету этих расчетов, есть постулирование на уровне "где то сэм-восэм".
Очень нескромно звучит, когда я говорю о себе "я на сегодня являюсь единственным человеком, который хочет ИТ сделать инженерным, и я пишу статьи с методологией расчета, чтобы превратить оценки с потолка в расчетные". Это говорит не обо мне, я никогда не считал себя исключительно технически одаренным - вокруг меня полно людей, куда более погруженных, вплоть до гениальности. Это говорит об индустрии в целом - раз никому не интересно как каждый кусочек (в котором возможно сидит гений) сводится в общую картину - это не инженерная индустрия, а торговля гербалайфом.
Да, я знаю, что есть большие общие теории в больших толстых учебниках, в том числе написанные чуть не в 70х в IBM. Но где из них выдержки, переведенные для младодевопсов, творящих дичь?
Я написал "общую теорию расчета виртуализованных ЦОД" пять лет назад. За это время более 20 тыс прочтений и НОЛЬ критики и значимых замечаний. Ну не может быть, не так уж я хорош как инженер.
ИТ не инженерная дисциплина, а дальше будет только хуже. Увы.
Часть 2. Продолжение.
Продолжая тему нарастующего разрыва "программистов" и реальности. На прошлый мой пост был получены от одного программиста следующие комментарии (приводятся по возможности прямыми цитатами:
- потому что программисту вредно знать об инфраструктуре
Есть мнение, что программисту необязательно изначально писать код под конкретную машину / конфигурацию, поскольку код потеряет портабельность и возможность миграции / развертывания на других машинах. С другим количеством ядер, процессоров, памяти и так далее.
Но утверждать, что *вредно знать* - это, извините, перебор на уровне "я не знаю и знать не хочу". Код будет исполняться не только на конкретной машине с конкретными процессорами, но так же в конкретном сетевом окружении с конкретными скоростями и задержками, и работать с данными, которые будут лежать не на абстрактном хранилище, а обладающем определенной функционостью. Дедупликация, репликация, мгновенные снимки и так далее. Если руководствоваться логикой "вредно знать", то единственный вариант обеспечения производительности и защиты данных - это КАЖДЫЙ РАЗ написание полного стека кода, в том числе по защите данных. Однако у нас давно есть интеллектуальные СХД, тесно игтегрированные как с системами резервного копирования, так и с ситемами виртуализации и даже с конкретными приложениями для обеспечения консистентных снимков.
В некоторых случаях надо писать так, словно внизу вообще ничего конкретного. В некоторых - напротив, стоило бы ориентироваться на конретные функции и делегировать определенные операции вниз по стеку, на инфраструктуру.
- посмотрел бы я как 20 лет назад можно было кидать приложения одной кнопкой и масштабировать по метрикаам
Человек открыл для себя скейлинг говнокода в условиях неограниченных ресурсов (облака), а значит все, что было до этого момента - устаревшее говно. Напоминает девочку-подростка "родители, вы устарели и ничего не понимаете в жизни"
- давай, расскажи мне, жава программисту, нахуя мне. numa
- Понимать нуму для коммитов в апстрим необязательно.
- А зачем мне понимать ее для работы?
Здесь и вовсе товарищ сам себя загнал в логическую ловушку. Зачем понимать принцип работы всех серверных процессоров x86 за последние 10лет?
Если, конечно, ослабить степень высказывания и охладить траханье, то будет вполне легитимный инженерный вопрос "а везде ли нужен numa-aware код?" И разумеется нет, далеко не везд нужно так писать. Если твой код "кидает json из браузера в субд", то наверное можно обойтись и без numa.
Но вот тут какой момент, чтобы понимать стоит ли заморачиваться на NUMA-aware код, или это избыточное усложнение - нужно понимать NUMA и как оно работает и как разрабатывается NUMA-aware код.
Нужно ли понимать NUMA глубочайше, если ты разрабатываешь на похапе - снова наверное нет. Но пожалуй стоит понимать базовые принципы архитектуры машин, для которых ты разрабатываешь код. Иначе так и останешься писать на похапе.
Притча во языцех для всех инфраструктурщиков - это 1С и требования 1С к железу. Тест Гилева как эталон.
И вы знаете что? 1С не умеет в NUMA, программисты 1С скорее всего услышат про NUMA случайно. Если вы считаете, что вам этого уровня достаточно, а дальше надо изучать только собственно прикладную часть, бухгалтерию и планы счетов, то у меня и вопросов к вам нет.
Вопросом "сколько серверов и с какими процессорами они должны быть" очевидно должен заниматься кто-то другой.
Но если вы претендуете на хоть сколько нибудь универсальность и занимаетесь развертыванием кода, то заявления "Мне *не нужно знать* базовые архитектурные принципы" - это скорее диагноз.
Бравировка "а вот ты знаешь сколько стоит переписать код" в ответ на "ты сможешь рассчитать требования к аппаратной части под свой код" - это вообще не аргумент. Аргумент
- переписать код, и возможно получить 20% экономию ресурсов - 3000 человеко-часов, полгода задержки и 50млн руб
- докинуть 20% железа - 30млн руб
Это абсолютно нормальный диалог, с нормальными цифрами, показателями и без эль пуканьеро бомабрдини.