Управляется программно: API

Боль, которую испытывают операторы связи, в связи с возникновением тренда 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":

(правда же прекрасно, что пока в СМИ можно ругаться на английском, потому что Netflix and Chill означает "собраться пойти в дом к девушке, чтобы в фоновом режиме настраивать ей Netflix" - варианты своего перевода можно оставить в камментах)

И все потому, что конечный потребитель не платит за крутой навороченный маршрутизатор или новейшую систему спектрального уплотнения. Потребитель платит за… а, собственно, за что потребитель платит?

Ответ: за то, чтоб работало.

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

Примеров в мировой, да и в российской бизнес-среде, более чем достаточно:

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

2. Иные игроки из "большой тройки" задумываются о передаче ИТ-инфраструктуры в аутсорс. Включая биллинг. Да, этот процесс не столь прост, но топ-менеджмент прямо-таки светится гениальностью  идиотизмом оптимизмом:
   

3. Со стороны конечного спроса также отмечаются определенные сдвиги: при общем падении фиксированной телефонии - да-да, моя любимая тема за #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. Как-то так: