Software Architecture Monday with Mark Richards 66 видео лекций по ИТ-архитектуре с 11 января 2018 по 12 августа 2019 https://www.developertoarchitect.com/lessons/ На YouTube они просто выложены россыпью здесь: https://youtu.be/3bxAm3XIFmk
Developertoarchitect
Software Architecture Monday | Developer to Architect | Mark Richards
Software Architecture Lessons
Пятничное из блога Архитектура информационных систем https://mxsmirnov.com/2016/03/02/muda/
Forwarded from Albert Bertyakov
TAdviser сегодня написал про встречу по поводу госИТ-архитектуры недельной давности. Неплохая там подборка высказываний участников встречи
http://www.tadviser.ru/a/470437
http://www.tadviser.ru/a/470437
TAdviser.ru
Критика и скепсис. Эксперты с осторожностью восприняли концепцию единой ИТ-архитектуры госорганов
По плану Минкомсвязи и НИИ "Восход", в 2020 году в России должен появиться главный государственный ИТ-архитектор, который займется унификацией методик и инструментов создания государственных цифровых платформ и ИТ-систем. Первое обсуждение концепции, предполагающей…
Хороший дизайн - это тот, который делает возможными будущие изменения поведения, Если бы нам нужно было выбирать между двумя дизайнами при наличии бесконечных ресурсов, мы бы просто реализовали их оба и посмотрели, какой из них сделает возможным будущие изменения.
Кент Бек о "тестировании" структурных изменений https://medium.com/@kentbeck_7670/testing-structure-changes-d8d01f65b64e
Кент Бек о "тестировании" структурных изменений https://medium.com/@kentbeck_7670/testing-structure-changes-d8d01f65b64e
Medium
“Testing” Structure Changes
Watching a design debate play out at work I’ve been struck by the lack of actual concrete feedback about the proposed alternatives. Data…
Бизнес-леди и двое мужчин. Трогательная история непростых отношений Лоретты и двух версий корпоративного архитектора Арчи
в блоге The Open Group:
в блоге The Open Group:
Much to Loretta’s surprise she finds out she already has an Enterprise Architect in her organization. She is reminded he is a part of the CTO organization. Loretta remembers that this is the position they discuss at the beginning of every budget cycle when they consider cutting costs. Each year for the last three years, the CTO defends the position saying that Enterprise Architecture is an investment and takes time to take hold and yield resultshttps://blog.opengroup.org/2019/08/20/the-future-enterprise-architect/
The Open Group Blog - Achieving business objectives through technology standards
The Future Enterprise Architect - The Open Group Blog
Before describing the future Enterprise Architect, we will reflect on the current Enterprise Architect, one of their customers - a current line of business leader - and the strained relationship between them. For the sake of personalization, we will call…
Поделитесь своими впечатлениями о мероприятии: https://clck.ru/Hm3T9
Google Docs
Вам понравилось?
Пожалуйста, дайте нам обратную связь по прошедшему мастер-классу "Гибкие подходы в Архитектуре Предприятия"
Это называется: обозначили тему https://martinfowler.com/articles/oss-lockin.html Ну, хорошо, ждем продолжения
martinfowler.com
Don't get locked up into avoiding lock-in
Lock-in is an important consideration. But, it's not a simple black-or-white affair, and minimizing isn't always best.
Вот эта статья https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ заставила меня задуматься о том, в какой мере и в наше время те или иные ИТ решения являются результатом экспериментов(серий неудачных, намного реже удачных попыток). Все хайповые ныне вещи от бигдаты до бессерверных архитектур делались для решения вполне утилитарных задач. Но делались они при этом каким-то особым, специальным способом, позволившим им выйти далеко за пределы изначальных потребностей... Теперь мы кипятим на них воду
Ars Technica
Unix at 50: How the OS that powered smartphones started from failure
Today, Unix powers iOS and Android—its legend begins with a gator and a trio of researchers.
Facebook пишет, что ссылка: https://tttttt.me/s/it_arch нарушает нормы сообщества. Не читайте FB, читайте Telegram в браузере (ссылка выше)
Больше проектов на Go хороших и разных :-) https://habr.com/ru/company/flant/news/t/466627/
Хабр
Maesh — новый простой service mesh для Kubernetes от авторов Traefik
На этой неделе компания Containous, хорошо известная в сообществе cloud native (Kubernetes и других проектов CNCF) благодаря своему продукту Traefik, анонсировала новое Open Source-решение категории...
Пропустил этот перевод известной статьи: https://habr.com/ru/company/redhatrussia/blog/455024/
Хабр
5 принципов здравого смысла для создания cloud-native apps
«Облачно-ориентированные» (cloud native) или просто «облачные» приложения создаются специально для работы в облачных инфраструктурах. Обычно они строятся как набор слабо связанных микросервисов,...
Не самый короткий, но довольно полезный текст (с хорошими ссылками) про CAP-теорему, панк-рок и "Войну и мир" Льва Толстого http://www.julianbrowne.com/article/brewers-cap-theorem
:julianbrowne
Brewer’s CAP Theorem
An explanation of Eric Brewer’s CAP theorem, which says you cannot have more than two of Consistency, Availability and Partition-tolerance in web-based distributed systems.
Рекомендую к прочтению книжку Распределенные системы. Паттерны проектирования. Издательство Питер, 2019 - тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны. Так, например, один из вопросов, на которые она дает ответ - как быть с повторно-используемыми (reusable) компонентами в микросервисной архитектуре
Архитектура ИТ-решений
Рекомендую к прочтению книжку Распределенные системы. Паттерны проектирования. Издательство Питер, 2019 - тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны.…
В отличии от сервиса в сервис-ориентированной архитектуре, которые изначально рассматривался как компонент, разработанный для повторного использования, микросервис таковым не является. Скорее наоборот, мы реализуем в микросервисе некий частный случай, функционал, востребованный иногда или возможно востребованный, например, при тестировании гипотез или функции необходимые лишь части клиентов и т.п.
Где же в этом случае реализовывать многократно используемые функции? В монолите такие функции реализуются в виде библиотек, принося с одной стороны несомненную пользу, а с другой – ад зависимостей. Брендан Бёрнс, автор книжки про паттерны проектирования распределенных систем, рекомендует реализовывать такой функционал в виде отдельных контейнеров. Нужен вам reusable функционал – добавляете в свой pod соответствующий контейнер и вызываете его из основного процесса внутри вашего микросервиса
Где же в этом случае реализовывать многократно используемые функции? В монолите такие функции реализуются в виде библиотек, принося с одной стороны несомненную пользу, а с другой – ад зависимостей. Брендан Бёрнс, автор книжки про паттерны проектирования распределенных систем, рекомендует реализовывать такой функционал в виде отдельных контейнеров. Нужен вам reusable функционал – добавляете в свой pod соответствующий контейнер и вызываете его из основного процесса внутри вашего микросервиса
Архитектура ИТ-решений
Рекомендую к прочтению книжку Распределенные системы. Паттерны проектирования. Издательство Питер, 2019 - тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны.…
Кстати, книжка довольно небольшая, чуть больше 200 страниц. Обзор её от издателя перевода на Хабре https://habr.com/ru/company/piter/blog/442514/ и страница книги с оглавлением и ознакомительным фрагментом на сайте издателя https://www.piter.com/product/raspredelennye-sistemy-patterny-proektirovaniya Паттернов проектирования распределенных систем, наверняка должно быть больше, особенно, если считать с анти-паттернами(другой подход к теме см., например, здесь https://www.infoq.com/articles/kubernetes-effect/). Но паттерны – это штука, которая плохо поддается учету. У кого-то их три, у кого-то пять, а еще у кого-нибудь пятьдесят, но он их никогда не использует. Мне показалось, что автор скорее использовал паттерны, в качестве последовательных вех, раскрывающих некий общий подход от простого к сложному, от одноузловых паттернов, через технологические компоненты к принципу проектирования прикладных решений
Хабр
Распределенные системы. Паттерны проектирования. Обзор книги
Здравствуйте, коллеги. Сегодня мы публикуем перевод очередного обзора с сайта Бена Нейдела — этот сайт наверняка заинтересует вас и в оригинале. На сей раз мы поговорим о книге " Распределенные...
Архитектура ИТ-решений
В отличии от сервиса в сервис-ориентированной архитектуре, которые изначально рассматривался как компонент, разработанный для повторного использования, микросервис таковым не является. Скорее наоборот, мы реализуем в микросервисе некий частный случай, функционал…
Интересно влияние идеи повторно-используемых компонент в виде контейнеров, дополнительно включаемых в микросервисы, на корпоративные ИТ-ландшафты. Когда-то давно стандартизация, унификация и борьба с дублированием функционала в корпоративных ИТ велась под флагом внедрения единых систем: корпоративное хранилище данных, корпоративная сервисная шина и т.п. (в английском, название таких систем начинаются со слова Enterprise). Когда стало ясно, что подобные системы моментально превращаются в черные дыры, способные пожирать данные и бюджеты, но совершенно не справляющиеся с задачей быстрой поставки функционала, политика корпоративных ИТ скорректировалась в сторону SOA-сервисов. Мол реализуйте логику где и на чем хотите, но читайте данные и отправляйте команды через обязательный набор сервисов. Сейчас вместо общих сервисов приходит тема раздачи адаптеров. Это чем-то похоже на service mesh. Нужен вам какой-нибудь справочник? – подцепите в свой pod MDM-контейнер, а где он возьмет данные и как раздаст их по всем узлам – это уже не забота прикладного программиста.
Вообще говоря, это уже не вполне микросервисы, что, само по себе, и не хорошо и не плохо. Зато какое поле деятельности для очередной волны переписывания всех корпоративных систем
Вообще говоря, это уже не вполне микросервисы, что, само по себе, и не хорошо и не плохо. Зато какое поле деятельности для очередной волны переписывания всех корпоративных систем
Архитектура ИТ-решений
Ян Шарп произнес эти слова в 1969 году на конференции NATO Conference on Software Engineering Techniques: Есть некое дополнение к программированию, и его надо вытащить на свет. Это программная архитектура. Архитектура и проектирование(дизайн, примечание моё)…
Следующей вехой развития ИТ-архитектуры стала книжка Фредерика Брукса "Мифический человеко-месяц, или как создаются программные системы", 1975г. (которая, кстати, навсегда поссорила разработку с архитектурой). Одна из многочисленных мыслей этой книги: архитектурных замыслов может быть более одного (что, кстати, хорошо по сравнению с их полным отсутствием).
Увязка различных идей обрела название концептуальной целостности (conceptual integrity). Пусть замыслов будет несколько, лишь бы они выстраивались в соглсованную картинку. Практически сразу анти-паттерном обеспечения концептуальной целостности был назван design by committee (верблюд - это лошадь, спроектированная комитетом), что впрочем не мешает нам устраивать битвы идей в формате архитектурных комитетов до сих пор
Увязка различных идей обрела название концептуальной целостности (conceptual integrity). Пусть замыслов будет несколько, лишь бы они выстраивались в соглсованную картинку. Практически сразу анти-паттерном обеспечения концептуальной целостности был назван design by committee (верблюд - это лошадь, спроектированная комитетом), что впрочем не мешает нам устраивать битвы идей в формате архитектурных комитетов до сих пор