Как стать автором
Обновить

Комментарии 23

А после объединения микросервисов в логически связанные сервисы возникает мысль — «а нужен ли нам вобще kubernetes?» Но лучше молчать, а то опозоришься.

Для нас Kubernetes — это просто один из инструментов. И очень мощный инструмент. И как и у любого мощного инструмента — у него достаточно высокий входной платеж. Нам, конечно же, удобней делать все проекты в Kubernetes, так-как именно для нас — так быстрей и удобней. Понятно, что в общем случае в первую очередь стоит исходить из возможностей команды и реальных потребностей проекта. Во многих может быть проще и правильней два хоста и docker-compose.

А после объединения микросервисов в логически связанные сервисы возникает мысль — «а нужен ли нам вобще kubernetes?» Но лучше молчать, а то опозоришься.

Конечно Kubernetes это оверлишний управляющий софт, казалось бы, но… А чем замените?

Все равно нужно для серьезного проекта:

  • хоть какой-то надежный деплой, с возможностью отката в случае сбоя деплоя;
  • green-blue deployment или быстрые откаты до предыдущих версий в случае выкатки ошибочного кода;
  • запускать экземпляр сервиса, мониторить здоровье экземпляра сервиса, перезапускать экземпляр сервиса при сбое;
  • мониторить загрузку нод, запускать на менее загруженной ноде;
  • запускать дополнительный экземпляр сервиса при росте нагрузке;
  • направлять и перенаправлять трафик на нужный экземпляр сервиса;
  • staging, тестирование нового функционала на части пользователей;
  • под Kubernetes полным полно адаптированного софта и best practics и готовых к развертыванию пакетов Prometheus/Grafana/ELK, иначе придется настраивать нечто подобное ручками


В комментариях предложите пожалуйста варианты для реализации описанного выше, но решения проще, чем Kubernetes. Очень нужно.

Склоняюсь или переплачивать на ненужный фунционал Kubernetes лишним рабочим временем и лишними управляющими нодами Kubernetes.
Или реализовывать на базе nomad/consul/registrator.

Как минимум большинство требований закрывает docker swarm. Для автомасштабирования нужна будет внешняя обвязка, масштабирующая в ответ на изменение метрик. Изучали этот вариант?
Как минимум большинство требований закрывает docker swarm.

habr.com/company/itsumma/blog/345976
Swarm при смерти
Когда Соломона Хайкеса спросили жив ли Docker Swarm, он ответил (в Твиттере): «Docker продолжит поддерживать и Kubernetes и Swarm на высшем уровне и будет стимулировать их взаимное развитие. Открытость и возможность выбора создают более здоровую экосистему для всех.» Проблема же здесь в том, что Docker Swarm поддерживается недостаточно хорошо. Совсем нет. Команда разработки Docker Swarm и горстка их опенсурсных разработчиков не смогут тягаться с сообществом Kubernetes. Как бы не был хорош Docker UI, Kubernetes UI гораздо лучше. Это почти как если бы Docker опустился до статуса маргинальной консалтинговой фирмы в мире контейнеров.

Я больше года не слежу за ченжлогами в связи со сменой обязанностей, отвечали лишь по требованиям на текущий (вернее на год+ назад момент).

К сожалению мне нечего вам предложить. Мы никогда не выбирали между Kubernetes и чем-то другим. Зашел с первого взгляда, так сказать. Просто эволюционно шли шли и пришли.

В комментариях предложите пожалуйста варианты для реализации описанного выше, но решения проще, чем Kubernetes. Очень нужно.

Amazon, деплоить виртуалками, образа подготавливать Packer. Какой-нибудь хероку тоже хорошо заходит.


Или реализовывать на базе nomad/consul

хорошая альтернатива!

разве это всё не очевидно?

И да и нет. И чем больше я общаюсь с людьми и получаю обратной связи по конкретно этому докладу — скорей нет, чем да. Если вам очевидно — вы молодец!

Полностью согласен с автором. Сейчас микросервисы пихают куда надо и не надо.
Зачем? Это модно и креативно. Для архитекторов замечательная задача нарисовать много блоков со стрелочками. За хорошие деньги и много думать не надо — разукрупняй все.
Для программеров, на самом деле, легче и приятней кодить свой маленький модуль на чем хочешь и как хочешь не беспокоясь о смежниках.
А потом и получается нечто монстрообразное и малопригодное для эксплуатации.
Но к тому времени проект уже завершен (тупо кончились деньги), все получили свои оплаты и скилы и радостно свалили на новые проекты по внедрению микросервисов.
Самое смешное, что архитекторы этого ужаса запишут в свои заслуги успешные внедрения микросервисов в крупных организациях и будут просить еще больше денег на следующей работе.

Это далеко не всегда так плохо, как вы описываете. По крайней мере "фантазеров" и "дойщиков" сразу видно и с ними все понятно. Очень часто я вижу и у архитекторов и у разработчиков большую и абсолютно искреннюю надежду, что микросервисная архитектура значительно упростит их жизнь, на практике же часто выходит боком. Об этом и пытался рассказать.

Ну так я и не утверждаю, что архитектура из примера на слайде родилась по причине намеренного саботажа. Все из лучших побуждений, как всегда…
На самом деле, ключевой, на мой взгляд момент в докладе, что успешное внедрения чаще происходит при движении от монолита. А изначальное планирование такой архитектуры скорее ведет к неудаче. В докладе делается предположение, что это происходит из за лучшего знания предметной области. Я думаю, что это не самая главная причина. Плохое знание предметной области ведет к неудаче и на монолите. Принципиальная же разница в том, на мой взгляд, что при движении от монолита, гораздо более четко и конкретно осознается проблема и для чего именно меняется архитектура. Отсюда проистекает более рациональный, объективно обусловленный подход к проектированию.
При проектировании же 'с нуля', такого четкого понимания часто нет. А исходят, зачастую, лишь из субъективных, не достаточно обоснованных, представлений о том, что проект должен делаться на микросервисах, недооценивая момент значительного, как предположено в докладе, экспоненциального роста сложности.
По моему опыту, есть два варианта, почему такое происходит. Один, когда архитектор хорошо знает именно такую архитектуру и изначально закладывает ее в каждый свой проект не особо задумываясь о необходимости. Происходит как в анекдоте про проктолога, который удалял гланды через задний проход. Никто не ставит под сомнения скилы такого специалиста — они у него несомненно имеются. Но зачем?
Другой, когда кто-то (а часто и весь тим архитекторов во главе с бизнес начальством) в компании, где-то прослушал доклад на тему 'очередная панацея' и, окрыленные услышанным, не имея вообще никакого опыта (все же так просто и очевидно было в докладе на слайдах!), принимается решение — внедрять. Зачем? почему? как? — по ходу разберемся. Вероятность успеха в таком случае — примерно как выиграть в лотерею.
Немного обидно было про 85 проектов за год и везде одно и тоже. Мы зашли сразу с ориентиром на Kubernetes и без 20k dns запросов :)
34 микросервиса на слайде. У нас их ~350 и я не вижу как это все работало бы на монолите (или что сейчас аутсорсеры продают).

«Навыки команды первичны» это 100%. Но причем тут Kubernetes и микросервисы? Buzzwords anchors?
Но причем тут Kubernetes и микросервисы? Buzzwords anchors?

Тут я вынужден просить прощения — доклад изначально планировался больше про эксплуатацию и про Kubernetes, как и обычно… а получился больше про архитектуру. Кажется я сказал об этом в начале. В любом случае прошу простить.

34 микросервиса на слайде. У нас их ~350 и я не вижу как это все работало бы на монолите (или что сейчас аутсорсеры продают).

Разве в тексте статьи сказано, что всегда и все должны использовать монолиты?
У нас как раз проект типа того, что на слайде — интернет-магазин. И да, вполне успешно живет всего на 3 сервисах. Kubernetes используется для reliability
В итоге предложили решение какое? Сделать новый монолит. Ок 10 гигантских монолитов, вместо 30-300 маленьких сервисов. Ещё «лучше»!

А всего лишь надо было иначе проектировать: 1 микросервис = 1 фича, т.е. один контекст. Не функционально близкие вызовы, а фича! Глобальный контекст это продукты или ордера в которые входят несколько микросервисов про ордера, например (импорт, отображение, проводка). Они не должны быть между собой связаны функционально, только логически, на схемках. А у вас это было функционально связано, не просто кодом, а вызовами сервисов. Конечно комок грязи получится.

У вас не должно быть микро сервиса product, order, catalog которые лепят CRUD операции плюс что-то делают. Это типичная ошибка новичка, которую 100 раз описали в книгах и обсудили. Но т.к. это про проектирование предметной области, а мало кто умеет это делать, то все просто пропускают мимо ушей и бегут деплоить докером новый orderService. У вас может быть микросервис «отобразить ордера для грида с общими данными, фильтрами и агрегацией», «провести новый заказ», «отменить заказ», «импортировать продукты», «отобразит продукты». Это физически разные сервисы. Тогда у вас не будет комка грязи с кучей вызовов. Вызовов вообще быть не должно практически. Максимум 1 уровень после Api Gateway + первого сервиса (того 2 уровня).

А главное, после такого объединения в 10 монолитов мы:
1. Получаем высокий уровень связанности, продолжая расширять его (нам же нужны новые фичи), вместо того чтобы не трогать то, что и так работает и делать новые фичи в новых микро сервисах. А связанность — главная проблема монолита. Она и влияет на сложность поддержки и увеличение вероятности ошибок и приводит к краху бизнеса, когда никто легаси г. не хочет расширять и даже переписывать. И это уже следующая глобальная беда, от которой страдает бизнес. Это вообще главная проблема — высокая стоимость поддержки и цена ошибки. Бинго, мы вернули её.
2. Мы не можем больше переписать микросервис за разумное время (12 человек за 1 неделю), не может быстро найти проблему и пофиксить её, не сломав другие куски, мы должны все перетестировать, вместо 1 куска.
3. ХЗ что делать с историей кода, т.к. 1 микросервис = 1 репозиторий. У нас не так, у нас общий репозиторий? поздравляю, мы мазохисты, но пока не знаем об этом.
4. Про порядок деплоя вообще смешно слушать было. Вы серьёзно? может у вас ещё микро сервисы один за другим вызываются и ждут действий в определённом порядке, а не только как справочники? Ок, молодцы. Вы сделали свою SOA шину. Это г. не работало ещё в 2005ом.

Слово микро — ключевое, а не лишнее. А то, что кто-то не умеет управлять большим количеством сервисов — так это его личная проблема, а не проблема архитектуры.

Вот что бывает, когда люди, не имея практики и не зная современных подходов по проектированию процессов предметной области, а умея только перекладывать данные из табличек базы в UI, не зная как применять DDD и формировать правильные контексты берутся за следующий уровень — делить код на инфраструктурном уровне. А потом виноваты все — микросервис, архитекторы, зоопарки.
Зато освоили кучу новых слов и возможно даже технологий, кубренетисы, докеры, OSGI.

Давайте начнем с начала. Один микросервис это никак не одна фича. Один микросервис это одна продуктовая команда. Ну и на этом можно закончить, пожалуй.

Один микросервис это никак не одна фича. Один микросервис это одна продуктовая команда

очень спорно. Тут отношение гораздо более сложное.
Вообще коллега на самом деле прав — потому что когда у тебя уровень вложенности вызовов больше 5 — это какая-то неправильная архитектура и неправильная декомпозиция. Другой вопрос, что вероятно, что когда-то что-то пошло не так, но уже сил и мужества признать ошибку не было… И получилось как получилось — как в энтепрайзе с кучей легаси систем коробок...

Да можно было и не начинать с такой глупости: путать и смешивать распределение ответственности (1 команда -> 1 сервис -> 1 ответственность за разработку и релиз ) с разделением предметной области\контекста ( 1 фича — 1-> один близкий контекст (домен) -> 1 один микро сервис). Или если в принципе команд физически 1 или 2, то что им после написания 2ого микро сервиса сказать: нанимайте ещё людей, а мы будем эти 2 поддерживать? нет конечно. Они будут продолжать их писать. И фичи делать и поддерживать.
Да и все эти авторы книг по DDD и микро сервисам они, конечно же дураки.
Заканчивать действительно стоит, раз на подробный комментарий человек безапелляционно говорит просто глупость в духе «ой всё». Вероятнее всего вы или не писали сами микро сервисы (судя по выступлениям вы обычный менеджер который делал раньше девопс, а не разработчик) или писал неправильно, но потом героически решал проблемы вызванные своим недопониманием проблемы связанности и разделения (распределённые транзакции, там где они не нужны, гонки в распределённых сервисах, многоуровневые подзапросы и т.д.)

PS и ваши моментальные и безответные минусы — как детский сад: радуют и забавляют. Когда нечего ответить, а признавать что не прав стыдно, то лучше поправить пенсне и притвориться важным
Зарегистрируйтесь на Хабре , чтобы оставить комментарий