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

06 Aug 2022

Об принятие инженерных решений

Reading time: 5 minutes

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

05 Jul 2022

Бирюзовый монолит

Reading time: 1 minutes

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

Но давайте вспомним про закон Конвея — “Организации проектируют системы, которые копируют структуру коммуникаций в этой организации”. Плоская структура без иерархии (либо развитой параллельной управляющей структуры в виде например HR или архитектурной функции) будет означать, что эта компания разрабатывает монолит. Свободное перемещение между командами и изменение их конфигурации и зон ответственности — то, что этот монолит будет сильносвязанным. Это действительно светлое будущее, или же мы движемся в будущее микросервисов?

04 Apr 2022

Вовлеченность и Agile

Reading time: 1 minutes

(из архива 2020)

Agile часто продают как способ повысить вовлеченность команды в процесс. На деле все наоборот — сначала вовлеченность, потом Agile.

Возможно многие “серебряные пули” не работают именно потому что пытаются при помощи их решить то, что они требуют.

К примеру, DevOps пытаются применять для того, чтобы с его помощью улучшить скорость поставки фич в продакшн, хотя на деле наоборот - улучшение такой скорости (помимо всего прочего) приводит к DevOps.

24 Mar 2022

Эволюция DevOps

Reading time: 3 minutes

15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию – через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействие команд на масштабе (фреймворк Team Topologies).

15 Dec 2021

Тестирование в IaC

Reading time: 1 minutes

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

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

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

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

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](/kb/kubernetes/) во многом является реализацией этого паттерна для своих объектов.

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

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

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

03 Aug 2021

Kubernetes

Reading time: 3 minutes

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

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

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

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

02 Aug 2021

Цитадель

Reading time: 1 minutes

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

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

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

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