Прозвучало про патент. Не соглашусь. Патентуют конкретные сочетания букв, а не язык.
Копирайт для кода. Патент для алгоритма или метода внутри кода. Хотя и лицензия бессильна против независимой реализации
Автор прав, на практике ИИ обвалил цену копирования архитектуры. Clean-room больше не нужен.
Итог будет жестким: 1. Лицензии с запретом на обучение ИИ. 2. Тотальная верификация кода (доверия к публичным репам не будет). 3. Бизнес-логика уйдет в закрытый код.
Open Source станет коммуналкой для инструментов и стандартов. И кровь человеческого кода с кровью AI смешивать перестанут.
В базе хранятся ID документов, а бинарники располагаются в файловом хранилище. 700 гигов это объем карточек и связей. Данные генерируются не только персоналом, но и автоматическими интеграциями с внешними системами. Отсюда такие объемы.
Добрый день, спасибо за комментарий. ALD не используется. Версия СУБД 13.12 без мандатного доступа. Поддержкой ОС занимается подрядная организация, на нашей памяти было обновление с 1.7.0 до 1.7.4. Как обстоят дела с периодическими обновлениями сейчас, подсказать не можем.
Вы таки продолжаете навязывать собственные причины. Мы вендор софта. Есть определенные обязательства перед заказчиком. Есть конкретные зоны ответственности. Обслуживание инфраструктуры это забота второй стороны, поймите уже наконец. Те неудобства, которые я привел выше, пополнили копилку других причин. Те связаны с производительностью серверной платформы и невозможностью держать руку на пульсе этой платформы.
А причем тут кластер? В нагруженной системе перезагружать узлы "когда угодно" нежелательно. Механизмы отказоустойчивости отработают, да. Но создадут кучу дополнительных задач для обслуживающего персонала, который сам же инициировал перезагрузку одного узла. Через 10 минут первая база снова окажется в сети и затем перезагрузят вторую. Так по-вашему?
Во-первых, к системы есть показатели доступности. В которые нельзя вмешиваться, устраивая мейтенанс, потому что так захотел разработчик СУБД или ОС. На весь год, допустим, есть разрешенный простой системы 4 часа. И если в "типа безопасной" операции отключения одной БД что-то пойдет не так, то мы можем исчерпать часть этих часов просто из-за прихоти инженера. Что выльется в штраф и неприятности. Причем даже когда это происходит в оговоренное окно для работ.
Во-вторых, любой техсбой недопустим для бизнеса. Заказчик теряет деньги, а вендор репутацию.
Даже если технически система допускает выход из работы часть серверов, то это не означает, что этим можно пользоваться ради обновления. Обновление это в первую очередь неудобство для большинства пользователей.
Это как дать юзеру либру вместо мс офиса и сказать, что ничего не поменяется. Поменяется. И риск, что поменяется в худшую сторону, есть. Потому мало кто решается на такое
И систему ещё не переписали, но вывод уже есть, потому что "ну вы ж знаете этот линукс" ))
Поделитесь примерами из вашей практики. Из вашего сообщения видно, что вы прочитали статью невнимательно. Речь идет о кроссплатформенном серверном веб-приложении. Изначально это приложение способно работать практически в любых средах, где есть Java. Соответственно сравнение Java-приложения c либрой здесь неуместно. Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое. Для конечного пользователя ничего не поменяется, а серверная часть станет другой. Большинство наших клиентов использует линукс с самого начала, и поэтому у нас было наблюдение, что с подобными решениями всегда проще. Система более предсказуемая и проще в обслуживании.
Взять тот же способ подключения. На нетерминальной винде только 2 RDP подключения, одно из которых как правило резервирует сторона заказчика. Сразу двоим сотрудникам невозможно подключиться. Один сеанс тратится на элементарные операции посмотреть лог, например. С учетом сложных схем подключения, скорость, стабильность соединения и возможности прямого чтения или управления в итоге вырождаются в недоразумение.
SSH позволяет все делать одним туннелем и использовать скилы сразу несколько человек. В такой схеме можно использовать средства автоматизации, например Ansible, и подключать системы мониторинга, недоступные на винде. Как дальнейший этап развития, это способ создания конвейеров для поставки сборок на сервер (Docker или традиционный деплоймент).
Сокращение Time to market может быть оправданием затрат на перенос платформы.
С точки зрения разработчика, интегратора и техподдержки разумно иметь одинаковый стек во всех контурах. Но не всегда это оправдано. Продукт пишется на ванильном постгресе и архитектура приложения в ITMS использует фичи PgPro, но не явно. То есть, на проде используется pg_repack для перестроения таблиц, а оптимизация плана запроса в про-версии дает выигрыш в производительности. Но эти фичи не так критичны, и таким образом остается обратная совместимость с другими версиями постгрес (ванильная и астра) в контурах разработки, тестирования и предпрода, которые менее требовательны к нагрузке.
Использование про-версии на проде защищает клиента от рисков, связанных с самой СУБД. То же самое касается ОС. К слову, из-за расхождения версий ядер ОС между контурами мы однажды столкнулись с проблемой, когда на тесте она не воспроизводилась, а на проде была. Ситуацию быстро решила команда Астры.
В таком подходе удается сохранить то, что важно для клиента. Для бизнеса важен баланс между совместимостью сред, оптимальными расходами, минимальными рисками возникновения инцидентов из-за разного окружения и возможностью быстро получать профессиональную помощь от первого лица.
СЭД на Windows + MS SQL разворачивали исходя из устоявшихся технологий и компетенций на стороне заказчика. Когда мы приходим со своим решением, то сложно сходу изменить сложившиеся устои, и как правило приходится работать с тем, что есть.
Спасибо, вы подсветили один из важнейших критериев выбора. Качественная поддержка продукта (ОС и СУБД в контуре прода) и серверного окружения для заказчика всегда являлась обязательным условием. Поэтому мы помогали найти ОС и СУБД российского производства с проверенной поддержкой.
В выводы мы не включили пункт о поддержке, чтобы не выделять кого-то из вендоров. Индустрия быстро развивается, и мы упомянули о том, что поначалу в дистрибутиве Астры не хватало некоторых версий постгреса. Всего через несколько месяцев ситуация выровнялась, видно что работа ведется.
В статье не сказано о необходимости перезагружать MS SQL. Требовать перезапуск и СУБД, и ОС могут ожидающие установки обновления. Об этом и сказано в выводах. Ни слова не было про дорого и недружественно. Заказчик сам пришел к выводу, что замена ОС даст преимущества.
С переходом на линукс решился вопрос с мониторингом веб-приложения СЭД, появилась прозрачность в вопросе производительности. Упростились интеграции продукта с внешними сервисами заказчика. Стало возможным заменить дополнительное ПО, которое раньше не представлялось возможным интегрировать без костылей. А уже в процессе перехода на линукс возникли известные обстоятельства, которые заставили отказаться от MS SQL.
Добрый день. Мы имели ввиду следующее: если у кроссплатформенного приложения есть выбор, на какой платформе размещаться, то по нашему опыту лучше использовать линукс
Прозвучало про патент. Не соглашусь. Патентуют конкретные сочетания букв, а не язык.
Копирайт для кода. Патент для алгоритма или метода внутри кода. Хотя и лицензия бессильна против независимой реализации
Автор прав, на практике ИИ обвалил цену копирования архитектуры. Clean-room больше не нужен.
Итог будет жестким:
1. Лицензии с запретом на обучение ИИ.
2. Тотальная верификация кода (доверия к публичным репам не будет).
3. Бизнес-логика уйдет в закрытый код.
Open Source станет коммуналкой для инструментов и стандартов. И кровь человеческого кода с кровью AI смешивать перестанут.
В базе хранятся ID документов, а бинарники располагаются в файловом хранилище. 700 гигов это объем карточек и связей. Данные генерируются не только персоналом, но и автоматическими интеграциями с внешними системами. Отсюда такие объемы.
Верно, домен не трогали и он пока остался виндовый.
Добрый день, спасибо за комментарий. ALD не используется. Версия СУБД 13.12 без мандатного доступа. Поддержкой ОС занимается подрядная организация, на нашей памяти было обновление с 1.7.0 до 1.7.4. Как обстоят дела с периодическими обновлениями сейчас, подсказать не можем.
Вы таки продолжаете навязывать собственные причины. Мы вендор софта. Есть определенные обязательства перед заказчиком. Есть конкретные зоны ответственности. Обслуживание инфраструктуры это забота второй стороны, поймите уже наконец. Те неудобства, которые я привел выше, пополнили копилку других причин. Те связаны с производительностью серверной платформы и невозможностью держать руку на пульсе этой платформы.
Вы совершенно правы. Но вы обратились не по адресу. Здесь обсуждаются технические и психологические аспекты замены ОС и СУБД.
А причем тут кластер? В нагруженной системе перезагружать узлы "когда угодно" нежелательно. Механизмы отказоустойчивости отработают, да. Но создадут кучу дополнительных задач для обслуживающего персонала, который сам же инициировал перезагрузку одного узла. Через 10 минут первая база снова окажется в сети и затем перезагрузят вторую. Так по-вашему?
Во-первых, к системы есть показатели доступности. В которые нельзя вмешиваться, устраивая мейтенанс, потому что так захотел разработчик СУБД или ОС. На весь год, допустим, есть разрешенный простой системы 4 часа. И если в "типа безопасной" операции отключения одной БД что-то пойдет не так, то мы можем исчерпать часть этих часов просто из-за прихоти инженера. Что выльется в штраф и неприятности. Причем даже когда это происходит в оговоренное окно для работ.
Во-вторых, любой техсбой недопустим для бизнеса. Заказчик теряет деньги, а вендор репутацию.
Даже если технически система допускает выход из работы часть серверов, то это не означает, что этим можно пользоваться ради обновления. Обновление это в первую очередь неудобство для большинства пользователей.
Действительно. Тогда извините, добавили уточнение в текст.
Поделитесь примерами из вашей практики. Из вашего сообщения видно, что вы прочитали статью невнимательно. Речь идет о кроссплатформенном серверном веб-приложении. Изначально это приложение способно работать практически в любых средах, где есть Java. Соответственно сравнение Java-приложения c либрой здесь неуместно. Статья написана не только для аудитории интересующихся айтишников, но и для тех, кто имеет отношение к руководству проектами, как со стороны разработки, так и со стороны бизнеса.
У нас нет цели доказать, что замена ОС и СУБД оправдана с точки зрения денег. Мы начали рассказывать историю, когда заказчик сам задался вопросом - а не станет ли лучше, если окружение сменится на линуксовое. Для конечного пользователя ничего не поменяется, а серверная часть станет другой. Большинство наших клиентов использует линукс с самого начала, и поэтому у нас было наблюдение, что с подобными решениями всегда проще. Система более предсказуемая и проще в обслуживании.
Взять тот же способ подключения. На нетерминальной винде только 2 RDP подключения, одно из которых как правило резервирует сторона заказчика. Сразу двоим сотрудникам невозможно подключиться. Один сеанс тратится на элементарные операции посмотреть лог, например. С учетом сложных схем подключения, скорость, стабильность соединения и возможности прямого чтения или управления в итоге вырождаются в недоразумение.
SSH позволяет все делать одним туннелем и использовать скилы сразу несколько человек. В такой схеме можно использовать средства автоматизации, например Ansible, и подключать системы мониторинга, недоступные на винде. Как дальнейший этап развития, это способ создания конвейеров для поставки сборок на сервер (Docker или традиционный деплоймент).
Сокращение Time to market может быть оправданием затрат на перенос платформы.
С точки зрения разработчика, интегратора и техподдержки разумно иметь одинаковый стек во всех контурах. Но не всегда это оправдано. Продукт пишется на ванильном постгресе и архитектура приложения в ITMS использует фичи PgPro, но не явно. То есть, на проде используется pg_repack для перестроения таблиц, а оптимизация плана запроса в про-версии дает выигрыш в производительности. Но эти фичи не так критичны, и таким образом остается обратная совместимость с другими версиями постгрес (ванильная и астра) в контурах разработки, тестирования и предпрода, которые менее требовательны к нагрузке.
Использование про-версии на проде защищает клиента от рисков, связанных с самой СУБД. То же самое касается ОС. К слову, из-за расхождения версий ядер ОС между контурами мы однажды столкнулись с проблемой, когда на тесте она не воспроизводилась, а на проде была. Ситуацию быстро решила команда Астры.
В таком подходе удается сохранить то, что важно для клиента. Для бизнеса важен баланс между совместимостью сред, оптимальными расходами, минимальными рисками возникновения инцидентов из-за разного окружения и возможностью быстро получать профессиональную помощь от первого лица.
СЭД на Windows + MS SQL разворачивали исходя из устоявшихся технологий и компетенций на стороне заказчика. Когда мы приходим со своим решением, то сложно сходу изменить сложившиеся устои, и как правило приходится работать с тем, что есть.
Спасибо, вы подсветили один из важнейших критериев выбора. Качественная поддержка продукта (ОС и СУБД в контуре прода) и серверного окружения для заказчика всегда являлась обязательным условием. Поэтому мы помогали найти ОС и СУБД российского производства с проверенной поддержкой.
В выводы мы не включили пункт о поддержке, чтобы не выделять кого-то из вендоров. Индустрия быстро развивается, и мы упомянули о том, что поначалу в дистрибутиве Астры не хватало некоторых версий постгреса. Всего через несколько месяцев ситуация выровнялась, видно что работа ведется.
В статье не сказано о необходимости перезагружать MS SQL. Требовать перезапуск и СУБД, и ОС могут ожидающие установки обновления. Об этом и сказано в выводах. Ни слова не было про дорого и недружественно. Заказчик сам пришел к выводу, что замена ОС даст преимущества.
С переходом на линукс решился вопрос с мониторингом веб-приложения СЭД, появилась прозрачность в вопросе производительности. Упростились интеграции продукта с внешними сервисами заказчика. Стало возможным заменить дополнительное ПО, которое раньше не представлялось возможным интегрировать без костылей. А уже в процессе перехода на линукс возникли известные обстоятельства, которые заставили отказаться от MS SQL.
Добрый день. Мы имели ввиду следующее: если у кроссплатформенного приложения есть выбор, на какой платформе размещаться, то по нашему опыту лучше использовать линукс