Комментарии 26
Статья, конечно, интересная, но хотелось бы увидеть для сравнения все-таки практическую реализацию (код)
Что-то как-то не то. Создаётся впечатление, что монолит (телевизор) можно превратить в микросервисы (телевизор с гаджетами) путём добавления частей к базе. Но телевизор с гаджетами это совершенно не то же самое, что изначально спроектированное частями целое, типа советских музыкальных центров, где ты можешь совмещать усилитель, колонки, радио, магнитофон, проигрыватель пластинок и т.п. в разных комбинациях.
В микросервисах не наращивается (улучшается) базовая архитектура, но общая функциональность разбивается на части и создаётся отдельно, с возможностью пересборки этих отдельных частей в других проектах со схожей функциональностью (подключить микрофон к усилителю и колонкам и использовать в караоке).
Так что если ваш бизнес (или телевизор) начинает барахлить, возможно, пришло время подумать о микросервисах — по чуть-чуть, шаг за шагом, вы сделаете его современным и гибким, не ломая всю систему сразу.
Ну и вывод, соответственно, также неверен.
так как раз и сделано то, что вы описали.
"общая функциональность разбивается на части и создаётся отдельно". была общая функциональность в одном телеке, разбили на части. От смарт тв осталась только функциональность монитора.
саундбар - используется в другом условном сервисе "прослушивание музыки без необходимости включения телевизора", до этого встроенный динамик использовался только в сервисе "просмотр фильмов".
приставка xiaomi используется в сервисе "просмотр фильмов в командировке", раньше этого было нельзя сделать, не потащу же я весь телек.
Понятно, что не одновременно, как в софте, но это ограничение хардверного примера.
Если убрать все навешанные навороты с телевизора, то возможность просмотра телепередач и интернета восстановится в прежнем объёме, пусть и в худшем, по сравнению с upgrade'ом, качестве.
В микросервисной архитектуре нет и не можеть быть в принципе ни одного компонента, который бы обладал функциональностью всего комплекса, пусть и в худшем качестве.
Я понимаю, что в некоторых случаях легаси-монолит можно постепенно трансформировать в микросервисы, но с телевизором и его периферией действительно не слишком удачный пример получился.
Очень слабенькая статья с жидкими примерами. Тут даже аргументировать нечего. Пожелание автору более плодотворной работы)
С примерами не угадали. Есть такое правило, что если концепция верна, то мы по идее можем заменить телевизор на другое устройство: тостер, микроволновку, вибратор:)
И выводы останутся прежними. Но чёт не работает:)
Был вроде бы монолит, а стал распределённый монолит. Где тут микросервисы?
почему?
саундбар же используется в другом условном сервисе "прослушивание музыки без необходимости включения телевизора", до этого встроенный динамик использовался только в сервисе "просмотр фильмов".
приставка xiaomi используется в сервисе "просмотр фильмов в командировке", раньше этого было нельзя сделать, не потащу же я весь телек.
понятно, что не одновременно, как в софте, но это простой хардверный пример.
А что мешает в монолите "разбить на части" и развивать независимо. Модульность существовала задолго до микросервисов.
А мне статья понравилась. Конечно, если душнить - во всём можно найти минусы, но в данном случае содержание соответствует заголовку: тема раскрыта легко (хоть и неглубоко - но глубин вроде тут никто не обещал), доступно и с юмором.
Как пример простыми словами подходит, именно так пилят монолит, выбирают одну функцию и выносят из монолита в микросервис, потом убивают легаси код. Когда телевизор превратится в монитор, работа закончена
У меня есть два проекта, один на микросервисах, второй на монолите. Предположим, и то и другое одновременно либо написано с головой (код переиспользуется, одинаково хорошо масштабируется, оптимизировано и т.д.), либо из гомна и палок. Оба чуда на X языке и на Y фремворке.
Ситуация 1: обновился X язык и нужно все обновить.
Ситуация 2: обновился Y фремворк и нужно все обновить.
Вопрос 1: всем выгода?
Ситуация 3: в каком-то модуле/микросервисе ошибка.
Вопрос 2: в чем выгода микросервисов/монолита?
Вопрос 3: статья о предпочтениях автора?
P.S. сугубо личное имхо: для выборо того или иного пути, нужно разобраться какими мы ресурсами обладаем, какие цели преследуем. Из плюсов микросервисов вижу только относительная простота конкретного микросервиса (у разработчиков меньше плавятся мозги) и если кто-то что-то утащит из кода, ущерб будет меньше (но разработчикам ли об этом думать?).
Спасибо за внимание :о)
Пример с телевизором плохой. В телевизоре можно заменить софт, но нельзя улучшить железо. А вот перетащить монолит на новое железо - это совсем не проблема. Да и в целом, серверные приложения и телевизор - это не одно и то же.
Опять срач микросервисы и монолит. Вот запомните , ни микросервисы ни монолит ни хорошо ни плохо. Если нужно посмотреть телек- включи и смотри. Если нравится менять батарейки в 10 пультах - то же твой выбор. Код должен решать задачу. Как то видел - вынесли все нахер в микросервисы все. Всю логику, системный архитектор уволился , и в 500 серверах , хер знает что происходит .
В момент пиковых нагрузок сеть цод нахер легла. Потому что - неожиданно , микросервисы работают как отдельные программы которые общаются по сети
Нужно хорошо написанный модульный код.который будет понятен. Из которого в случае необходимости , можно вынести микросервис с которым можно работать А не обосраться микросервисами потому что так модно.
Хотя у меня ощущение что уже так проджектам мозги прополаскали что в их создании девять баб за месяц могут ребенка родить
Этот пример доказывает что сервисная архитектура (SOA) это вещь, но никак не микро! В реальном мире нет ни одного примера МИКРО-сервисной архитектуры.
Умный дом?)
А поскольку в реальном мире нет ни одного примера микро-сервисной архитектуры, то это говорит о том, что такая архитектура не прошла проверку временем и была забракована эволюцией как не жизнеспособная и не выдерживающая конкуренции с другими архитектурами, что современные разаработчики ощущают сейчас на собственной шкуре матерясь и плюясь пытаясь разобраться в сотнях непонятных микросервисов.
Теперь осталось запустить на тумбу кота и привязать к проводам его игрушки - будет хорошая аналогия "стабильной" работы микросервисов в шареной сетке облака.
Микросервисная архитектура — это концепция, которая существует уже довольно давно, но до сих пор многие не до конца понимают, в чем ее суть
Например, автор статьи.
Вне контекста масштабирования и отказоустойчивости любое обсуждение микросервисной архитектуры - ересь.
Черное, белое… Серое!
Лучше всего если бы вы могли вытащить колонки из телевизора и поставить на их место новые, то же и с модулем с ОС, пульт бы был один и работал с таким же заменяемым контроллером пульта.
И если бы замена занимала минуту даже дауном, а настройка выполнялась бы автоматически. Пульт при этом должен «подстраиваться» под набор устройств в телевизоре как Мистик из XMan.
В идеале и экран тоже так же нужно менять.
Нужно лишь договориться об интерфейсе подключения (Type C?) и протоколе…
Это тоже монолит, только с правильной архитектурой. Но большинство разработчиков делают либо обычный телевизор, либо то, что вы описали… Только у них еще хуже всё, чтобы подсоединить колонки надо самому паять переходник, каждый динамик настраивается отдельно по сложной инструкции, иначе не заработает или звук будет отставать где-то, где-то тише, где-то громче :) Приставка требовала бы ручного патчинга KDE под FreeBSD, работала бы от питания 4.37V ни больше ни меньше, но только если колонки играют тише 50% громкости, если больше - уже 5V. Пульты бы не работали, если бы лежали ближе 1м друг к другу и некоторые функции меняли бы что-то еще в других системах (типа сделал громче и стала яркость меньше, увеличил яркость и язык в ОС поменялся на японский)
Микросервисная архитектура vs монолит (на простом примере)