Сложность выбора
Как профессионалы в области программного обеспечения или просто энтузиасты, мы частенько поражаемся тем огромным выбором, который появляется перед нами, когда речь заходит о технологических компонентах. Взять те же менеджеры очереди сообщений в Kernel… Вы можете выбрать из Kafka, RabbitMQ, ActiveMQ, HornetQ и т. д. Или использовать управляемый сервис от одного из крупных поставщиков облачных услуг. Со всеми этими опциями и вариантами, как нам узнать, какие из них лучше всего подходят для наших конкретных целей?
Это тема, которая зудела у меня в голове довольно долгое время. Это также тема, с которой я смог поэкспериментировать и благодаря которой смог усовершенствовать свое мышление в сфере профессиональной карьеры разработчика. Я даже рассматривал ее в разговоре о том, как сделать правильный выбор для вашего текущего проекта, не жертвуя своей мечтой стать следующим Google.
Так что в этой статье я приведу важные критерии, которые следует учитывать при оценке компонентов программного обеспечения с открытым исходным кодом. После того, как я расскажу об открытом исходном коде, я добавлю еще пару моментов, в частности о том, что означает платить кому-то еще за сторонние сервисы.
Критерии оценки компонентов с открытым исходным кодом
1. Возраст и зрелость проекта
Насколько обоснован проект, который вы рассматриваете? Он все еще в бета-версии (или альфа-версии), десятилетней давности и готовится к выпуску третьей основной версии (Hadoop!) Или где-то посередине?
Вес, который вы должны придать этому критерию, зависит от того, насколько важную роль этот проект будет играть в вашей архитектуре, и насколько много кода задействовано. Например, я был бы крайне нерешителен, если бы кто-то предложил совершенно новую технологию баз данных для основного пользовательского хранилища данных. Если библиотека JavaScript отображает карусель изображений в варианте A/B-тестирования одной страницы, возможно, стоит поэкспериментировать с чем-то более новым.
2. Техническое обслуживание
Текущая концепция технического обслуживания практически неразрывно связана со зрелостью проекта. Зачем иметь дело с тем (что, как вы знаете) не будет иметь надежных и постоянных обновлений в будущем?
В большинстве случаев вам нужен проект с открытым исходным кодом, который вышел за пределы первоначальной компании или отдельного человека, который первым его разработал и заручился поддержкой более широкого сообщества. Достаточно крупные проекты в конечном итоге разовьют свои собственные фонды, чтобы поддержать их (например, Django Software Foundation). Но если это не так, ищите поддержку таких групп, как Apache, Linux Foundation или Software Freedom Conservancy.
3. Скорость выпуска и стабильность
Что касается вопроса поддержки, подумайте, как быстро развивается проект. Как часто бывают релизы? Есть ли регулярная каденция? Вилка на внутреннем сервере пакетов в течение нескольких месяцев в ожидании интеграции с исправлениями ошибок и выпуска официального релиза может привести к большим накладным расходам.
Когда релизы происходят, легко ли сказать, что изменилось с их введением? Использует ли проект семантическое управление версиями или подобный механизм, чтобы указать, присутствуют ли критические изменения? Доступны ли ветки долгосрочной поддержки (LTS), которые получают исправления безопасности и стабильности, о которых сообщалось ранее, из основных выпусков разработки?
4. Безопасность
Как минимум, найдите в базе данных Common Vulnerabilities and Exposures (CVE) проекты, которые вы рассматриваете. Вопросы для обсуждения: сколько уязвимостей было зарегистрировано? Были ли они решены, и сколько времени это заняло? Насколько сложно будет реализовать обходные пути в ожидании исправлений? Когда эти патчи появятся, насколько разрушительным будет их применение (например, загрузка нового комплекта ресурсов в CDN или перезагрузка всего уровня базы данных)?
Если, как и многие из нас в наши дни, вы работаете над веб-сервисами, обязательно ознакомьтесь с атаками и мерами по снижению риска, задокументированными в проекте безопасности Open Web Application Security, и поймите, как внедрение нового кода или систем в вашу среду меняет вашу модель угроз.
5. Стандарты и экосистема проекта
Придерживается ли этот проект общеизвестных стандартов для своего концептуального пространства, если они существуют? Вам и вашей команде будет проще интегрировать новый бэкэнд поиска, если он использует HTTPS и JSON вместо бинарного протокола на заказ.
Доступны ли библиотеки на выбранном вами языке реализации, или вы будете писать «склеивающий» код вручную? Имейте в виду, что если библиотеки для вашего языка не существует, это, безусловно, может стоить компромисса для проекта, который отвечает всем другим вашим требованиям. Это также отличный способ принять участие и внести свой вклад в сообщество!
Знают ли разработчики об этом проекте? Если вам понадобится помощь, будет ли легко найти людей, которые знают о выбранных вами технологиях и могут начать работу?
6. Простота и доступность
Обычно эта фраза характеризует, на что похожи ваши первые полчаса с программным обеспечением.
Насколько сложно его установить на свой ноутбук и запустить пример проекта? Есть ли у него требования к привередливости, которые затруднят работу в вашей среде непрерывной интеграции? Как насчет того, чтобы запустить его в производство – у него надежные и безопасные конфигурации по умолчанию, или вы собираетесь потратить недели на настройку переменных?
7. Документация
Хорошая документация, безусловно, является искусством, но для любого проекта существуют основные требования:
- Прежде всего, документация должна существовать;
- Она должна быть доступна для поиска и обнаружения;
- Документы должны обновляться, а устаревшие версии должны быть помечены как таковые.
8. Поддержка и подрядчики
Посмотрите, существует ли экосистема консалтинга и поддержки для основных компонентов любого большого проекта. Если вы небольшой магазин, который не может позволить себе администратора базы данных на полный рабочий день (DBA), заключение контракта с фирмой DBA может иметь огромное значение, когда ваша реляционная база данных умирает в 2 часа ночи, и вы обнаруживаете все свои резервные копии за последний месяц испорченными.
9. Лицензирование
Наконец, вы должны знать о лицензии (ях), под которой выпущен проект и совместимы ли они с вашей. В прошлом году Facebook повторно лицензировал React в ответ на озабоченность сообщества по поводу совместимости своих лицензий с другими проектами с открытым исходным кодом. Разработка для iOS или MacOS? Помните, что ПО, лицензированное по лицензии GPL, несовместимо с условиями Apple App Store, поэтому все, что вы используете, должно быть под другой лицензией.
Критерии оценки программного обеспечения как услуги
Многие из вышеперечисленных проблем программного обеспечения с открытым исходным кодом также подходят для использования в условиях централизованных или размещенных решений. Тем не менее, есть еще несколько моментов, о которых стоит подумать специально для таких случаев.
10. Цена компромиссов
Очевидным компонентом стоимости программного пакета на основе подписки является денежная единица. Анализ этого фактора – статья сама по себе, но самый важный элемент – найти стандартную единицу стоимости (например, стоимость за обработанный запрос) для сравнения предложений, которые могут иметь разные модели ценообразования.
Помимо немедленной прейскурантной цены, имеются и другие расходы:
- Сколько времени будет стоить вашей команде создать функциональные возможности внутри компании или собрать воедино существующие решения и научиться управлять ими?
- Что вы теряете из своего плана развития функционала, пока ваша команда занята работой над этим, и можете ли вы позволить себе не иметь его завтра?
11. Самопроизвольное исчезновение поставщика
Тут ситуация такая же, как и с банками: если ваш проект опирается на сторонние сервисы, как будет существовать ваш проект, если поставщик, предоставляющий какую-либо услугу, внезапно обанкротится?