Всем привет)
Какие ресурсы/блоги/рассылки по архитектуре читаете?)
Какие ресурсы/блоги/рассылки по архитектуре читаете?)
Часто в разные чаты прилетают запросы на разбор реальных архитектурных кейсов.
При этом в больших чатах:
- бывает сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую
- во время обсуждения бывает сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем
- вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.
Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌
В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса
Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун.
При этом в больших чатах:
- бывает сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую
- во время обсуждения бывает сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем
- вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.
Для решения этих проблем создал отдельную группу в телеграм: «Архитектурные этюды» (правила группы)
Первый кейс уже обсуждается 👌
В этой группе:
- публикуются только кейсовые вопросы
- каждый кейс публикуется в собственном топике
- обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса
Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун.
Большой-большой материал по «Data Engineering: ETL, ELT, Data Pipeline, Data Warehouse, Data Lakes, Data Marts»
https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/
https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/
Cейчас в чате обсуждаетя (примерно здесь старт https://tttttt.me/microservices_ru/17178), сокращенно:
— Сервисы суют тогда, когда нужно …. масштабироваться горизонтально ….
— ….по-моему нормально монолитом решается
— Ага, особенно хорошо решается монолитом, когда одна часть монолита требует мощный процессор, вторая много оперативки, третья большой диск, и при горизонтальном масштабировании приходится ставить сразу N мега-серверов вне зависимости от того, во что уперлись)
🙂
— Сервисы суют тогда, когда нужно …. масштабироваться горизонтально ….
— ….по-моему нормально монолитом решается
— Ага, особенно хорошо решается монолитом, когда одна часть монолита требует мощный процессор, вторая много оперативки, третья большой диск, и при горизонтальном масштабировании приходится ставить сразу N мега-серверов вне зависимости от того, во что уперлись)
🙂
Всем привет, есть новости 🙂
14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.
А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.
14 апреля в онлайн формате проведу на AgileDays воркшоп по Event Storming.
А кто будет 21-го апреля очно, пишите в личку или в комментарии, соберемся/встретимся, можем и спонтанное обсуждение насущных вопросов устроить.
AgileDays 2023
Воркшоп Event Storming
Онлайн-воркшоп спикера Сергей Баранов — 14.04.2023
Наблюдения Jim Hurne, technical lead for a "services" team within IBM Watson касательно структуры команд под микросервисы:
Many of the organizations that have successfully applied the microservices style (e.g. Amazon, Netflix) have had a similar internal team structure:
- Teams are responsible for one or more services
- No service is owned by more than one team
- Teams are relatively autonomous and are free to make independent implementation choices, so long as they adhere to the agreed-upon APIs and service contracts.
- Teams contain the complete skill set necessary to support a service from inception to deployment (product management, development, operations, database administration, production support, etc).
- While teams are loosely coupled from internal implementation details, they are tightly aligned on overall organizational goals.
Many of the organizations that have successfully applied the microservices style (e.g. Amazon, Netflix) have had a similar internal team structure:
- Teams are responsible for one or more services
- No service is owned by more than one team
- Teams are relatively autonomous and are free to make independent implementation choices, so long as they adhere to the agreed-upon APIs and service contracts.
- Teams contain the complete skill set necessary to support a service from inception to deployment (product management, development, operations, database administration, production support, etc).
- While teams are loosely coupled from internal implementation details, they are tightly aligned on overall organizational goals.
Микросервисы / распределенные системы
Выступление одного из учередителей нашего Объединения на ArchDays Recap https://www.youtube.com/watch?v=NSN-NXfbEqM
А я как-то пропустил, что многоликий DDD и на DotNext выложили, доклад похожий, но рассказан немного иначе и все-таки на конференции, а не на митапе 🙂
https://www.youtube.com/watch?v=2WHarUW0PjI
https://www.youtube.com/watch?v=2WHarUW0PjI
YouTube
Сергей Баранов — Многоликий DDD
Подробнее о конференции DotNext: https://jrg.su/3WmFRE
— —
Domain Driven Design всегда имел высокий порог входа. Сложность изучения и применения усугублялась туманностью объяснений выгод как для коллег-разработчиков, так и для архитекторов, менеджеров, продактов.…
— —
Domain Driven Design всегда имел высокий порог входа. Сложность изучения и применения усугублялась туманностью объяснений выгод как для коллег-разработчиков, так и для архитекторов, менеджеров, продактов.…
В Архитектурных Этюдах новый кейс.
…Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку…
…Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку…
Предлагаю анонимную перекличку :)
Anonymous Poll
29%
У нас всё на микросервисах
34%
У нас кое-где микросервисы
11%
У нас нет микросервисов
20%
Мы на пути от монолита к микросервисам
6%
Мы на пути от микросервисов к монолиту
Кто успел поиграться, как впечатления?
We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices.
https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html
We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices.
https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html
Boehm - 1991.pdf
1.3 MB
Нетленная классика, принципы и практики управления рисками от Barry Boehm
Заметки по распределенным системам.
Категории заметок
- Concepts
- Failure Detection
- Leader Election
- Replication Consistency
- Dissemination
- Anti-Entropy
- Gossip
- Distributed Transactions
- Consensus
- Paxos
- Message Queues
- Distributed Locks
- Clustering
- Cache
- Rate Limit
https://tangentyh.github.io/notes-of-tan/backend/distributed.html
Категории заметок
- Concepts
- Failure Detection
- Leader Election
- Replication Consistency
- Dissemination
- Anti-Entropy
- Gossip
- Distributed Transactions
- Consensus
- Paxos
- Message Queues
- Distributed Locks
- Clustering
- Cache
- Rate Limit
https://tangentyh.github.io/notes-of-tan/backend/distributed.html
tangentyh.github.io
Distributed System | Notes of Tan
Tan's notes.
Latency Comparison Numbers
Source: https://gist.github.com/jboner/2841832?permalink_comment_id=412306
Source: https://gist.github.com/jboner/2841832?permalink_comment_id=412306
A Metrics Suite for Microservices, EventStorming and DDD 👍
Measuring Coupling and Cohesion of Bounded Contexts on an EventStorming Domain Model
https://phillipjohnson.co.uk/a-metrics-suite-for-microservices-eventstorming-and-ddd
Measuring Coupling and Cohesion of Bounded Contexts on an EventStorming Domain Model
https://phillipjohnson.co.uk/a-metrics-suite-for-microservices-eventstorming-and-ddd
Много ссылок по Solution Architecture
https://github.com/unlight/solution-architecture
https://github.com/unlight/solution-architecture
Много ссылок по распределенным системам
https://github.com/theanalyst/awesome-distributed-systems
https://github.com/theanalyst/awesome-distributed-systems
Don’t Share Code Between Microservices
Ключевой тезис: every piece of knowledge must have a single, unambiguous, authoritative representation within a system
Данные не равно знания. И код - не равно знания. Один и тот же код (я имею в виду символы) может означать разное в разных контекстах и одни и те же данные (именно данные, байты) могут означать разное в разных контекстах.
https://www.infoq.com/news/2015/01/microservices-sharing-code/
Ключевой тезис: every piece of knowledge must have a single, unambiguous, authoritative representation within a system
Данные не равно знания. И код - не равно знания. Один и тот же код (я имею в виду символы) может означать разное в разных контекстах и одни и те же данные (именно данные, байты) могут означать разное в разных контекстах.
https://www.infoq.com/news/2015/01/microservices-sharing-code/
Software Engineering Institute
The SEI Digital Library provides access to more than 5,000 documents from three decades of research into best practices in software engineering. These documents include technical reports, presentations, webinars, podcasts and other materials searchable by user-supplied keywords and organized by topic, publication type, publication year, and author.
https://resources.sei.cmu.edu/library/
have fun 🙂
The SEI Digital Library provides access to more than 5,000 documents from three decades of research into best practices in software engineering. These documents include technical reports, presentations, webinars, podcasts and other materials searchable by user-supplied keywords and organized by topic, publication type, publication year, and author.
https://resources.sei.cmu.edu/library/
have fun 🙂