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

Reading time: 3 minutes

В начале 20 века английский экономист Рональд Коуз изучал причину появления фирм на свободном рынке, и в своей статье Природа фирм он пришел к следующему:

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

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

Read more...

Reading time: 5 minutes

Меня периодически спрашивают каким образом строить инфраструктуру для небольших проектов, когда в команде еще нет компетенций админа/девопс-инженера ни у руководителя или программистов, ни в в виде выделенного человека. Что при этом выбрать — выделенные сервера, облако или Kubernetes? Я сейчас не буду делать какие-то технологические рекомендации, но опишу на что нужно обратить внимание организационно, чтобы можно было сделать такой выбор.

При планировании развертывания любого приложения для продакшна важно всегда в том или ином виде продумывать как минимум следующие 5 бизнес-процессов / Value stream:

Read more...

Reading time: 6 minutes

Существует мнение, что тяжеловесные подходы проектирования (ITIL, TOGAF, ГОСТ34 и т.д.) несовместимы с быстрыми частыми релизами и изменениями. А следовательно, зачем их изучать? Это верно только отчасти.

Во-первых вспомним всем известную методологическую максиму, которая упрощенно звучит как: “практика = дисциплина + технология”. И далее эта самая практика адаптируется под вполне конкретный контекст организации.

Дисциплина описывает мотивацию, взаимоотношения с окружающим миром, онтологию и принципы. К примеру, CI/CD предназначено для ускорения поставки разрабатываемого софта в продакшн, состоит из последовательной цепочки преобразований, которую проходит описание фичи до продакшна (в процессе превращаясь в код, затем в некий набор артефактов), подразумевает активное участие команды в процессах этой цепочки, и наконец можно говорить о принципах Shift Left и Fail Fast как примере более частных описаний.

Read more...

Reading time: 3 minutes

Периодически поднимается тема того, чем отличается deploy от release, и на это есть элегантный ответ в недавно вышедшей новой версии стандарта IT4IT от The Open Group.

• Deploy – это собственно инсталляция новой версии продукта на продакшн (сюда же включают и удаление старых версий с продакшна). В этот процесс входят и все стратегии деплоя – в том числе canary deploy, раскатка на какую-то небольшую часть аудитории, или деплой функциональности вообще прикрытой через feature flags и недоступной никому.

  Read more...

Reading time: 2 minutes

Кажется, спустя полтора года после прочтения книги Accelerate наконец удалось кратко и компактно сформулировать в чем проблема с отчетом State Of Devops.

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

1. DORA статистически показали, что использование CI/CD приводит (“предсказывает”) к сокращению Lead Time, увеличению частоты поставки и снижению количества ошибок при развертывании. На деле же это и есть основная функция CI/CD - он строится как раз для того, чтобы именно это и происходило. Если ваш процесс CI/CD не приводит к ускорению поставки он не выполняет свою основную функцию, и скорее всего вы что-то делаете не так, и это можно сказать без исследований. Ждем горячих заголовков “Доказано научно: передвигаться на велосипеде быстрее чем пешком”.

   Read more...

Reading time: 2 minutes

Недавно вышли новые роадмапы профессионального развития на https://roadmap.sh/ и они на мой взгляд очень хорошо помогают прояснить мой предыдущий пост про то, что подход Infrastructure as Code — это особая форма разработки. Я не уверен, что согласен с названиями роадмапов, но разделение на роадмапы мне кажется очень хорошо сделанным:

• Software Architect — список навыков указывают, что основные задачи это построение систем, состоящих из множества отдельно разрабатываемых компонентов (и интеграция этих компонентов между собой), коммуникация с разработчиками, другими архитекторами и руководством компании, и организация проекта. Одним словом, чтобы множество команд разработки и программные сервисы которые они разрабатывают интегрировались друг с другом и при этом решали бизнес-задачи. Нужны ли эти практики в подходе Infrastructure as Code? Не уверен, скорее всего если выходишь на такой уровень в организации тебе уже не нужен IaC, но вместе с тем практически все эти темы в той или иной мере затрагиваются если ты занимаешься методологией DevOps.
• Software Design and Architecture (напомню, что “design” переводится как “проектирование”) — список навыков указывает, что основные задачи это структурирование программного кода, разбиение на модули и интеграция между ними. Одним словом, все то, что нужно для того, чтобы код был не лапшой, а был поддерживаемым, тестируемым, изменяемым, надежным и т.п. Нужны ли эти практики в подходе Infrastructure as Code? Несомненно. Если размер инфраструктурного кода десятки тысяч строк, применение всех этих практик и концептов поможет справиться со сложностью и в относительно более декларативных языках — она в них с ростом кодовой базы растет медленнее чем в императивных, но все же растет. Отдельные принципы скорее всего неприменимым, но не столько неприменимы сами по себе, сколько по причине относительно более простой и относительно маленькой кодовой базы в случае инфраструктуры, и относительно стабильного пространства понятий которые мы при помощи IaC описываем.
• Backend Developer — здесь говорится об инструментах и концепциях применяемых собственно в процессе разработки. Что-то из этого если находимся в контексте инфраструктуры мы знаем и так, что-то становится применимо сразу же как-только мы начинаем заниматься SRE, а не только писать код. В целом кажется применимым не столько к IaC, сколько к SRE.

Напомню свой тезис, который прозвучал в начале: практика Infrastructure as Code является не чем иным как программированием в “особой” доменной области на “особом” языке. Примерно так же как современное фронтенд-программирование имеет довольно мало общего с тем программированием на языке Паскаль, которое мы изучали в школе. Основные отличия находятся в решаемой проблематике и в конкретных языках программирования, которые применяются для решения задач.

Read more...

Reading time: 2 minutes

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

В статье ¹ мимоходом отлично прояснен этот вопрос через определение того, что такое “инженерия”:

Ideally the construction design phase results first into an ontological model of the object system, i.e. a white-box model that is completely independent of its implementation. Gradually this ontological model is transformed into more detailed (and more implementation dependent) whitebox models, the last one being the implementation model. This process is called implementation design or just engineering. If the object system is a software application, then the implementation model would be the source code in some programming language. The act of implementing consists of assigning appropriate technological means to the implementation model, e.g. running the source code on an appropriate platform.

Read more...

Reading time: 3 minutes

Интересным, но не совсем понятным в современной парадигме разработки становится место аутсорсинга в любом виде.

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

Read more...

Reading time: 1 minutes

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

Компоненты, обеспечивающие практики жизненного цикла (т.е. песочницы для разработчиков, автотесты, системы сборки, пайплайны CI/CD, система логирования и т.д.) становятся настолько же важны как и сами компоненты приложения — они теперь проектируются, разрабатываются, тестируются, эксплуатируются точно так же. Для них самих прорабатывается обеспечение жизненого цикла и интегрируются инструменты его автоматизации. Этим в частности и отличается подход Infrastructure as Code от Infrastructure as Scripts. А именно, тем, что теперь инфракод (в т.ч. CI/CD, мониторинг и т.п.) это точно такой же программный компонент самого приложения как и, например, его web-фронтенд. Если же говорить про больший масштаб – инфра-компоненты будут точно такими же компонентами многокомпонентного приложения, примерно как “сервис нотификаций” или “сервис некоей бизнес-отчетности”.

Read more...

Reading time: 5 minutes

Read more...