Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Интересует. Розетки без приборов — это аналог Kubernetes без микросервисов. Мы же говорим не об этом.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
Да ну, серьёзно? А у Вас никогда не вырубались сразу все приборы от включения, например, стиральной машины? Точно не влияет на другие?
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Не смогу даже свет включить в нём? А окно открыть? Или даже с парой силачей отогнать на обочину, т. е. колёса не смогут выполнять свою функцию? А датчики показывать будут скорость, с которой машину толкают? А ручной тормоз тоже работать не будет, то есть она даже стоять не сможет? Или всё-таки не работает только двигатель, а остальные части автомобиля работают?
Можно подумать, если двигатель откажет в автомобиле, то датчики ничего показывать не будут, или колёса крутиться не будут. Если тормоз откажет во время движения, машина ведь не перестанет ехать от этого? :)
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Сравнивать нужно не розетки, а приборы. Розетка — это разомкнутая цепь, а, значит, ток не проводит. И даже если у Вас стоят автоматы везде по дому и по нейтрали, и по фазе, пара человек в доме всегда могут догадаться пустить заземление по отопительной батарее (на нейтраль тоже любят пускать). Случаи, когда какой-то уникум спалит оборудование по подъезду, случаются.
Всё-таки пытаться сложность работы микросервисов через аналогию с электротехникой или механикой — это бессмысленная идея. Это как пытаться доказать математическую теорему через философию.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Вы просто взяли и разделили механические связи и электрические, хотя по факту оба являются способом передачи энергии и данных. Если забыть про эти же провода в автомобиле, взять для рассмотрения электромобиль, двигатель нельзя запустить отдельно от автомобиля? Или аккумулятором нельзя запитать что-либо в другой цепи? А сколько датчиков у автомобиле? Может там всё-таки много групп микросервисов разного рода?
Если красиво спрятать провода, то будет монолит получается? Странная логика.
Это красиво звучит, но через какой промежуток времени, оторванный от разработки управленец с высоким уровнем профессионализма, потеряет свой уровень в разработке?
Я не использовал волновой алгоритм уже около 13 лет. Я до сих пор помню, как он реализуется. Примерно столько же я не программировал на Turbo Pascal, но если мне дадут его, то я без проблем напишу требуемую программу. Я даже до сих пор помню, что команда очистки экрана называется примерно `clrscr();` из модуля `CRT`. И я не гуглил, чтобы подглядеть (поэтому не гарантирую, что правильно). И вот зачем мне сейчас знать, что разрешение EGA или CGA около 320x200? Это при том, что паскалеподобные языки я не использую давным давно, а информация того времени мне уже вообще не нужна.
Профессиональная специализация — это то, что очень хорошо заседает в голове, вряд ли её получится оттуда убрать даже, если захочется.
Проблема менеджера будет скорее в выгорании из-за намного менее интересной работы. На этот случай можно было бы ввести практику поощрения перемещения по должностям с постоянной подготовкой новых менеджеров из сеньоров. Это и повышение квалификации программистов, и гарантия, что не потребуется срочно в панике искать нового менеджера проекта.
Управленец скорее не потеряет уровень в разработки, а просто отстанет от быстро меняющихся технологий. Но опять же решается или периодическим повышением квалификации, или свободными перемещениями по карьерной лестнице.
По вашей классификации это получается микросервисная архитектура.
* Шина взаимодействия IPC разная.
* Система вряд ли будет работоспособна, если хотя бы один сервис упадёт.
* Вряд ли в такой системе предусмотрена возможность запуска нового сервиса, о котором другие до того не знали, так, чтобы он начал взаимодействовать с другими сервисами.
Имхо микросервисная архитектура без какой-нибудь оркестрации — это нонсенс.
Я бы не стал привязывать термин исключительно к новомодным явлениям. Микросервисы в первую очередь однотипны (исполняются в одной среде), и каждый выполняет ровно свою полностью законченную задачу. Вы сейчас говорите об этом шаблоне использования:
Microservices architectures have given rise to many approaches for making them work well at varying degrees of scale. One widely discussed pattern for large-scale microservices development and delivery is the service mesh pattern.
In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as Kubernetes.
Микросервисы, судя по Википедии, входят в SOA и это не обязательно контейнеры и оркестрация через популярные штуковины. А границы термина размыты.
* Взаимодействие одноранговое.
* Если один микросервис не поднялся, остальные продолжают работать в штатном режиме (иначе — ошибка разработчика).
То есть потому что это оказалось непросто — вы делаете выводы, что любая другая неизвестная технология будет лучше?
Может всё-таки потому, что проект заходит местами в тупики и потихоньку всё-таки обрастает микросервисами? Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже. Почему так — вопросы финансирования, кадров, сроки и компромиссы.
А что если декомпозированы неправильно, где будет легче исправить? Думаете переписать несколько микросервисов будет легче?
Думаю, что можно будет сделаю прослойку абстракции для API, а переписывать по мере надобности. Весь проект будет переписать тяжелее, в любом случае.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами? Там в обоих случаях всё плохо будет.
Есть проекты, где нет никакого смысла в микросервисах. Есть проекты, где монолитную систему можно сделать модульной, но всё ещё нет смысла в микросервисах. Есть те, — где уже появляются выгоды при создании микросервисной архитектуры, но всё ещё можно монолитом сделать. А есть проекты, где монолит будет уже сильно убыточен из-за дороговизны поддержки. Всё зависит от сложности проекта.
Правильнее было бы рассматривать отдельные связки узлов. У меня такой график в Doxygen был недавно. Просто в любом сложном проекта он абсолютно неинформативен.
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов, иерархически объединённые в одну сложную систему. Простой в создании она становится именно благодаря декомпозиции на независимые составляющие.
Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
Опыт разработки монолитной системы.
И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Потому что покрыть тестами желательно каждую мелочь в монолитном проекте. Если отдельно микросервис покрыт собственными тестами, то в монолите в каждом тесте требуется тестировать сразу весь проект. Тут стоит сделать оговорку, что и в монолите можно повставлять всякие моки и подобное, но сложности будут. Из-за таких сложностей либо тесты будут дорогостоящими, либо будут очень дешёвыми комплексными и не учитывающими множественные частные случаи, т. к. по большей части тесты будут просто отсутствовать, а ошибки — циклически исправляться на лету.
Разницы во времени разработки (без учёта тестирования/исправления ошибок) с самого начала между двумя подходами быть практически не должно, если всё грамотно сделано. В случае микросервисов будет только начальный период подготовки инфраструктуры для внедрения и тестирования, а также создание скелета системы. Но это же ускоряет тестирование и отладку в будущем по сравнению с монолитными проектами.
Плюс монолита — в скорости начальной разработки, но не более. Монолит подходит для создания прототипа. И достоверных графиков Вы здесь не найдёте, а предположенные приводить бессмысленно, т. к. для подобного исследования потребовалось бы очень много денежных средств.
Есть вещи где достаточно логики, основанной на необходимых базовых знаниях, чтобы с большой долей вероятности выдвигать какие-либо гипотезы. Это тот случай.
В этом вопросе полностью солидарен. Компания должна предоставлять все средства для повышения квалификации персонала и максимально к этому мотивировать.
Просто в статье высмеивается найм профессионалов вместо подготовки кадров:
В терминальных стадиях это может выражаться в постулате «лучших людей можно и нужно нанять, нам некогда готовить своих».
Но не из всех программистов 3-й категории (junior) может получиться 2-я или 1-я, либо на это потребуется очень много времени. Многое зависит от черт характера и мотивации. Средств тратится на обучение иногда много, в то время как найм нескольких программистов 1-й категории на высокую заработную плату в очень долгосрочной перспективе может окупить работу пары десятков программистов 3-й категории.
Дочитал-таки до конца. То же самое, но кратко:
* выгоднее управленцев выращивать;
* управленец всегда должен быть уровня 1-й категории (сеньоры) с большим опытом работы;
* должно поощряться любое взаимодействие внутри компании (в том числе между разными отделами);
* обоснованные метрики должны быть основаны на разных параметрах и не должны быть беспрекословными;
* больше менеджеров — не значит лучше.
По большей части согласен, но статья слишком негативная. И от себя добавлю, что у разработчиков уровня 1-ой категории должна быть определённая доля свободы в принятии решений при разработке, вплоть до сдвига сроков разработки отдельных функций для реализации других или отказа от их реализации в предложенном виде на данном этапе разработки.
Проценты с точки зрения психологии плохо воспринимаются. Можно то же самое в числах переписать: на 1 миллион человек в возрасте от 30 до 40 лет в среднем умирает 12 000 тысяч человек. При увеличении на 9% — 13 080. Тысяча на миллион. Если вместо условного миллиона указать население Земли этого возраста, число будет уже пугать людей.
Если будут разрабатываться какие-то лекарства от старения, то убедиться в том, что они действительно работают можно будет только с помощью таких биомаркеров. А т. к. старение комплексный процесс, то чем больше маркеров насобирать, тем точнее будет анализ эффективности. Насколько понимаю, это всё на далёкое будущее, по крайней мере у нас. Зато привлекает внимание общественности к вопросу, пока цель, вероятно, в этом.
А более практичным применением на ближайшее будущее могло бы быть определение индивидуального пенсионного возраста, если в правительстве кто-нибудь догадается до этого. Но это сомнительная перспектива, т. к. не очень справедливо будет, что лютые алкоголики будут выходить на пенсию намного раньше всех остальных. И некоторые люди могут просто начать гробить здоровье принудительно, лишь бы раньше пенсия была.
А вот в плане определения рисков и выработки рекомендаций по изменению образа жизни уже сейчас такие маркеры могут пригодиться. Но тут ещё менталитет людей придётся менять.
Для того, что Вы предлагаете, требуется много свободного времени. У профессионалов, которые могут таким заниматься его как раз почти нет. А вот крупные компании такое могут потянуть, у них это может окупиться рекламой или побочными неявными возможностями, при условии не очень высоких начальных и низких последующих затрат.
Идея, которую я предложил несколько в другом, — фреймворк, который позволил бы разрабатывать некоммереские системы, в которых трудозатраты превышают любую возможную выгоду. Трудозатраты просто постепенно переносятся на доровольцев, нужен только начальный старт.
Ну и почему-то не смог найти статью, где хакеры увели у АНБ их архив наработок для взлома. Там рассказывалось про виртуализованную ОС, крутящуюся параллельно основной ОС, взлом через doc-файлы и прочее.
Так что не стоит недооценивать технические возможности обычных людей при наличии прекрасного финансирования и почти абсолютной власти.
Интересует. Розетки без приборов — это аналог Kubernetes без микросервисов. Мы же говорим не об этом.
Да ну, серьёзно? А у Вас никогда не вырубались сразу все приборы от включения, например, стиральной машины? Точно не влияет на другие?
Не смогу даже свет включить в нём? А окно открыть? Или даже с парой силачей отогнать на обочину, т. е. колёса не смогут выполнять свою функцию? А датчики показывать будут скорость, с которой машину толкают? А ручной тормоз тоже работать не будет, то есть она даже стоять не сможет? Или всё-таки не работает только двигатель, а остальные части автомобиля работают?
Сравнивать нужно не розетки, а приборы. Розетка — это разомкнутая цепь, а, значит, ток не проводит. И даже если у Вас стоят автоматы везде по дому и по нейтрали, и по фазе, пара человек в доме всегда могут догадаться пустить заземление по отопительной батарее (на нейтраль тоже любят пускать). Случаи, когда какой-то уникум спалит оборудование по подъезду, случаются.
Всё-таки пытаться сложность работы микросервисов через аналогию с электротехникой или механикой — это бессмысленная идея. Это как пытаться доказать математическую теорему через философию.
Вы просто взяли и разделили механические связи и электрические, хотя по факту оба являются способом передачи энергии и данных. Если забыть про эти же провода в автомобиле, взять для рассмотрения электромобиль, двигатель нельзя запустить отдельно от автомобиля? Или аккумулятором нельзя запитать что-либо в другой цепи? А сколько датчиков у автомобиле? Может там всё-таки много групп микросервисов разного рода?
Если красиво спрятать провода, то будет монолит получается? Странная логика.
Я не использовал волновой алгоритм уже около 13 лет. Я до сих пор помню, как он реализуется. Примерно столько же я не программировал на Turbo Pascal, но если мне дадут его, то я без проблем напишу требуемую программу. Я даже до сих пор помню, что команда очистки экрана называется примерно `clrscr();` из модуля `CRT`. И я не гуглил, чтобы подглядеть (поэтому не гарантирую, что правильно). И вот зачем мне сейчас знать, что разрешение EGA или CGA около 320x200? Это при том, что паскалеподобные языки я не использую давным давно, а информация того времени мне уже вообще не нужна.
Профессиональная специализация — это то, что очень хорошо заседает в голове, вряд ли её получится оттуда убрать даже, если захочется.
Проблема менеджера будет скорее в выгорании из-за намного менее интересной работы. На этот случай можно было бы ввести практику поощрения перемещения по должностям с постоянной подготовкой новых менеджеров из сеньоров. Это и повышение квалификации программистов, и гарантия, что не потребуется срочно в панике искать нового менеджера проекта.
Управленец скорее не потеряет уровень в разработки, а просто отстанет от быстро меняющихся технологий. Но опять же решается или периодическим повышением квалификации, или свободными перемещениями по карьерной лестнице.
* Шина взаимодействия IPC разная.
* Система вряд ли будет работоспособна, если хотя бы один сервис упадёт.
* Вряд ли в такой системе предусмотрена возможность запуска нового сервиса, о котором другие до того не знали, так, чтобы он начал взаимодействовать с другими сервисами.
Я бы не стал привязывать термин исключительно к новомодным явлениям. Микросервисы в первую очередь однотипны (исполняются в одной среде), и каждый выполняет ровно свою полностью законченную задачу. Вы сейчас говорите об этом шаблоне использования:
* Взаимодействие одноранговое.
* Если один микросервис не поднялся, остальные продолжают работать в штатном режиме (иначе — ошибка разработчика).
Чем не микросервисы?
Может всё-таки потому, что проект заходит местами в тупики и потихоньку всё-таки обрастает микросервисами? Переделать монолитный проект в микросервисный (каким он изначально и задумывался) намного дороже. Почему так — вопросы финансирования, кадров, сроки и компромиссы.
Думаю, что можно будет сделаю прослойку абстракции для API, а переписывать по мере надобности. Весь проект будет переписать тяжелее, в любом случае.
И, думаю, не стоит рассматривать случай, когда декомпозиция была неправильной по той причине, что делалась начинающими программистами? Там в обоих случаях всё плохо будет.
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов, иерархически объединённые в одну сложную систему. Простой в создании она становится именно благодаря декомпозиции на независимые составляющие.
Опыт разработки монолитной системы.
Потому что покрыть тестами желательно каждую мелочь в монолитном проекте. Если отдельно микросервис покрыт собственными тестами, то в монолите в каждом тесте требуется тестировать сразу весь проект. Тут стоит сделать оговорку, что и в монолите можно повставлять всякие моки и подобное, но сложности будут. Из-за таких сложностей либо тесты будут дорогостоящими, либо будут очень дешёвыми комплексными и не учитывающими множественные частные случаи, т. к. по большей части тесты будут просто отсутствовать, а ошибки — циклически исправляться на лету.
Разницы во времени разработки (без учёта тестирования/исправления ошибок) с самого начала между двумя подходами быть практически не должно, если всё грамотно сделано. В случае микросервисов будет только начальный период подготовки инфраструктуры для внедрения и тестирования, а также создание скелета системы. Но это же ускоряет тестирование и отладку в будущем по сравнению с монолитными проектами.
Плюс монолита — в скорости начальной разработки, но не более. Монолит подходит для создания прототипа. И достоверных графиков Вы здесь не найдёте, а предположенные приводить бессмысленно, т. к. для подобного исследования потребовалось бы очень много денежных средств.
Есть вещи где достаточно логики, основанной на необходимых базовых знаниях, чтобы с большой долей вероятности выдвигать какие-либо гипотезы. Это тот случай.
Но не из всех программистов 3-й категории (junior) может получиться 2-я или 1-я, либо на это потребуется очень много времени. Многое зависит от черт характера и мотивации. Средств тратится на обучение иногда много, в то время как найм нескольких программистов 1-й категории на высокую заработную плату в очень долгосрочной перспективе может окупить работу пары десятков программистов 3-й категории.
* выгоднее управленцев выращивать;
* управленец всегда должен быть уровня 1-й категории (сеньоры) с большим опытом работы;
* должно поощряться любое взаимодействие внутри компании (в том числе между разными отделами);
* обоснованные метрики должны быть основаны на разных параметрах и не должны быть беспрекословными;
* больше менеджеров — не значит лучше.
По большей части согласен, но статья слишком негативная. И от себя добавлю, что у разработчиков уровня 1-ой категории должна быть определённая доля свободы в принятии решений при разработке, вплоть до сдвига сроков разработки отдельных функций для реализации других или отказа от их реализации в предложенном виде на данном этапе разработки.
Думаю да. Не видели никогда как в аптеке в очереди за боярышником стоят?
Все эти маркеры — это коммерция. Если не будет спроса, то и направление может не начать развиваться.
А более практичным применением на ближайшее будущее могло бы быть определение индивидуального пенсионного возраста, если в правительстве кто-нибудь догадается до этого. Но это сомнительная перспектива, т. к. не очень справедливо будет, что лютые алкоголики будут выходить на пенсию намного раньше всех остальных. И некоторые люди могут просто начать гробить здоровье принудительно, лишь бы раньше пенсия была.
А вот в плане определения рисков и выработки рекомендаций по изменению образа жизни уже сейчас такие маркеры могут пригодиться. Но тут ещё менталитет людей придётся менять.
Идея, которую я предложил несколько в другом, — фреймворк, который позволил бы разрабатывать некоммереские системы, в которых трудозатраты превышают любую возможную выгоду. Трудозатраты просто постепенно переносятся на доровольцев, нужен только начальный старт.
АНБ следит за теми, кто интересуется Linux и информационной безопасностью
АНБ в реальном времени контролирует каналы между дата-центрами Yahoo! и Google
АНБ не справляется с объёмами трафика
Правда Сноудена
Ну и почему-то не смог найти статью, где хакеры увели у АНБ их архив наработок для взлома. Там рассказывалось про виртуализованную ОС, крутящуюся параллельно основной ОС, взлом через doc-файлы и прочее.
Так что не стоит недооценивать технические возможности обычных людей при наличии прекрасного финансирования и почти абсолютной власти.