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

06 Nov 2024

Об платформенных инженеров

Reading time: 4 minutes

Некоторое время назад я озвучивал свое мнение о том, что такое “devops-инженер” (спойлер: определенный вид разработчика), однако на днях было указание на термин “платформенный инженер” (спасибо, Антон!).

Несмотря на то, что термин “platform engineer” постепенно распространяется, я не считаю его верным. Но вместе с тем он может оказаться полезным.

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

Read more...

11 May 2024

Об менеджерское и инженерное рассмотрение процесса разработки

Reading time: 4 minutes

Если продолжать обсуждать переход от документо-ориентированных (document-centric) процессов управления к программно-задаваемым (software-defined) (предыдущие посты: раз, два, три), легко упустить одно обстоятельство, которое одновременно наиболее ярко покажет совершившуюся революцию (и возможно окажется, что это революция консервативная).

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

Read more...

04 Apr 2024

Куда идет DevOps

Reading time: 6 minutes

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

Kubernetes

  • Будет ли он ещё популярен через 5-10 лет?
  • Какие технологии могут прийти ему на смену?
  • Какие вызовы ему придётся решать?

Kubernetes никуда не исчезнет, он стал таким же стандартом, каким стал Docker для упаковки и передачи приложений. Пока что это стандарт на описание и композицию приложений и инфраструктуры. Но он сейчас достаточно быстро становится базой для стандартов, например, для комплаенса или интеграции с телеметрией, одним словом при помощи Kubernetes API уже значимое время описывают объекты, которые не всегда связаны с инфраструктурой напрямую:

Read more...

15 Dec 2023

Об гиперпространственные тоннели между деятельностными мирами

Reading time: 3 minutes

Меня очень вдохновляет язык моделирования Archimate при всех его недостатках. Я не особенно задумывался почему — на нем удобно отображать связи и взаимодействие между людьми, процессами, приложениями, технологиями, но кажется этого недостаточно чтобы служить вдохновением. Сегодня я понял в чем дело: за счет его метамодели у нас в рассуждениях появляется интерфейс, связывающий между собой понятия из самых разных областей.

Метамодель Archimate очень простая, это формула “cубъект — выполняет действия — с объектом”, и в дополнение представление ее же во внешний мир в виде сервисов и интерфейсов.

Read more...

01 Oct 2023

Об разницу между Waterfall и Agile

Reading time: 2 minutes

(из неопубликованных архивов)

Некоторое время назад нашел простое и потрясающее объяснение того, когда нужно выбирать waterfall, когда scrum, а когда еще что-то другое.

Цитата (отсюда https://sebokwiki.org/wiki/System_Lifecycle_Models):

There are a large number of potential life cycle process models. They fall into three major categories:

  1. primarily pre-specified and sequential processes (e.g. the single-step waterfall model)

  2. primarily evolutionary and concurrent processes (e.g. lean development, the agile unified process, and various forms of the vee and spiral models)

Read more...

28 May 2023

Ситуационная инженерия метода

Reading time: 5 minutes

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

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

Read more...

19 Mar 2023

Об Модифицирующие Команды

Reading time: 3 minutes

Из всех тем, рассматриваемых в Team Topologies наиболее непонятная тема — это Enabling team, “модифицирующая” или “преобразующая” команда. Я буду использовать слово Модифицирующая Команда, потому что такой же перевод используется в Platen.

В самой книге про нее говорится многих общих слов типа:

Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance

или

The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area

Read more...

01 Feb 2023

Об формальные и неформальные нотации

Reading time: 1 minutes

Если сравнивать “просто стикеры” в миро и Archimate, то Archimate удобнее тем, что мы в нем получаем “встроенную” валидацию типов, которую в случае стикеров приходится выполнять более явно.

Скорее всего это применимо и для других формальных языков описаний (BPMN, UML и т.д.) в сравнении со “свободными” рассуждениями.

С другой стороны, если понимания типов у человека нет все нотации мгновенно становятся бессмысленными. А для коммуникации нужны именно типы, пространство понятий, а не нотация.

Read more...

06 Jan 2023

Платформенный подход и трансакционные издержки

Reading time: 3 minutes

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

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

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

Read more...

02 Jan 2023

5 бизнес-процессов в разработке

Reading time: 5 minutes

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

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

Read more...