История изменений

anonymous (08.09.21 10:36:28) С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)?

Удобство != стабильность. Если речь про всякие dev/test среды, то там пожертвовать стабильностью в сторону удобства - частая картина.

Хотя, я лично всегда против этого по банальной причине. Что потом, как правило, сводится к тому что нужно иметь PROD-like env для тестирования и получается, что удобно не будет в любом случае. Особенно, если проект становится старше и разрастается.

Когда, у тебя где-то 100 микросервисов и много баз под high load… Ну извини, не будет удобно, ну ни как…

Проекты по инфра простейшие, но возни целая гора. Если простейшие, то можно. Но где гарантии, что условно через полгода или год он не превратится в сложный? … так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4

Ну, а почему не должно быть сложно? На самом деле, самое большое заблуждение современного IT, что сложность и проблемность проектов пытаются переложить на инфраструктуру. Когда, условно программисты говнокод делают, и их ПО работает «кое-как»…

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках.

Могу тебе сказать, что за последнее время заметил, что современные программистики уже не залезают в SQL и не пытаются оптимизировать базы, а начинают юзать подход «ORM/code first», где доверяют работу с базой - ОРМу вплоть до генерации всего (таблиц, индексов, SQL-запросов в runtime), где конечно знатно обсираются… Еще одно из больных мест с их code first - это миграции с РСУБД, и тут точно так же… Не важно, Докер-шмокер или облака/bare-metal, если ПО работает нестабильно, то инфра не столь важна… Проблемы искать надо в говнокоде программистиков.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya

Это просто розовая мечта. Надо принять реальность, что повозиться придется в любом случае. Причем, если уровень сложности проектов возрастает, то ты будешь точно так же и с контейнерами мучаться.

влезать в Dockerfile, проводить оптимизации
влезать в Helm-chart шаблоны, делать в них фиксы и тестить их

И тут, ты поймешь, что с этой темой по мере разрастания проекта - overhead много и в плане рабочей деятельности. Тебя будет бесить то, что ты будешь тратить много времени на обслугу абстракций.

anonymous (08.09.21 10:36:28) С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)?

Удобство != стабильность. Если речь про всякие dev/test среды, то там пожертвовать стабильностью в сторону удобства - частая картина.

Хотя, я лично всегда против этого по банальной причине. Что потом, как правило, сводится к тому что нужно иметь PROD-like env для тестирования и получается, что удобно не будет в любом случае. Особенно, если проект становится старше и разрастается.

Когда, у тебя где-то 100 микросервисов и много баз под high load… Ну извини, не будет удобно, ну ни как…

Проекты по инфра простейшие, но возни целая гора. Если простейшие, то можно. Но где гарантии, что условно через полгода или год он не превратится в сложный? … так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4

Ну, а почему не должно быть сложно? На самом деле, самое большое заблуждение современного IT, что сложность и проблемность проектов пытаются переложить на инфраструктуру. Когда, условно программисты говнокод делают, и их ПО работает «кое-как»…

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках.

Могу тебе сказать, что за последнее время заметил, что современные программистики уже не залезают в SQL и не пытаются оптимизировать базы, а начинают юзать подход «ORM/code first», где доверяют работу с базой - ОРМу вплоть до генерации всего (таблиц, индексов, SQL-запросов в runtime), где конечно знатно обсираются… Еще одно из больных мест с их code first - это миграции с РСУБД, и тут точно так же… Не важно, Докер-шмокер или облака/bare-metal, если ПО работает нестабильно, то инфра не столь важна… Проблемы искать надо в говнокоде программистиков.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya

Это просто розовая мечта. Надо принять реальность, что повозиться придется в любом случае. Причем, если уровень сложности проектов возрастает, то ты будешь точно так же и с контейнерами мучаться.

влезать в Dockerfile, проводить оптимизации
влезать в Helm-chart шаблоны, делать в нем фиксы

И тут, ты поймешь, что с этой темой по мере разрастания проекта - overhead много и в плане рабочей деятельности. Тебя будет бесить то, что ты будешь тратить много времени на обслугу абстракций.

anonymous (08.09.21 10:36:28) С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)?

Удобство != стабильность. Если речь про всякие dev/test среды, то там пожертвовать стабильностью в сторону удобства - частая картина.

Хотя, я лично всегда против этого по банальной причине. Что потом, как правило, сводится к тому что нужно иметь PROD-like env для тестирования и получается, что удобно не будет в любом случае. Особенно, если проект становится старше и разрастается.

Когда, у тебя где-то 100 микросервисов и много баз под high load… Ну извини, не будет удобно, ну ни как…

Проекты по инфра простейшие, но возни целая гора. Если простейшие, то можно. Но где гарантии, что условно через полгода или год он не превратится в сложный?

так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4

Ну, а почему не должно быть сложно? На самом деле, самое большое заблуждение современного IT, что сложность и проблемность проектов пытаются переложить на инфраструктуру. Когда, условно программисты говнокод делают, и их ПО работает «кое-как»…

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках.

Могу тебе сказать, что за последнее время заметил, что современные программистики уже не залезают в SQL и не пытаются оптимизировать базы, а начинают юзать подход «ORM/code first», где доверяют работу с базой - ОРМу вплоть до генерации всего (таблиц, индексов, SQL-запросов в runtime), где конечно знатно обсираются… Еще одно из больных мест с их code first - это миграции с РСУБД, и тут точно так же… Не важно, Докер-шмокер или облака/bare-metal, если ПО работает нестабильно, то инфра не столь важна… Проблемы искать надо в говнокоде программистиков.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya

Это просто розовая мечта. Надо принять реальность, что повозиться придется в любом случае. Причем, если уровень сложности проектов возрастает, то ты будешь точно так же и с контейнерами мучаться.

влезать в Dockerfile, проводить оптимизации
влезать в Helm-chart шаблоны, делать в нем фиксы

И тут, ты поймешь, что с этой темой по мере разрастания проекта - overhead много и в плане рабочей деятельности. Тебя будет бесить то, что ты будешь тратить много времени на обслугу абстракций.

anonymous (08.09.21 10:36:28) С точки зрения удобства и RAD, стоит ли юзать докеры и к8сы для быстрого деплоя (учитывая что я и то, и другое только в туториалах видел)?

Удобство != стабильность. Если речь про всякие dev/test среды, то там пожертвовать стабильностью в сторону удобства - частая картина.

Хотя, я лично всегда против этого по банальной причине. Что потом, как правило, сводится к тому что нужно иметь PROD-like env для тестирования и получается, что удобно не будет в любом случае. Особенно, если проект становится старше и разрастается.

Когда, у тебя где-то 100 микросервисов и много баз под high load… Ну извини, не будет удобно, ну ни как…

Проекты по инфра простейшие, но возни целая гора. Если простейшие, то можно. Но где гарантии, что условно через полгода или год он не превратится в сложный?

так теперь каждый апдейт это зайди, запулли, конфиг доправь, перезапусти, логи чекни, поправь, запушь… х4

Ну, а почему не должно быть сложно? На самом деле, самое большое заблуждение современного IT, что сложность и проблемность проектов пытаются переложить на инфраструктуру. Когда, условно программисты говнокод делают, и их ПО работает «кое-как»…

Если условный программистик наговнокодил, то его ПО будет плохо работать, что в bare-metal, что в облаках.

Могу тебе сказать, что за последнее время заметил, что современные программистики уже не залезают в SQL и не пытаются оптимизировать базы, а начинают юзать подход «ORM/code first», где доверяют работу с базой - ОРМу вплоть до генерации всего (таблиц, индексов, SQL-запросов в runtime), где конечно знатно обсираются… Еще одно из больных мест с их code first - это миграции с РСУБД, и тут точно так же… Не важно, Докер-шмокер или облака/bare-metal, если ПО работает нестабильно, то инфра не столь важна… Проблемы искать надо в говнокоде программистиков.

И чтобы если новый инстанс, то на нем сделать лишь apt-get install wunder-waflya Это просто розовая мечта. Надо принять реальность, что повозиться придется в любом случае. Причем, если уровень сложности проектов возрастает, то ты будешь точно так же и с контейнерами мучаться.

влезать в Dockerfile, проводить оптимизации
влезать в Helm-chart шаблоны, делать в нем фиксы

И тут, ты поймешь, что с этой темой по мере разрастания проекта - overhead много и в плане рабочей деятельности. Тебя будет бесить то, что ты будешь тратить много времени на обслугу абстракций.