Знание точных наук дает возможность «уметь думать». Лично мне теорема Пифагора не пригождалась, но я не знаю ни одного хорошего программиста, который слаб в математике.

В базовых понятиях я не путаюсь.

И вам добро пожаловать в общество пустословов ;)

Стоимость аналогичной инфраструктуры выходит в 4 раза дороже. Да, удобнее, но бизнес не одобрил.

Генератор ПК на основании совместимости комплектующих как на проме реализуете?)

Уже в разработке)

В нашем случае речь идет о didicated сервере. Конечно если бы мы говорили об облаке , то там поднять пару лишних виртуалок вопросы двух кликов.

Поэтому и было принято решение о линуксе, так как он в 99% случаев удобнее в поддержке и совместимости. В статье я и указывал что это вопросы конкретно нашего бизнеса и наших реалий.

Крутить на 1 железе несколько виртуалок показало себя крайне неудобным, уже был опыт.

Этот вопрос был задан в контексте необоснованного высказывания Андрея. К чему ваш комментарий?

так вы опять не ответили)

И все же, если для вас эти аргументы в статье не подходящие, так предложите где должен крутиться ELK на нашем проекте)

Пожалуйста, не уходите от ответа)

Одной из причин миграции, как было сказано в статье была необходимость в ELK. он удобно запускается и администрируется в контейнерах на линуксе.

Предложите решение, вы же архитектор.

Вы так и не ответили где должен хоститься ELK. Расскажите раз уж упомянули его.

Если вы считаете что в статье есть технические неточности, так назовите как было бы точнее)

Я же говорю, с удовольствием выслушаю ваши предложения)
Я не услушал ни одного аргумента от Вас. Подкрепите свои слова аргементами)

Вы считаете что миграция была бессмысленной и как гуру айти вам не нравятся ее причины. Окей. Предложите решение вышеперечисленных проблем)

Как бы вы их решили? Расскажите)

я за фронт не отвечаю) мое дело это бэк.

Ну, во-первых, моя статья никому ничего не должна)

А во-вторых, специально в статье указал что мотивация была исключительно личная, я никому не навязываю свое мнение, а просто рассказываю личные приоритеты и опыт.

Откройте docker.com и там вы найдете сугубо технические аспекты.

Складывается ощущение, что Вам в молодости запретили переехать на докер, и у вас образовался комплекс «CTO запретил», учитывая сколько раз Вы об этом упомянули в комментариях.

мы в процессе поиска)

Да возможно. Спасибо за подсказку. Вижу две проблемы в этом:

1) это не удобно, по сравнению с докером.

2) маленькое комьюнити, сложно искать решение проблем.

1. Спасибо, отпечатался (

2. Если более развёрнуто, то тут скорость может быть достигнута когда не хватает потоков по какой либо причине, в случае 32 битного процесса когда инстанс ограничивается в 4гб, если инстанс не умеет держать нужное кол-во коннектор куда либо, или одновременное кол-во открытых файлов. В случае идеального вакуумного сервиса репликация действительно бессмысленна.

Конкретно а нашем случае используется коннектор к redis , который живет всего на 1 общем коннекте, и да , он достаточно быстрый, но все равно имеет свой пропускной ресурс.

А вы знаете много проектов где запущены дотнет сервиса под высокой нагрузкой без прокси сервера? Для меня это подразумевающиеся технологические связки. И опять же, статья не об этом. Я рассказывал в статье то, что считал нужным, и опускал то, что считал не интересным.

Я нигде не упоминал что решение о миграции было потому что мы просто хотели. У нас был ряд задач, мы его решили. Все остались довольны. А люди, которые за это платили прочитали эту статью ещё до ее выхода)

Спасибо за отзыв) а какие у вас вышли проблемы потом? Мы пока ещё не долго на нем сидим, пока что ничего плохого не заметили.

Спасибо за совет)

Под аппаратной имею в виду то, что кубернетес отлично справляется с окрестрированием нескольких физических серверов. В нашем случае 1 физический сервер и это не имеет смысла.

А если сравнивать докер swarm и кубернетес без «аппаратных фич», то как по мне, докер проще в освоении. Учитывая то что у команды еще не было опыта вообще в этом, то простота освоения была достаточно важным фактором.