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

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

За последние пару лет технология в данной области сильно изменилась, и тема развертывания в мире микросервисов более глубоко будет рассмотрена в главе 6.

Решение организационных вопросов

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

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

Компонуемость

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

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

Оптимизация с целью последующей замены

Если вы работаете в организации среднего размера или крупной, то, скорее всего, знаете, что такое большая, противная, унаследованная от прошлых времен система, стоящая где-то в углу. Никто не хочет к ней даже прикасаться. Но ваша компания не может без нее работать, несмотря на то что она написана на каком-то странном варианте Фортрана и работает только на оборудовании, которое следовало бы списать лет 25 назад. Почему же никто эту систему не заменил? Вы знаете почему: это слишком объемная и рискованная работа.

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

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

А как насчет сервис-ориентированной архитектуры?