Блог им. SPUПочему рядовые компании-разработчики не любят использовать Open Source.


После одного случая, о котором я расскажу ниже, у меня возник вопрос: каким образом можно повысить интерес небольших и средних компаний, занимающихся разработкой софта, к Open Source проектам? Под «интересом» я понимаю хотя бы использование продуктов Open Source в собственных разработках компаний, пусть даже в первозданном виде без модификаций.
Разумеется, гиганты вроде Google могут позволить себе доработку/разработку Open Source проектов для своих нужд, а что делать обычным компаниям?
Начну, собственно, с самой истории, которую постараюсь изложить максимально абстрактно, т.к. подробности истории являются коммерческой тайной и разглашать ее я не могу. В любом случае, думаю, что многие сталкивались с похожими ситуациями.

Итак:

1. Имеется небольшая группа достаточно квалифицированных программистов;
2. Имеется задача, которая очень хорошо знакома этим самым программистам, но требуется реализовать ее средствами, совершенно отличными от использовавшихся ранее (переход на кроссплатформенность, независимость от используемой СУБД и т.д.);
3. Стоит требование максимального удешевления конечной стоимости продукта для потребителя.

Естественно, решения о использовании тех или иных инструментов принимает начальство. Исходя из пункта 3, начальство сразу выбирает GNU/Linux или свободный *nix, Java с разными примочками (GlassFish и прочее) и открытую СУБД, т.е. клиент компании в идеале должен будет оплатить только стоимость серверов и самого разработанного софта.

Заказали сервера под разработки и тестирование проекта, начали выбирать ОС…

Тут вылезли первые грабли: компания не хочет сама отвечать за работу ОС (что потребовалось бы для большинства GNU/Linux и *nix), поэтому выбор сузился до RedHat и AltLinux, которые имеют коммерческую поддержку и гарантии. Для бизнеса решение весьма логичное, т.к. зачем иметь лишний геморрой, если можно заплатить немного денег (читай, содрать их с клиента) и свалить большинство проблем на третьих лиц.
В итоге с RedHat решили не связываться (из-за бОльшей удаленности) и остановились на отечественном производителе… о чем многие (кроме начальства) несколько пожалели, т.к. AltLinux на сервера устанавливался ужасно криво.

Разобрались с ОС, развернули кластер GlassFish, задумались о выборе СУБД…

Задача требовала хранение и обработки больших объемов данных, поэтому от MySQL решили отказаться сразу. В итоге, естественно, остановили свой выбор на PostgreSQL. Не знаю почему, но в данном случае начальство почему-то не озаботилось наличием коммерческой поддержки СУБД. В любом случае система должна была работать, как минимум, еще с MS SQL и, желательно, Oracle, т.е. имелось в виду, что у клиента могла быть уже куплена какая-то коммерческая СУБД и ему нет смысла разворачивать и поддерживать еще что-то.

Началась разработка… по началу все шло хорошо: на Java понаделали веб-сервисов и прочих веселых штук, предусмотрели независимость от СУБД. Вскоре последовал этап тестирования первых наработок…

То, что при проектировании казалось гибкостью и масштабируемостью превратилось в тормоза, но главное заключалось в том, что PostgreSQL начинал жутко тупить и даже падать, когда количество строк в таблице начинало превышать несколько миллионов (а требовались миллиарды), хотя по первоначальному замыслу от СУБД ничего сверхъестественного не требовалось: хранение данных, обеспечение их целостности и не очень сложные выборки, т.е. хватило бы и функционала MySQL 4.x. Однако PostgreSQL тупил даже на таблицах, в которые только писали и никаких выборок не делали вообще.

Дальнейшие приключения я опущу, но в итоге была выкинута PostgreSQL и заменена на MS SQL, был выкинут GlassFish и все веб-сервисы… от системы остались только несколько программ на Java, а вся логика была перенесена внутрь БД. Причем после такой переработки для полноценного функционирования системы хватает одной-двух средненьких машинки без всякого кластера. Зато стоить они будут вместе с серверной виндой и MS SQL ой сколько…

==========================================================

После этой «поучительной» :) истории возникает вопрос: что же дает Open Source для коммерческих разработок? В описанном выше случае дал только убытки.

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

В итоге получается, что развитие Open Source &mdash это не для всех и каждого, а только для одиночек специалистов/любителей и гигантов «софтостроения». Остальным же «намекают», что лучше использовать коммерческие решения, которым Open Source вроде как пытается составить конкуренцию. Заколдованный круг какой-то…

А что думают по этому поводу представители Open Source? Как выходить из данной ситуации?

P.S. Не знаю, в какой блог определить эту заметку, поэтому пока оставляю в персональном.
  • +11
  • SPU
  • 06 июня 2009, 20:03

Комментарии (11)

хм, а вы не задумывались, что возможно ошибки были в проектировании? не знание продуктов, переоценка их возможностей, неправильный дизайн?
Я с этим и не спорю.
Ошибки 100% были. Я изначально предлагал совершенно другую архитектуру, которая была бы максимально масштабируема и более производительна, но, к сожалению, куда более сложна в реализации (хотя усложнять ее можно было бы и поэтапно). Но я не начальник, поэтому с моим мнением никто особо считаться не будет, тем более, что сроки установлены еще более высокими начальниками.
Что касается СУБД, то можно посмотреть сюда и убедиться, что заявляют они совсем не то, что есть на практике. Как наши «умельцы» не бились, ничего путного они от PostgreSql ни с какими настройками не получили.
Вы же не станете пилить дерево пилкой
для ногтей, только потому что она у вас есть и выглядит красивее чем
бензопила, которой у вас нет? То же самое и с программами. Ни одному
профессионалу не придёт в голову использовать для вэб-сервера Windows +
IIS. Скорее всего там будет какой-то UNIX и Apache. И самое интересное,
что стоить это будет во много раз дешевле, потому что эти программы
распространяться бесплатно.
В заметке речь совершенно о другом. Ни один профессионал не будет ставить клиенту (в рамках готового решения) сторонний софт непонятной надежности, если ему (профессионалу) самому придется отвечать за его работоспособность.
С теми же майкрософтовскими решениями все гораздо проще: клиент покупает лицензии, ему все устанавливается, настраивается, а дальше компания отвечает только за работу именно своего продукта, а не за все подряд. Дело не в том, что компания будет все валить на третьих лиц, она всегда готова помочь и разобраться, но в случае каких-то конкретных наездов часть проблем (если не все) можно спихнуть на производителя.
Не смогли настроить тот же PostgreSQL -> MS SQL + логика внутри базы.
Тут дело даже не в open source. Хотели решение независимое от БД -> получили решение исключительно на windows и зависимое от БД.

Тут возникает куча вопросов. А сколько стоит ваша разработка, те есть ли смысл его покупать, если в довесок придется купить windows server + ms sql. А если есть уже купленная Oracle да еще и на unix стоит? Что теперь покупать БД поскромнее?

В общем хотели сделать хорошо, но времени\знаний\опыта не хватило и получилось как обычно.
Перенести логику с MS SQL на Oracle не так уж трудно. В Oracle может даже и более оптимально получится. Если понадобится, то сделаем. Остальная обвязка написана на Java и, соответственно, ей все равно на чем работать.
Сама система стоит заметно дороже лицензий на винду и СУБД, но это в полноценной комплектации, а есть простенькие варианты, под которые хотели сделать «бюджетный» вариант с открытой СУБД, чтобы действительно не получалось, что собственно продаваемый софт стоит чуть ли не меньше, чем лицензии на необходимое для работы ПО.
Pg прекрасно управляется с таким объёмом данных как 2-3 миллиарда строк в таблице веб-сервер, проверено не раз что 10 миллионов записей для него это ерунда. Надо правильно строить запросы, таблицы и саму стуктуру базы оптимизировать… На ней поднимали очень серьзные биллинговые системы, катртографические сервисы и ни разу СУБД не падала…
Pg прекрасно управляется с таким объёмом данных как 2-3 миллиарда строк в таблице веб-сервер скорее упадет по-моему чем эта СУБД, проверено не раз что 10 миллионов записей для него это ерунда. Надо правильно строить запросы, таблицы и саму стуктуру базы оптимизировать… На ней поднимали очень серьзные биллинговые системы, катртографические сервисы и ни разу СУБД не падала…
Он не падает, он просто тупит. У нас не биллинг и не картография, которые могут подождать, когда вакуум отработает. У нас все должно работать практически в реальном времени. Запись идет со скоростью до нескольких тысяч строк в секунду и данные должны быть доступны для чтения сразу же.
Про структуру базы вообще смешно говорить. Пара таблиц без внешних ключей и с одним автоинкрементным полем + индекс по времени.
Из RDBMS только Oracle под Вашу задачу пойдёт, если в лоб.
Но на лицо проблемы архитектуры.
Плюс работа в реальном времени, которая накладывает требования на используемые инструменты: это Scala/Erlang/JavaRT и, если запросы не сложные — нафига Вам вообще RDBMS, с их нелёгкой, неотключаемой и не нужной Вам функциональностью? Может — файлов хватит?
С производительностью проблем нет, поэтому никакие специфические инструменты не нужны. Писать можно было бы и в файл, но данные из него используются кучей дополнительного софта, работающего удаленно, поэтому все равно пришлось бы создавать какой примитивный аналог СУБД над этим файлом.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.