Создание открытых сетей в реальном мире. Часть 5. Несоответствие между сетями и областями применения программного обеспечения

В нашем предыдущем посте мы завершили подробное рассмотрение различных аспектов взаимодействия. В этом посте мы проанализируем различия в мышлении между традиционными сетевыми областями и областями разработки программного обеспечения, объясним, почему часто возникает внутренний диссонанс.

Справочная информация

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

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

Проблема

Существует множество аспектов диссонанса, которые могут возникнуть в открытом сетевом проекте из-за различных парадигм или мировоззрений. Ниже мы рассмотрим четыре основных аспекта проблемы:

• Конфликты парадигм проектирования и производства
• Возможность выполнения итераций
• Взаимодействие с конечными пользователями
• Ожидания от взаимодействия

Ожидания от разработки

В части 6 «Software Interlude» мы описали парадигмы разработки, которые традиционная сетевая инженерия в большей степени согласует с производственной моделью компании. работа, то есть процессы проектирования и производства в значительной степени упорядочены и разделены.С другой стороны, разработка программного обеспечения основана на другой парадигме, в которой проектирование и производство в значительной степени взаимосвязаны: не просто параллельны, но и переплетены в рамках одной команды и одних и тех же ресурсов.

Сети (в целом) проектируются с использованием дискретных компонентов и могут быть спроектированы и построены в соответствии с заранее определенными и предсказуемыми шагами, руководствуясь инженерными принципами. Сети в высшей степени механичны и математичны по своей природе и подчиняются четко установленному набору правил. Даже программные компоненты традиционного сетевого оборудования (конфигурация) подчиняются правилам, подтвержденным многолетними математическими исследованиями. Сетевые проекты могут быть проверены заранее с использованием тех же методов.

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

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

Ожидания от возможности итерации

Гибкость — ключевой аспект проектов по разработке программного обеспечения: она лежит в основе всего, что делает и думает разработчик программного обеспечения. Сети, по-видимому, ценят другие вещи: целостность, безопасность и т.д. Разница сводится к относительному размеру приращений, прототипов и/или MVP. Примечание: MVP (Minimum Viable Product — минимально жизнеспособный продукт) — это наименьший компонент, который может быть внедрен в производство и который обеспечивает как минимум 1 полезный вариант использования.

Небольшие улучшения функциональности, прототипы и MVP являются важными составляющими процесса разработки решения. Все они поддерживают принципы agile, если их проверять и адаптировать.

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

Ожидания от взаимодействия с конечными пользователями

Нередко сетевые проекты разрабатываются в соответствии с очень общими требованиями, а не с требованиями конкретного конечного пользователя варианты использования. Логическим следствием этого является то, что конечные пользователи не принимают активного участия в жизненном цикле разработки.

Программные проекты, и в частности проекты гибкого программного обеспечения, основаны на взаимодействии с конечными пользователями: предполагается, что конечные пользователи будут взаимодействовать с разработчиками на ежедневной основе. Это требует определенных навыков, которые хорошо развиты у инженеров-программистов (ну, в разной степени), но лишь немногие сетевые инженеры обладают таким опытом.

Ожидания от функциональной совместимости

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

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

Заключение

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

Как при планировании, так и при реализации проекта возникают проблемы, когда одна сторона хочет вложить время во что-то (например, в создание резервов рисков или валидационное тестирование), в чем другая сторона не видит необходимости (и, следовательно, считает неоправданным завышение оценок) или просто не ориентируется. к непониманию и недоговоренности в общении.

Как нам эффективно управлять этим? Мы относимся ко всему как к программному проекту.

Позвольте нам упростить вашу работу.
Узнайте, как управляемые сервисы Aptira могут работать для вас.

Узнайте здесь

После создания реальной открытой сети. Часть 5: Диссонанс между сетями и программными доменами впервые появилась на Aptira.

Другие новости:

---