Категорически не согласен с тем, что это "быстро-грязно". В принципе когда человек максимализирует какую-то идею, это фанатизм, и диалог с таким человеком не выйдет. Так что честь имею.
Для микросервиса важно, чтобы его можно было через CI/CD пайплайн вывести отдельно от других микросервисов - то есть независимость деплоймента. Если пайплайн устроен так, что одновременно деплоится несколько микросервисов - это нарушает изоляцию деплоймента.
Я говорю не про CI/CD утилиту, а про конкретный пайплайн для одного микросервиса.
Если у микросервиса есть общие с другим микросервисом файлы, которые при деплое могут быть изменены - это тоже нарушает независимость деплоймента.
Ну и не важно, эксешник это или нет. Это компонент который можно задеплоить и запустить. А как он реализован - скрипт, бинарник, докер образ - уже второстепенно, главное чтобы каждый микросервис можно было задеплоить независимо от других.
При этом для упрощения релизов, можно сделать какой-то враппер, который может задеплоить одной кнопкой несколько микросервисов, это не мешает, главное чтобы в случае необходимости можно было каждый из них отдельно.
в северокорейском может быть. в СНГ - не припомню такого случая, а в фидо оно бы очень быстро разлетелось - в отличие от инета это было очень небольшая сеть. там знакомые через 2 руки а не через 10
Думаю блочили не Фидо, а то, что телефонные линии не являлись свободными и полностью бесплатными, как думали некоторые пользователи. Никогда не слышал о контроле Фидо в 70-80е со стороны государства. Скорее инициатива отдельных учреждений, направленная не против фидо, а против использования телефонов организации не по назначению. Дома - сиди, звони.
Есть же view. Если вы работали с оракл или постгрес, и не пользовались этим, то зря - как раз для таких случаев.
Опять же, изоляция ради изоляции - не то, что нужно. Основная задача микросервисов - упрощение разработки и масштабирования. Изоляция тут как часть основной задачи. И изоляция базы данных может быть реализована или через документирование структуры или через вьюхи или через независимые базы. Смотря что требуется.
Вот есть у нас микросервис, который занимается созданием отчетов о бизнес процессах. Он берет данные из основной базы. Скажете это не микросервис? Или каким образом нужно для него генерировать данные - копировать всю основную базу? Внедрять экспорт данных в сервис который ведет процессинг? Нет, вполне достаточно чтобы конкретно эти два микросервиса пользовались одной базой. Микросервис отчетов только считывает и в случае изменения структуры базы да, нужно будет поправить оба. С точки зрения архитектуры - это проще и дешевле, чем создавать полную изоляцию ради изоляции.
в чем тогда отличие микросервисов от просто экзешников (обычных приложений), которые тоже можно писать совершенно независимо друг от друга?
просто экзешник это просто бинарный файл. В этом определении не указано как его деплоить и запускать. Микросервис по определению должен не только разрабатываться независимо, но и деплоиться. То есть его рантайм окружение, и его CI/CD пайплайн должны быть незаивисимы. Например оба эксешника можно руками копировать и запускать на том же хосте. Но в разных директориях, с разными конфигами, чтобы можно было не останавливая один, например удалить перенести на другой хост другой.
Очень многие недооценивают ретро, а ведь именно ретро позволяет внедрять гибкие методологии.
Без ретро, это не гибкая методология, а спринт-ориентированная. Какая же она гибкая, если один раз настроили и все? Методология должна адаптироваться к проекту по мере изменения/роста проекта.
И именно ретро и помогает вывести проблемы на передний план и найти решение. Если у участников ретро нет никаких полномочий на изменение процессов, то смысл в ретро отсутствует. Действительно задача менеджера организовать правильную работу ретро-митингов.
У нас примерно так было - каждый может вынести свои вопросы на ретро. Совместно тратим небольшое количество времени чтобы уточнить это системная проблема или разовая и ее можно решить прямо сейчас, если нет - вносим в бэклог ретро и назначаем ответственного, который до следующего ретро должен провести исследование и возможно предложить решение. Ответственный не обязательно то, кто будет внедрять решение. Это тот, кто отвечает за организацию, коммуникации, ищет кто и как может решить. На следующем митинге ответственный может и измениться, если будет понятно кто лучше это сделает. Главное, что в бэклоге мы отслеживаем сколько времени проблема там висит, и если висит слишком долго, повышаем приоритет. Бывают проблемы, которые требуют значительных изменений в процессах. Надо обосновать что эти изменения окупятся. И да, благодаря такой структуре было проведено множество как мелких, так и достаточно значимых изменений в работе проекта.
Ну и во вторую очередь речь о том, что желательно использовать общепринятые термины, а не какие красивее звучат
Так в определении микросервисов нигде не указано что в изоляцию включается база данных. Если почитаете банальное определение на википедии, там будет видно что изоляция на уровне разработки и деплоймента, что означает - отдельные кодовые базы и отдельный процесс/под. Структура базы данных может быть согласована заранее и не меняться. Либо использовать разные таблицы. Либо использовать вьюхи - это уже не есть часть определения. Сервисы должны общаться друг с другом, поэтому в любом случае нужно соблюдать контракты и это уже означает согласование, а не идеальную независимость всего от всего. То, что за полтора десятка лет распространения микросервисов, начинают переосмысливать и вводить новые вещи... ну так ООП тоже изначально был задуман не так, как используется, и частные споры о том, что и как должно быть в ООП не заменяют базовых определений.
Я считаю, что когда независимость микросервисов возводится в абсолют - это неправильное понимание что такое микросервисы. Микросервисы были сделаны для того, чтобы облегчить разработку и облегчить масштабирование. Делается это методом, что один микросервис выполняет одну определенную функцию и коммуницирует с другими компонентами. Изоляция в разработке позволяет довольно быстро переписать конкретный микросервис с нуля, в том числе и на другом языке, с применением других технологий, что было бы сложно в случае монолита. Изоляция в деплойменте говорит, что изменения в этот микросервис можно внести и вывести на продакшен без изменений где-либо в другом месте. Часто деплоймент может быть полностью автоматизирован.
Насчет того, что микросервисы обязаны иметь изолированные базы, иначе это не микросервис - тут я не соглашусь, это уже просто разные варианты использования микросервисной архитектуры, и тут нет "лучшего". Есть просто разные подходы как этим пользоваться в каждом конкретном случае.
Один микросервис предоставляет API для работы с приложением. Другой может предоставлять UI для пользователей. Третий микросервис позволяет выполнять отчеты Четвертый может быть UI админкой.
Для всех сервисов могут требоваться разные варианты ресурсов. Сервис для отчетов, например, может быть вообще кронджобой, которая не не будет требовать ничего в ожидании события. И все работают с одной базой. Все могут независимо масштабироваться.
Вот вполне рабочий вариант микросервисов и одной базы.
Микросервисы по сути не имеют права быть полностью независимыми - ведь они по сути являются частью большого приложения, а не независимых приложений. Основная задача микросервисов - простое масштабирование тех моментов, где может возникать бутылочное горлышко, и упрощение приложение, чтобы было легче разрабатывать новые фичи - тут да, нужна независимость от других микросервисов, но она может соблюдаться грамотным версионированием "коннекторов" и апи.
Признайтесь, что вы не в курсе всей ситуации. Основной заказчик лунной программы - не Маэдзава, а НАСА, и там совсем другие деньги и определенные задачи. Работа по контракту с НАСА в принципе не мешает параллельно подрабатывать на других заказчиках, чем пытался воспользоваться Маск, который делал Старщип для выхода на орбиту и возможно будущем прилунении (там еще будут вопросы). Но НАСА придумало достаточно сложный вариант лунной программы, который включает в себя участие нескольких подрядчиков в сложном взаимодействии, которое кроме конечной цели, имеет также цель создать конкурентную среду, много рабочих мест и задействовании большого количества компаний, которые развивают космическую промышленность.
Был момент, когда SpaceX получило определенный зеленый свет, и уже начало работу, конкуренты подали жалобу, проект был приостановлен на некоторое время, пока не решился вопрос "справедливого" распределения денег. Ну там много аспектов, справедливость штука сложная в политике. Тем не менее это помешало Маску выполнить параллельно договроенности с туризмом.
кому нужны?
Ну я вот тоже старожил, я не припомню ни одного случая, и вообще про ФИДО мало кто тогда знал, в основном там сидели подростки.
Как Дурова с ВК?
Категорически не согласен с тем, что это "быстро-грязно".
В принципе когда человек максимализирует какую-то идею, это фанатизм, и диалог с таким человеком не выйдет. Так что честь имею.
Для микросервиса важно, чтобы его можно было через CI/CD пайплайн вывести отдельно от других микросервисов - то есть независимость деплоймента.
Если пайплайн устроен так, что одновременно деплоится несколько микросервисов - это нарушает изоляцию деплоймента.
Я говорю не про CI/CD утилиту, а про конкретный пайплайн для одного микросервиса.
Если у микросервиса есть общие с другим микросервисом файлы, которые при деплое могут быть изменены - это тоже нарушает независимость деплоймента.
Ну и не важно, эксешник это или нет. Это компонент который можно задеплоить и запустить. А как он реализован - скрипт, бинарник, докер образ - уже второстепенно, главное чтобы каждый микросервис можно было задеплоить независимо от других.
При этом для упрощения релизов, можно сделать какой-то враппер, который может задеплоить одной кнопкой несколько микросервисов, это не мешает, главное чтобы в случае необходимости можно было каждый из них отдельно.
свобода слова не означает, что у вас должен быть доступ к медиа. Это означает что вас не посадят.
в северокорейском может быть.
в СНГ - не припомню такого случая, а в фидо оно бы очень быстро разлетелось - в отличие от инета это было очень небольшая сеть. там знакомые через 2 руки а не через 10
Хроники лаборатории? =)
Думаю блочили не Фидо, а то, что телефонные линии не являлись свободными и полностью бесплатными, как думали некоторые пользователи.
Никогда не слышал о контроле Фидо в 70-80е со стороны государства. Скорее инициатива отдельных учреждений, направленная не против фидо, а против использования телефонов организации не по назначению.
Дома - сиди, звони.
Есть же view. Если вы работали с оракл или постгрес, и не пользовались этим, то зря - как раз для таких случаев.
Опять же, изоляция ради изоляции - не то, что нужно. Основная задача микросервисов - упрощение разработки и масштабирования. Изоляция тут как часть основной задачи. И изоляция базы данных может быть реализована или через документирование структуры или через вьюхи или через независимые базы. Смотря что требуется.
Вот есть у нас микросервис, который занимается созданием отчетов о бизнес процессах. Он берет данные из основной базы. Скажете это не микросервис? Или каким образом нужно для него генерировать данные - копировать всю основную базу? Внедрять экспорт данных в сервис который ведет процессинг? Нет, вполне достаточно чтобы конкретно эти два микросервиса пользовались одной базой. Микросервис отчетов только считывает и в случае изменения структуры базы да, нужно будет поправить оба. С точки зрения архитектуры - это проще и дешевле, чем создавать полную изоляцию ради изоляции.
просто экзешник это просто бинарный файл. В этом определении не указано как его деплоить и запускать.
Микросервис по определению должен не только разрабатываться независимо, но и деплоиться. То есть его рантайм окружение, и его CI/CD пайплайн должны быть незаивисимы.
Например оба эксешника можно руками копировать и запускать на том же хосте. Но в разных директориях, с разными конфигами, чтобы можно было не останавливая один, например удалить перенести на другой хост другой.
Очень многие недооценивают ретро, а ведь именно ретро позволяет внедрять гибкие методологии.
Без ретро, это не гибкая методология, а спринт-ориентированная. Какая же она гибкая, если один раз настроили и все? Методология должна адаптироваться к проекту по мере изменения/роста проекта.
И именно ретро и помогает вывести проблемы на передний план и найти решение. Если у участников ретро нет никаких полномочий на изменение процессов, то смысл в ретро отсутствует. Действительно задача менеджера организовать правильную работу ретро-митингов.
У нас примерно так было - каждый может вынести свои вопросы на ретро. Совместно тратим небольшое количество времени чтобы уточнить это системная проблема или разовая и ее можно решить прямо сейчас, если нет - вносим в бэклог ретро и назначаем ответственного, который до следующего ретро должен провести исследование и возможно предложить решение. Ответственный не обязательно то, кто будет внедрять решение. Это тот, кто отвечает за организацию, коммуникации, ищет кто и как может решить. На следующем митинге ответственный может и измениться, если будет понятно кто лучше это сделает.
Главное, что в бэклоге мы отслеживаем сколько времени проблема там висит, и если висит слишком долго, повышаем приоритет. Бывают проблемы, которые требуют значительных изменений в процессах. Надо обосновать что эти изменения окупятся.
И да, благодаря такой структуре было проведено множество как мелких, так и достаточно значимых изменений в работе проекта.
РКН занят дискордом
Они расследуют сообщения, а не ищут пути.
Путь тут могли бы найти пользователи, но им страшно.
Так в определении микросервисов нигде не указано что в изоляцию включается база данных. Если почитаете банальное определение на википедии, там будет видно что изоляция на уровне разработки и деплоймента, что означает - отдельные кодовые базы и отдельный процесс/под.
Структура базы данных может быть согласована заранее и не меняться. Либо использовать разные таблицы. Либо использовать вьюхи - это уже не есть часть определения. Сервисы должны общаться друг с другом, поэтому в любом случае нужно соблюдать контракты и это уже означает согласование, а не идеальную независимость всего от всего.
То, что за полтора десятка лет распространения микросервисов, начинают переосмысливать и вводить новые вещи... ну так ООП тоже изначально был задуман не так, как используется, и частные споры о том, что и как должно быть в ООП не заменяют базовых определений.
Я считаю, что когда независимость микросервисов возводится в абсолют - это неправильное понимание что такое микросервисы.
Микросервисы были сделаны для того, чтобы облегчить разработку и облегчить масштабирование. Делается это методом, что один микросервис выполняет одну определенную функцию и коммуницирует с другими компонентами.
Изоляция в разработке позволяет довольно быстро переписать конкретный микросервис с нуля, в том числе и на другом языке, с применением других технологий, что было бы сложно в случае монолита.
Изоляция в деплойменте говорит, что изменения в этот микросервис можно внести и вывести на продакшен без изменений где-либо в другом месте. Часто деплоймент может быть полностью автоматизирован.
Насчет того, что микросервисы обязаны иметь изолированные базы, иначе это не микросервис - тут я не соглашусь, это уже просто разные варианты использования микросервисной архитектуры, и тут нет "лучшего". Есть просто разные подходы как этим пользоваться в каждом конкретном случае.
Вы реально считаете, что тем кто блокируют это интересно? И их логика совпадает с вашей?
Один микросервис предоставляет API для работы с приложением.
Другой может предоставлять UI для пользователей.
Третий микросервис позволяет выполнять отчеты
Четвертый может быть UI админкой.
Для всех сервисов могут требоваться разные варианты ресурсов. Сервис для отчетов, например, может быть вообще кронджобой, которая не не будет требовать ничего в ожидании события.
И все работают с одной базой. Все могут независимо масштабироваться.
Вот вполне рабочий вариант микросервисов и одной базы.
Микросервисы по сути не имеют права быть полностью независимыми - ведь они по сути являются частью большого приложения, а не независимых приложений.
Основная задача микросервисов - простое масштабирование тех моментов, где может возникать бутылочное горлышко, и упрощение приложение, чтобы было легче разрабатывать новые фичи - тут да, нужна независимость от других микросервисов, но она может соблюдаться грамотным версионированием "коннекторов" и апи.
Дети это просто память. А хорошая или плохая память зависит уже не от детей а от активности самого человека.
Признайтесь, что вы не в курсе всей ситуации.
Основной заказчик лунной программы - не Маэдзава, а НАСА, и там совсем другие деньги и определенные задачи.
Работа по контракту с НАСА в принципе не мешает параллельно подрабатывать на других заказчиках, чем пытался воспользоваться Маск, который делал Старщип для выхода на орбиту и возможно будущем прилунении (там еще будут вопросы).
Но НАСА придумало достаточно сложный вариант лунной программы, который включает в себя участие нескольких подрядчиков в сложном взаимодействии, которое кроме конечной цели, имеет также цель создать конкурентную среду, много рабочих мест и задействовании большого количества компаний, которые развивают космическую промышленность.
Был момент, когда SpaceX получило определенный зеленый свет, и уже начало работу, конкуренты подали жалобу, проект был приостановлен на некоторое время, пока не решился вопрос "справедливого" распределения денег. Ну там много аспектов, справедливость штука сложная в политике.
Тем не менее это помешало Маску выполнить параллельно договроенности с туризмом.
Почитайте тоже про https://habr.com/ru/companies/bothub/articles/815609/