Интересный открытый вопрос про современные сети: 'Почему, во м | Патчкорд
Интересный открытый вопрос про современные сети: "Почему, во многом, они работают по старинке?" У нас есть относительная гибкость внутри облака, мы этим можем управлять наравне со всем остальным в едином процессе CI/CD. Но сложности возникают когда надо пропустить трафик через реальный мир и тут, на мой взгляд, мы упираемся в технологии (это вторая опция предложенная автором).
В облаке мы имеем конечный ресурс который кратно превышает наши потребности, и этот ресурс мы можем делить между большим количеством задач, попутно решая их с некоторым перерасходом ресурсов, как плату за гибкость. Когда ресурс кончается мы можем добавить ещё мощностей - добавить серверов и устроить миграцию части сервисов. Это выглядит и обслуживается как единое целое, но в итоге живёт на одном сервере с большим запасом по мощности.
А что в сетях, за пределами внутриоблачных систем? У нас есть API, у нас есть верхнеуровневые гибкие архитектуры вроде SD-WAN и SD-LAN, но под этим всем лежат всем нам знакомые технологии и протоколы, в которых нет ничего такого, что нельзя было сделать руками, сложность только в объёмах абстракций чтобы создать 100500 VRF, виланов и маршрутов. По сути, всё что нам предлагают не новый подход, а вендорская оркестрация старого. И тут мы упираемся в то чего мы не имеем - кратного запаса ресурсов. Сколько угодно можно делить физическую магистраль добавляя оверлеев, но там где нужны 10 портов, нужно 10 портов и миграция не заключается в копировании настроек и данных, надо менять топологию. Мы видим запас по мощности в ДЦ с повсеместным CLOS, где мы также видим и наибольшую гибкость в сети как основу облаков и всех сетевых абстракций, пусть и не универсальную как того хочется автору. Но весь запас тут же улетучивается если вы не можете строить свои магистрали с кратным запасом между ДЦ, как раз отсюда и растут проблемы отсутствия универсального API между вендорами.
В конечном итоге, мы можем автоматизировать настройки правил доступа и маршрутизации, то что нам предлагают системы оркестрации или то что мы можем написать сами, которые добавляют новый сетевой сервис по запросу в CI/CD стиле, и этим непременно надо заниматься. Но, чем дальше мы находимся от среды с запасом ресурсов, тем больше задача поиска ресурсов и тонкой оптимизации под конкретное место будет превалировать перед универсальными и общеупотребимыми автоматическими подходами.
Ещё раз приведу пример который я иногда упоминал - автоматизация в интернет провайдерах была всегда, с самого первого моего рабочего дня и очень многие из моих коллег там умеют писать код. Такая автоматизация в первую очередь касалась настройки подключения нового абонента, потому что эта задача частая и лежит в области с большим запасом ресурсов - свободных портах на коммутаторах доступа. Поэтому, в большинстве случаев переместить абонента из одного места сети в другое, или подключение нового не составляло никаких проблем и не отвлекало никого внимания сетевого администратора, часто вообще не отвлекало ничьё внимание, достаточно было физически переместить патчкорд.
