Когда браузер запрашивает веб-страницу, для которой требуются сценарии JS для правильной работы, хост (центр обработки данных, узлы, кластеры веб-серверов, CDN), получающий этот запрос, будет обслуживать эти файлы JavaScript.
Умный владелец крупномасштабного веб-приложения в то время знает, что эти файлы JavaScript были запрошены, версию браузера, который их запросил, а также нагрузку и характер трафика, который, вероятно, может возникнуть в следующие несколько секунд с этими файлами JavaScript. . Потому что каждый из этих файлов внешнего интерфейса JavaScript имеет определенный шаблон трафика, который зависит от количества пользователей и функций внешнего интерфейса, которые они обеспечивают. Затем владелец крупномасштабного веб-приложения может предоставить эту информацию об ожидаемом трафике группе сетевых инженеров, управляющей программно-определяемой сетью, поддерживающей трафик этого веб-приложения. Затем они могут вводить эти данные об ожидаемом трафике в программно определяемый API управления сетью и автоматически реконфигурировать сеть для эффективной и бесплатной поддержки ожидаемого входящего и исходящего трафика.
Этот цикл запросов файлов JS, обмена исторической и прогнозной информацией о трафике и реконфигурации сети происходит за считанные секунды или микросекунды. Это цикл, который никогда не прекращает делать программно-определяемую сеть топологически гибкой, динамичной и предиктивной, потому что в каждый момент времени T команда сетевых инженеров будет знать топологию, конфигурацию и масштаб сети, которые потребуются в момент времени T+1.
Другой пример — когда вы разрабатываете и используете крупномасштабное веб-приложение, основанное на множестве микросервисов в качестве серверной части и многих компонентах, управляемых событиями пользовательского интерфейса, в качестве внешнего интерфейса. Как на внешнем, так и на внутреннем уровнях маршрутизация становится ключевым рычагом для того, чтобы ваше крупномасштабное приложение работало не только правильно, но и быстрее.
Что касается внешнего интерфейса, такие решения, как Redux и MobX, помогают фронтенд-инженерам решать вопросы взаимодействия компонентов внешнего интерфейса, используя механизмы DOM и JavaScript, такие как V8 или Chakra.
Что касается серверной части, то DevOps, инженеры по серверной части и инженеры по базам данных полагаются на такие решения, как Kubernetes, NoSQL, Node.js и другие, для фрагментации операционных функций внутреннего стека в небольших и независимых службах, которые можно разместить на одном виртуальном или физическом сервере, который имеет необходимый объем вычислительных ресурсов, памяти и хранилища для запуска службы. Чего не хватает крупномасштабным инженерам-программистам, разработчикам и менеджерам, так это важной части сетевой инфраструктуры, этой части, которая склеивает интерфейс и серверную часть, а также все микросервисы вместе, обеспечивая их бесперебойную и прозрачную связь через хорошо зарекомендовавшие себя или настраиваемые сетевые протоколы. .
Открытость и программируемость коммутаторов (пример использования программируемых коммутаторов здесь) и революция программно-определяемых сетей снова поставили сетевую инфраструктуру в основу ускорения и удешевления крупномасштабных веб-приложений для работы в масштабе. В настоящее время немыслимо и не рекомендуется проектировать и разрабатывать ваше внешнее решение, не заботясь о маршрутах, по которым сетевые пакеты будут проходить через ваш внешний интерфейс, чтобы добраться до вашего внутреннего устройства, и о том, как эти пакеты будут обрабатываться внешним интерфейсом вашей сетевой инфраструктуры, чтобы сделать их доступными. они обрабатываются быстрее микросервисов, которые должны их обрабатывать. Сетевая инженерия находится на стыке серверной и внешней инженерии, и теперь ее можно использовать для упрощения и ускорения масштабирования веб-приложений. Если вы хотите разрабатывать и эксплуатировать гипермасштабируемые веб-приложения, теперь вам следует уделять много внимания сетевому проектированию.
Эти два вышеприведенных сценария показывают, что барьер между инженером-программистом JavaScript и сетевым инженером преодолен для всех видов клиент-серверных приложений, и это более верно для крупномасштабных клиент-серверных приложений, для которых применение этого шаблона трафика и сети на основе прогнозирования может позволить значительно сэкономить на хостинге и ускорить базовое веб-приложение.
Даже если облачные решения, такие как Microsoft Azure и другие, делают сетевой стек прозрачным для интерфейсных и внутренних инженеров, реальность такова, что крупномасштабные веб-приложения должны разрабатываться с самого начала, когда инженеры-программисты и сетевые инженеры должны работать рука об руку.
Я надеюсь, что команда маркетинга также будет вовлечена на этом раннем этапе, потому что то, как вы будете умело разрабатывать свое гибкое крупномасштабное приложение, может быть рассказано с помощью интересных историй, которые команда маркетинга могла бы использовать, чтобы сделать его принятым техническими энтузиастами, такими как я. В этих историях рассказывается о том, как вы создали такое гибкое и крупномасштабное веб-приложение с такой динамичной и изменчивой программно-определяемой сетью, используя возможности командной кросс-функциональности.
Если вы являетесь инженером по интерфейсу или серверу, пора перестать игнорировать сетевое проектирование, потому что, если приложение, которое вы создаете или которое вы уже создали, будет широко распространено, вы наверняка столкнетесь с проблемами на уровне сетевого стека из-за масштаба трафика и вам придется перепроектировать и свой код, и инфраструктуру, как это сделал почти каждый стартап, такой как LinkedIn, Twitter, Facebook, когда у них появились миллионы пользователей.
Сетевые инженеры добились огромного прогресса, используя свои навыки (инженер-программист) и революцию в области виртуализации инфраструктуры и облачных вычислений (Kubernetes) для разработки программно-определяемых сетевых операционных систем. Пришло время нам, инженерам-программистам, помочь этим сетевым инженерам улучшить эти сетевые операционные системы (NOS), которые они разработали, и использовать их для создания наших веб-приложений, готовых к крупномасштабному проектированию, привлекая сетевых инженеров в самом начале наш проект веб-приложения. Потому что, как я уже говорил в своей прошлой статье, скорость фронтенда — это следующее дело, и то же самое верно и для бэкенда.
Пожалуйста, не забывайте о своей маркетинговой команде.
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Получите эксклюзивный доступ к возможностям написания и советам в нашем сообществе Discord.
