А вы когда собеседуете разработчиков или архитекторов на продукты/проекты, построенные по принципу распределенной системы/микросервисного решения, вы какие вопросы на собеседовании задаете?
Или какие вопросы задавали вам, тем, кто проходил собеседования?
Думаю это многим может помочь составить траекторию обучения с учетом реальной (не гипотетической) потребности реальных проектов и продуктов.
Или какие вопросы задавали вам, тем, кто проходил собеседования?
Думаю это многим может помочь составить траекторию обучения с учетом реальной (не гипотетической) потребности реальных проектов и продуктов.
Ольга пишет диссер на тему самоактуализации в сфере IT, попросила помочь, если кому интересно можете пройти тест.
👇
👇
Приглашаю пройти участие в исследовании в сфере самореализации у IT-специалистов.
✅ по его результатам вы сможете узнать о том, насколько в вас развиты: гибкость, креативность, синергия и другие важные качества для реализации себя в IT сфере.
Опрос анонимный, состоит из небольшой анкеты и 2 тестов.
Займёт примерно 20 минут.
https://docs.google.com/forms/d/e/1FAIpQLSdWL8HklTaEr02iWzl_YclfexJjiEmvpuGEz5tz9KzLAmFVSw/viewform?usp=sf_link
Если будут вопросы по ходу тестирования - задай их мне, я подскажу, отвечу (@OlgaEgelskaya)
Благодарю за уделенное время!
✅ по его результатам вы сможете узнать о том, насколько в вас развиты: гибкость, креативность, синергия и другие важные качества для реализации себя в IT сфере.
Опрос анонимный, состоит из небольшой анкеты и 2 тестов.
Займёт примерно 20 минут.
https://docs.google.com/forms/d/e/1FAIpQLSdWL8HklTaEr02iWzl_YclfexJjiEmvpuGEz5tz9KzLAmFVSw/viewform?usp=sf_link
Если будут вопросы по ходу тестирования - задай их мне, я подскажу, отвечу (@OlgaEgelskaya)
Благодарю за уделенное время!
Google Docs
Особенности самоактуализации IT-специалистов
Предлагаем Вам принять участие в диссертационном исследовании.
Целью исследования является изучение характеристик самоактуализации специалистов IT-направлений.
Исследование включает в себя анкету и 2 методики (126 и 22 вопроса), их заполнение займет примерно…
Целью исследования является изучение характеристик самоактуализации специалистов IT-направлений.
Исследование включает в себя анкету и 2 методики (126 и 22 вопроса), их заполнение займет примерно…
Forwarded from Russian Association of Software Architects (Ivan)
Мы решили объединить усилия в новом коллективном телеграм-канале, посвященном вопросам ИТ-архитектуры и управления процессами разработки.
Существует барьер, который человеческое внимание еще способно осилить, и этот барьер уже давно превзойден сложившейся в информационном пространстве разрозненностью источников архитектурной информации. Работать с такими источниками стало сродни расчёту мелочью в магазине. При этом полнота покрытия информации качественных телеграм-каналов зачастую оставляет желать лучшего. Наряду с качественной информацией появилось много информационных помех, которые повышают и без того высокую когнитивную нагрузку на подписчиков.
Сложилось противоречие. Обеспечить достаточную полноту качественной информации - это непреодолимая задача для автора-одиночки, являющегося практикующим специалистом. С другой стороны, перерабатывать такое количество разрозненных источников информации, разбавленной информационными помехами - это непреодолимая задача для подписчика, являющегося практикующим специалистом.
За последнее время у нас выкристаллизовался коллектив единомышленников, который решил объединить усилия для разрешения этого противоречия.
Канал самоуправляется консенсусом коллегии из четырех человек: @sergey486 , @GKruglov , @elukianov и @emacsway . Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).
Для обсуждений создан чат: https://tttttt.me/ru_arc_chat
Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.
Существует барьер, который человеческое внимание еще способно осилить, и этот барьер уже давно превзойден сложившейся в информационном пространстве разрозненностью источников архитектурной информации. Работать с такими источниками стало сродни расчёту мелочью в магазине. При этом полнота покрытия информации качественных телеграм-каналов зачастую оставляет желать лучшего. Наряду с качественной информацией появилось много информационных помех, которые повышают и без того высокую когнитивную нагрузку на подписчиков.
Сложилось противоречие. Обеспечить достаточную полноту качественной информации - это непреодолимая задача для автора-одиночки, являющегося практикующим специалистом. С другой стороны, перерабатывать такое количество разрозненных источников информации, разбавленной информационными помехами - это непреодолимая задача для подписчика, являющегося практикующим специалистом.
За последнее время у нас выкристаллизовался коллектив единомышленников, который решил объединить усилия для разрешения этого противоречия.
Канал самоуправляется консенсусом коллегии из четырех человек: @sergey486 , @GKruglov , @elukianov и @emacsway . Круг авторов этим не ограничивается. Если вы поддерживаете наши устремления и обладаете необходимыми навыками, то можете пополнить наш авторский коллектив (обращайтесь к любому из списка).
Для обсуждений создан чат: https://tttttt.me/ru_arc_chat
Это только первый шаг. Уже сейчас мы продумываем принципы, которые позволят коллективизировать работу над архитектурными руководствами, а так же над Reference Architectures/Applications. Есть и другие идеи, но о них говорить пока еще преждевременно. В общем, должно получиться интересно.
27-го выступаю на DotNext (очно), кто идет?)
https://dotnext.ru/talks/1d81350f83a040519d454f92a5164ad8/
https://dotnext.ru/talks/1d81350f83a040519d454f92a5164ad8/
DotNext 2022 Spring. Конференция для .NET‑разработчиков
Многоликий DDD | Доклад на DotNext 2022 Spring
Поговорим о том, какие частные модели можно получить из модели предметной области (в том числе с использованием Event Storming).
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
Kalele
Microservices and [Micro]services
The week began as busy as ever. And then I learned that one more task — beyond everything else on my plate — must be accomplished.
Forwarded from Grisha Skobelev
Всем привет 👋
В рамках книжного клуба { между скобок } мы организовали интервью с тем самым Мартином Клеппманном книгу которого мы прочитали. Обсудим книгу, поговорим про будущее data systems и о новых исследованиях Мартина:
📍 https://www.inkandswitch.com/local-first/
📍https://automerge.org/
Встречаемся 30 июня в 20:00 по мск
Martin Kleppmann is a researcher in distributed systems and security at the University of Cambridge, and author of the bestselling book Designing Data-Intensive Applications (O'Reilly Media). Previously he was a software engineer and entrepreneur, co-founding and selling two startups, and working on large-scale data infrastructure at LinkedIn.
Ссылка на подключение будет чуть позже в чате https://tttttt.me/backend_megdu_skobkah
Также закидывайте ваши вопросы для Мартина в гугл форму https://forms.gle/ZCGNfZ42JJDNsEcd8
В рамках книжного клуба { между скобок } мы организовали интервью с тем самым Мартином Клеппманном книгу которого мы прочитали. Обсудим книгу, поговорим про будущее data systems и о новых исследованиях Мартина:
📍 https://www.inkandswitch.com/local-first/
📍https://automerge.org/
Встречаемся 30 июня в 20:00 по мск
Martin Kleppmann is a researcher in distributed systems and security at the University of Cambridge, and author of the bestselling book Designing Data-Intensive Applications (O'Reilly Media). Previously he was a software engineer and entrepreneur, co-founding and selling two startups, and working on large-scale data infrastructure at LinkedIn.
Ссылка на подключение будет чуть позже в чате https://tttttt.me/backend_megdu_skobkah
Также закидывайте ваши вопросы для Мартина в гугл форму https://forms.gle/ZCGNfZ42JJDNsEcd8
Кто дотнет умеет, норм пример в статье?
Quickly find out the log correlation in your microservice with the Dotnet example
https://betterprogramming.pub/microservice-tracing-log-in-the-distributed-system-96f49bcb7bd
UPD от @Robo_Net (спасибо):
«В доке дотнета есть более актуальная версия, которая входит в стандартную библиотеку https://docs.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs и по ссылочкам внизу тоже много примеров. Если конечно нужен актуальный дотнет, а не под старый фреймворк»
Quickly find out the log correlation in your microservice with the Dotnet example
https://betterprogramming.pub/microservice-tracing-log-in-the-distributed-system-96f49bcb7bd
UPD от @Robo_Net (спасибо):
«В доке дотнета есть более актуальная версия, которая входит в стандартную библиотеку https://docs.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs и по ссылочкам внизу тоже много примеров. Если конечно нужен актуальный дотнет, а не под старый фреймворк»
Airbnb’s Microservices Architecture Journey To Quality Engineering
https://medium.com/qe-unit/airbnbs-microservices-architecture-journey-to-quality-engineering-d5a490e6ba4f
https://medium.com/qe-unit/airbnbs-microservices-architecture-journey-to-quality-engineering-d5a490e6ba4f
Эффект траектории
Если когда-то в большом монолите было принято неподходящее инженерное решение, то, скорее всего, оно уже распространилось по всей системе, а его выкорчевывание требует значительных затрат и переходного периода, когда стабильность решения будет под угрозой. Само наличие этого решения провоцирует дальнейшее развитие последовательности неудачных решений и компромиссов.
Микросервисы — это еще и способ пересмотреть ранее принятые неподходящие и/или устаревшие решения и избавиться от их негативного влияния сегодня и, что более ценно, завтра. Если же мы снова примем неподходящее решение, то скоуп его негативных последствий будет уже и исправить его будет дешевле.
Если когда-то в большом монолите было принято неподходящее инженерное решение, то, скорее всего, оно уже распространилось по всей системе, а его выкорчевывание требует значительных затрат и переходного периода, когда стабильность решения будет под угрозой. Само наличие этого решения провоцирует дальнейшее развитие последовательности неудачных решений и компромиссов.
Микросервисы — это еще и способ пересмотреть ранее принятые неподходящие и/или устаревшие решения и избавиться от их негативного влияния сегодня и, что более ценно, завтра. Если же мы снова примем неподходящее решение, то скоуп его негативных последствий будет уже и исправить его будет дешевле.
Рассказал про Intelligent Swarming
В конце концов всем нам приходится заниматься поддержкой того, что пилим, вот есть такой подход к суппорту, который в целом должен (но не обязан) снизить нагрузку на ключевых экспертов с одновременным ускорением решения проблем)
https://www.youtube.com/watch?v=zfnuFSAqC40
Тут мануалы:
https://www.serviceinnovation.org/intelligent-swarming/
В конце концов всем нам приходится заниматься поддержкой того, что пилим, вот есть такой подход к суппорту, который в целом должен (но не обязан) снизить нагрузку на ключевых экспертов с одновременным ускорением решения проблем)
https://www.youtube.com/watch?v=zfnuFSAqC40
Тут мануалы:
https://www.serviceinnovation.org/intelligent-swarming/
AWS DevOps Series Module 7 SRE and Incident Management.pdf
5.1 MB
И вдогонку занятная преза
«AWS DevOps Series Module 7 SRE and Incident Management»
«AWS DevOps Series Module 7 SRE and Incident Management»
Forwarded from Malikov A.V. (Alexey Malikov)
Без каких инструментов современному веб проекту будет не просто?
Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.
Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).
Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/
Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.
⬇️ Далее
Для домашних проектов все эти рекомендации скорее оверхед чем польза, но чем серьезнее становится проект и аудитория - тем важнее эти советы и правила.
Никогда не забывайте делать резервные копии.
⁃ Бекап должен быть максимально полезным, а значит содержать в себе только те данные, которые заново воспроизвести будет не возможно или долго-дорого.
⁃ Бекап должен быть подтвержден тестами на работоспособность сохраненной копии данных.
⁃ Бекап должен быть эксплуатирован, развертка из бекапа должна проверяться с какой-то переодичностью
⁃ Бекап должен быть безопасным. В идеале зашифрован.
⁃ Используйте специальный софт, а не bash скриптики с кроном. (хотя это тоже работает до определенного момента), но лучше - https://habr.com/ru/company/flant/blog/420055/
⁃ Используйте несколько источников хранения бекапов. Бывает так, что одного может не оказаться в какой-то момент (не доверяйте слепо облакам).
Фиксируйте ошибки приложения проактивно.
⁃ Если приложение упало, вы можете об этом никогда не узнать, если не мониторите access логи сервера.
⁃ Если приложение работает не корректно у клиента, при этом это современное spa приложение, вы об этом не узнаете примерно никогда, если не настроите правильный мониторинг такого поведения (читай сбор ошибочного поведения со стороны фронтенда) или до тех пор пока к вам не придет сам пользователь с жалобой (нужно дать возможность сообщать о багах из веб морды).
⁃ Хорошим тоном и практикой является подключение публичной sentry для фиксации ошибок, например вот так можно начать - https://habr.com/ru/post/508686/
Мониторинг работы сервера и приложения.
⁃ Чем больше всего нужно, тем больше за этим нужно наблюдения, к сожалению.
⁃ Хорошим стартом будет базовый grafana + prometheus + экспортеры метрик для фиксации работы приложения, сервера и инфраструктурных слоев.
⁃ Если есть опыт и желание, можно обойтись zabbix.
⁃ Уведомление о том, что сервер сломался и(или) что-то подходит к пиковым характеристикам можно реализовать либо через туже grafana, либо через alertmanager.
⁃ Использования облачных grafana или других инструментов для сбора и анализа метрик тоже хорошая история, если вы им доверяете (!)
⁃ Логи кстати тоже надо мониторить, тут подойдут какие-нибудь graylog или loki, или еще что-то ибо решений прям очень много.
⁃ Ну и внутреннего мониторинга не достаточно, нужно проверять что приложение работает из вне. Для этого есть saas сервисы, ну или можно реализовать самостоятельно.
⬇️ Далее
Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.
📍Программа и регистрация: https://archconf.ru/recap-27-07-22
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.
📍Программа и регистрация: https://archconf.ru/recap-27-07-22
Микросервисы / распределенные системы
Привет! Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве. 🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций: — расскажут о дальнейшем развитии истории из выступления; — раскроют некоторые аспекты…
Тем временем уже можно подавать заявки на выступление на ArchDays (https://archdays.ru).
Темы в этом году более общие, но при этом, как нам показалось, они совместно полны и взаимоисключающие (насколько это возможно):
1.Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
Если у вас тема огонь и не подходит под тематики, пишите мне, разберемся, как это у нас тематики под огненную тему не нашлось 🖖
Темы в этом году более общие, но при этом, как нам показалось, они совместно полны и взаимоисключающие (насколько это возможно):
1.Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
Если у вас тема огонь и не подходит под тематики, пишите мне, разберемся, как это у нас тематики под огненную тему не нашлось 🖖
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
💬 "These were elucidated in the mid-70s by Yourdon & Constantine in "Structured Design" and haven't changed. Their argument goes like this:
1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.
(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"
-- "Monolith -> Services: Theory & Practice" by Kent Beck
1. We design software to reduce its cost.
2. The cost of software is ≈ the cost of changing the software.
3. The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
4. The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then…
5. Coupling between elements of a design is this propensity for a change to propagate.
6. So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling.
(This skips loads of interesting stuff, but I'm just trying to set up the argument for why rapid decomposition of a monolith into micro-services is counter-productive.)"
-- "Monolith -> Services: Theory & Practice" by Kent Beck
Medium
Monolith -> Services: Theory & Practice
How can we get from a monolith to micro-services quickly?
Недавно в чате было обсуждение микрофронтендов, свежая статья в тему:
https://medium.com/@anilcanerciyes/microfrontends-module-federation-for-runtime-integration-2bdac86fcf0f
https://medium.com/@anilcanerciyes/microfrontends-module-federation-for-runtime-integration-2bdac86fcf0f
Сергей_Баранов_DotNext_Многоликий_DDD.pdf
29 MB
Преза моего недавнего выступления на DotNext про то, что можно получить из модели предметной области представленной в нотации Event Storming.
Микросервисов тоже слегка рукавом коснулся.
Микросервисов тоже слегка рукавом коснулся.
Monolith First строится вокруг простой идеи — восприятие монолита как прототипа.
Напишите, пожалуйста, в комментариях, какие статьи (всех времен) вы считаете фундаментальными в области архитектуры и разработки (на русском или английском)?
Собираем в @ru_arc список статей для переводов (в том числе с русского на английский).
Собираем в @ru_arc список статей для переводов (в том числе с русского на английский).