Создание микросервисов

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

В итоге мы поняли, что, несмотря на имеющиеся недостатки в устройстве системы, для перехода в новое качество понадобилось внесение изменений в структуру организации. Сколько лет прошло, а этот процесс все еще не завершен!

Люди

Неважно, как это выглядит на первый взгляд, но проблема всегда в людях.

Джеральд Вайнберг (Gerry Weinberg). Второй закон консалтинга

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

Точно так же может стать обременительным принуждение команд разработчиков к повышению автономности. Люди, которые в прошлом перебрасывали свою работу кому-то еще через забор, привыкли выдвигать обвинения в чужой адрес и не могут почувствовать себя комфортно, когда несут за свою работу полную ответственность. Могут быть даже выработаны условия контракта, предписывающие вашим разработчикам ношение приборов оперативного оповещения о сбоях в работе систем, которые они поддерживают!

Хотя эта книга посвящена в основном решению технологических вопросов, людей нельзя сбрасывать со счетов, ведь речь идет о людях, которые создали то, чем вы пользуетесь сейчас, и создают все, что будет применяться в дальнейшем. Если придумывать, как все должно делаться, без учета мнения персонала или людских возможностей, то это, скорее всего, не приведет ни к чему хорошему.

Что касается данной темы, то у каждой организации имеется свой ход развития. Нужно понимать, насколько ваш персонал готов к изменениям. Не нужно их подталкивать сверх всякой меры! Вероятно, на короткий период времени у вас по-прежнему будет отдельная команда, занимающаяся поддержкой клиентов или разработкой, что даст разработчикам время на то, чтобы подстроиться под новые инструкции. Возможно, придется смириться с тем, что для выполнения всей этой работы потребуются люди различных наклонностей. При любом подходе нужно понимать, что в мире микросервисов следует четко определять зоны ответственности людей, а также понимать, почему именно такие зоны ответственности играют для вас важную роль. Это может помочь вам заметить возможные квалификационные пробелы и подумать о том, как их заполнить. Для многих людей это путешествие станет весьма непростым. Всегда нужно помнить о том, что без людей, с которыми вы работаете, любые изменения, которые захочется внести, с самого начала могут быть обречены на провал.

Резюме

Закон Конвея подчеркивает опасности попыток навязывания моделей систем, не соответствующих структуре организации. Он подводит нас к стремлению закрепить владение микросервисами за командами, расположенными в одном месте, которые, в свою очередь, выстраиваются вокруг соответствующих ограниченных контекстов, существующих в организации. Если такая двойная увязка отсутствует, мы получаем точки напряженности, рассмотренные в данной главе. Признавая связь между этими двумя понятиями, мы сможем гарантировать наличие смысла создаваемой нами системы для заказавшей ее организации.

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

11. Масштабирование микросервисов