ИТ-архитектура

#интеграция #архитектура

Страх и ненависть в шиномонтаже.
Шина, это как REST - все обсуждают, но каждый говорит о своем. Иногда интерпретации могут путать и сбивать с толку. Короткая памятка о том, что могут называть шиной и какие они бывают.

Enterprise Service Bus
Она же ESB, она же Корпоративная Шина
1. Широко распространенный паттерн в SOA архитектуре. Описывает центральный компонент архитектуры предприятия, который позволяет:
• подружить системы на техническом уровне, т.к. они используют разные технологии для взаимодействия: HTTP, MQ, CORBA, DB, etc.
• избавиться от сильной связанности и подружить разные модели данных

2. Класс решений, реализующих паттерн ESB и другие паттерны SOA. Например:
• IBM Integration Bus
• Mule ESB
• Red Hat Fuse

Message Broker
Он же Брокер Сообщений, он же Шина Сообщений.
Класс решений, реализующих логику очередей сообщений, публикации и подписки. Например:
• IBM MQ
• Rabbit MQ
• Kafka

Шина данных
Некая абстракция, которая позволяет передавать данные. Может значить что угодно. Иногда так называют брокеры сообщений. Если вам известно устоявшееся определение - поделитесь, плз.

Event Bus
Она же Шина Событий, она же Шина Сообщений
Паттерн взаимодействия сервисов путем обмена сообщениями-событиями. Как правило реализуется за счет брокера сообщений, но можно и с помощью БД.

И что?
Под словам Шина могут подразумевать любой из этих вариантов. Sad but true.

Какие каналы в Telegram читать ИТ-архитектору? (разбито по направлениям)

Architecture

ИТ-архитектура

https://t.me/itarchitecture – Полезные ссылки и материалы без лишней воды по архитектуре предприятия, решений, данных, системной архитектуре, archops. Мой канал 🙂

Архитектура ИТ-решений

https://t.me/it_arch – Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

ИТ-АС – ИТ в корпорациях (Архитектура и Стратегия, ИТ-менеджмент)

https://t.me/it_ace – ИТ-АС – корпоративная Архитектура и Стратегия (ИТ и цифровизации), управление и менеджмент ИТ в корпорациях. Практики, примеры и шаблоны, фреймы мышления и др.

Работа для ИТ-архитекторов

https://t.me/itarchitect_jobs – Не только резюме и вакансии ИТ-архитекторов, но и обсуждение вопросов: где найти, сколько платить, как своих вырастить и удержать, чего ожидать от ИТ-архитектора…

Solution Architecture

Architecture Weekly

https://t.me/architectureweekly – Architecture Weekly newsletter originated at https://vvsevolodovich.dev/architecture-weekly/ . 10 articles or videos on solution architecture and system design each Sunday.

Yet another SA

https://t.me/another_sa – Непрофессиональный блог об анализе и архитектуре.

Интеграция и распределенные системы

https://t.me/another_api – Обсуждаем интеграцию и распределенные системы. И все остальное.

Software architecture

Software architecture

https://t.me/software_architecture_ru – Об архитектуре программного обеспечения

Business & System Analysis

IT Systems Analysis/Design – Events & Stuff

https://t.me/itsysdes_events – Очные и онлайн-события для аналитиков и проектировщиков ИТ-систем, интересные статьи и новости.

Business | System analyst

https://t.me/ba_and_sa – Канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых. Выкладываем статьи (также зарубежные), авторские посты, видео, опросы, юмор))

Amazon Web Services

AWS User group Kazakhstan

https://t.me/+RJDua434TOPlinwD – Казахстанское сообщество

Cообщество Amazon Web Services в России

https://t.me/aws_ru

DevOps

DevOps_ru

https://t.me/devops_ru – Общаемся на темы DevOps, мониторинга, метрикам и облакам. Новости.

Kubernetes_ru

https://t.me/kubernetes_ru – Общаемся на темы, посвященные Kubernetes, конфигурации и возможностям. Новости, вопросы, идеи и т.д.

В дополнение к интересной заметке добавлю, что например Amazon Web Services уже представляет свой собственный сервис - облачную реляционную СУБД Aurora, которая по заявлениям AWS быстрее других реляционных СУБД в 5 раз (в случае использования в их облаке).

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

Например, DataStax, стартап с продуктом Astra DB на базе Apache Cassandra [1]. Для тех кто не помнит, Apache Cassandra - это такая NoSQL база данных с хорошей масштабируемостью. Не такая удобная, ИМХО, из коробки как MongoDB, но гораздо лучше масштабируется горизонтально.

Особенность Apache Cassandra в языке CQL, очень похожем на SQL. Он, с одной стороны, довольно привычен, но с другой не так удобен для работы со схематичными объектами. И вот DataStax в Astra DB [2] добавили почти MongoDB совместимое Document API. Это возможность работы с режиме CRUD.

В общем удобная и полезная возможность. Но, существующая только в облачном виде. Даже Enterprise версия тоже облачная. Этого, в последнее время всё больше, появление cloud-only продуктов. С одной стороны они дают возможность крайне высокой скорости развертывания и управляемости инфраструктуры, а с другой, зависимость от облачных сервисов становится огромной. Впрочем это не только про этот продукт, а про многочисленные другие также.

Ссылки:
[1] https://www.datastax.com/products/datastax-astra
[2] https://docs.datastax.com/en/astra/docs/develop/dev-with-doc.html

#data #startups

Эволюция архитектуры: усложнение программных решений требует все больше «узких» специалистов и подходов в управлении этим командами 🧐

Какие бывают ИТ-архитекторы?

Postman опубликовали обновление API Platform Landscape [1] с перечнем продуктов и трендов в мире API.

Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.

Не все согласятся что экосистема API существует автономна, например, для меня это скорее часть экосистемы работы с данными, а Postman показывают её с выгодной для них стороны там где они лидеры, но, тем не менее, в части описанного, тренды изложены верно и сам обзор полезен.


Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/

#api

Продолжаем говорить про сертификацию. Николай Пойда @mykola7799 community builder рассказал о своем опыте сдаче 8 сертификатов.
В этом выпуске вы узнаете:
- Кто такой AWS community builder, какие требования к участникам и какие бенефиты программы
- История Николая подготовки и сдачи 8-ми сертификатов. В каком порядке Николай сдавал, какие ресурсы использовал (все ссылки ниже).
- Мотивация важный компонент в долгом путешествии в мир облачной сертификации. Что именно мотивировало Николая сдать столько сертификатов.
- Поможет ли сертификация в карьере, на примере конкретного человека.

Послушать можно тут:
Anchor
Yandex
GooglePodcasts
ApplePodcasts
Spotify

https://www.youtube.com/watch?v=BusflGz1ewQ

Трансляция начнётся в 22:00 по времени Астаны

https://youtu.be/lTkL1oIMiaU

В этом видео в вводной форме объясняется архитектура программного обеспечения, как она выглядит в целом и три важные ее части:
- Архитектурные шаблоны
- Обмен сообщениями
- Атрибуты качества
Кроме того, разъясняется разница между архитектурными паттернами и дизайн-паттернами.

Немножко об ИТ-инфраструктуре от Accenture

Только 80 порт

Большая боль для современной эксплуатации — это бекенд, который лезет на уровень протокола: терминирует SSL, отдаёт заголовки HSTS или CSP или даже делает Basic-авторизацию. С одной стороны звучит довольно просто — поставил пару пакетов для любимого фреймворка, и добавил безопасности и удобства.

К сожалению, это не правда. Возьмём, к примеру, HSTS — заголовок, с помощью которого приложение может сказать «дальше соединяйся со мной только по HTTPS, пожалуйста». Браузер кеширует этот заголовок, и больше никогда не пойдёт по HTTP-ссылке на приложение. Вроде бы отличное поведение, но ровно до того момента, пока вы не запустите приложение с таким заголовком на локалхосте, после чего у вас перестают работать все не-SSL приложения, которые висят на этом же порту.

Или CSP — список доменов, с которых браузеру разрешено грузить внешние ассеты. Вроде бы клёво, когда программисты сами прописывают, что им нужно, но представьте, как грустно становится админу, когда он разворачивает какой-нибудь новый вид тестовой среды — скажем песочницу для потенциальных партнёров. Ему нужно идти к программистам, чтобы те добавили новые хосты в свои списки, иначе песочница будет падать с кучей ошибок.

Я не говорю о попытках терминировать SSL или реализовать HTTP/2 в том же контейнере, где крутится код. В специально приспособленных местах такие вещи делаются за 1 строку кода, или вообще без неё. А в контейнер приходится заводить nginx, letsnencrypt и ещё кучу скучных вещей.

Всё, что должен знать современный бекенд про HTTP — это то, что его будут спрашивать по 80 порту (и то не обязательно). Всё остальное — забота балансировщика, nginx, cloudflare или что там у вас.

API и микросервисы