За пределами докера есть огромный мир - не спорю, есть.
А вот про непрегодность докера для продакшена - поспорил бы. Уже лет 10 активно и успешно в продакшене он используется. И очень-очень-очень много где. Скажи мне кто, что он docker (или аналоги) совсем не использует - я скорее удивлюсь (речь, разумеется, про бекенд).
Так что эра docker-а (и/или аналогов) в продакшен пришла, и каких-либо предпосылок для ее завершения я не вижу.
Ну и у HighLoad-адептов может быть свой взгляд на пригодность docker к продакшену. Но опять же, не поверю, что они совсем от docker отказались.
Ну и не глядя на прод, разработчику, тем более бекенд-разработчику - docker очень и очень полезен. Разные СУБД можно гонять локально, практически не заморачиваясь их конфигурацией. Можно развернуть пачку микросервисов локально для отладки. Можно много чего еще полезного сделать - да даже IDE в контейнере запустить.
P.S. Для embeded-разработки и системной разработки тоже можно использовать docker периодически (например, Lakka для сборки образов может использовать специально подготовленный docker-образ).
Серьезный / несерьезный проект - это несерьезная классификация )
Большой / небольшой проект - да, еще можно оценивать. Сложный / несложный - тоже можно (и не сказать, что это к размеру привязано сильно, хотя некая корреляция и есть).
Ну а сложность Dockerfile - не сказал бы что сильно от размера проекта зависит. Да, можно предположить, что большой и более сложный проект будет иметь и более сложный Dockerfile. Но это не точно. Просто потому что все эти десятки env заменяется простым конфиг-файлом. А в Dockerfile остается сборка да команда запуска. И даже для больших и сложных проектов этого может быть достаточно (а может быть и недостаточно, не спорю).
P.S. смотрю первый попавшийся в IDE проект - 3 Dockerfile + docker-compose. Но проект не сказать что сложный или большой. Хотя... Сложный - еще можно назвать. Просто потому что бекенд на Golang, статичный фронт через NodeJS генерируется, а документация генерируется через Python. Ну и 60+ параметров, которые бекенду через env/флаги/конфиг задаются (в минимуме, правда, можно ничего не задавать).
Тот, что в корне проекта ) Или тот, что в ReadMe упоминается. Но я ни разу не видел 20 Dockerfile в проекте (если не брать проекты-сборники Dockerfile или монорепы какие). Несколько - да, бывает. Но в них можно разобраться при желании )
Админ может накрутить в Dockerfile не хуже разработчика. Но исправлять будет сложнее - потому как нужны согласованные изменения в проекте и там, где лежит его Dockerfile.
Если же бекенд-разработчик со стажем отказывается работать с Dockerfile и docker - то это крайне хреново. Начинающему еще можно простить. И начать изучать новое - как раз есть повод (компиляция через IDE и отсутствие Dockerfile ;) ) Без docker сейчас никуда не деться.
P.S. Если над проектом работают только начинающие разработчики - то отсутствие Dockerfile и компиляция через IDE были бы далеко не самыми главными моими проблемами )
Ты или сам разбираешься во всех этих нюансах, или работаешь с тем, кто в них разбирается. Или в самый неожиданный момент получишь много-много проблем, которые и не знаешь как решать или куда вообще смотреть.
Так что если надежность не важна - да, можно не париться.
Как программист со стажем скажу, что Dockerfile от разработчика - это очень хорошая и правильная практика. Просто потому, что он описывает в нем "а как вообще собрать мое приложение".
Это не трата времени, а его экономия - на выяснение "почему не собирается" или "почему не работает как надо" уйдет гораздо больше времени, чем на поддержку разработчиком Dockerfile-а.
А если есть нюансы - то ни кто не мешает DevOps или еще кому поработать над этим Dockerfile вместе с разработчиком, чтобы учесть все эти нюансы.
Так что Dockerfile от разработчика в корне проекта - это очень и очень хорошая практика. И очень полезная - неоднократно выяснял "а как это собрать" через изучение Dockerfile, не отвлекая расспросами других разработчиков.
И Dockerfile - это не конфиги докера, k8s или прочая "обвязка".
Из "обвязки" для разработчика хорошо владеть docker-compose (помимо docker) - чтобы уметь запускать все сервисы проекта в изолированной среде. Ну а большее - уже по желанию/возможностям/необходимости.
Да, несколько раз с btrfs натыкался на подобное. В целом решение простое - удалить старые снепшоты. Но пару раз пришлось с бубном поплясать - о проблемах становится известно когда места уже совсем нет и ФС переходит в режим read-only.
Но справился - и данные не пострадали. Но все равно крайне неприятно.
Можно затестить: https://chitchatter.im/public/habrahabr Как понимаю, одна вкладка - одна комната. И пока вкладка открыта хоть у кого-либо - беседа существует.
А одинаковые приватные комнаты с уникальным паролем образуют уникальные комнаты ) Правда идет ли трафик между всеми "одинаковыми" комнатами (и потом расшифровывается по паролю) или трафик идет с учетом пароля - вопрос отдельный.
Был SOAP, были другие методы и подходы к удаленному вызова процедур (и удаленного выполнения кода в целом). Сам по себе подход "вызов сервиса из другого сервиса" был известен намного раньше появления термина "микросервисы" и популяризации такой архитектуры.
"Большой монолит" когда-то был достаточно безальтернативной практикой ) Микросервисный подход получил популярность "всего лишь" лет 10 назад... Лишь с появлением и развитием Docker он стал популярен - когда управлять кучей сервисов стало сильно проще.
Впрочем, и сейчас монолит может сильно выиграть в плане производительности - так что его век может еще и вернется...
В плане артефактов сборки - проблема усугубляется тем, что под разные версии компилятора и под разные версии зависимостей - зависимости компилируются в отдельные файлы. Поэтому со временем target только растет. А уж если использовать свежие ночные сборки компилятора...
P.S. а еще есть очень холиварный вопрос - когда микросервис перестает быть микро?
И с Rust пока встречал баги компилятора пока только в ночных сборках (с WASM было связано). В Golang находил багу в релизной версии (справедливости ради - то была бага в LSP, а не непосредственно в компиляторе).
Не знаю. Может попадалось слишком много библиотек с обилием макросов и кодогенерации. Так-то простой код Rust вполне читаем, вопросов нет. Может не всегда понятно как именно он работает в деталях (с учетом трейтов и прочей магии шаблонов Rust), но что именно в нем происходит - вполне понятно.
Да, не хуже, чем в других языках, ни капли не спорю. Просто не надо забывать, что даже если напрямую не используешь unsafe - то твои зависмости вполне могут unsafe использовать.
Я с Rust активно познакомился уже имея существенный опыт разработки на C#/Java/Golang - и это был прямо "глоток свежего воздуха". Rust на многие вещи смотрит по другому. Простейший пример - отсутствие null-значений и работа c enum-ами. Владение переменной - тоже очень интересный подход. Так что контраст будет и после C#/Java/Golang. Это был очень интересный опыт.
Но рекомендовать Rust прям для всего я не буду - на мой взгляд, он очень хорош для небольших проектов (например, для микросервисов).
Я скорее основываюсь на впечатлениях, а не на твердом знании "что там под капотом". Во времена VS Code с RLS существенной разницы c Rust-плагином я не увидел (возможно совсем небольшое преимущество было за JetBrains - деталей не помню). Во времена VS Code с rust-analyzer существенной разницы c Rust-плагином я не увидел.
В переходный период Rust-плагин JetBrains отставал, как отставал RLS от rust-analyzer. Но я все возможности досконально не сравнивал - только подсветку типов, да авто-дополнение (то, с чем работаешь больше всего и что можно быстро сравнить). В идеале, конечно, надо было погонять IDE "и в хвост, и в гриву", для формирования более целостного впечатления.
И да, это было достаточно давно - как там сейчас обстоят дела я не скажу.
Не знаю на счет RustRover, но раньше их плагин Rust основывался на LSP. И с момента прихода rust-analyzer взамен RLS стало намного лучше.
Но большой разницы с той же VS Code я не увидел - LSP и там и там.
Да, стандартная библиотека, крупные и популярные либы - выглядят очень неплохо (подозреваю, это и было фактором, определившим их популярность).
Опять же, подсказки, в большинстве, своем очень хорошие, спору нет. Но не всегда из них можно понять что именно не так и как это исправить.
После полугода с языком - может некоторое число проблем с компилятором и уходит, но не исчезает полностью. И заранее предсказывать мне так и не удавалось. Возможно тут сыграл фактор, что я работал над множеством небольших и разноплановых проектов (в большинстве своем), а не над одним большим. И к каждому проекту привыкать надо отдельно - а общего навыка под множество либ и их особенностей так и не выработалось за это время.
Большой проект из множества микросервисов - это не тоже самое, один большой монолит ) С микросервисной архитектурой Rust прекрасно справляется, спору нет. Микросервисы писать на Rust - одно удовольствие, могу подтвердить.
Не стал уточнять сразу - но в микросервисной архитектуре я Rust вполне вижу. Он действительно очень удобен в таком виде, а этап привыкания и борьбы с компилятором и либами достаточно небольшой.
Правда размер бинарников (debug), объем артефактов сборки (десятки и стони гигов), длительность компиляции (я понял, зачем мне 16 ядер и 64Gb RAM) - могут сыграть не в пользу Rust и тут ))) Но это больше вопрос техники.
За пределами докера есть огромный мир - не спорю, есть.
А вот про непрегодность докера для продакшена - поспорил бы. Уже лет 10 активно и успешно в продакшене он используется. И очень-очень-очень много где. Скажи мне кто, что он docker (или аналоги) совсем не использует - я скорее удивлюсь (речь, разумеется, про бекенд).
Так что эра docker-а (и/или аналогов) в продакшен пришла, и каких-либо предпосылок для ее завершения я не вижу.
Ну и у HighLoad-адептов может быть свой взгляд на пригодность docker к продакшену. Но опять же, не поверю, что они совсем от docker отказались.
Ну и не глядя на прод, разработчику, тем более бекенд-разработчику - docker очень и очень полезен.
Разные СУБД можно гонять локально, практически не заморачиваясь их конфигурацией. Можно развернуть пачку микросервисов локально для отладки. Можно много чего еще полезного сделать - да даже IDE в контейнере запустить.
P.S. Для embeded-разработки и системной разработки тоже можно использовать docker периодически (например, Lakka для сборки образов может использовать специально подготовленный docker-образ).
Серьезный / несерьезный проект - это несерьезная классификация )
Большой / небольшой проект - да, еще можно оценивать. Сложный / несложный - тоже можно (и не сказать, что это к размеру привязано сильно, хотя некая корреляция и есть).
Ну а сложность Dockerfile - не сказал бы что сильно от размера проекта зависит. Да, можно предположить, что большой и более сложный проект будет иметь и более сложный Dockerfile. Но это не точно. Просто потому что все эти десятки env заменяется простым конфиг-файлом. А в Dockerfile остается сборка да команда запуска. И даже для больших и сложных проектов этого может быть достаточно (а может быть и недостаточно, не спорю).
P.S. смотрю первый попавшийся в IDE проект - 3 Dockerfile + docker-compose. Но проект не сказать что сложный или большой.
Хотя... Сложный - еще можно назвать. Просто потому что бекенд на Golang, статичный фронт через NodeJS генерируется, а документация генерируется через Python. Ну и 60+ параметров, которые бекенду через env/флаги/конфиг задаются (в минимуме, правда, можно ничего не задавать).
По той же логике:
Если писать docker-файлы для "простых" приложений, то ты никогда не научишься их писать для "сложных".
В генерации ничего плохого не вижу - при условии, что разработчик тщательно вникнет в результат генерации.
Тот, что в корне проекта ) Или тот, что в ReadMe упоминается.
Но я ни разу не видел 20 Dockerfile в проекте (если не брать проекты-сборники Dockerfile или монорепы какие).
Несколько - да, бывает. Но в них можно разобраться при желании )
Админ может накрутить в Dockerfile не хуже разработчика. Но исправлять будет сложнее - потому как нужны согласованные изменения в проекте и там, где лежит его Dockerfile.
Если же бекенд-разработчик со стажем отказывается работать с Dockerfile и docker - то это крайне хреново.
Начинающему еще можно простить. И начать изучать новое - как раз есть повод (компиляция через IDE и отсутствие Dockerfile ;) ) Без docker сейчас никуда не деться.
P.S. Если над проектом работают только начинающие разработчики - то отсутствие Dockerfile и компиляция через IDE были бы далеко не самыми главными моими проблемами )
Ты или сам разбираешься во всех этих нюансах, или работаешь с тем, кто в них разбирается. Или в самый неожиданный момент получишь много-много проблем, которые и не знаешь как решать или куда вообще смотреть.
Так что если надежность не важна - да, можно не париться.
Как программист со стажем скажу, что Dockerfile от разработчика - это очень хорошая и правильная практика. Просто потому, что он описывает в нем "а как вообще собрать мое приложение".
Это не трата времени, а его экономия - на выяснение "почему не собирается" или "почему не работает как надо" уйдет гораздо больше времени, чем на поддержку разработчиком Dockerfile-а.
А если есть нюансы - то ни кто не мешает DevOps или еще кому поработать над этим Dockerfile вместе с разработчиком, чтобы учесть все эти нюансы.
Так что Dockerfile от разработчика в корне проекта - это очень и очень хорошая практика. И очень полезная - неоднократно выяснял "а как это собрать" через изучение Dockerfile, не отвлекая расспросами других разработчиков.
И Dockerfile - это не конфиги докера, k8s или прочая "обвязка".
Из "обвязки" для разработчика хорошо владеть docker-compose (помимо docker) - чтобы уметь запускать все сервисы проекта в изолированной среде. Ну а большее - уже по желанию/возможностям/необходимости.
Да, несколько раз с btrfs натыкался на подобное. В целом решение простое - удалить старые снепшоты. Но пару раз пришлось с бубном поплясать - о проблемах становится известно когда места уже совсем нет и ФС переходит в режим read-only.
Но справился - и данные не пострадали. Но все равно крайне неприятно.
А разве здесь возня с GitHub обязательна?
Да и фишка с "работает через GitHub Pages" лично мне нравится )
Можно затестить: https://chitchatter.im/public/habrahabr
Как понимаю, одна вкладка - одна комната. И пока вкладка открыта хоть у кого-либо - беседа существует.
А одинаковые приватные комнаты с уникальным паролем образуют уникальные комнаты )
Правда идет ли трафик между всеми "одинаковыми" комнатами (и потом расшифровывается по паролю) или трафик идет с учетом пароля - вопрос отдельный.
Был SOAP, были другие методы и подходы к удаленному вызова процедур (и удаленного выполнения кода в целом).
Сам по себе подход "вызов сервиса из другого сервиса" был известен намного раньше появления термина "микросервисы" и популяризации такой архитектуры.
"Большой монолит" когда-то был достаточно безальтернативной практикой )
Микросервисный подход получил популярность "всего лишь" лет 10 назад... Лишь с появлением и развитием Docker он стал популярен - когда управлять кучей сервисов стало сильно проще.
Впрочем, и сейчас монолит может сильно выиграть в плане производительности - так что его век может еще и вернется...
В плане артефактов сборки - проблема усугубляется тем, что под разные версии компилятора и под разные версии зависимостей - зависимости компилируются в отдельные файлы. Поэтому со временем target только растет. А уж если использовать свежие ночные сборки компилятора...
P.S. а еще есть очень холиварный вопрос - когда микросервис перестает быть микро?
Тогда всю ОС надо на Rust писать и как-то гарантиями безопасности учиться делиться между разными приложениями.
Баги бывают во всех компиляторах.
И с Rust пока встречал баги компилятора пока только в ночных сборках (с WASM было связано).
В Golang находил багу в релизной версии (справедливости ради - то была бага в LSP, а не непосредственно в компиляторе).
Не знаю. Может попадалось слишком много библиотек с обилием макросов и кодогенерации. Так-то простой код Rust вполне читаем, вопросов нет.
Может не всегда понятно как именно он работает в деталях (с учетом трейтов и прочей магии шаблонов Rust), но что именно в нем происходит - вполне понятно.
Да, не хуже, чем в других языках, ни капли не спорю.
Просто не надо забывать, что даже если напрямую не используешь unsafe - то твои зависмости вполне могут unsafe использовать.
Не забываем про unsafe в Rust. Для unsafe никаких подобных гарантий нет.
Я с Rust активно познакомился уже имея существенный опыт разработки на C#/Java/Golang - и это был прямо "глоток свежего воздуха".
Rust на многие вещи смотрит по другому. Простейший пример - отсутствие null-значений и работа c enum-ами. Владение переменной - тоже очень интересный подход.
Так что контраст будет и после C#/Java/Golang. Это был очень интересный опыт.
Но рекомендовать Rust прям для всего я не буду - на мой взгляд, он очень хорош для небольших проектов (например, для микросервисов).
Возможно.
Я скорее основываюсь на впечатлениях, а не на твердом знании "что там под капотом".
Во времена VS Code с RLS существенной разницы c Rust-плагином я не увидел (возможно совсем небольшое преимущество было за JetBrains - деталей не помню).
Во времена VS Code с rust-analyzer существенной разницы c Rust-плагином я не увидел.
В переходный период Rust-плагин JetBrains отставал, как отставал RLS от rust-analyzer.
Но я все возможности досконально не сравнивал - только подсветку типов, да авто-дополнение (то, с чем работаешь больше всего и что можно быстро сравнить). В идеале, конечно, надо было погонять IDE "и в хвост, и в гриву", для формирования более целостного впечатления.
И да, это было достаточно давно - как там сейчас обстоят дела я не скажу.
Не знаю на счет RustRover, но раньше их плагин Rust основывался на LSP. И с момента прихода rust-analyzer взамен RLS стало намного лучше.
Но большой разницы с той же VS Code я не увидел - LSP и там и там.
Да, стандартная библиотека, крупные и популярные либы - выглядят очень неплохо (подозреваю, это и было фактором, определившим их популярность).
Опять же, подсказки, в большинстве, своем очень хорошие, спору нет. Но не всегда из них можно понять что именно не так и как это исправить.
После полугода с языком - может некоторое число проблем с компилятором и уходит, но не исчезает полностью. И заранее предсказывать мне так и не удавалось. Возможно тут сыграл фактор, что я работал над множеством небольших и разноплановых проектов (в большинстве своем), а не над одним большим. И к каждому проекту привыкать надо отдельно - а общего навыка под множество либ и их особенностей так и не выработалось за это время.
Большой проект из множества микросервисов - это не тоже самое, один большой монолит )
С микросервисной архитектурой Rust прекрасно справляется, спору нет. Микросервисы писать на Rust - одно удовольствие, могу подтвердить.
Не стал уточнять сразу - но в микросервисной архитектуре я Rust вполне вижу. Он действительно очень удобен в таком виде, а этап привыкания и борьбы с компилятором и либами достаточно небольшой.
Правда размер бинарников (debug), объем артефактов сборки (десятки и стони гигов), длительность компиляции (я понял, зачем мне 16 ядер и 64Gb RAM) - могут сыграть не в пользу Rust и тут ))) Но это больше вопрос техники.