Как DevOps и гибридная модель могут максимально долго использовать старые приложения

243

У вас есть приложение с надписями с предупреждающими знаками и множеством паутины, которые работают на устаревшем оборудовании, скрытом где-то в углу вашего центра обработки данных? Если вы находитесь на корпоративной ИТ-инфраструктуре, вероятность того, что так и есть очень большая. Эти старые платформы часто считаются проклятием для ИТ. Что еще более важно, устаревшие приложения могут представлять настоящую головную боль при попытке принятия людей, процессов и инструментов, необходимых для внедрения гибридной облачной модели.

Обеспечение самообслуживания, организованных рабочих процессов и конвейеров доставки - всего лишь несколько атрибутов для создания гибридного облака. Представьте, что вы пытаетесь применить эти идеи к устаревшим технологиям, где интерфейс требует использования архаичной консоли и программного обеспечения, похожего на то, что оно было написано для Windows 3.1. Это не забавно и часто сводит на нет все усилия по предоставлению услуг, которые могут быть использованы в локальном программном центре или в общедоступной облачной среде. Он также разбивает команду, ориентированную на работу в области культурной модели DevOps, потому что такие понятия, как инфраструктура, как код, конфигурация без состояния и совместная проверка кода, рушатся.

Для большинства людей, с которыми я общаюсь, унаследованные приложения остаются с небольшой командой скелетов, которая держит свет и работает на устаревшем аппарате.

Гибридность - это реальность для большинства инфраструктур, а не просто в публичном облаке или просто на физической стойке. Именно здесь познается важность DevOps и охват первого уровня API-интерфейса. Наличие подхода, основанного на API, не обязательно связано с наличием единого репозитория кода или одного приложения, которое выполняет «все». Речь идет об использовании API-интерфейсов в нескольких хранилищах и нескольких приложениях для соткания единой программной ткани, в которой все может взаимодействовать и интегрироваться независимо от того, является ли оно устаревшим или облачным.

Путь к прекращению хаоса, вызванный сложностью с гибридностью, - это прогрессивное политическое государство с надлежащей реализацией.

Вот четыре совета о том, как интегрировать свою устаревшую команду с командой DevOps для создания высокофункциональной гибридной модели облака:

Ищите инструменты, которые хорошо сочетаются с другими

Устаревшие приложения не обязательно должны быть якорем, удерживающим вас от принятия стратегии DevOps. Найдите решения, которые обрабатывают устаревшие приложения, современные приложения и облачные приложения, как если бы они были первоклассными гражданами. Унаследованные приложения обычно работают на старых ОС, в том числе на некоторых, которые больше не поддерживаются. В конце концов эта конфигурация становится все более хрупкой, требующей ручного ухода и питания. Принятие стратегии автоматизации может снизить риск, связанный со сборкой, тестированием, развертыванием, восстановлением и мониторингом.

Стремитесь к простоте - не создавайте силосы

Убедитесь, что рабочие процессы, которые предоставляют услуги, применимы к подавляющему большинству случаев использования. Исторически сложилось не так много стимулов для создания механизмов, которые распределяются между предприятиями. Системное мышление говорит о наличии зависимостей, но если вы только улучшаете одно приложение в кластере, выгоду получит не весь кластер. Весь успешный прогресс необходимо решить для всего кластера. Использование API RESTful - это превращение таблиц, позволяющих использовать один набор инструментов для многих приложений, платформ и сервисов. Совместное использование данных в организации; использовать API для оптимизации взаимодействия команды с устаревшими рабочими нагрузками путем извлечения данных из старой архитектуры.

Придумать менталитет одной команды

Не формируйте несколько команд или рядов команд. Если принято решение принять DevOps, то оно должно быть охвачено всей организацией. Как говорится в старой поговорке: «Нет никаких унаследованных систем, просто унаследованное мышление». DevOps не касается разработчиков и операционных сотрудников, скорее, речь идет о двух отдельных силосах, которые становятся одной командой. Сосредоточьтесь на улучшении коммуникации и выделите время для обучения.

Избегайте решений, специфичных для конкретной инфраструктуры

Абстрактное хранение и вычисление; вместо этого работают на уровне приложений и как предоставлять услуги для этих приложений. Устаревшие приложения часто тесно связаны с базовым оборудованием, что делает его сложным и рискованным для управления любым компонентом приложения по отдельности. Это означает, что техническое обслуживание и модернизация невероятно трудоемки, сложны и даже дороги. Принятие инфраструктуры как кода, будь то в физическом сервере или в облаке, дает командам разрешения и инфраструктуру предоставления инструментария по требованию. Как вы можете себе представить, не все устаревшие приложения могут быть легко перенесены в этот тип инфраструктуры, но многие могут.

Использование автоматизации увеличивает гибкость организации за счет сокращения взаимодействия между людьми и организации зависимостей между организациями. Самообслуживание потребления инфраструктуры дополнительно устраняет силосы. DevOps несовместим с устаревшими приложениями, но для этого требуется, чтобы организация оценила, что на самом деле означает эта реализация, и как начать эту трансформацию.

Никогда не бойтесь: вы все еще можете зависеть от устаревшего приложения и использовать DevOps. Это требует дополнительных дизайнерских соображений и немного креативности. Фундаментальным элементом является последовательное и эффективное применение этих принципов в контексте всех приложений, как старых, так и современных.

К списку публикаций