В отличии от сервиса в сервис-ориентированной архитектуре, которые изначально рассматривался как компонент, разработанный для повторного использования, микросервис таковым не является. Скорее наоборот, мы реализуем в микросервисе некий частный случай, функционал, востребованный иногда или возможно востребованный, например, при тестировании гипотез или функции необходимые лишь части клиентов и т.п.
Где же в этом случае реализовывать многократно используемые функции? В монолите такие функции реализуются в виде библиотек, принося с одной стороны несомненную пользу, а с другой – ад зависимостей. Брендан Бёрнс, автор книжки про паттерны проектирования распределенных систем, рекомендует реализовывать такой функционал в виде отдельных контейнеров. Нужен вам reusable функционал – добавляете в свой pod соответствующий контейнер и вызываете его из основного процесса внутри вашего микросервиса

Кстати, книжка довольно небольшая, чуть больше 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-контейнер, а где он возьмет данные и как раздаст их по всем узлам – это уже не забота прикладного программиста.

Вообще говоря, это уже не вполне микросервисы, что, само по себе, и не хорошо и не плохо. Зато какое поле деятельности для очередной волны переписывания всех корпоративных систем

Следующей вехой развития ИТ-архитектуры стала книжка Фредерика Брукса "Мифический человеко-месяц, или как создаются программные системы", 1975г. (которая, кстати, навсегда поссорила разработку с архитектурой). Одна из многочисленных мыслей этой книги: архитектурных замыслов может быть более одного (что, кстати, хорошо по сравнению с их полным отсутствием).
Увязка различных идей обрела название концептуальной целостности (conceptual integrity). Пусть замыслов будет несколько, лишь бы они выстраивались в соглсованную картинку. Практически сразу анти-паттерном обеспечения концептуальной целостности был назван design by committee (верблюд - это лошадь, спроектированная комитетом), что впрочем не мешает нам устраивать битвы идей в формате архитектурных комитетов до сих пор

Понравилось: https://kristoff.it/blog/why-go-and-not-rust/

Прямая ссылка на вебинар: https://youtu.be/9vtf33NIJrE

Остановил опрос. Всем большое спасибо за участие. Мой текущий выбор перевода:
облачные(cloud-native) приложения

ИМО лучше чем Облачные (cloud-native) приложения пока не увидел.

Познавательно. Впрочем AWS - это отдельный мир если не сказать The Matrix https://www.jeremydaly.com/serverless-microservice-patterns-for-aws/

к предыдущей ссылке

Мне не очень нравится текст статьи Eltjo R. Poort https://eltjopoort.nl/blog/2019/06/25/a-map-to-waterfall-wasteland-and-the-agile-outback/ но нельзя не согласиться с обозначенными фазами эволюции понятия ИТ-архитектура. Впрочем фаз больше и базовых компетенций архитектора тоже, увы ...

Google наконец выпустил инструмент Audience Connect для взаимодействия аудитории с презентацией. По-моему, получилось ужасно https://create.withgoogle.com/tools/audience-connect Можно смело покупать годовую подписку на Mentimeter или что-то похожее

Вполне по делу и с хорошими ссылками: https://www.infoq.com/articles/postgres-handles-more-than-you-think/

​​На злобу дня...

Очень полезная заметка Svyatoslav Kotusev о двух группах архитектурных артефактов(факты и решения) и разнице подходов при их создании и использовании: https://www.bcs.org/content-hub/enterprise-architecture-artifacts-facts-and-decisions/

Очередные сообщения о масштабных утечках клиентских данных так и подмывает задать вопрос: ну и нафига вы храните все данные в одной базе? ... адреса, телефоны, ФИО, давайте еще дни рождения и профили в соцсетях туда же приклеим.

А как-же предметно-ориентированное проектирование aka domain driven design? Не, не слышали?

Почему я люблю читать описание вакансий архитекторов? (кстати, даже группу https://tttttt.me/itarchitect_jobs создал для этого); особенно Enterprise Architect-ов. Да в них как нельзя лучше отражаются ожидания от этого персонажа. Обоснованные и напрасные, конкретные и расплывчатые, адекватные и не очень - для учебного курса, например, это не столь уж важно. Главное список сверхспособностей получить, а как их слушатели смогут приобрести - задача для ИТ-тренера более или менее традиционная

В том что касается Semantic Web и Linked Data всегда было немного коммерчески успешных проектов. Эти технологии продвигались W3C и Тимом Бернерсом-Ли, шкала в 4 и 5 звёзд открытости данных были привязаны как раз к их связности, но всегда побеждала прагматика и мало из владельцев данных сейчас публикует их в виде "связанных данных".

Одним из наиболее успешных стартапов в этой области была компания Metaweb со специализацией на интеграцие множества разных источников с возможностью интегрировать их в единую онтологическую модель на базе Википедии. В 2010 году их купил Google [1] за неназванные условия и вскоре в поиске Google появились подсказки с данными из Википедии, IMDB и других источников.

Этим июлем, стартап data.world [2] претендующий на то чтобы стать Github'ом для данных объявил о покупке стартапа Capsenta [3] специализировавшегося на онтологиях и семантическом вебе. Их продукты Ultrawrap NoETL и Gra.fo [4] были ориентированы на интеграцию и визуализацию связанных данных. Сумма сделки не разглашается. Но в любом случае, похоже, стоит ждать появления инструментов визуализации и интеграции пользовательских данных в Data.world, а сам Data.world может пойти по пути Metabase.

Из всех проектов которые претендовали на роль Github для данных - пока data.world наиболее перспективен, но и его судьба именно в этой роли далеко не предопределена. А вот чем больше там будет связанных данных и интеграции большего числа источников тем выше вероятность его покупки крупным игроком на рынке, тем же Alphabet/Google, или Amazon и последующая интеграция в их экосистему.

Ссылки:
[1] https://www.cnet.com/news/google-buys-metaweb-and-its-sprawling-database/
[2] http://data.world
[3] https://data.world/blog/weve-acquired-capsenta-to-bring-the-power-of-knowledge-graphs-to-companies-with-on-prem-data/
[4] https://gra.fo/

#data #opendata #semanticweb

Нет ничего святого у этих айтишников. Ну разве можно вот так вот просто взять и экспортировать один из немногих примеров применения нотации Archimate, кейс вымышленной компании ArchiSurance, в графовую базу данных Neo4j https://lju-lazarevic.github.io/ArchiMateNeo4j1.html а потом еще и обратно загрузить