Об DevOps и архитектуру

Reading time: 1 minutes

Citadel — архитектурный паттерн проектирования наряду с паттернами “Монолит” и “Микросервисы”.

Состоит в выделении некоторой функциональности из монолита в виде “Outpost” и сохранении основного условно монолитного ядра.

Для того, чтобы принять решение оставлять ли некоторую функциональность в монолите, или же вынести ее в микросервис кажется можно применить [6 причин делать микросервис](/kb/6-reasons-for-microservices/).

Хороший пример для выделения в Outpost — сервис аутентификации, на который обычно бывает высокая нагрузка, или сервис-представление для какого-нибудь счетчика, который выдает пользователю количество непрочитанных сообщений.

Read more...

Reading time: 1 minutes

Микросервисы имеют и плюсы и минусы, на которых мы сейчас останавливаться не будем.

Существует 6 причин разделять компоненты на микросервисы, вместо разработки монолита:

1. Разная частота изменений (сервисы, которые меняются часто имеет смысл выделить в отдельный микросервис)
2. Разный жизненный цикл (например, какой-то компонент требует особого вида тестирования или к нему особые требования у регуляторов)
3. Разные требования к масштабированию (например, сильно нагружены чаще всего только 1-2 сервиса из десятков)
4. Изоляция сбоев (если взорвется один сервис остальные продолжат работать, но при этом критичных компонентов не так много)
5. Фасад к внешним зависимостям (устойчивость к смене их API, всякие AAA, и т.д.)
6. Необходимость в разном техническом стеке в разных частях системы

(Это вольный пересказ статьи ¹)

Read more...

Reading time: 1 minutes

Предоставление API можно рассматривать как способ подключения к деятельности других субъектов, или способ подключения к другому рынку.

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

В этом смысле конструирование API наиболее удобных для каких-то конкретных пользователей можно рассматривать как упаковку имеющегося продукта под новые рынки. В этом же контексте по видимому можно применять те же способы разработки продуктов, которые применяются и для продуктов физического мира (такие как Lean Startup и т.д.)

Read more...

Reading time: 1 minutes

[Открытые стандарты](/kb/open-standards/) — это способ формирования вендорами рынка, на котором они смогут строить свои решения и играть по понятным правилам.

Через создание спецификации некоторого API вендоры оформляют и стабилизируют рынок, чтобы появилась возможность выпускать под него свои продукты.

Помимо этого это удешевляет разработку как компонентов, так и архитектуры — не нужно специально проектировать интерфейсы.

Примеры (возможно не все из них корректные):

• [Open Container Initiative](/kb/open-container-initiative/): https://opencontainers.org/

• Open Application Model: https://oam.dev/

• Open Service Broker API: https://www.openservicebrokerapi.org/

  Read more...

Reading time: 1 minutes

[Open Container Initiative](/kb/open-container-initiative/) — это рабочая группа, включающая в себя крупных вендоров, которая разрабатывает [открытые стандарты](/kb/open-standards/) для запуска контейнеров.

В стандарт входят три спецификации:

• Спецификация образов контейнеров (https://github.com/opencontainers/image-spec)
• Спецификация передачи образов (https://github.com/opencontainers/distribution-spec)
• Спецификация рантайма для контейнеров (https://github.com/opencontainers/runtime-spec)

Это позволяет разным вендорам делать собственные реализации контейнеризации оставаясь при этом совместимыми с пользовательским тулчейном – инструментами разработки, сборки, оркестраторами и т.д.

Примеры реализации этих стандартов (список не исчерпывающий):

• https://github.com/opencontainers/image-spec/blob/main/implementations.md
• https://github.com/opencontainers/runtime-spec/blob/master/implementations.md

Reading time: 2 minutes

Большая ошибка многих рассуждающих в контексте DevOps о “снижении TTM” и необходимости “релизиться чаще” состоит в том, что они рассматривают частоту релизов и время “от коммита до продакшна” как технический показатель. В лучшем случае рассматривают с учетом простоев в цепочке поставке. Они считают, что если автоматизировать все, они смогут релизиться 100 раз в день и догонят и перегонят Google (конечно, для этого автоматизировать нужно “не просто так”, а “по-умному”).

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

Read more...

Reading time: 1 minutes

Атрибуты качества уточняют требования к системе —- как функциональные, так и не функциональные. Они не могут обсуждаться отдельно без требований.

Атрибуты качества должны быть максимально конкретными и точными, с минимумом возможных интерпретаций. В идеале по ним должно быть возможно построить Quality Gate.

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

Примеры атрибутов качества см. например в статье по ссылке ¹.

Read more...

Reading time: 1 minutes

Architect Elevator – принцип, который утверждает, что Архитектура — это способ коммуникации между уровнями в организации.

С учетом того, что современные организации движутся в сторону Software defined processes, коммуникация эта должна затрагивать как организационные, так и технические взаимодействия.

Read more...