Команды-монолиты и команды-микросервисы
· 2 мин
В начале жизни любого продукта, проекта или компании практически по определению очень маленькая команда.
Она — как монолитная система, в которой всё завязано друг на друга, непонятно кто чем занимается и всё склеено каким-то спагетти-говнокодом. В этой команде очень много гибкости именно потому, что в ней нет жёстких интерфейсов и правил. Она просто работает органически.
С добавлением каждого нового человека затраты на коммуникацию возрастают нелинейно. В какой-то момент формируются подкоманды и всё это разрастается в “организацию”. Или империю.
Тогда появляется потребность в организационном рефакторинге. Коммуникация становится более структурированной, формируются стандартные интерфейсы. Хочешь что-то от другой команды — зафайль тикет и жди согласования, чтобы его приняли в работу. Начинают появляться очереди и все становится жутко медленным.
Со временем небольшой монолит трансформируется в распределённую систему с микро-сервисной архитектурой, которая связана между собой неким подобием API и имеет над собой некий master service в виде руководства.
В отличие от систем, минимальный scale unit, то есть единица масштабирования, в организационных структурах — это человек. Это очень дорогая единица и очень негибкая. Людей приходится нанимать целиком, даже когда нужна только треть. И иногда вместо человека в мешке оказывается кот.
И в такие моменты хочется убежать из этого бардака, засучить рукава и снова зарыться по уши в спагетти и говнокодить, заботясь только о продукте, а не процессах, которые кормят этого монстра, в которого неизбежно вырастают успешные стартапы.
Аминь.