Программы становятся важнее железа
Прочитав новость про сокращения штата в компании Cisco, я решил созвониться со своим хорошим знакомым, который уже не один год трудится на благо этого производителя сетевого оборудования. Знакомый подтвердил, что действительно собираются уволить часть сотрудников. Правда, он озвучил более скромную цифру, нежели та, которая фигурировала в статье одного российского интернет издания. Это далеко не первое сокращение. И как это было в прошлые годы основная причина — переориентация компании на разработку программного обеспечения. Сам же он перешёл в другой отдел, где занимается теперь поддержкой облачных продуктов.
На новом месте работы лучшим другом моего знакомого, как и многих других сетевых инженеров, стал питон. Не тот, который ползает, а тот который язык программирования. Python востребован для всякого рода проектов по улучшению внутренних систем, процедур и автоматизации в компании. Вообще данный язык программирования стал достаточно часто фигурировать в различных документах, презентациях и решениях вендора. Например, в коммутаторах Nexus появилась поддержка этого языка программирования. В целом дать возможность пользователям самим создавать необходимую логику поведения сетевого оборудования является правильной. Такими темпами скоро на курсах Cisco нам предстоит писать различные программы. И вместо show run будем выводить Hello world.
Перекинувшись парой слов об основных трендах, оказалось, что все поголовно заняты мыслями о нейронных сетях, Big Data, машинном обучении и других заоблачных технологиях. Это, наверное, и правильно. Ведь коммутаторы, маршрутизаторы, точки доступа сделать революционней, сложно. Но пока есть стойкое ощущение, что эти заоблачные решения чуточку не про нас. Во всяком случае, на данный момент. Хотя в плане той же безопасности, Cisco уже предлагает облачные решения в разрезе безопасности, опирающиеся на реализации подобные искусственному интеллекту.
Производство программных продуктов становятся более интересным для бизнеса нежели аппаратных решений. Во-первых, не секрет, что продажи железа потихоньку падают. Тут сказываются и облака, переход в которые приводит к тому, что собственная инфраструктура компании, переходящей в облака, становится беднее. И серьёзная конкуренция, которая никуда не уходит, а только усиливается, подпитываемая постоянным выходом на рынок новых компаний. А вместе с тем, что железо становится относительно стандартным (иногда мне кажется, что многие продукты различных производителей производятся на одном и том же заводе Foxconn), конкуренция только растёт.
Во-вторых, в плане финансов производство ПО кажется более выгодным, нежели железа. Не нужно решать проблемы с постройкой заводов и их обслуживанием, остатками на складах, комплектующими, бракованным оборудованием и пр. Продавать лицензии более приятное и маржинальное занятие. Ведь фактически в этом случае продаётся практически воздух. Правда, если этот воздух постоянно подглючивает, обслуживать его становится затратно.
Если мы говорим про продукты, традиционно являющиеся программным обеспечением, более глубокая переориентация на них не вызывает каких-то вопросов. То же самое можно сказать и про программно-определяемые сети (SDN). Данная концепция открывает огромные просторы для создания новых программных решений, тесно связанных с сетевым оборудованием. Область применения SDN огромна. Начиная от автоматизации рутинных процессов настройки сетевого оборудования. И заканчивая управлением всеми элементами ИТ-инфраструктуры с целью автоматизации различных процессов и получением совершенно новых сервисов.
Но как быть с коммутаторами, маршрутизаторами и прочими устройствами, которые мы привыкли видеть в железном исполнении? Тут выходит на первый план технология виртуализации. Рецепт относительно прост: виртуализируем сетевые сервисы и уходим от железной части. Если мы посмотрим на Cisco, мы заметим, что вендор уже достаточно давно идёт по этому пути. Происходит планомерный переход от схемы аплайнсов к схеме вирутальная машина на чём-нибудь. Конечно, для Cisco идеально, если это будет сервер UCS. Но если и не он, то вендор, как мне кажется, сильно не обидится.
На данный момент в продуктовой линейке Cisco мы видим, что многие решения предлагаются в виде виртуальных реализаций. Современные процессоры вкупе с поддержкой оптимизированной обработки сетевого трафика позволяют реализовать многие решения, не прибегая к использованию специализированного железа (ASIC«ов, сетевых процессоров и пр.). Об этом частично мы упоминали в блоге компании CBS про control и data plane в сетевом оборудовании.
Сейчас в виде виртуального решения мы можем получить маршрутизатор (например, Cisco ISRv), межсетевой экран (например, Cisco ASAv), контроллер беспроводной сети (например, Cisco vWLC) и прочие решения. Подобные решения предлагают и другие игроки рынка: Juniper, Huawei и пр. А так как в большинстве случаев на входе мы имеем Ethernet, все эти решения можно запускать на базе обычного сервера.
Всё это объединяется под зонтиком архитектуры Network Functions Virtualization (NFV). Стоит отметить, что виртуализация сервисов позволяет существенно продвинуться как в сторону облаков, так и SDN. Автоматическое развёртывание сервисов здесь и сейчас представляется более простой задачей, когда эти сервисы виртуализированы. Поэтому для ЦОДов решения NFV являются крайне интересными. Но и энтерпрайз потихоньку подтягивается. К чему-то мы уже в виртуальном исполнении привыкли. К чему-то ещё нет. Например, маршрутизатор или межсетевой экран в своём офисе мы всё-таки хотим видеть в виде отдельной коробки. Так кажется и надёжнее, и безопаснее. Но рынок нас двигает дальше, предлагая полностью виртуализированные решения для офиса. Например, Cisco дополнив NFV решения средствами оркестровки, мониторинга и аппаратными ресурсами (тут от собственно железа отвязываться вендор не хочет), предлагает архитектуру Enterprise NFV. Основными её составляющими являются:
- решение по оркестровке Enterprise Service Automation (ESA) на базе APIC-EM (контроллер SDN) и мониторингу Prime Infrastructure;
- различные NFV решения;
- программное обеспечение, на базе которого запускаются все сервисы: гипервизор на базе Linux с дополнительными средствами мониторинга, коммутации и пр.;
- аппаратные ресурсы: сервер UCS или UCS-E.
Enterprise NFV должен позволить уменьшить время внедрения различных сервисов в офисе компании, сделав процесс максимально автоматизированным. Где-то это я уже слышал. На мой взгляд такой подход кажется не слишком жизненным. Хотя время покажет. Как бы там ни было, но вектор движения задан.
С большинством сетевых устройств всё понятно. А как же привычные железные коммутаторы? С ними сложнее. Всё-таки патч-корды нужно куда-то подключать, и явно сервер для этого не очень годится. Но здесь на рынке есть продукты, позволяющие отделить программную реализацию от аппаратной. Это так называемые bare metal коммутаторы. Такой коммутатор идёт без операционной системы, которую пользователь выбирает и устанавливает самостоятельно. Такие решения есть у HPE, Edgecore, Dell и пр.
Таким образом, в наше время можно спокойно сконцентрироваться на разработке программных решений, существенно не потеряв присутствие в различных сегментах рынка. Безусловно производство специализированных железных решений, где программная часть практически не отделима от аппаратной, продолжится до тех пор, пока рынок будет в этом заинтересован. Это могучие шкафы и шкафчики для обработки огромного количества трафика. И, например, беспроводные точки доступа. Хотя нет, с точками доступа вопрос интересный. Если взглянуть на аппаратную часть этих устройств, можно увидеть, что многие из них строятся на чипсете Broadcom. По большому счёту меняется только ПО и корпус устройства.
Таким образом прослеживается тенденция, что многие решения можно предлагать рынку в отрыве от железной составляющей. Мне, как инженеру, такая возможность нравится, так как позволяет тестировать практически любые решения, при этом не покупая дорогостоящее оборудование.
