На самом деле гелий-3 образуется из трития, который, в свою очередь, получается при реакциях скалывания ядер вроде углерода и азота нейтронами, которые вышибаются из других ядер протонами солнечного ветра.
Но гелий-3 сам по себе бесполезен для энергетики, он ничем особо не лучше обычного дейтерия. Гелий-3 был псевдонаучным обоснованием необходимости освоения луны.
Дайте догадаюсь, это - нефункциональные требования и даже не SLA. В таких случаях новый модный фреймворк обычно обкатывают на новых микросервис ах, избавляясь от риска заодно сломать старые.
Ну а вообще, для единственной команды которая поддерживает сразу весь функционал, нужды в микросервисах вероятно, и нет
Всё взаимодействие с микросервисом должно быть ограничено его API и SLA. Остальное должно быть внутренним делом команды или разработчика, который его поддерживает. Откуда взяться изменениям для всех? Не политика ли случаем?
Если вы ссылаетесь на два процессора (это такой класс с бизнес-логикой), то уместные имена будут: ClientProcessor, OrderProcessor, чтобы отличить один процессор от другого.
Называть что-либо "процессор" - это уже антипаттерн.
Строго говоря, микросервисы должны быть мелкими в любом отношении. 10 реплик, кушающих по 1 гб памяти и 10 реплик, кушающих по 10 мб - это совсем разные расходы на инфраструктуру
Оверхед k8s и контейнеров вообще - неочевиден. Можно ли привести какие то примерные числа для сравнения эффективности условного нативного микросервиса на WASM и в K8s?
Строго говоря, на графике в нижнем правом углу Utilization, а не Saturation. Но так даже лучше, ибо Saturation определяет Latency и виден на соответствующем графике
На самом деле гелий-3 образуется из трития, который, в свою очередь, получается при реакциях скалывания ядер вроде углерода и азота нейтронами, которые вышибаются из других ядер протонами солнечного ветра.
Но гелий-3 сам по себе бесполезен для энергетики, он ничем особо не лучше обычного дейтерия. Гелий-3 был псевдонаучным обоснованием необходимости освоения луны.
Как так отмененная страна ещё и ракеты к Луне запускает? Порвали же в клочья (с) ещё в 2009 г, не?
Вы ещё европейской медицины не видели
Статья полна фактических ошибок, вроде
Или
Не надо, пожалуста
С каких пор галлий и германий стали редкоземельными элементами?
Еретик! Ловите его
Если электроника уйдёт на отдых, то поднять будет уже никак
Дайте догадаюсь, это - нефункциональные требования и даже не SLA. В таких случаях новый модный фреймворк обычно обкатывают на новых микросервис ах, избавляясь от риска заодно сломать старые.
Ну а вообще, для единственной команды которая поддерживает сразу весь функционал, нужды в микросервисах вероятно, и нет
Всё взаимодействие с микросервисом должно быть ограничено его API и SLA. Остальное должно быть внутренним делом команды или разработчика, который его поддерживает. Откуда взяться изменениям для всех? Не политика ли случаем?
Собственно, это единственная проблема, которую такой монолитный подход решает. В остальном монолит только создаёт проблемы.
Но зачем изменения во всех микросервис ах? Микросервисы должны быть независимы по определению и вообще могут быть написаны на разных языках.
Называть что-либо "процессор" - это уже антипаттерн.
https://stackoverflow.com/questions/5569666/what-is-a-better-name-than-manager-processor-etc
Строго говоря, микросервисы должны быть мелкими в любом отношении. 10 реплик, кушающих по 1 гб памяти и 10 реплик, кушающих по 10 мб - это совсем разные расходы на инфраструктуру
IPC? Вы к нам случаем не из python?
Да, оборот "could be" здесь намекает на то, что wasm быстрее lxc в лучшем случае иногда)
А, кажется я понял, на WASM контейнер может стартовать быстрее, чем в Docker. Но тогда речь не о микросервисах, а о serverless функциях.
Оверхед k8s и контейнеров вообще - неочевиден. Можно ли привести какие то примерные числа для сравнения эффективности условного нативного микросервиса на WASM и в K8s?
Строго говоря, на графике в нижнем правом углу Utilization, а не Saturation. Но так даже лучше, ибо Saturation определяет Latency и виден на соответствующем графике
Емнип купить машину без венды уже давно не так просто
Действительно. Убрал