20 апреля Oracle объявила о покупке Sun Microsystems за 7,4 млрд долларов. Месяцем раньше переговоры вела IBM и сорвались. Теперь под одной крышей оказываются Java, MySQL, Solaris, OpenOffice.org, NetBeans и линейка серверов SPARC. Для нас как для интегратора это не новость с биржевой ленты, а вопрос, который завтра зададут заказчики: «Мы строили систему на Java и MySQL – что с ней будет?» Отвечаем по делу, без паники и без рекламы перемен.

Java остаётся, но владелец сменился

Java – фундамент тысяч корпоративных систем, и Oracle купила Sun во многом ради неё. У Oracle уже есть огромный стек на Java: сервер приложений WebLogic, Fusion Middleware, инструменты разработки. Логика сделки в том, чтобы получить контроль над платформой, на которой эти продукты работают. Значит, Java будут развивать, а не закрывать – это её главный актив в сделке.

Практические риски лежат в другом. Во-первых, судьба GlassFish и NetBeans под вопросом: они пересекаются с WebLogic и JDeveloper, и Oracle вряд ли станет одинаково вкладываться в конкурирующие продукты. Если ваш проект завязан на эти инструменты, заложите в план риск смены технологического направления. Во-вторых, открытость платформы. Java живёт за счёт сообщества и процесса JCP – резкие движения нового владельца способны его расколоть. Пока заявления Oracle сдержанные, и мы исходим из того, что Java-код, написанный сегодня, проработает годы.

MySQL – главная зона неопределённости

Здесь интрига острее. Oracle – это в первую очередь СУБД, и MySQL прямо конкурирует с её основным бизнесом, включая бесплатную Oracle Express. Закрывать открытый проект Oracle не станет: MySQL распространяется под GPL, а форки появятся в тот же день, когда развитие застопорится. Но темп и приоритеты развития определять теперь будет компания, которой невыгодно, чтобы бесплатная СУБД отъедала продажи флагмана.

Что делать тем, кто уже на MySQL. Паниковать и срочно переписывать ничего не нужно. Трезво оцените, насколько проект завязан на специфику конкретной СУБД. Если приложение работает через стандартный SQL и абстрагированный слой доступа к данным, запас прочности у вас большой. Если в коде намертво зашиты диалектные особенности – это технический долг, который стоило бы разгрести независимо от сделки. На случай, когда заказчик решит уйти на PostgreSQL или коммерческую СУБД, такой переход разумнее вести как управляемую миграцию данных и приложений – со сверкой схем, переносом логики и проверкой целостности, а не «по живому» в проде.

Что это значит для госсектора и крупного бизнеса

Для государственных заказчиков сделка добавляет аргумент в давний разговор про снижение зависимости от одного вендора. Когда один владелец контролирует и язык, и популярную открытую СУБД, и операционную систему, концентрация рисков растёт. Разумный ответ – не метаться, а закладывать переносимость на этапе проектирования: стандартный SQL, чистые контракты между слоями, документированные схемы данных.

Та же логика касается всей инфраструктуры. Мы уже писали, как упорядочивание электронного документооборота и поиска снижает привязку к конкретной платформе, а архивное хранение в облаке S3 разводит данные и вычисления по разным поставщикам. Принцип один: данные и бизнес-логика принадлежат заказчику, а не вендору.

Вывод

Покупка Sun компанией Oracle – событие крупное, но не повод для авральных решений. Java продолжит жить, MySQL остаётся главной точкой неопределённости, а лучшая страховка от любых корпоративных сделок – архитектура, готовая к переносу. Те же выводы напрашивались ещё по итогам 2008 года: экономьте на лицензиях с умом, но не привязывайте себя к одному поставщику намертво. Кто заложил переносимость заранее – встретит любую новость с биржи спокойно.