Открыт прием докладов на конференцию ArchDays!
Детально проработав обратную связь с прошлой конференции мы расширили спектр тем:
Организационные вопросы в архитектуре
Архитектурная методология на базе теории сложности, подходов из области социо-техники, работ в области Agile Architecture от Open Group и прочих.
Моделирование в архитектуре
Практика Domain Driven Design, Event Storming, C4 model, Architecture as Code
Качество и надежность
Подходы к работе с качеством, например Chaos Engineering, тестирование микросервисов, самовосстанавливающиеся системы.
Технические аспекты архитектурных решений
Общая рубрика — кейсы применения микросервисов в организациях.
Безопасность в распределенных системах
Все, что касается безопасности в распределенных системах. Стандарты PCI DSS, PSD2 и прочие. Модели угроз в микросервисных архитектурах.
Облачные решения
Использования как российских облачных платформ, так и AWS/Google Cloud; serverless
Будет 🔥
Детально проработав обратную связь с прошлой конференции мы расширили спектр тем:
Организационные вопросы в архитектуре
Архитектурная методология на базе теории сложности, подходов из области социо-техники, работ в области Agile Architecture от Open Group и прочих.
Моделирование в архитектуре
Практика Domain Driven Design, Event Storming, C4 model, Architecture as Code
Качество и надежность
Подходы к работе с качеством, например Chaos Engineering, тестирование микросервисов, самовосстанавливающиеся системы.
Технические аспекты архитектурных решений
Общая рубрика — кейсы применения микросервисов в организациях.
Безопасность в распределенных системах
Все, что касается безопасности в распределенных системах. Стандарты PCI DSS, PSD2 и прочие. Модели угроз в микросервисных архитектурах.
Облачные решения
Использования как российских облачных платформ, так и AWS/Google Cloud; serverless
Будет 🔥
COBOL в Кубере запустили...
По задумке - должно стать катализатором развития микросервисов на COBOL.
Что-но новенькое :)
https://containerjournal.com/topics/container-ecosystems/ibm-shows-instances-of-cobol-running-natively-on-kubernetes/
По задумке - должно стать катализатором развития микросервисов на COBOL.
Что-но новенькое :)
https://containerjournal.com/topics/container-ecosystems/ibm-shows-instances-of-cobol-running-natively-on-kubernetes/
Container Journal
IBM Shows Instances of COBOL Running Natively on Kubernetes
IBM has launched a research and development project through which applications developed in COBOL are able to run natively on Kubernetes clusters. JJ
Кто должен разрабатывать админку?
Частый вопрос. Обсуждение на примерно эту тему сейчас идет в @microservices_ru
Суммирую в этом посте свои мысли.
Есть Продукт. Что такое администрирование? Это — возможность выполнять дополнительные действия над Продуктом в зависимости от прав доступа, не больше и не меньше.
Таким образом, появляется контекст Авторизации, а то, что мы называем админкой — это работа всё с тем же контекстом Продукт, но с определенным набором прав доступа, полученным из контекста Авторизации.
Когда мы говорим о домене Продукта, то он находится НАД технической реализацией. А значит фронт, бэк, инфраструктура, — все, что относится к Продукту — это граница ответственности команды или нескольких команд (как в LeSS) в рамках одного домена.
Никаких отдельных команд для админки, оказывается, не требуется (если только админка не является реально существующим отдельным бизнес-доменом), а границы ответственности команды Продукта аккуратно соблюдены в рамках границ модели предметной области.
Однако, вполне возможно существование Продукта в разных контекстах, например — контексте Продаж и контексте Поддержки. Вот тогда границы ответственности, теперь уже двух команд, изменяются соответственно границам в модели предметной области (при этом каждая из команд все равно сама внутри развивает админку :)
Частый вопрос. Обсуждение на примерно эту тему сейчас идет в @microservices_ru
Суммирую в этом посте свои мысли.
Есть Продукт. Что такое администрирование? Это — возможность выполнять дополнительные действия над Продуктом в зависимости от прав доступа, не больше и не меньше.
Таким образом, появляется контекст Авторизации, а то, что мы называем админкой — это работа всё с тем же контекстом Продукт, но с определенным набором прав доступа, полученным из контекста Авторизации.
Когда мы говорим о домене Продукта, то он находится НАД технической реализацией. А значит фронт, бэк, инфраструктура, — все, что относится к Продукту — это граница ответственности команды или нескольких команд (как в LeSS) в рамках одного домена.
Никаких отдельных команд для админки, оказывается, не требуется (если только админка не является реально существующим отдельным бизнес-доменом), а границы ответственности команды Продукта аккуратно соблюдены в рамках границ модели предметной области.
Однако, вполне возможно существование Продукта в разных контекстах, например — контексте Продаж и контексте Поддержки. Вот тогда границы ответственности, теперь уже двух команд, изменяются соответственно границам в модели предметной области (при этом каждая из команд все равно сама внутри развивает админку :)
Подоспело видео моего выступления на TechLeadConf «Моделирование микросервисов с помощью Event Storming»
Приятно, что средний балл — 4,41 из 5.
Описание: «При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.»
https://www.youtube.com/watch?v=cG9DVbcPc9M
Приятно, что средний балл — 4,41 из 5.
Описание: «При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.»
https://www.youtube.com/watch?v=cG9DVbcPc9M
YouTube
Моделирование микросервисов с помощью Event Storming / Сергей Баранов (ScrumTrek)
Приглашаем на TechLead Conf X 2025, которая пройдет 5 июня в Москве.
Программа, подробности и билеты по ссылке https://bit.ly/3PZN1hk
---------
Онлайн-конференция, полностью посвященная инженерным процессам и практикам TechLeadConf 2020
Тезисы и презентация:…
Программа, подробности и билеты по ссылке https://bit.ly/3PZN1hk
---------
Онлайн-конференция, полностью посвященная инженерным процессам и практикам TechLeadConf 2020
Тезисы и презентация:…
Kubernetes_for_Kids_ITSummaPress.pdf
7.5 MB
Ну теперь «познать кубер» стало действительно просто, смотрите что нашел: «Путеводитель по Kubernates для детей в картинках» :)
Убер написал статью о том, что они пришли к «Domain-Oriented Microservice Architecture» (и как они к этому пришли). Интересно, что я даже не думал, что можно как-то иначе получить слабосвязанное микросервисное решение. По крайней мере на текущем уровне нашего понимания процесса проектирования через модели предметной области.
Спойлер тем, кто был у меня на курсах «Проектирование микросервисов» — это примерно то, что мы делали с вами в течение почти всего первого дня (через все эти Event Storming’и, выделение контекстов, anti-corruption слои и прочие важные элементы) и затем наполняли техническими деталями.
Статья хорошая, советую.
Похоже, что статью удалили, но в гуглокэше она еще жива: https://webcache.googleusercontent.com/search?q=cache%3Af7N-baQWhTgJ%3Ahttps%3A%2F%2Feng.uber.com%2Fmicroservice-architecture%2F%20&cd=2&hl=ru&ct=clnk&gl=ru&lr=lang_en%7Clang_ru&client=safari&fbclid=IwAR1utfoUsdIDGAXi8DvG_yyJOE5D9yel-d_tU-vYGw6SkvNhXipd8NgPF2U
Спойлер тем, кто был у меня на курсах «Проектирование микросервисов» — это примерно то, что мы делали с вами в течение почти всего первого дня (через все эти Event Storming’и, выделение контекстов, anti-corruption слои и прочие важные элементы) и затем наполняли техническими деталями.
Статья хорошая, советую.
Похоже, что статью удалили, но в гуглокэше она еще жива: https://webcache.googleusercontent.com/search?q=cache%3Af7N-baQWhTgJ%3Ahttps%3A%2F%2Feng.uber.com%2Fmicroservice-architecture%2F%20&cd=2&hl=ru&ct=clnk&gl=ru&lr=lang_en%7Clang_ru&client=safari&fbclid=IwAR1utfoUsdIDGAXi8DvG_yyJOE5D9yel-d_tU-vYGw6SkvNhXipd8NgPF2U
Перенес перевод модели оценки навыков и компетенций DevOps от DASA в Miro!
По ссылке модель доступна только к просмотру, но с возможностью оставлят комментарии, так что если вы считаете, что где-то можно улучшить формулировку, либо не понятно что написано, смело оставляйте комментарий.
Кто хочет скопировать себе модель, пишите в личку, отправлю ссылку с правами редактирования (не выкладываю такую ссылку в паблик, потому как не проживет эта доска без вандализма и пары часов 😈
По ссылке модель доступна только к просмотру, но с возможностью оставлят комментарии, так что если вы считаете, что где-то можно улучшить формулировку, либо не понятно что написано, смело оставляйте комментарий.
Кто хочет скопировать себе модель, пишите в личку, отправлю ссылку с правами редактирования (не выкладываю такую ссылку в паблик, потому как не проживет эта доска без вандализма и пары часов 😈
Достойное собрание материалов по RBAC для k8s.
Тема хоть и узкая, но одна из наиболее проблемных когда дело доходит до практики.
https://rbac.dev
Тема хоть и узкая, но одна из наиболее проблемных когда дело доходит до практики.
https://rbac.dev
Исследование состояния DevOps в России.
Полезное и важное дело от Экспресс 42 и Онтико. Давайте поддержим инициативу, а то на другие страны (DORA, Puppet,..) смотрим, а про себя не знаем.
Ссылочка на опрос:
https://ru.surveymonkey.com/r/VQZRLN6?fbclid=IwAR17rIikgnQvBdsheEj4mvbDocjcdI3tFO2a30qPtbtIF-QA-SX6hJK_jJE
Полезное и важное дело от Экспресс 42 и Онтико. Давайте поддержим инициативу, а то на другие страны (DORA, Puppet,..) смотрим, а про себя не знаем.
Ссылочка на опрос:
https://ru.surveymonkey.com/r/VQZRLN6?fbclid=IwAR17rIikgnQvBdsheEj4mvbDocjcdI3tFO2a30qPtbtIF-QA-SX6hJK_jJE
Surveymonkey
Бесплатное ПО для онлайн-опросов от SurveyMonkey: закрытый опрос
В настоящее время этот опрос закрыт. Для получения дополнительной информации свяжитесь с автором данного опроса.
У микросервисов есть несомненные преимущества. Однако, как когда-то Scrum, микросервисы поддаются все большей компрометации от бездумного внедрения.
Например, кто-то услышал, что микросервисы - это автономные команды, автономная поставка. Это, действительно, так, однако беда случается тогда, когда решение перейти на микросервисы становится политическим, а не продиктованным потребностью бизнеса с четкой оценкой все требуемых изменений в архитектуре, орг. структуре, процессах, инфраструктуре.
И тут начинается самое интересное. Оказывается, что отсутствует хотя бы гигиенический минимум инженерных практик и процессов, все тестирование ручное, все развертывание ручное, разработчики работают по четкому тз и не особо погружены в предметную область...ну то есть все как-то работает и даже вроде неплохо, и фичи выпускаются «быстро» и продукт зарабатывает.
Только почему-то в совершенно не инженерной области все больше проблем. Программисты уходят к конкурентам (и не одни, а со своими знаниями), высокая скорость поддерживается героизмом по вечерам и выходным, все больше дефектов, да и затраты на кофе в компании выросли кратно.
Но задачи выполняются. И в таком «типа скраме» звучит «нам нужны микрсоервисы».
Нет. Не нужны.
Для начала нужны простые вещи:
1. Визуализация потока создания технологической ценности (то, что станет delivery pipeline)
2. Выявление потерь в этом потоке
3. Готовность к устранению этих потерь (это может привести и к политике работы с help desk и процессам взаимодействия с безой и инвестициям в обучение/автоматизацию тестирования)
4. Обложить все что можно телеметрией. Иначе мы даже эффект от перехода на микросервисы не оценим.
5. Сделать систему разработки предсказуемой и надежной. Так, чтобы планировать было можно и выполнять работу без постоянных переработок. Для этого существует исчерпывающий набор практик на сокращение объемов незапланированной работы (в том числе вносящей серьезный вклад в неопределенность).
Параллельно можно провести Event Storming для создания стратегического дизайна, выделения модулей, целевого рефакторинга в сторону слабо связанных модулей.
И вот, когда разработчики перестанут уходить, когда все поймут, что это не потогонка в погоне на индивидуальным KPI на внедрение микросервисов, тогда можно переходить.
Интересно, что к этому моменту скилы прокачиваются так, что в целом нередко потребность в микросервисах отпадает. Так и хорошо, если мы можем обеспечить бизнес-результат, не добавляя сложность в продукт.
Например, кто-то услышал, что микросервисы - это автономные команды, автономная поставка. Это, действительно, так, однако беда случается тогда, когда решение перейти на микросервисы становится политическим, а не продиктованным потребностью бизнеса с четкой оценкой все требуемых изменений в архитектуре, орг. структуре, процессах, инфраструктуре.
И тут начинается самое интересное. Оказывается, что отсутствует хотя бы гигиенический минимум инженерных практик и процессов, все тестирование ручное, все развертывание ручное, разработчики работают по четкому тз и не особо погружены в предметную область...ну то есть все как-то работает и даже вроде неплохо, и фичи выпускаются «быстро» и продукт зарабатывает.
Только почему-то в совершенно не инженерной области все больше проблем. Программисты уходят к конкурентам (и не одни, а со своими знаниями), высокая скорость поддерживается героизмом по вечерам и выходным, все больше дефектов, да и затраты на кофе в компании выросли кратно.
Но задачи выполняются. И в таком «типа скраме» звучит «нам нужны микрсоервисы».
Нет. Не нужны.
Для начала нужны простые вещи:
1. Визуализация потока создания технологической ценности (то, что станет delivery pipeline)
2. Выявление потерь в этом потоке
3. Готовность к устранению этих потерь (это может привести и к политике работы с help desk и процессам взаимодействия с безой и инвестициям в обучение/автоматизацию тестирования)
4. Обложить все что можно телеметрией. Иначе мы даже эффект от перехода на микросервисы не оценим.
5. Сделать систему разработки предсказуемой и надежной. Так, чтобы планировать было можно и выполнять работу без постоянных переработок. Для этого существует исчерпывающий набор практик на сокращение объемов незапланированной работы (в том числе вносящей серьезный вклад в неопределенность).
Параллельно можно провести Event Storming для создания стратегического дизайна, выделения модулей, целевого рефакторинга в сторону слабо связанных модулей.
И вот, когда разработчики перестанут уходить, когда все поймут, что это не потогонка в погоне на индивидуальным KPI на внедрение микросервисов, тогда можно переходить.
Интересно, что к этому моменту скилы прокачиваются так, что в целом нередко потребность в микросервисах отпадает. Так и хорошо, если мы можем обеспечить бизнес-результат, не добавляя сложность в продукт.
В поддержку прерыдущего поста лишь небольшой список недостастков микросервисов в сравнении с монолитом от участников моих курсов (ничего не додумывал, большинство кейсов связаны с попыткой резкого перехода на MSA). Обратите внимание, что немало недостатков таковыми не являются в сильной DevOps-культуре, однако и в области проектирования явно наблюдается skill gap, требующий повышения навыков (может потому, что микросервисы — это архитектурный стиль, а не «практика разработки?» 🙂 ):
Сложность управления и мониторинга транзакций
Сложность сопровождения
Сложность проектирования
Сложный вход, так как толстый технологический стек
Дублирование данных (но не доменных сущностей)
Проблемы с целостностью межсервисных операций
Сквозное логирование бизнес-процесса
Дорогие специалисты
Сложность отладки
Сложность в поиске специалистов и обучении команд
Отсутствует качественная "теория" по моделированию распределенных асинхронных процессов - BPMN и прочие UML не эффективны
Хайп
Сложность диагностики
Сложность проектирования и разработки
У каждой успешной компании в MSA свой "опыт" и "заплатки" трудно обобщать
Сложно всем этим зоопарком управлять
Сложность управлением памятью
Сложность системы в целом
Дольше разрабатывать
Сложнее определить требования к ресурсам
Стоимость владения может оказаться выше
Высокие затраты на входе
Производительность массовых операций из-за межсетевых вызовов
Поиск ошибок среди всего множества сервисов
Сложность использования общих библиотеки
Необходимость наличия культуры в организации
Сложность декомпозиции
Наличие множества БД и их поддержки
Необходимость в большом количестве инфраструктурных ресурсов
Требуется организация взаимосвязи между микросервисами
Больше оборудования чем в монолите
Без должно автоматизации деплой сложнее
Сложность управления и мониторинга транзакций
Сложность сопровождения
Сложность проектирования
Сложный вход, так как толстый технологический стек
Дублирование данных (но не доменных сущностей)
Проблемы с целостностью межсервисных операций
Сквозное логирование бизнес-процесса
Дорогие специалисты
Сложность отладки
Сложность в поиске специалистов и обучении команд
Отсутствует качественная "теория" по моделированию распределенных асинхронных процессов - BPMN и прочие UML не эффективны
Хайп
Сложность диагностики
Сложность проектирования и разработки
У каждой успешной компании в MSA свой "опыт" и "заплатки" трудно обобщать
Сложно всем этим зоопарком управлять
Сложность управлением памятью
Сложность системы в целом
Дольше разрабатывать
Сложнее определить требования к ресурсам
Стоимость владения может оказаться выше
Высокие затраты на входе
Производительность массовых операций из-за межсетевых вызовов
Поиск ошибок среди всего множества сервисов
Сложность использования общих библиотеки
Необходимость наличия культуры в организации
Сложность декомпозиции
Наличие множества БД и их поддержки
Необходимость в большом количестве инфраструктурных ресурсов
Требуется организация взаимосвязи между микросервисами
Больше оборудования чем в монолите
Без должно автоматизации деплой сложнее
А те, у кого получилось, называют такие преимущества, часть из которых прямо противоположна недостаткам из предыдущего сообщения. И снова мы видим, что большинство преимуществ напрямую не связаны с микросервисами, микросервисы являются как-бы катализатором для появления подобных преимуществ, а некоторые являются предусловиями, то есть без них сложно управлять микросервисами и их приходится делать, что говорит нам о том, что осознанный, грамотный подход еще до появения микросервисов серьезно апгрейдит разработку:
Гибкое перераспределение нагрузки на всех уровнях
При необходимости отдельные микросервисы могут быть развернуты или масштабированы независимо
Независимый релизный цикл
Разные языки программирования и БД в разных сервисах
Высокая скорость доставки
Интересный стек технологий для разработчиков
Выделение и изолирование функциональности
Канареечные релизы
Небольшие команды
Возможность перепридумать решение с нуля
Высокая отказоустойчивость
Актуальные технологии индустрии, появилось большое число качественных opensource платформ
Слабая связанность
Можно быстро переписать код
Легко заменять модули
Устойчивость
Улучшение доступности за счет изоляции сбоев в границах отдельного сервиса
Изоляция и слабая связанность ведут к возможностям более гибкой эволюции в границах модуля
Поддержка множества платформ и языков
Быстрое тестирование
Быстрый деплой
Автономный деплой
Использование трассировки запросов между сервисами
Быстрота решения инцидентов
Быстрее локальная разработка - не нужно все разворачивать
Возможность динамического распределения нагрузки
Независимая разработка
Проще рефакторить, меньше тех.долга - проще переписать один независимый сервис
Свой архитектурный подход для каждого сервиса (DDD, CRUD)
Гибкое перераспределение нагрузки на всех уровнях
При необходимости отдельные микросервисы могут быть развернуты или масштабированы независимо
Независимый релизный цикл
Разные языки программирования и БД в разных сервисах
Высокая скорость доставки
Интересный стек технологий для разработчиков
Выделение и изолирование функциональности
Канареечные релизы
Небольшие команды
Возможность перепридумать решение с нуля
Высокая отказоустойчивость
Актуальные технологии индустрии, появилось большое число качественных opensource платформ
Слабая связанность
Можно быстро переписать код
Легко заменять модули
Устойчивость
Улучшение доступности за счет изоляции сбоев в границах отдельного сервиса
Изоляция и слабая связанность ведут к возможностям более гибкой эволюции в границах модуля
Поддержка множества платформ и языков
Быстрое тестирование
Быстрый деплой
Автономный деплой
Использование трассировки запросов между сервисами
Быстрота решения инцидентов
Быстрее локальная разработка - не нужно все разворачивать
Возможность динамического распределения нагрузки
Независимая разработка
Проще рефакторить, меньше тех.долга - проще переписать один независимый сервис
Свой архитектурный подход для каждого сервиса (DDD, CRUD)
Неслабый gap образовался в области enteprise architecture в отношении микросервисов. В любой компании в том или ином виде существует архитектура этой компании. Порядка 3-х лет консолидировал данные из книг, научных источников, подкреплял собственными знаниями из практики, помогал нескольким компаниям построить agile enteprise architecture (отлично открывает путь к микросервисам).
Одна из наиболее подходящих базовых моделей, как мне кажется, все-таки togaf. Она удобна своей полнотой, из нее легко «извлекаются» не нужные в конкретной компании практики и при этом она остается рабочей. Хотя для монопродуктовых компаний на стадии роста у меня есть своя модель, построенная на циклах обратной связи, куда более простая и так же проверенная на практике.
Не так давно начал переносить консолидированные данные в миро, укладывая в понятную и простую структуру, наполненную практиками и циклами обратной связи (не «мифическими», а вполне конкретными). Получается достаточно наглядно, на мой взгляд.
Если есть желающие принять участие в разработки модели Agile Enterprise Architecture с уклоном в микросервисы, пишите в личку (@sergey486), объединим усилия.
Одна из наиболее подходящих базовых моделей, как мне кажется, все-таки togaf. Она удобна своей полнотой, из нее легко «извлекаются» не нужные в конкретной компании практики и при этом она остается рабочей. Хотя для монопродуктовых компаний на стадии роста у меня есть своя модель, построенная на циклах обратной связи, куда более простая и так же проверенная на практике.
Не так давно начал переносить консолидированные данные в миро, укладывая в понятную и простую структуру, наполненную практиками и циклами обратной связи (не «мифическими», а вполне конкретными). Получается достаточно наглядно, на мой взгляд.
Если есть желающие принять участие в разработки модели Agile Enterprise Architecture с уклоном в микросервисы, пишите в личку (@sergey486), объединим усилия.
В качестве вводной хорошо подойдет статья от Open Group
USING AGILE PRACTICES IN ENTERPRISE ARCHITECTURE
https://publications.opengroup.org/w194
USING AGILE PRACTICES IN ENTERPRISE ARCHITECTURE
https://publications.opengroup.org/w194
publications.opengroup.org
Using Agile Practices in Enterprise Architecture
This White Paper expresses the view that an enterprise needs both Enterprise Architecture and Agility.
Я иногда вспоминаю первый софт, который писал, а было это 20 лет назад. Мелкие эксперименты.
Например, корпоративные сайты.
Я тогда все писал ра Perl и было достаточно удобно - каждая .pl-ка (cgi-скрипт) выполняется в своем процессе, не пересекается с другими, развивается автономно. Правда, не было тестов, а деплой был по F5 в mc. И сразу работает :)
Это, конечно, не промышленный софт, но если посмотреть на всю последующую историю работы с промышленным софтом, то можно выделить несколько важных тезисов (и еще пару десятков к этим):
1. Промышленным стандартом стали языки, в которых разрабатывать в рамках отдельных независимых модулей стало сложнее (java/c#). Этому же способствовал и инструментарий IDE.
Да и лицензии на application servers стоили как самолет. Даже там, где обычного apache хватало с лихвой.
2. Основной объем сложности находился в окружающем контексте. Те самые пресловутые требования, по кусочкам собираемые с сотен человек, затем зачем-то переводимых с бизнес-языка на технический людьми, которые бизнес знают с чужих слов и код если и писали, то в далеком прошлом.
3. Динамика изменений стала высокой. И совмещая тезисы один и два мы получаем достаточно странную структуру того самого легаси-монолита. То есть монолит нас вроде бы уберегает от того, что при неверном проектировании запросов между сервисами не станет больше (все ж локально), но при этом он же позволяет нам дать слабину и не сильно заморачиваться с проектированием. Но даже, если попробуем построить хороший, модульный монолит (а это возможно только при хорошем понимании бизнес-сущностей, предметной области), то окажется, что мы ее не знаем, потому что см тезис 2. И это несмотря на то, что те самые IDE позволяют нам проводить крутейший анализ и рефакторинг над всей кодовой базой. Только код остается кодом, а семантика зависимостей лежит над ним, в области бизнеса.
Например, корпоративные сайты.
Я тогда все писал ра Perl и было достаточно удобно - каждая .pl-ка (cgi-скрипт) выполняется в своем процессе, не пересекается с другими, развивается автономно. Правда, не было тестов, а деплой был по F5 в mc. И сразу работает :)
Это, конечно, не промышленный софт, но если посмотреть на всю последующую историю работы с промышленным софтом, то можно выделить несколько важных тезисов (и еще пару десятков к этим):
1. Промышленным стандартом стали языки, в которых разрабатывать в рамках отдельных независимых модулей стало сложнее (java/c#). Этому же способствовал и инструментарий IDE.
Да и лицензии на application servers стоили как самолет. Даже там, где обычного apache хватало с лихвой.
2. Основной объем сложности находился в окружающем контексте. Те самые пресловутые требования, по кусочкам собираемые с сотен человек, затем зачем-то переводимых с бизнес-языка на технический людьми, которые бизнес знают с чужих слов и код если и писали, то в далеком прошлом.
3. Динамика изменений стала высокой. И совмещая тезисы один и два мы получаем достаточно странную структуру того самого легаси-монолита. То есть монолит нас вроде бы уберегает от того, что при неверном проектировании запросов между сервисами не станет больше (все ж локально), но при этом он же позволяет нам дать слабину и не сильно заморачиваться с проектированием. Но даже, если попробуем построить хороший, модульный монолит (а это возможно только при хорошем понимании бизнес-сущностей, предметной области), то окажется, что мы ее не знаем, потому что см тезис 2. И это несмотря на то, что те самые IDE позволяют нам проводить крутейший анализ и рефакторинг над всей кодовой базой. Только код остается кодом, а семантика зависимостей лежит над ним, в области бизнеса.
Свежая статья о принципах использования feature toggles от thoughtworks.
Каждый из принципов поясняется:
- Feature toggles should be flippable
- Feature toggles should be used by default
- Feature toggles should be added per story
- Feature toggles should be visible
- Feature toggles should be short-lived
- Feature toggles should be tested
https://www.thoughtworks.com/insights/blog/managing-feature-toggles-teams
Каждый из принципов поясняется:
- Feature toggles should be flippable
- Feature toggles should be used by default
- Feature toggles should be added per story
- Feature toggles should be visible
- Feature toggles should be short-lived
- Feature toggles should be tested
https://www.thoughtworks.com/insights/blog/managing-feature-toggles-teams
Thoughtworks
Managing feature toggles in teams
For its advocates, trunk-based development (TBD) is seen as preferable to feature branches because it makes Continuous Integration easier and reduces the chance of painful merge conflicts. Despite its advantages, TBD introduces its own challenges. When all…
Авторизация между сервисами часто воспринимает лишь как метод обеспечения безопасности. Но это не так. Авторизация так же используется как тактика ограничения путей коммуникация для снижения уровня зависимостей. Другая архитектурная тактика, направленная на недопущение появления новых зависимостей — сокрытие интерфейса в принципе, что немного сложнее и снижает обозреваемость системы в целом.
В микросервисах зависимости — большая боль, так что в ряде случаев авторизация доступа как жесткая мера против бесконтрольного роста уровня зависимостей может быть оправдана.
В микросервисах зависимости — большая боль, так что в ряде случаев авторизация доступа как жесткая мера против бесконтрольного роста уровня зависимостей может быть оправдана.
Крис Ричардсон на DDD SoCal поделился десятью принципам рефакторинга при движении в сторону микросервисов. По ссылке и преза и видео. Классное выступление, я бы сказал — обобщающее.
https://chrisrichardson.net/post/refactoring/2020/08/21/ten-principles-for-refactoring-to-microservices.html
https://chrisrichardson.net/post/refactoring/2020/08/21/ten-principles-for-refactoring-to-microservices.html