Начало в предыдущем посте⤴️
Во втором акте нам нужно создать с нуля все недостающее ПО. Например, нормальную графику, кластерный софт, свой API, инструменты мониторинга и сбора статистики и т.д.
Почему нельзя взять узкоспециализированные необходимые компоненты из открытых источников? Во-первых и в-единственных, потому, что их там нет. Никто в здравом уме не будет выкладывать такие вещи. Люди, которые уже делали нечто подобное, прекрасно помнят, сколько крови и пота ушло на разработку этих решений и очень ценят свой труд.
«Ой, да ладно. В чем проблема написать необходимое ПО? Взял, собрал команду и написал!» – спросит недоверчивый читатель и, возможно, будет в чем-то прав. Но есть проблема, даже две.
Недостаточно просто написать, нужно еще как-то обеспечить совместимость создаваемого софта с исходными программными компонентами и «железом». СХД – это сложная и чувствительная структура, где все элементы должны бесшовно взаимодействовать между собой. И очень много времени и сил уходит на то, чтобы довести не только свой, но и открытый код до ума. Более того, некоторые готовые решения практически полностью переписываются и используются вообще по-другому. Это как с пнем: можно на нем сидеть, можно его сжечь, а можно – использовать для строительства, например. Какой из вариантов будет полезнее? Также и с софтом.
Далее надо не прогореть на этапе проектирования. Для упрощения, допустим, что с архитектурой вроде все понятно – сразу бросаемся в омут с головой и беремся за самые хардкорные задачи. Например, если кластерный модуль, то непременно для high-end.
И как раз тут вылезает вторая проблема (это уже про нашу матушку – Россию). На деле оказывается, что реализовать задумку совсем не просто. Особенно, когда без опыта (а для России это норма, ведь за последние 30 лет у нас делалось не так много СХД, да и специалистов по их разработке нет). И начинается круговорот проблем в разработке – одну решили, продукт заработал, как бац – получите еще парочку.
Процесс стопорится, все расстроены. А ведь это закономерно, мы же не идем на Эльбрус без подготовки? Здесь такая же история. Нужно двигаться от простого к сложному, класть кирпичик за кирпичиком.
💬 Для иллюстрации: свой первый кластерный модуль для mid-range СХД мы создали еще семь лет назад. Он был простым, в том числе с точки зрения отказоустойчивости, но рабочим. Постепенно СХД усложнялась, требования к кластерному ПО увеличивались, навыки и знания команды – тоже. И вот за это время мы переделали компонент 4 или 5 раз, причем почти с нуля.
Ну и до кучи, любая серьезная разработка – это сразу несколько контуров, многочисленные тесты, работа множества отделов. Процесс требует не только значительных ресурсов, но и сильной команды. А кадров не хватает. Особенно в нашей узкоспециализированной области.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт
Во втором акте нам нужно создать с нуля все недостающее ПО. Например, нормальную графику, кластерный софт, свой API, инструменты мониторинга и сбора статистики и т.д.
Почему нельзя взять узкоспециализированные необходимые компоненты из открытых источников? Во-первых и в-единственных, потому, что их там нет. Никто в здравом уме не будет выкладывать такие вещи. Люди, которые уже делали нечто подобное, прекрасно помнят, сколько крови и пота ушло на разработку этих решений и очень ценят свой труд.
«Ой, да ладно. В чем проблема написать необходимое ПО? Взял, собрал команду и написал!» – спросит недоверчивый читатель и, возможно, будет в чем-то прав. Но есть проблема, даже две.
Недостаточно просто написать, нужно еще как-то обеспечить совместимость создаваемого софта с исходными программными компонентами и «железом». СХД – это сложная и чувствительная структура, где все элементы должны бесшовно взаимодействовать между собой. И очень много времени и сил уходит на то, чтобы довести не только свой, но и открытый код до ума. Более того, некоторые готовые решения практически полностью переписываются и используются вообще по-другому. Это как с пнем: можно на нем сидеть, можно его сжечь, а можно – использовать для строительства, например. Какой из вариантов будет полезнее? Также и с софтом.
Далее надо не прогореть на этапе проектирования. Для упрощения, допустим, что с архитектурой вроде все понятно – сразу бросаемся в омут с головой и беремся за самые хардкорные задачи. Например, если кластерный модуль, то непременно для high-end.
И как раз тут вылезает вторая проблема (это уже про нашу матушку – Россию). На деле оказывается, что реализовать задумку совсем не просто. Особенно, когда без опыта (а для России это норма, ведь за последние 30 лет у нас делалось не так много СХД, да и специалистов по их разработке нет). И начинается круговорот проблем в разработке – одну решили, продукт заработал, как бац – получите еще парочку.
Процесс стопорится, все расстроены. А ведь это закономерно, мы же не идем на Эльбрус без подготовки? Здесь такая же история. Нужно двигаться от простого к сложному, класть кирпичик за кирпичиком.
💬 Для иллюстрации: свой первый кластерный модуль для mid-range СХД мы создали еще семь лет назад. Он был простым, в том числе с точки зрения отказоустойчивости, но рабочим. Постепенно СХД усложнялась, требования к кластерному ПО увеличивались, навыки и знания команды – тоже. И вот за это время мы переделали компонент 4 или 5 раз, причем почти с нуля.
Ну и до кучи, любая серьезная разработка – это сразу несколько контуров, многочисленные тесты, работа множества отделов. Процесс требует не только значительных ресурсов, но и сильной команды. А кадров не хватает. Особенно в нашей узкоспециализированной области.
Продолжение ⬇️⬇️
#это_СХД #СХД #разработка #софт