Да, получим. Я не готов обсуждать «в общем случае», но в частном — совершенно точно и даже примеры есть (можно прямо мой выше).
Нет, микросервисы не требуют кубернетеса. И даже не факт, что там будет удобнее. Мониторинг и авто[ДО]запуск можно без проблем реализовать и без кубернетеса.
Ну а «разумность» деления, как и всё прочее, по-прежнему опирается на разумность(опыт?) тех, кто это решает. В целом и как в монолите ранее.
Желательно сильно не буквально. На мой взгляд цель создания «микросервисной архитектуры» в том, чтобы в будущем делать изменения и масштабирование системы удобно и с минимальным влиянием на остальные части.
Нам же не нужен микросервис ради микросервиса: переход должен нести какую-то ценность, а не просто удовлетворять каким-то там требованиям по определению.
Например: поиск, изменение и создание клиентской записи. Вполне логично, что их можно разделить на три сервиса, но с другой стороны, чем больше сервисов, тем больше нужно заботиться о модели хранения данных и нужно больше контроля за ними. А если заранее известно, что запросов на создание и изменение будет мало, то проще все три сделать в одном модуле и просто поднять приоритет операциям «создание/изменение» (если это вообще требуется).
Это или не мне или мой комментарий понят неправильно.
Я «за» точную цитату (практически) любой длины, если она красиво встроена в речь, а не занудно читается с экрана.
Идеально будет встроить эту фразу в рассказ, а не читать её. Например: «как сказал Эйнштейн» и далее цитата. Ну или как-то обыграть по-другому.
Просто читать с экрана да ещё отвернувшись от зала — плохая идея.
Не очень понятно какая из сторон отвечает за то, чтобы в топике было нужное количество партиций для потребителей? Что делать ответчику, если нужно отправить сообщение в partition_id, но партиции с таким номером нет.
Да вроде бы ведёт себя как описано в документации. В зависимости от режимов — либо восстановится сам, либо потребует ручного вмешательства. Есть нюансы: при некоторых настройках и неправильном восстановлении можно убить целиком весь кластер.
Лифты, вентиляция, насосы для воды и отопления, освещение. Это всё в зависимости от дома и его систем может дать вполне значимые цифры.
Вот например даже одна лампочка на 60Вт за месяц потребляет ~40кВт.
Я инженер проектировщик, главный конструктор в одной из крупнейших кампаний СПБ.
Дело в том, что опыт «строительства» и опыт «строительства с хорошим результатом» это два разных опыта. Я ничего не хочу сказать про вас, но людей, которые заявляли «да у меня опыт» за последние два года я видел очень много, с десяток точно наберётся… И пострадать от чуши, которую они делали, мне пришлось солидно.
Выскажу несколько другое мнение: я скорее буду ориентироваться не на шаблонность, а на полноту информации по товарам и всякие доставки-самовывозы (ну и цена конечно).
Я даже больше скажу: скорее всего я выберу шаблонный сайт, потому что почти наверняка он продуман в плане навигации, а какой-нибудь вырвиглазный дизайн с непредсказуемым поведением при клике — проигнорирую.
Дьявол в деталях: увеличие радиуса действительно зависит только от удлинения, а вот если натягивать в одной точке, то ответ становится «неожиданным».
Например: пусть изначально длина окружности «земли» 1 мм, а удлинение опять таки 1м, тогда натяжение в одной точке даст «высоту» почти 50 сантиметров.
Нет, микросервисы не требуют кубернетеса. И даже не факт, что там будет удобнее. Мониторинг и авто[ДО]запуск можно без проблем реализовать и без кубернетеса.
Ну а «разумность» деления, как и всё прочее, по-прежнему опирается на разумность(опыт?) тех, кто это решает. В целом и как в монолите ранее.
Нам же не нужен микросервис ради микросервиса: переход должен нести какую-то ценность, а не просто удовлетворять каким-то там требованиям по определению.
Например: поиск, изменение и создание клиентской записи. Вполне логично, что их можно разделить на три сервиса, но с другой стороны, чем больше сервисов, тем больше нужно заботиться о модели хранения данных и нужно больше контроля за ними. А если заранее известно, что запросов на создание и изменение будет мало, то проще все три сделать в одном модуле и просто поднять приоритет операциям «создание/изменение» (если это вообще требуется).
Итого: всё зависит от задачи.
Я «за» точную цитату (практически) любой длины, если она красиво встроена в речь, а не занудно читается с экрана.
Просто читать с экрана да ещё отвернувшись от зала — плохая идея.
Вот например даже одна лампочка на 60Вт за месяц потребляет ~40кВт.
Дело в том, что опыт «строительства» и опыт «строительства с хорошим результатом» это два разных опыта. Я ничего не хочу сказать про вас, но людей, которые заявляли «да у меня опыт» за последние два года я видел очень много, с десяток точно наберётся… И пострадать от чуши, которую они делали, мне пришлось солидно.
Я даже больше скажу: скорее всего я выберу шаблонный сайт, потому что почти наверняка он продуман в плане навигации, а какой-нибудь вырвиглазный дизайн с непредсказуемым поведением при клике — проигнорирую.
Например: пусть изначально длина окружности «земли» 1 мм, а удлинение опять таки 1м, тогда натяжение в одной точке даст «высоту» почти 50 сантиметров.