Подписаться
Читать в телеграм
Плюсы и минусы ПО с открытым кодом?
Check-up Open Source — оцените свои ИТ перед внедрением?
Говоря об Инфраструктуре 3.0, мы постоянно упоминаем Open Source. Почему? Ведь и раньше большие и малые компании использовали огромное количество ПО с открытым исходным кодом (особенно в среде разработки): Linux, MySQL, Git, Python и множество других.
Вся разница в том, что Open Source сейчас попал в самое сердце Enterprise-компаний — в инфраструктуру, на которой работают Business, а иногда и Mission Critical приложения. На такой платформе работают автоматизированные банковские системы и системы дистанционного банковского обслуживания, АСУ ТП в промышленности, CRM и ERP в ритейле. Инфраструктура под этими приложениями всегда строилась на глубоко закрытых решениях от именитых вендоров — с поддержкой 24/7 и выделенным менеджером по обслуживанию.
Приведу несколько примеров. Многие компании сейчас применяют Zabbix в качестве системы мониторинга, PostgreSQL или Mongo DB как СУБД, Hadoop для хранения Big Data, Elasticsearch для хранения и обработки логов, Kubernetes как платформу для микросервисов, на которой работают те самые АБС и ДБО в банках.
Предпосылки внедрения Open Source
Как это произошло? Какие предпосылки привели к такому смещению фокуса с Enterprise на Open Source? Их несколько:
1. Цена
Кажется, что это главный фактор. Не надо платить — значит, уменьшатся расходы и бизнес станет более прибыльным. Но на самом деле для критичных приложений цена сбоя и простоя гораздо больше, чем стоимость софта. Разве что популярность PostgreSQL можно объяснить именно ценовым фактором. Очень уж дорог Oracle...
2. Скорость развертывания
T2M сейчас играет важнейшую роль в бизнесе. Успел сделать новый функционал раньше конкурента — переманил часть его клиентов и увеличил прибыль компании. Разработка сервисов на Open Source не требует долгих согласований бюджета, проведения конкурсов, переговоров с подрядчиками и вендором. Git clone — и софт уже готов к использованию. Не получилось — не беда, сделаем по-другому. Не надо объяснять начальству, почему пару миллионов на Oracle теперь надо куда-то деть, потому что идея «не пошла».
3. Скорость изменений
Вендорский enterpise-софт славится своей надежностью. Есть курсы, инженеры поддержки, документация, а весь функционал неоднократно протестирован и проверен. Именно за это с компаний и берут деньги. Но все это требует больших временных затрат. Пользователи проприетарного ПО вынуждены ждать внедрения новых функций довольно долго — от полугода до нескольких лет, в отличие от реализаций Open Source, где сообщество дописывает приложения очень быстро.
4. Возможность кастомизации
Бизнес многих компаний, особенно в банковской сфере и ритейле, требует постоянных изменений в функционале ИТ. За пару лет информационная система может значительно поменяться, вплоть до полной смены функционала. Многие компании даже выкупают проприетарное ПО и начинают самостоятельно его адаптировать, не дождавшись реализации функционала от вендора. С Open Source таких проблем нет: каждый может использовать его как хочет, имея штат программистов.
5. Новые технологии
Сейчас многие концепции и продукты перекочевали в Enterprise-компании из интернет-гигантов. Яркий пример тому — Kubernetes. Фактически на рынке просто нет достойного аналога такой технологии, все вендорские решения — это красивая обертка, внутри которой реализация Open Source, рожденная в Google. Аналогичная ситуация с Apaсhe Hadoop, Kafka, ZooKeeper и прочим ПО, чей функционал стал резко востребованным на рынке ИТ при полном отсутствии таких разработок у привычных нам вендоров.
Недостатки
Безусловно, Open Source не лишен недостатков. Больше того, их много, и на них обязательно нужно обратить внимание. Приведу самые главные:
1. Отсутствие поддержки
Используя ПО в критичных процессах бизнеса, очень важно не остаться один на один со своей проблемой. В классическом варианте всегда есть вендор с командой разработчиков, которые готовы решить проблему (пусть иногда и не сразу). А как быть с Open Source? Открыть issue на GitHub и ждать, что кто-нибудь захочет забесплатно решить именно вашу проблему из сотни других? Поэтому, используя Open Source, компания либо готова к простоям, либо держит свой штат разработчиков, либо платит за поддержку софта интегратору или вендору (такому как Red Hat, который специализируется на поддержке многих продуктов Open Source).
2. Недостаток персонала
Этот пункт неразрывно связан с первым. Open Source требует постоянного вмешательства в код, поддержки со стороны разработчиков и интеграции со смежными продуктами компании. Затраты на поиск и удержание таких сотрудников, а также их заработная плата должны учитываться в сравнении бюджетов на проприетарное и бесплатное ПО. Некоторые компании обращаются к услугам партнеров, способных решить эксплуатационные проблемы своими силами. К примеру, мы поддерживаем часть инфраструктуры одного из заказчиков, состоящую из кластеров на Kubernetes, с объектным S3-хранилищем, программной балансировкой на nginx, кластерами PostgreSQL, брокером сообщений Kafka, стеком ELK и еще несколькими продуктами Open Source. Инфраструктуру создавали с нуля, и на быстрое построение собственной эксплуатации у заказчика банально не хватило времени и кадров на рынке.
3. Слишком большой выбор
Странный пункт, не правда ли? 😃 Но это действительно проблема. На одну функцию (например, балансировку трафика) может приходиться до 50, а иногда и больше разных программных продуктов. «Завтра» часть из них перестанут поддерживать или перепрофилируют под другой функционал, а оставшаяся часть может вам не подходить по функционалу или окажется несовместимой с другими продуктами. Перед использованием ПО его обычно тестируют. Но провести тесты 3–4 приложений — это одно дело, а если их 50? Тут нужны сотрудники или партнеры, у которых достаточно экспертизы для сравнения продуктов и их правильного позиционирования. Такая услуга довольно популярна: в одном из топ-банков мы 3 месяца вместе писали техническую политику, которая позволила, с одной стороны, перейти на микросервисную платформу и автоматизировать конвейер доставки приложений, а с другой — ограничить зоопарк ПО, конфигураций и интеграций и позволить службе эксплуатации поддерживать достойный уровень сервиса, не распыляя сил.
4. Несовместимость с экосистемой смежных продуктов
Последний пункт по списку, но уж точно не по значимости. Уже давно есть гипервизоры Open Source. Почему до сих пор все покупают VMware? Потому что в процессе оказывается, что система резервного копирования с ним не интегрируется, мониторинг не мониторит, а купленный вчера новый сервер почему-то не подходит. Интеграция существующей экосистемы ИТ с ворохом продуктов Open Source — соответствующая часть затрат при их внедрении, и ее обязательно надо учитывать.
Например, PostgreSQL сам по себе не имеет многих enterprise-функций, которые очень нужны большим компаниям. Интеграция с СРК, кластер отказоустойчивости с автоматическим переключением, подробный внутренний мониторинг — все это мы реализуем в проектах на основе других решений Open Source. В итоге работающий Enterprise PostgreSQL — это минимум 4 тесно связанных продукта, которые внедрять и поддерживать нужно вместе, как единую систему.
Чек-лист
Для ответа на вопрос «О чем нужно подумать при внедрении решения Open Source?» я подготовил чек-лист, в котором собрал самые важные пункты:
- Сколько потребуется трудозатрат (каких сотрудников), денег и времени для внедрения и переноса в продуктив ПО с открытым кодом?
- Как я буду поддерживать это решение? (Увеличение штата сотрудников / привлечение интегратора / плата за поддержку вендору)
- Как я буду выполнять резервное копирование? (Стоимость интеграции в СРК)
- Как я буду мониторить состояние этого приложения? (Стоимость интеграции в систему мониторинга)
- Какие данные хранит приложение? Как выполнить требования регулятора и обеспечить информационную безопасность? (Возможно ли это вообще?)
- Как я обеспечу доступность приложения в случае сбоя или катастрофы? (Выполнение принятых в компании показателей RTO/RPO)
- Насколько жизнеспособно внедряемое ПО? (Насколько активное у него сообщество / часто ли выходят новые релизы?)
- Выдержит ли решение планируемую нагрузку в продуктиве на следующие 3–5 лет? (Функциональное тестирование без нагрузки не подойдет)
- Есть ли на рынке достаточное количество кадров с нужной компетенцией? (И сколько они стоят)
- Если текущая команда уйдет, как продолжить эксплуатацию и развитие продукта?
Ответив на эти вопросы, вы сможете подготовиться к правильному внедрению продуктов Open Source в компании.
Перспективы
Невозможно точно предсказать развитие такой динамичной области, как ИТ, но уже сейчас есть несколько очевидно устойчивых трендов. Во-первых, сверхдорогие монолитные вендорские продукты понемногу уступают место самописным микросервисным приложениям с широким использованием решений Open Source. Во-вторых, компании активно развивают собственный штат разработчиков и эксплуатации, переходя в инсорс, либо инвестируют в интеграцию ИТ с партнерами-интеграторами. В-третьих, продукты Open Source активно развиваются коммерческими компаниями, такими как Red Hat, Suse, Nginx Inc, Cloudera и пр., которые дорабатывают интеграцию с экосистемой существующих продуктов, обеспечивают поддержку и разработку новых функций. Со временем количество таких решений будет только расти. А в-четвертых, отчетливо видна тенденция сокращения рынка чистой поставки, уменьшения количества box-moving-компаний в ИТ-инфраструктуре. Сейчас существенно увеличивается роль партнеров-интеграторов с глубокой экспертизой, способных помочь компаниям с внедрением сложных, комплексных решений в их ИТ-инфраструктуру.
