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

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

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

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

Резюме

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

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

4 И как всем нам известно, похвастаться особой надежностью Windows Vista не могла!

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

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

Сбои могут происходить везде

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

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

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

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