Боль, которую испытывают операторы связи, в связи с возникновением тренда OTT - трудно описать. Нечеловеческая боль. Как так - двести без малого лет, со времен изобретения телеграфа (с 1837 года), телеком был и кузницей, и житницей, и здравницей всего, что передавалось по сетям. А тут - какие-то пацаны, не вложившись ни копейкой в инфраструктуру…
Действительно, сакральное "What hath God wrought" ("Вот что творит Бог"), переданное Сэмом Морзе из Балтимора в Вашингтон (примерно 60 км.), обошлось по тем временам в 30 тыс. долларов (на нынешние потребительские цены, это приблизительно 787 тыс. долларов). И никому в голову даже не приходило, что некто может не платить за проволоку, бумагу, знание телеграфистом азбуки и всего остального, что прилагается к инфраструктуре.
Но со времен отправки первой коммерческой телеграммы (в 1844 уже году) прошел 171 год и много изменилось. Прежде всего, человечество узнало неизмеримо больше о "науке передавать информацию на расстояние", неизмеримо увеличилась пропускная способность, эффективность. Мы научились более лучше строить инфраструктуру.
Однако по-прежнему испытываем дефицит пропускной способности, ибо информация, как выяснилось, мгновенно занимает всю доступную ей память и каналы передачи.
Бороться же с дефицитом можно двумя способами: а) постоянно расширяя каналы передачи данных и б) ограничивая собственно информационные потоки. Это совершенно нормальный, логически оправданный исторический путь.
С физическим расширением каналов худо-бедно все понятно. Там, правда, также несколько путей: например, больше кабеля. Или более быстрые среды передачи - от стальной проволоки (как в телеграфе Морзе) к оптическим системам со спектральным уплотнением.
Со вторым, ограничением инфопотоков, боролись чаще всего путями экономическими - посмотрите цены на спутниковую телефонную связь, и вы поймете, о чем я. Но возможны и некоторые технические ухищрения - например, сжатие трафика, более совершенные кодеки передачи мультимедийной информации, использование CDN и контент-кешей.
Но вот приходят новые времена. Интернет. Он меняет картину взаимоотношений между операторами и прочими участниками забега "достать денег из кармана потребителей". Например, упомянутый (я надеюсь, вы не к ночи это читаете?) Over-the-Top, которого "традиционные операторы" люто-бешено ненавидят, считая, что все эти месенджеры и нетфликсы отнимают долю в доходах. На самом деле, конечно, все не так. Это гораздо лучше меня объясняет камрад Прохожий в своем слайдкасте, но суть™ примерно такова:
Оператор должен заниматься передачей данных, а производитель информационного продукта - производить информационный продукт.
Пироги печет пирожник, сапоги тачает сапожник. Вот такая банальная истина, замеченная еще Иваном Андреевичем Крыловым в 1838 году (совпадение? не думаю).
Но перенесёмся из века XIX в наше время, когда интернет опутал всю Планету, и, кажется, что нет никакого дефицита в мощностях ПД. Но на самом деле - есть:
Это прогноз роста трафика (не мой - Cisco!) по различным категориям. Прогнозно, суммарный объем трафика в 2019 году будет порядка 51794 GBps (50 терабит в секунду). На минуточку представьте, что в 1997 году суммарный интернет-трафик составлял 100 GB в час, то есть сейчас в секунду передается больше информации. Разумно предполагать, что через пару-тройку лет, так или иначе, расширять магистрали придется всем. Опять.
Но можно пойти другим путем©: через более эффективную упаковку контента и оптимизацию маршрутизации трафика. Но погодите. Если речь идет об упаковке контента, то причем тут тогда Лужков телеком? Пусть контентщики и занимаются упаковкой, разрабатывают новые кодеки, например. Браузеры. Ставят на сети свои GGC|CDN или строят ЦОДы. Тачают свои сапоги, так?
Не так.
Дело в том, что телеком переживает те же самые процессы становления от натурального хозяйства к узкоспециализированным подотраслям, что и, например, электронная промышленность. Про нее уже давно написал уважаемый Алексей Павлюц (что-то я много на него ссылаюсь - Леша, ты почти классик!), и я не буду тут долго и нудно расписывать экономические теории: почитайте Анти-Дюринг, Адама Смита или хотя бы учебник по теории автоматического управления. Эффективность в специализации.
Суть изменений же заключается во все большей специализации телеком-компаний, и их расслоении на биллинг и расчеты | маркетинг и бренды | управление сетями | эксплуатация/строительство сетей доступа/магистралей | и еще сотни разных дел различной степени важности и сложности. И ОТТ, к слову, вполне себе вхож в эту экосистему на правах равноправного партнера.
Интересно, что ОТТ-сервисы сильно ближе к пользователям, ибо это витрина, физиономия, вывеска, и даже где-то киот, обращенный к пользователю. Причем, в особо запущенных случаях, потребитель вообще может не знать, кто этот человек, который протянул кабель в конкретную локацию, а информационный сервис точно знает. Вот, к примеру, самый популярный OTT-сервис "в там" - Netflix. Он настолько популярен, что вошел уже в народный фольклор в виде устоявшихся идиом, пословиц и поговорок. Самое популярное выражение на Urban Dictionary - "Netflix and Chill":
И все потому, что конечный потребитель не платит за крутой навороченный маршрутизатор или новейшую систему спектрального уплотнения. Потребитель платит за… а, собственно, за что потребитель платит?
Ответ: за то, чтоб работало.
В общем и целом, много умных слов, суть которых сводится к глобальному изменению ландшафта телекома, которое ждет нас в самом ближайшем будущем. А именно в том, что если разбить процесс оказания телеком-услуг на составляющие, то специализированные игроки, занимающиеся только одной из задач, становятся сильно эффективнее, чем внутреннее подразделение пусть бы и очень большого оператора.
Примеров в мировой, да и в российской бизнес-среде, более чем достаточно:
- Инфраструктурный аутсорсер Zayo, о котором уже есть развернутая статья на Наге, и его российский аналог (ну, ок, не полный аналог, но все же) - компания "Русские башни". Они просто строят и эксплуатируют инфраструктуру, которую сдают в аренду розничным операторам связи.
- Со стороны конечного спроса также отмечаются определенные сдвиги: при общем падении фиксированной телефонии - да-да, моя любимая тема за #RIP_PSTN, которая, несмотря на скепсис постоянных читателей Нага, оправдывается. По итогам 3Q2015 Мегачемпион отчитался о падении абонентской базы YoY аж на 10,2% по услуге Fixed-line subscriber в секторе B2C. Теперь абонентская база РТ в этой услуге составляет всего 19 миллионов абонентов. Я прогнозировал примерно 20 миллионов - ошибся в большую сторону. Так вот, а в секторе B2B фиксированной телефонии (VoIP, разумеется) все больше OTT-игроков, услуги которых выглядят все больше привлекательными, а выручка растет.
Есть мнение, что сепарация услуги "телекоммуникации" во множество разных в ближайшее время достигнет апогея. По меньшей мере, прогнозируется появление следующих рынков:
- Рынок магистрального (оптового) доступа был всегда, в силу капиталоемкости входа в рынок. Центральные игроки уже расставлены по местам. Остается только дождаться, когда у пытающихся войти в него новых действующих лиц включатся калькуляторы, а инвесторы наконец выучат термин IRR.
- Услуги "инфраструктура последней мили" - экономический смысл "не строить собственные сети доступа, а арендовать их у застройщика" имеется. Особенно в новостройках. Возможно, об этом нужно будет написать отдельно.
- Рынок услуг "аутсорсинг информационных систем" начнет формироваться в самое ближайшее время. Многие разработчики биллинговых систем уже находятся в позиции низкого старта. А всевозможным "облачным дата-центрам" по ночам снятся цветные сны, о том, как к ним приходят телекомы, скупая вычислительные мощности терабитами/петагерцами.
- Есть мнение, что и стойкоместа будут тоже скупаться гектарами, но вовсе не телекомами, а специализированными организациями из пункта выше - разделение труда и специализаций породит огромное количество новых профессий. Будут отдельные компании, которые строят и эксплуатируют ЦОДы, к которым придут эксплуатанты биллингов|CRM|OSS/BSS, продающие услуги, которые будут на корню скупать услуги разработчиков информационных систем.
- Существует ненулевая вероятность, что рынок "системной интеграции" умрет, раздробившись на тысячи мелких кусочков, каждый из которых будет покупать и продавать услуги собратьям по пищевой цепочке. Кто-то будет заниматься обслуживанием исключительно маршрутизаторов, кто-то возьмет на себя оркестровку узлов связи, кто-то - управлять миллионами пользовательских CPE.
- Рынок оборудования с равной долей вероятности рискует либо укрупниться до десятка вендоров, которые станут продавать не столько железки, сколько услуги. Либо развалиться на миллион мелких поставщиков, которые будут покупать платформы крупных вендоров и доводить их до узких потребностей конкретных заказчиков.
Но. Остается вопрос, как управлять всей этой сворой поставщиков так, чтоб не попасть в зависимость от прокрастинации разрабов в критичных точках, и как связать весь этот зоопарк в работающую как часы систему?
И вот на сцене появляется сабж нашего исследования - Software Define Network, сиречь, Программно-конфигурируемые сети. И здесь нужно сделать еще одно лирическое отступление, ибо понимания дефиниции SDN нет почти ни у кого в русскоязычной прессе - все трогают слона за разные части тела, не понимая, как в итоге будет выглядеть конечный продукт:
SDN - это не OpenFlow, не "централизация control plane", и даже не коммодитизация телеком-оборудования. Это все вместе, и еще кое-что. Но ни в коем случае SDN не является "механизмом" управления сети.
Правильнее всего рассматривать SDN, как framework-платформу, которая позволяет сетевым администраторам как динамически, так и автоматически контролировать большое количество сетевых устройств, услуг, топологий и маршрутизации. Контролировать трафик, и обработку пакетов (включая качество обслуживания - QoS). Выстраивать различные политики с использованием языков высокого уровня и API.
Управление же включает инициализацию, эксплуатацию, мониторинг, оптимизацию и управление FCAPS (Faults, Configuration, Accounting, Performance, and Security) в многопользовательской среде.
И логически-экономически главное в этом сонме задач - совместимость. И не столько оборудования, сколько информационных систем, оборудованием управляющих. И потенциально, это возможно на уровне Aplication Programm Interface, в простонародье именуемой API.
Просто представьте тот новый дивный мир, где любое оборудование будет совместимо с любыми информационными системами. Вы просто устанавливаете, скажем, новый коммутатор, любой, пусть бы и российского производства, подключаете патчкорд и электропитание, делаете несколько магических пассов, и… вуаля! Коммутатор имплементирован в общую информационную систему оператора. А может даже и двух. Или трех. Да сколько угодно! Управление же сводится к двум кликам мышки в веб-интерфейсе. Мониторинг FCAPS - там же. Причем, искусственный интеллект сам распределит наш коммутатор в общей системе, найдет ему достойное место в общей системе, и даже резерв, если есть такая необходимость.
Аналогично можно поступать и с новыми услугами, и ОТТ, и сервисами, и прочим нужным и полезным стаффом в программной и/или аппаратной реализации.
И хотелось бы еще обратить внимание: существует разница между OpenFlow и SDN. Эти два термина тесно связаны, но совершенно неэквивалентны. OpenFlow это протокол, с помощью которого управляется сетевое оборудование, он в некотором смысле похож на SNMP, который использует свой API. SDN же, повторюсь, это термин, который описывает предоставление совокупности программных интерфейсов в сетевой инфраструктуре. Термин "SDN" в большей степени маркетинговый, конечно.
Технико-маркетингово у SDN имеется три архитектурных слоя: физическая сеть, приложения SDN и контроллер SDN.
Слой физической сети: самый нижний слой, состоящий, собственно, из сетевых физических устройств. По аналогии с картографическими заблуждениями, все, что снизу, называется "югом". В данном случае, все API будут относиться к Southbound или к "южному мосту".
Коммуникационные приложения SDN: наиболее видимый со стороны конечного пользователя слой в конструкции - приложения, которые предоставляют, собственно, услуги.
Это могут быть привычные для профессионального использования: виртуализация коммутаторов (сети), межсетевые экраны, балансировка трафика etc. А могут быть и более привычные пользователям SMS-сообщения, например, или видеопотоки.
Приложения, по большому счету, это то же самое, что сегодня используется для организации услуг, но в аппаратном исполнении - голос, передача сообщений, прочие виды ДВО (хотя, мне больше нравится термин Rich Services, но от этого суть посыла не меняется). Большинство предстоящей инновационной деятельности в программно-конфигурируемых сетях будет происходить именно в приложениях SDN.
SDN-контроллер находится ровно посередине и служит стержнем всей архитектуры. Собственно, контроллер и должен уметь общаться со всеми физическими и виртуальными устройствами в Сети. Но не следует считать SDN-контроллер волшебно-магическим центром сетевой вселенной - это всего лишь уровень абстракции для физических сетевых устройств. Контроллером может быть любой прибор в ПК-сети, включая виртуальный. Предназначение контроллера - создать логическую связь между "севером" и "югом", ибо в физической среде он будет общаться на NETCONF для конфигурации устройств, и на OpenFlow для управления потоками данных. А для обращения в вышестоящие организации системы контроллер использует высокоуровневые API.
Вы скажете, WF читает слишком много ненаучной фантастики. Отнюдь. Ибо уже сейчас сотни (а может и тысячи) разработчиков пилят свои нетленные продукты. Некоторые уже даже есть в релизах, хотя пока и не в столь грандиозных, как я пытаюсь живописать.
Разумеется, не все сразу оборудование будет выведено в API. Разумеется, будут грабли и факапы. И всеобщая API-изация телекома начнется с сервисов для конечного потребителя, ибо собственно телекомы будут некоторое время сопротивляться изменениям - защита инвестиций это очень чувствительная тема, которую трудно обойти простым удобством. Если вы не в курсе, то вот некоторые аэропорты (казалось бы - хайтек незамутненный) до сих пор используют Windows версии 3.11 в критических приложениях. С 1992 года, между прочим. Так что, никто не будет выбрасывать то, что работает. Но последовательного внедрения не избежать. Потому что это выгодно.
Вот примерная таксономия API’s, которые будут внедряться (точнее - уже внедряются) в базовые телеком-процессы:
В чем преимущество использования механизмов API? Это же очевидно - любая информационная система может обратиться к любой другой информационной системе за данными, или поставить задачу. Причем, собственно разметка API имеет выраженную семантику функций, а каждая функция может быть прочитана и, главное, понята человеком. Механизм обмена данными уже не столь важен - он может быть любой, на любом уровне OSI. Но предпочтительнее на HTTP-запросах, как наиболее универсальном способе обмена данных.
Перевод же различных API-запросов из одного в другой так же возможен осознанно, если имеется необходимая и достаточно полная документация. Очевидно, что появятся и спецсервисы/софт, который будет знать множество разных систем, и достаточно легко транслировать одно в другое. На самом деле, такие сервисы уже есть: http://webshell.io/ или http://swagger.io/ - пусть пока еще и в зачаточном состоянии.
Я же приведу несколько конкретных примеров российской современности.
OneAPI
Этот проект является внутренним стратапом, не поверите, компании Huawei. И стартапом исключительно российским. Пока он довольно прост, но имеет самое непосредственное отношение к API-изации телекома в части клиентских сервисов.
OneAPI предлагает механизм отправки SMS, организации голосовых вызовов, и что-то пытается сделать в области платежей. Да, пока нельзя сказать, что это тот самый слон - это всего лишь маленькая его часть. Но он позволяет быстро и недорого "поднять" дополнительные телекоммуникационные сервисы людям, от телекома далеким.
Это, разумеется, реализация на уровне "северного моста", и к собственно SDN имеет отношение исключительно маркетинговое (но кого-то же надо притащить, похвалить?).
ITooLabs
Еще одно решение команды "северных". Об этой компании Наг уже публиковал пространную статью. Парни продолжают совершенствоваться и развиваться. Публичных API у них пока не много, но они стараются.
Да, я понимаю натянутость совы на глобус относительно следующего игрока (как и предыдущих), но все же хочу упомянуть биллинг "Гидра". Потому что импортозамещение, и моя прямая обязанность, как отраслевого аналитика, всенепременно обращать внимание на тех, кто рядом.
Итак, Гидра от компании Латера имеет, судя по заявлению, 860 API-процедур в описанном и открытом виде. В поле зрения Гидра попала постольку, поскольку упомянутый выше ITooLabs взял, и интегрировался с биллингом Гидра, что собственно является демонстрацией именно той схемы, которую я описывал выше. Ну, про "дивный новый мир". Получилось примерно следующее:
Разработчик, специализирующийся на системах IP-телефонии, создал продукт сообразно со своей компетенцией. Продукт хороший, годный, но для полного счастья не хватало компоненты "про деньги". Разработчик обращается к другому специалисту, который как раз в теме. В итоге получается законченная коробка, которую оператор внедряет с полоборота, запуская услугу конечным потребителям. Все стороны в выигрыше. И все благодаря тому, что Карл Маркс называл "разделением труда". Вместе они эффективнее, чем по отдельности. А API всего лишь клей, с помощью которого были склеены системы. Впрочем, этот проект бы описать подробнее - интересно же (коммерческий анонс).
Но все примеры про "северный мост". Их, на самом деле, очень много, что хорошо. А вот с "южным мостом" все гораздо сложнее. Из российских разработчиков мне известен только ЦПИКС. Парни там молодцы, хоть и подсели на госбабло, что в конечном итоге их и погубит. Но все равно молодцы. Потому что, например, проект RunOS вполне себе рабочий и находится в открытом доступе. Можно поиграться.
Но все равно, российские технологии в теме выглядят пока так:
А из разработок вообще (не российских) - то их очень. Очень много. SDN одна из самых горячих тем в технотусовке "Кремниевой долины". Причем, некоторые вещи по Hype Cycle от Gartner уже отшумели. Некоторые только начинают входить в фазу "рекламного шума":
Собственно концепт SDN даже уже прошел острую фазу. Виртуальные коммутаторы вышли на "плато продуктивности". Теперь в моду входят те самые Software Defined Network Applications и программные реализации WAN (SD-WAN, Cloud Managed LAN, WAN optimization as a Service).
Многие вендоры, все эти Cisco, HP и Dell вкладывают миллионы в SDN-стартапы. Есть несколько интернет-порталов, полностью посвященных SDN: http://sdnhub.org, https://www.sdxcentral.com, http://searchsdn.techtarget.com - тысячи их.
Из наиболее интересных, где есть много Open Source и можно прикоснуться собственно к продуктам, приведу два примера: операционную систему ONOS (очень круто, я думаю, надо написать отдельно) и про старый добрый OpenWRT, про который на Github имеется штук тридцать форков по реализации OpenFlow и NETCONF.
Еще можно прикоснуться к прекрасному, и понаблюдать (а возможно и поучаствовать), как пилится стандарт NETCONF и умирает старый добрый SNMP. Как-то так:
