Настоящий CTO: думай как технический директор - Алан Уильямсон

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

Микросервисы дают возможность внесения изменений в будущем и позволяют отложить технологические решения в какой-то области. Создав надежный, согласованный API, вы можете развивать реализацию сервиса со временем, по мере необходимости. Если, например, вам нужно сохранять и раздавать файлы для всей системы – вы можете создать микросервис для работы с файлами (File MS).

Этот File MS будет иметь два простых API: принимающий файл для сохранения и возвращающий файл. Первая версия реализации может просто хранить файл в локальном каталоге (с резервной копией). По мере развития сервиса она может хранить файл в сети SAN с большей емкостью. Если сервис становится очень востребован, можно использовать для его реализации облачный сервис, такой как Amazon S3.

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

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

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

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

Звучит знакомо? Да – именно так работают все современные облачные провайдеры. AWS – это всего лишь набор микросервисов, каждый из которых предоставляет свой функционал через API-интерфейсы, которые вы оплачиваете по мере использования.

Подавляющее большинство сервисов AWS возникло благодаря необходимости поддерживать основные сайты торговой площадки Amazon. Библиотека микросервисов AWS стала настолько мощной, что появилась возможность продавать функциональность внешним разработчикам – то есть нам с вами. Хотя ваша компания, может быть, и не станет следующей AWS, надежная микросервисная архитектура позволит вам стать ближе к клиентам и предоставлять им доступ к вашим API, чтобы они могли выстраивать свою собственную экосистему на основе предоставляемых вами услуг.

8.7. ПО с открытым исходным кодом

ПО с открытым исходным кодом (open source) – это ПО, которым члены сообщества разработчиков делятся друг с другом на безвозмездной основе и которое доступно каждому желающему, по крайней мере для просмотра, и, возможно, для использования в собственных проектах, с некоторыми ограничениями в зависимости от лицензии. Именно эти ограничения мы здесь и рассмотрим, поскольку многие компании не разбираются в их различиях и сталкиваются с юридическими трудностями при продаже или взаимодействии с отдельными клиентами или организациями.

ПО с открытым исходным кодом позволяет ускорить разработку любого программного проекта за счет использования готовых компонентов. Популярными примерами ПО с открытым исходным кодом являются операционные системы (яркий пример – Linux), серверы баз данных (MySQL, Postgres) и настольные приложения (Firefox, Open Office), а также программные библиотеки (JQuery, Gson). Учитывая степень распространения ПО с открытым исходным кодом, вы найдете в нем что-то полезное для себя на любом уровне.

8.7.1. Виды лицензий

Хотя у вас есть доступ к исходному коду этого ПО в интернете, это не значит, что у вас есть все права на его использование. Хотя я и могу сыграть Let It Be (на самом деле не могу) на фортепиано, это не значит, что мне можно продавать записи своего исполнения, не выплачивая гонорары правообладателям – Маккартни и Леннону. Так и с исходным кодом. Исходный код может быть защищен авторским правом, как и любое написанное слово, и обычно его использование ограничивается лицензией, которая определяет, что вы можете и что не можете с ним делать. Лицензии для исходного кода делятся на две большие категории:

• копилефт (Copyleft);

• разрешительные.

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

Разрешительные лицензии (например, BSD, MIT или Apache) не имеют таких ограничений, поскольку они разрешают включать ПО с открытым исходным кодом в коммерческое программное обеспечение или дорабатывать продукты с открытым исходным кодом, а также объявлять производный продукт своей частной собственностью и закрывать исходный код, что, естественно, гораздо предпочтительнее для бизнеса.

Некоторые разрешительные лицензии обязывают вас публично уведомлять об использовании библиотеки в конечном продукте. Подобные уведомления можно увидеть в разделе «О программе» на некоторых устройствах (например, для телефонов на Android перечислены все использованные библиотеки с открытым исходным кодом).

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

Хотя GPL является исключительно копилефт-лицензией, существует ее облегченная версия (LGPL). Этот тип лицензии не требует делать код общедоступным в случае, если его связывание с лицензируемым ПО динамическое, а не статическое. Это гораздо более удобно для бизнеса, чем GPL.

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

ПРИМЕЧАНИЕ

Стоит отметить еще один тип лицензии, называемый «общественное достояние» (public domain). Это самая свободная из существующих лицензий, она не устанавливает права собственности и авторские права и не содержит абсолютно никаких ограничений на использование. Она встречается не так часто, хотя примеры кода в книгах часто публикуются под этой лицензией.

8.7.2. Рекомендации по использованию

Старайтесь по возможности использовать ПО с открытым исходным кодом, особенно если вы работаете на Java, JavaScript или Python, поскольку на GitHub и SourceForge доступно множество ответов на вопросы и готовых утилит. Прежде чем вы дадите зеленый свет разработчикам, ознакомьтесь с рекомендациями о том, как лучше включать ПО с открытым исходным кодом в ваш продукт:

• Составьте список лицензий, которые может использовать команда, – скорее всего, это будут лицензии типа Apache/MIT/BSD.

• Библиотеки необходимо использовать целиком – не выделяйте отдельные фрагменты и не включайте их таким образом, как будто они были разработаны у вас. Воровство недопустимо.

• Создайте централизованный список всех внешних библиотек (например, общую электронную таблицу) со следующей информацией:

• имя библиотеки;

• URL веб-сайта;

• тип лицензии;

• компонент, в котором она используется.

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

8.7.3. Публикация ПО с открытым исходным