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

11 Dec 2021

Различение между проектом и процессом

Reading time: 1 minutes

Из комментариев к обсуждению различия между проектом и процессом https://www.facebook.com/alex.turkhanov/posts/10227176872024711 : а) процесс не мобилизует ресурсы (проект мобилизует), он использует выделенные и зарезервированные под него; б) у процесса множественная причинность (у проекта токен-причинность), если мы сделаем вот такие действия над вот такими объектами, то из такой ситуации перейдем вот в такую; в) процесс есть инвариант , неизменная и неполная по составу и структуре основа для действий. Например, у Росатома есть процесс сооружения АЭС, события и действия, которые должны произойти, чтобы соорудить АЭС.

02 Nov 2021

4 DORA Metrics

Reading time: 3 minutes

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

04 Oct 2021

Operator Pattern

Reading time: 1 minutes

Паттерн Operator предназначен для создания инфраструктурных продуктов через декларативные описания. К примеру, сам Kubernetes во многом является реализацией этого паттерна для своих объектов. От контроллера отличается тем, что контроллер — это функциональный объект. Чаще всего Оператор строится при помощи контроллеров (по крайней мере в Kuberenetes). От IaC отличается тем, что оператор не только описывает инфраструктуру декларативно, но и реализует жизненный цикл создания-управления-уничтожения этой инфраструктурой. К примеру, Terraform описывает инфраструктуру как код, но применяет это изменение человек.

03 Aug 2021

Kubernetes

Reading time: 3 minutes

Kubernetes – это runtime для для написания распределенных инфраструктурных приложений с использованием Operator pattern, плюс оркестратор контейнеров. Ключевые составляющие: Хранилище описаний объектов Модель нотификаций об изменениях как описаний, так и самих объектов Готовые простые инструменты для работы с хранилищем и событиями Мутноватый, но в целом неплохой stdlib для того, чтобы это было применимо к реальным вещам (запуск контейнеров, модель прав доступа и ограничений ресурсов и т.д.) Встроенный оркестратор контейнеров, за счет которого появляется возможность через эти механизмы достраивать самого себя Иными словами, это state-machine интегрированная с оркестратором.

02 Aug 2021

Цитадель

Reading time: 1 minutes

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

02 Aug 2021

6 Причин Делать Микросервис

Reading time: 1 minutes

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

01 Aug 2021

API

Reading time: 1 minutes

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

01 Aug 2021

Открытые стандарты

Reading time: 1 minutes

Открытые стандарты — это способ формирования вендорами рынка, на котором они смогут строить свои решения и играть по понятным правилам. Через создание спецификации некоторого API вендоры оформляют и стабилизируют рынок, чтобы появилась возможность выпускать под него свои продукты. Примеры (возможно не все из них корректные): Open Container Initiative: https://opencontainers.org/ Open Application Model: https://oam.dev/ Open Service Broker API: https://www.openservicebrokerapi.org/ Open SLO: https://openslo.com/ Open Policy Agent: https://www.openpolicyagent.org/ Open API: https://www.openapis.org/ Open Service Mesh: https://openservicemesh.

01 Aug 2021

Open Container Initiative

Reading time: 1 minutes

Open Container Initiative — это рабочая группа, включающая в себя крупных вендоров, которая разрабатывает открытые стандарты для запуска контейнеров. В стандарт входят три спецификации: Спецификация образов контейнеров (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

01 Aug 2021

Индикаторы и метрики Devops

Reading time: 2 minutes

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