Поводов много, например, сегодня даже маленькое предприятие может за пару часов накликать мышкой себе в облаке инфраструктуру, которую лет 20 назад использовали действительно крупные проекты с предварительным обоснованием и закупкой оборудования.
А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Хорошо, что автор(ы) решили разобраться в этом непростом вопросе. Поэтому предложил бы почитать про классификацию моделей данных и типы соответствующих СУБД, например здесь (англ.) или здесь (рус). Уверен, даже после поверхностного ознакомления появится много вариантов улучшить и упростить статью.
Вы "опровергаете" повышенные требования к СУБД тем, что такие требования есть у вас, как пользователя, а неполное им соответствие вызывает у вас же проблемы эксплуатации?
Выглядит как подтверждение сказанного выше, спасибо.
На самом деле нет. Вопрос не в том, что можно делать, а в том, что нужно. Несмотря на.
Все системные продукты (ОС, СУБД, виртуализация, сервера приложений...), компиляторы, базовые библиотеки, фреймворки по умолчанию имеют повышенные требования к надежности, производительности, развертыванию, зависимостям и прочая. Для прикладных систем нужно дополнительное обоснование.
Не совсем понятна новизна ситуации. С 1960-х годов, когда были изобретены (но далеко не все внедрены) 80% используемый сейчас технологий, появилось разделение на системных и прикладных программистов. Для работы первых важна надежность и производительность программ. Прикладникам всегда важнее быстрее реализовать запрашиваемую функциональность. Тем более прикладникам "домашней" (in-house) разработки. Та, что раньше велась в отделах АСУ предприятий.
Поэтому всегда были рядом Фортран и Лисп, потом Си и Бейсик (Си++ и Вижал Бейсик), Ява и Ява-скрипт и т.д. и т.п. И было еще множество инструментов "посередине", таких как Паскаль-Дельфи. И появлялись культуры использования операционных систем, вместо их написания. Потом СУБД.
Питон - это прекрасный заменитель старого Бейсика с теми же целями: побыстрее реализовать небольшую по масштабам прикладную задачку. Побыстрее вставить свой кирпич в общую стену-плотину, затыкая потоки прорывающейся воды пользовательских историй.
Манипулировать рабочей БД через инструменты разработчика типа postman не очень хорошая идея. В инструментах администраторов обычно можно просто обозначить соединение как production, и тогда операции на запись или блокируются, или требуют дополнительных подтверждений.
Если условия позволяют использовать minimally logged (пустая таблица с ключом, индексы строим позже, заливка в порядке кластерного ключа), то даже простой INSERT SELECT отрабатывает так же быстро, как BULK.
Поводов много, например, сегодня даже маленькое предприятие может за пару часов накликать мышкой себе в облаке инфраструктуру, которую лет 20 назад использовали действительно крупные проекты с предварительным обоснованием и закупкой оборудования.
В связи с распространением Devops, процедура интеграции нового разработчика стала занимать долгие недели даже в небольших фирмах.
Вы читали руководство по скраму? Там действительно есть чему обучаться более одного вечера?
Странный вывод: речь шла о причинах "смерти" проекта. Ведь не из-за скриптов же сборки-развертывания, если серьезно.
А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
>Когда поддерживать и чинить что-то руками стало дурным тоном
Разве девопсы не занимаются ручной поддержкой и починкой своих скриптов, ломающихся ежечасно при изменении одного из 100500 компонентов сборки?
Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Разработка и эксплуатация - два разных мира с противоречивыми целями существования.
Хорошо, что автор(ы) решили разобраться в этом непростом вопросе. Поэтому предложил бы почитать про классификацию моделей данных и типы соответствующих СУБД, например здесь (англ.) или здесь (рус). Уверен, даже после поверхностного ознакомления появится много вариантов улучшить и упростить статью.
Вы "опровергаете" повышенные требования к СУБД тем, что такие требования есть у вас, как пользователя, а неполное им соответствие вызывает у вас же проблемы эксплуатации?
Выглядит как подтверждение сказанного выше, спасибо.
На самом деле нет. Вопрос не в том, что можно делать, а в том, что нужно. Несмотря на.
Все системные продукты (ОС, СУБД, виртуализация, сервера приложений...), компиляторы, базовые библиотеки, фреймворки по умолчанию имеют повышенные требования к надежности, производительности, развертыванию, зависимостям и прочая. Для прикладных систем нужно дополнительное обоснование.
Конечно есть: технологический стек, круг задач, организация их реализации
Не совсем понятна новизна ситуации. С 1960-х годов, когда были изобретены (но далеко не все внедрены) 80% используемый сейчас технологий, появилось разделение на системных и прикладных программистов. Для работы первых важна надежность и производительность программ. Прикладникам всегда важнее быстрее реализовать запрашиваемую функциональность. Тем более прикладникам "домашней" (in-house) разработки. Та, что раньше велась в отделах АСУ предприятий.
Поэтому всегда были рядом Фортран и Лисп, потом Си и Бейсик (Си++ и Вижал Бейсик), Ява и Ява-скрипт и т.д. и т.п. И было еще множество инструментов "посередине", таких как Паскаль-Дельфи. И появлялись культуры использования операционных систем, вместо их написания. Потом СУБД.
Питон - это прекрасный заменитель старого Бейсика с теми же целями: побыстрее реализовать небольшую по масштабам прикладную задачку. Побыстрее вставить свой кирпич в общую стену-плотину, затыкая потоки прорывающейся воды пользовательских историй.
Речь не о культуре, а о специализации.
Манипулировать рабочей БД через инструменты разработчика типа postman не очень хорошая идея. В инструментах администраторов обычно можно просто обозначить соединение как production, и тогда операции на запись или блокируются, или требуют дополнительных подтверждений.
Название WNT (Windows NT) - инкремент букв в аббревиатуре VMS.
Это была шутка, надеюсь? Вроде до 1 апреля еще больше недели.
Если условия позволяют использовать minimally logged (пустая таблица с ключом, индексы строим позже, заливка в порядке кластерного ключа), то даже простой INSERT SELECT отрабатывает так же быстро, как BULK.
Если все-таки желаете сравнивать теплое с мягким, проверяйте (с поправкой на объемы 2008 года)
Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings