Comments 35
Вот казалось бы, простое правило - если вы, к примеру, менеджер и пишете статью на хабр, пишите о том, в чем разбираетесь, не трогайте технические детали. Но нет, обязательно надо вставить какой-нибудь фейспалм типа
Линукс более стабилен, требует меньшего числа перезагрузок из-за обновлений, работа процессора и файловая система в нем более эффективная.
Добрый день. Мы имели ввиду следующее: если у кроссплатформенного приложения есть выбор, на какой платформе размещаться, то по нашему опыту лучше использовать линукс
Это в среднем по больнице безусловно понятная позиция по самым разным причинам, но в контексте конкретно перевода корп. систем типа ЭДО с MS SQL на Postgres читать то, что я процитировал выше, несколько забавно, по крайней мере с моей колокольни. У вас вообще сколько было кейсов, когда вот эту замену в корп. софте делали именно по означенными причинам? Не тех, что "MS SQL дорого, Оракл еще дороже и вообще они все теперь недружественные, поэтому все-таки придется грызть кактус", а именно потому что работа процессора и файловой системы там эффективная, и вообще этот ваш MS SQL постоянно перезагружать надо? :)
В статье не сказано о необходимости перезагружать MS SQL. Требовать перезапуск и СУБД, и ОС могут ожидающие установки обновления. Об этом и сказано в выводах. Ни слова не было про дорого и недружественно. Заказчик сам пришел к выводу, что замена ОС даст преимущества.
С переходом на линукс решился вопрос с мониторингом веб-приложения СЭД, появилась прозрачность в вопросе производительности. Упростились интеграции продукта с внешними сервисами заказчика. Стало возможным заменить дополнительное ПО, которое раньше не представлялось возможным интегрировать без костылей. А уже в процессе перехода на линукс возникли известные обстоятельства, которые заставили отказаться от MS SQL.
А что собственно с этими тезисами не так?
Linux умеет даже ядро подменять на лету, только иксы перезагрузить, если они нужны. Так что про перезагрузки вроде верно, винда даже в серверном варианте всё таки иногда требует перезагрузить себя.
То, что работа процессора более эффективна конечно спорный момент, но с другой стороны в винде с невырезанной телеметрией и прочим мусором можно считать что тоже верно.
Про файловые системы тоже спорно, но тот же ext4 вроде как быстрее в создании файлов и каталогов, а так-же лучше работает с фрагментацией. Т.е. с натяжкой можно считать что тоже верно. Тем более что мир linux куда проще в натягивании своих файловых систем которые конкретно в вашем сценарии будут производительнее. Zfs какой нибудь.
Я не знаю как это работает но, когда стала переходить на линукс. Первое что заметила, это что диски под ним будто работают шустрее и практически не кряхтят. Даже когда я монтирую ntfs. На винде у этих дисков такой скрежет и тормоза, что кажется вот вот рассыпятся.
Качество системы бессмысленно оценивать по критерию сколько дней/лет она проживет без перезагрузки, времена Novell NetWare когда серваки по 10 лет без рестарта работали закончились.
Качественная система должна переживать перезагрузки без проблем, хоть 2 раза в день ее ребути - она должна стоять и работать.
Применительно к обсуждаемой предметной области с ними не так примерно всё, начиная с того, что это вообще не те параметры, на основании которых заказчиком делается выбор (см. мой коммент выше). А сравнения сферических винды и линукса в вакууме - холивар, который интересен только первые лет 20 работы в ИТ, и то не всем. :)
А где самое веселое?
Как переписать stored procedures с TSQL на Postgres?
Только дошел до самого интересного: на тесте postgres, на проде postgrespro и ожидал историй про отличия и как потом перешли на единый стек.
А тут сразу итог в виде воды....
С точки зрения разработчика, интегратора и техподдержки разумно иметь одинаковый стек во всех контурах. Но не всегда это оправдано. Продукт пишется на ванильном постгресе и архитектура приложения в ITMS использует фичи PgPro, но не явно. То есть, на проде используется pg_repack для перестроения таблиц, а оптимизация плана запроса в про-версии дает выигрыш в производительности. Но эти фичи не так критичны, и таким образом остается обратная совместимость с другими версиями постгрес (ванильная и астра) в контурах разработки, тестирования и предпрода, которые менее требовательны к нагрузке.
Использование про-версии на проде защищает клиента от рисков, связанных с самой СУБД. То же самое касается ОС. К слову, из-за расхождения версий ядер ОС между контурами мы однажды столкнулись с проблемой, когда на тесте она не воспроизводилась, а на проде была. Ситуацию быстро решила команда Астры.
В таком подходе удается сохранить то, что важно для клиента. Для бизнеса важен баланс между совместимостью сред, оптимальными расходами, минимальными рисками возникновения инцидентов из-за разного окружения и возможностью быстро получать профессиональную помощь от первого лица.
Процесс замены ОС и СУБД непростой. Может возникнуть соблазн ничего не менять, но все вопросы решаемы, а результат того стоит.
Я только знаю, что это стоит денег. Если цель в том, что их нужно периодически пилить, то можно не заморачивался так глубоко.
Если имелся ввиду какой-то другой результат, то зачем же было сразу лезть в винду, когда был такой прекрасный линукс? Предыдущие разработчики были дураками? Так может они и в других частях системы так же накодили?
СЭД на Windows + MS SQL разворачивали исходя из устоявшихся технологий и компетенций на стороне заказчика. Когда мы приходим со своим решением, то сложно сходу изменить сложившиеся устои, и как правило приходится работать с тем, что есть.
Да каждый первый программист приходит с таким решением: взять всё и переписать. И ведь речь в данном случае идёт не о легаси, а просто о желании. Так и не понятно, почему все эти затраты "того стоят"? )
У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое. Для конечного пользователя ничего не поменяется, а серверная часть станет другой. Большинство наших клиентов использует линукс с самого начала, и поэтому у нас было наблюдение, что с подобными решениями всегда проще. Система более предсказуемая и проще в обслуживании.
Взять тот же способ подключения. На нетерминальной винде только 2 RDP подключения, одно из которых как правило резервирует сторона заказчика. Сразу двоим сотрудникам невозможно подключиться. Один сеанс тратится на элементарные операции посмотреть лог, например. С учетом сложных схем подключения, скорость, стабильность соединения и возможности прямого чтения или управления в итоге вырождаются в недоразумение.
SSH позволяет все делать одним туннелем и использовать скилы сразу несколько человек. В такой схеме можно использовать средства автоматизации, например Ansible, и подключать системы мониторинга, недоступные на винде. Как дальнейший этап развития, это способ создания конвейеров для поставки сборок на сервер (Docker или традиционный деплоймент).
Сокращение Time to market может быть оправданием затрат на перенос платформы.
У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое.
Просто пил чай и подумал, а не станет ли лучше? И фиг с ними деньгами. Это точно про бизнес?
Для конечного пользователя ничего не поменяется, а серверная часть станет другой
Это как дать юзеру либру вместо мс офиса и сказать, что ничего не поменяется. Поменяется. И риск, что поменяется в худшую сторону, есть. Потому мало кто решается на такое
И систему ещё не переписали, но вывод уже есть, потому что "ну вы ж знаете этот линукс" ))
Насчёт предсказуемости и простоты в обслуживании весьма спорно, тема отдельного холивара. Особенно учитывая выбор поставщика решения
PS. По RDP можно подключаться троим и более, как легально, так и нелегально. И оба способа стоят меньше, чем переписывание системы. Нелегальный так и вовсе бесплатен
Это как дать юзеру либру вместо мс офиса и сказать, что ничего не поменяется. Поменяется. И риск, что поменяется в худшую сторону, есть. Потому мало кто решается на такое
И систему ещё не переписали, но вывод уже есть, потому что "ну вы ж знаете этот линукс" ))
Поделитесь примерами из вашей практики. Из вашего сообщения видно, что вы прочитали статью невнимательно. Речь идет о кроссплатформенном серверном веб-приложении. Изначально это приложение способно работать практически в любых средах, где есть Java. Соответственно сравнение Java-приложения c либрой здесь неуместно. Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
"не столько", вы хотели сказать )
теперь стало яснее. из чего всё-таки вывод, что изначальные разработчики были не очень умны (как я и предполагал сразу), либо исполняли прямой приказ руководства.
пример есть. но не вижу смысла обсуждать прямой приказ заказчика, в котором он потребовал линуксовые "устоявшиеся практики" на винде, а сделать всё нативно для винды не захотел, потому что не понравилось название языка программирования.
Перечитал статью ещё раз, даже с поиском, но про Java так и не увидел
На нетерминальной винде только 2 RDP подключения
"Мы не умеем это обслуживать" - тоже вполне себе валидная причина для отказа от какой-то платформы в пользу другой. Но не вполне ясно, зачем пытаться это выдавать за недостатки платформы, ведь текст могут ненароком прочитать люди, для которых RSAT, PS, Admin Center, и прочая, и прочая - не темный лес.
Вы таки продолжаете навязывать собственные причины. Мы вендор софта. Есть определенные обязательства перед заказчиком. Есть конкретные зоны ответственности. Обслуживание инфраструктуры это забота второй стороны, поймите уже наконец. Те неудобства, которые я привел выше, пополнили копилку других причин. Те связаны с производительностью серверной платформы и невозможностью держать руку на пульсе этой платформы.
Я никому ничего не навязываю - напротив, я вам открытым текстом пишу, что незнание платформы и неумение с ней работать могут являться для бизнеса вполне валидными основаниями для отказа от нее. Но именно вы продолжаете выставлять отсутствие у персонала (своего или заказчика - вообще неинтересно) нужных компетенций как недостаток платформы. Причем совершенно непонятно, зачем вы это делаете.
Из статьи сложилось мнение, что заказчик выбирал не конкретный линукс и постгрес, а продукты с реально работающим саппортом, как бы сами продукты не назывались.
Более того, из текста понятно, что это не было прихотью, и на этапе миграции саппорт действительно понадобился.
А вот в выводах необходимость саппорта не отмечена
Спасибо, вы подсветили один из важнейших критериев выбора. Качественная поддержка продукта (ОС и СУБД в контуре прода) и серверного окружения для заказчика всегда являлась обязательным условием. Поэтому мы помогали найти ОС и СУБД российского производства с проверенной поддержкой.
В выводы мы не включили пункт о поддержке, чтобы не выделять кого-то из вендоров. Индустрия быстро развивается, и мы упомянули о том, что поначалу в дистрибутиве Астры не хватало некоторых версий постгреса. Всего через несколько месяцев ситуация выровнялась, видно что работа ведется.
Не совсем понятно, почему Вы беспокоитесь о перезагрузках серверов или СУБД: обе СУБД способны работать в кластере. Соответственно, перезагружать узлы можно когда угодно.
Или cluster -а нет?
А причем тут кластер? В нагруженной системе перезагружать узлы "когда угодно" нежелательно. Механизмы отказоустойчивости отработают, да. Но создадут кучу дополнительных задач для обслуживающего персонала, который сам же инициировал перезагрузку одного узла. Через 10 минут первая база снова окажется в сети и затем перезагрузят вторую. Так по-вашему?
Во-первых, к системы есть показатели доступности. В которые нельзя вмешиваться, устраивая мейтенанс, потому что так захотел разработчик СУБД или ОС. На весь год, допустим, есть разрешенный простой системы 4 часа. И если в "типа безопасной" операции отключения одной БД что-то пойдет не так, то мы можем исчерпать часть этих часов просто из-за прихоти инженера. Что выльется в штраф и неприятности. Причем даже когда это происходит в оговоренное окно для работ.
Во-вторых, любой техсбой недопустим для бизнеса. Заказчик теряет деньги, а вендор репутацию.
Даже если технически система допускает выход из работы часть серверов, то это не означает, что этим можно пользоваться ради обновления. Обновление это в первую очередь неудобство для большинства пользователей.
А не проще вести себя как цивилизованные люди, не развязывать войны и не убивать людей в других странах , тогда и не придется изобретать велосипед
Почему нельзя взять и перевести сервер с корпоративной системой на Linux и Postgres