Здравствуйте, Vetal_ca, Вы писали:
S>>Да я понял что тебе какойто админ дорогу крепко перешёл, травму на всю жизнь оставил. Сочувствую. V_>Я тебе даже ссылки кинул, что можно глянуть не отходя далеко от твоего Ансибла.
По ссылке было про то как тебе админ дорогу перешол? о0
V_>Подрастешь, поймешь, что максимальная жестокость это потакать человеку в его деградации. Чтобы выкинуть на мороз и поржать в итоге когда способность двигаться совсем утрачена.
Вот я и пытаюсь вас в тепло затащить.
Здравствуйте, Sheridan, Вы писали:
C>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается. S>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред.
И категорически совершенно невозможно реализовать откат без докера. дадада.
Здравствуйте, Sheridan, Вы писали:
НС>>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред. S>И категорически совершенно невозможно реализовать откат без докера. дадада.
Возможно, но сложее.
Однако, опять топорная попытка сменить тему. Возможность отката уже не бредовый бред, да?
S>По ссылке было про то как тебе админ дорогу перешол? о0
Н-да, самый тяжелый случай. Сколько тебе до пенсии осталось, Шеридан? Дотянешь?
Может, кризис поможет, голод и неопределенность это базовые чувства, работают и на таких вот, полностью застывших в невежестве.
S>Вот я и пытаюсь вас в тепло затащить.
На самое днище? Чтобы новички смеялись за спиной и пальцем у виска крутили?
Здравствуйте, gandjustas, Вы писали:
V_>>- чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся. G>Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sheridan, Вы писали:
НС>>>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред. S>>И категорически совершенно невозможно реализовать откат без докера. дадада.
НС>Возможно, но сложее.
Не сказал бы что сложнее. Тысячи разработчиков, пакетирующих свой софт могут а вы — нет.
НС>Возможность отката уже не бредовый бред, да?
А я когдато это утверждал? Я говорил о том что тестировать нужно на своих серверах, и хорошо тестровать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь.
Почему же? Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
Здравствуйте, Vetal_ca, Вы писали:
S>>По ссылке было про то как тебе админ дорогу перешол? о0 V_>Н-да, самый тяжелый случай. Сколько тебе до пенсии осталось, Шеридан? Дотянешь? V_>Может, кризис поможет, голод и неопределенность это базовые чувства, работают и на таких вот, полностью застывших в невежестве.
Застывать в докере не буду без необходимости.
S>>Вот я и пытаюсь вас в тепло затащить. V_>На самое днище? Чтобы новички смеялись за спиной и пальцем у виска крутили?
А, так ты новичок. Тогда всё ок.
Здравствуйте, gandjustas, Вы писали:
НС>>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь. G>Почему же?
Странный вопрос.
G> Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
I/O это не только внешний сторадж. К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь. G>>Почему же?
НС>Странный вопрос.
G>> Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
НС>I/O это не только внешний сторадж.
А что еще?
НС>К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений.
Использовать public cloud для кастомных микросервисов можно только если у вас очень много лишних денег. Монлитное приложение, использующее ресурсы azure (тот же самый azure storage или azure sqldb\cosmosdb) будет не просто в разы, а на порядки более cost-effective.
Здравствуйте, gandjustas, Вы писали:
G>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад.
Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4.
G>Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах.
Если команды разные (а это обычно и подразумевается в случае микросервисов), то стоимость взаимодействия через REST API зачастую даже ниже, чем стоимость взаимодействия через API на богатых языках.
Здравствуйте, gandjustas, Вы писали:
G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса.
Здравствуйте, gandjustas, Вы писали:
НС>>I/O это не только внешний сторадж. G>А что еще?
Еще локальный сторадж и сеть.
НС>>К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений. G>Использовать public cloud для кастомных микросервисов можно только если у вас очень много лишних денег.
Ох как все запущено.
G> Монлитное приложение, использующее ресурсы azure (тот же самый azure storage или azure sqldb\cosmosdb) будет не просто в разы, а на порядки более cost-effective.
С чего бы это? Машина в AKS стоит ровно столько же, сколько standalone VM или VMSS. ACI подороже, но не в разы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад. НС>Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4.
Таких компаний единицы. Настолько мало, что их практики не применимы к тем кто поменьше.
G>>Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах. НС>Если команды разные (а это обычно и подразумевается в случае микросервисов), то стоимость взаимодействия через REST API зачастую даже ниже, чем стоимость взаимодействия через API на богатых языках.
Звучит сказочно. В монолитном приложении один разработчик пойдет и сделает изменение как в вызывающем, так и в вызываемом коде. А если язык нормальный, то компилятор проверит корреткность. Потом задеплоит все одной кнопкой.
Если это разные проекты, то один сделат вызов, второй в это время будет в носу ковыряться со своими задачами, через пару дней поменят вызываемый код, окажется что формат данных у првого и второго не сопадает и вызываемый сервис отдает ошибку. Второй передаст это первому, первый еще пару дней до этого изменения не доберется.
Простая задача в итоге стент большой и сложной.
Я понимаю что есть случаи когда разработка отдельнго приложения дешевле и эффективнее, но это отдельные случаи, их нельзя обобщить до "архитектруного паттерна".
Здравствуйте, Sheridan, Вы писали:
S>>>И категорически совершенно невозможно реализовать откат без докера. дадада. НС>>Возможно, но сложее. S>Не сказал бы что сложнее.
Есть опыт?
S> Тысячи разработчиков, пакетирующих свой софт могут а вы — нет.
Все тысячи умеют в откат? Уверен?
НС>>Возможность отката уже не бредовый бред, да? S>А я когдато это утверждал?
Шеридан, ты совсем уже стыд потерял:
C>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
S>>Версий не несколько, а одна. Ставить не определённую, а свежую.
C>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
НС>Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса.
Это полу-правда.
Там где для монолитного приложения нужно 2-3 человека из 5 чтобы были достаточно скилловыми, то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу. В сумме окажется что скилловых посонов нужно больше.
Здравствуйте, gandjustas, Вы писали:
G>>>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад. НС>>Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4. G>Таких компаний единицы.
Не единицы, даже в РФ. А если еще и в объеме денег и разработчиков посчитать, то как бы не больше половины рынка вышло.
G>Звучит сказочно.
Это не аргумент.
G>Если это разные проекты, то один сделат вызов, второй в это время будет в носу ковыряться со своими задачами, через пару дней поменят вызываемый код, окажется что формат данных у првого и второго не сопадает и вызываемый сервис отдает ошибку. Второй передаст это первому, первый еще пару дней до этого изменения не доберется.
Ситуация с отдельными компонентами одного монолита, разрабатываемыми разными командами, точно такая же. А богатый API делает эту задачу в разы более сложной. В то время как REST принудительно API упрощает и уплощает. Это увеличивает стоимость дизайна API, но снижает потери на взаимодействии команд.
G>Я понимаю что есть случаи когда разработка отдельнго приложения дешевле и эффективнее, но это отдельные случаи
Здравствуйте, gandjustas, Вы писали:
НС>>Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса. G>Это полу-правда.
Это наблюдение.
G>Там где для монолитного приложения нужно 2-3 человека из 5 чтобы были достаточно скилловыми,
Нет. Для монолита нужно примерно 100% скилловых. Причем чем больше монолит, тем выше должна быть скилловость. У меня были в команде люди уровня джуна или миддла. в итоге пришлось от них избавиться и на тот же бюджет нанять меньшее количество сеньоров.
G> то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу.
Не нужно. Достаточно одну высококлассную core team.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>И категорически совершенно невозможно реализовать откат без докера. дадада. НС>>>Возможно, но сложее. S>>Не сказал бы что сложнее. НС>Есть опыт?
Да. С БД, правда, нетривиально, нужен diff хотя бы или бэкапы. А в остальном всё сводится к правилу "намусорил — убери за собой".
S>> Тысячи разработчиков, пакетирующих свой софт могут а вы — нет. НС>Все тысячи умеют в откат? Уверен?
При удалении пакетов из системы как правило остаются лишь изменённые конфиги.
НС>>>Возможность отката уже не бредовый бред, да? S>>А я когдато это утверждал? НС>Шеридан, ты совсем уже стыд потерял: НС>
C>>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
S>>>Версий не несколько, а одна. Ставить не определённую, а свежую.
C>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
НС>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Это ты стыд потерял. Сказанное мной относится не к откату а к тому что нужно ставить свежую для дистрибутива версию либы из репозитория дистрибутива. Что ты осуждаешь, зачем-то вспоминая про откаты.
