Вопросы импортозамещения касаются нас часто, как интегратора и известной своим опытом команды.
Но часто вопросы ставятся перед нами некорректные, по причине недальновидности частичного замещения ПО.
Давайте рассмотрим два постулата:
- переезд всей рабочей ИТ-среды разом не может быть моментальным - не получиться здесь и сразу в день "П" отказаться.
например, от vmware, microsoft и veeam, просто переключившись на подготовленное кошерное ПО. Не получиться потому, что потребуется конвертация данных.
- частичное замещение учитывает ТЕКУЩИЕ ИТ решения, но не факт, что покрывает будущие изменения/замены текущих ИТ решений. Например, системы резервного копирования которую заменили с проприетарной на open source Bacula может быть подобрана и оправдана, и даже прекрасно настроена на резервное копирование баз данных среды виртуализации hyper-v. Но при переезде через полгода среды виртуализации на open source ovirt - внедрение и переезд на эту систему резервного копирования окажутся безполезными, и повторно придется решать задачу подбора софта под изменяющиеся инфраструктуры.
Часто, смотря на заменяемую часть в своей неизменной инфраструктуре, заказчики не учитывают, что решения которыми мы "заткнём дыры" и переедем в состоянии как есть с изменением лишь части ИТ-инфраструктуры, окажутся нерабочими при переезде остальной части ит инфраструктуры на новый свободный софт. И это ошибка планирования.
Нужно понимать и отдать должное вложенным колосальным средствам у проприетарного софта, который финансировался со всего мира и развивался десятилетия
- NetBackup, BE, Veeam, Acronis как примеры виртуализации
- Hyper-V, RHEL virtualization, VmWare как примеры виртуализации
- MS SQL, Oracle DB, IBM DB2 как примеры СУБД
- MS Windows, Debian base, RHEL... как примеры ОС
итд.
Все они при единичной замене одного элемента в разнородной ИТ среде могут быть заменены на OpenSource решения.
У OpenSource решений был задел на конкуренцию и работу с... ЭТИМИ ПРОПРИЕТАРНЫМИ СИСТЕМАМИ от больших вендоров: все лезли, чтобы стать частью коммерческого Enterprise сегмента. И никак не было интереса "точить" под другой open source, который редко когда использовался массово и в коммерции.
У OpenSource решений, за редким исключением, нету хорошей совместимости с другими OpenSource решениями, ввиду заточки друг друга под коммерческие продукты и существенно меньшего финансирования этих проектов в сравнении с коммерческими продуктами.
У всех - коммерческих и коммерческих ОТЕЧЕСТВЕННЫХ, opensource, - есть плагины, лицензии итд... Но сейчас время такое, что и при желании не все могут позволить купить и продлить себе лицензию, а некоторые лицензии при изменении составляющих системы с канонично сложенных оказываются безполезны. Поэтому когда систему резервного копирования хотят заменить на Open Source, нужно понимать, что при замене, например, системы резервного копирования, нужно учитывать не только и не сколько то, что сейчас объекты резервного копирования живут в vmware, а то, что
- Сейчас объекты будут жить в vmware
- А условно "завтра" будут смигрированы в oVirt или ProxMOX, где решение принятое ранее будет неуместно.
И это понимание (в данном примере, намерено введена провокационная ошибка в планировании) в корни меняет подход к постановке задачи и порядок рассмотрения аспектов в переезде своей ИТ-инфраструктуры.
Нельзя просто взять и сопоставить софт виртуализации по формальным признакам, это не будет работать в меняющейся инфраструктуре.
Требуется учитывать стек технологий который используется сейчас, будет меняться при модернизации инфраструктуры со временем (переходный процесс), стек технологий который уляжется в будущем (финал миграции с проприетарного ПО). Это дорожная карта и без неё нормальной работы не выйдет.
Я показал в этой заметке основную проблему в подходе, подробнее развитие ожидайте в будущих статьях.
За консультациями и помощью в переезде на open source и отечественное ПО с проприетарного обращайтесь к нам , а также за обучением Astra-linux и типовым решениям.
