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

Reading time: 3 minutes

Read more...

Reading time: 1 minutes

Подход “Инфраструктура как Код” (IaC) противопоставляется подходу “Infrastructure as Scripts” в том, что к коду (в отличие от скриптов) начинают применять практики обычные для программирования, например тестирование.

Вот что имеет смысл тестировать в IaC:

• контракты (входы и выходы) модулей
• мутации параметров ( "${env}-${name}" или if env=prod then https should be enabled )
• внешние ограничения (“не должно быть security group с полностью открытыми портами”)

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

Read more...

Reading time: 1 minutes

Из комментариев к обсуждению различия между проектом и процессом https://www.facebook.com/alex.turkhanov/posts/10227176872024711 :

• а) процесс не мобилизует ресурсы (проект мобилизует), он использует выделенные и зарезервированные под него;
• б) у процесса множественная причинность (у проекта токен-причинность), если мы сделаем вот такие действия над вот такими объектами, то из такой ситуации перейдем вот в такую;
• в) процесс есть инвариант , неизменная и неполная по составу и структуре основа для действий. Например, у Росатома есть процесс сооружения АЭС, события и действия, которые должны произойти, чтобы соорудить АЭС. Каждый отдельный экземпляр процесса сооружения порождает еще и проект сооружения, в рамках программы конкретной АЭС, в которой еще есть и куча процессов (проектов) эксплуатации и вывода из эксплуатации и пр.
• Т.е., проект и процесс - это разные методы описания архитектуры действия.

В этом контексте начинает новыми красками играть понятие о Платформенной стратегии – она также мобилизует экосистему.

Read more...

Reading time: 3 minutes

DORA в своем исследовании State Of Devops вывели метрики, которые показывают производительность организации:

• Lead Time
• Deployment Frequency
• MTTR
• Change Failure Rate

В двух словах, это важнейшие метрики из Lean, примененные к разработке софта, и они означают эффективность производственного процесса в компании. В упомянутом отчете показывается, что у тех компаний, кто показывает наилучшие бизнес-результаты эти метрики также высоки. Подробнее об этом говорится в вышеупомянутом отчете State Of Devops, а еще подробнее в книге Accelerate.

Read more...

Reading time: 1 minutes

Паттерн Operator предназначен для создания инфраструктурных продуктов через декларативные описания.

К примеру, сам [Kubernetes](/kb/kubernetes/) во многом является реализацией этого паттерна для своих объектов.

От контроллера отличается тем, что контроллер — это функциональный объект. Чаще всего Оператор строится при помощи контроллеров (по крайней мере в Kuberenetes).

От IaC отличается тем, что оператор не только описывает инфраструктуру декларативно, но и реализует жизненный цикл создания-управления-уничтожения этой инфраструктурой.

К примеру, Terraform описывает инфраструктуру как код, но применяет это изменение человек.

Read more...

Reading time: 3 minutes

[Kubernetes](/kb/kubernetes/) – это runtime для для написания распределенных инфраструктурных приложений с использованием [Operator pattern](/kb/operator-pattern/), плюс оркестратор контейнеров.

Ключевые составляющие:

• Хранилище описаний объектов
• Модель нотификаций об изменениях как описаний, так и самих объектов
• Готовые простые инструменты для работы с хранилищем и событиями
• Мутноватый, но в целом неплохой stdlib для того, чтобы это было применимо к реальным вещам (запуск контейнеров, модель прав доступа и ограничений ресурсов и т.д.)
• Встроенный оркестратор контейнеров, за счет которого появляется возможность через эти механизмы достраивать самого себя

Иными словами, это state-machine интегрированная с оркестратором. За счет этого у него появляются свойства, которые по-отдельности отсутствуют как у оркестраторов, так и у state-machine.

Read more...

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...