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

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

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

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

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

Зонирование

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

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

В пределах отдельно взятого сервиса можно будет вполне смириться с тем, что команда, ответственная за данную зону, выберет другую технологию стека или хранения данных. Но здесь можно пострадать от проблем совершенно иного рода. Разрешая командам выбирать подходящий им инструментарий для работы, будьте готовы к тому, что при необходимости поддержки десяти различных технологий стека станет труднее нанимать людей на работу или переводить их из одной команды в другую. Аналогично, если каждая команда выберет собственное хранилище данных, вам может не хватить опыта для запуска любого из этих хранилищ в масштабе системы. К примеру, компания Netflix при выборе технологий хранения данных придерживается в основном стандарта Cassandra. Может, для всех случаев этот вариант и не самый подходящий, но в компании Netflix считают, что ценность накопленных за счет использования Cassandra инструментария и опыта важнее необходимости поддержки и эксплуатации в масштабе компании нескольких других платформ, которые могли бы лучше подойти для решения конкретных задач. Netflix — это весьма яркий пример, в котором масштаб, вероятно, является первостепенным фактором, но главное — ухватить саму идею.