Jeszcze niedawno w branży dostawców usług istniała wyraźna linia podziału. Z jednej strony zespoły ds. sieci i bezpieczeństwa kontynuowały ewolucję architektury do NFV, kładąc szczególny nacisk na wirtualizację funkcji sieciowych i bezpieczeństwa. Wchodzenie w obszar automatyzacji miało charakter co najwyżej eksperymentalny. Z drugiej strony programiści entuzjastycznie przyjęli platformy chmurowe, metodologie DevOps i automatyzację w oparciu o potoki CI/CD. Szybkie wdrażanie i dostarczanie aplikacji było i jest dla nich najważniejsze. Brzeg sieci łączy oba te światy, dzięki czemu aplikacje mogą harmonijnie egzystować z funkcjami sieciowymi.
Edge computing – ze swoją rozproszoną naturą i wsparciem zapewnianym przez postępujące globalne wdrażanie 5G – umożliwia usługodawcom oferowanie nowych rozwiązań i usług. Tym samym daje im szansę na zwiększenie strumieni przychodów i obniżenie kosztów transferu sieciowego. W tym przypadku, nie ma konieczności przesyłania danych do chmury lub centralnej hurtowni danych w celu ich analizy, bo przetwarzanie może odbywać się na brzegu sieci. Zmniejsza to opóźnienia w sieci, zwiększa jej przepustowość i zapewnia znacznie krótszy czas reakcji.
Warto tu przywołać przykład pojazdów autonomicznych. Użycie aplikacji hostowanej (wraz ze wszystkimi powiązanymi z nią danymi) w centralnej lokalizacji, takiej jak chmura publiczna, może skutkować opóźnieniami liczonymi w dziesiątkach milisekund. Będzie ona wtedy działać zbyt wolno. Ten sam efekt otrzymamy, pozostawiając aplikację w centrum i umieszczając na brzegu funkcje sieciowe. Dopiero po przesunięciu zarówno aplikacji, jak i funkcji sieciowych na brzeg sieci możliwa stanie się redukcja opóźnień do pojedynczych milisekund. A o to właśnie chodzi.
Zwirtualizowane sieci CDN (Content Delivery Networks) to kolejny niezwykle istotny przykład. Do tej pory CDN niezależnego dostawcy była zwykle hostowana w punkcie połączeń (peering point) lub w centrum danych. Teraz to się zmienia, ponieważ niektórzy usługodawcy tworzą w oparciu o edge computing własne CDN do lokalnego dostarczania treści wideo i usług IPTV. W ten sposób oszczędzają na kosztach tranzytu i przesyłu danych.
W tworzeniu zastosowań edge computingu dostępne są różne modele biznesowe. W najprostszym scenariuszu, dostawca usług daje fizyczny dostęp do brzegu sieci. Niezależne firmy umieszczają tam własny sprzęt i wszystkim zarządzają. W tym modelu, czyli kolokacji – usługodawca odpowiada za oferowaną powierzchnię, zasilanie i łączność.
Jednak o wiele bardziej interesującym podejściem jest zapewnianie przez dostawcę niezależnym podmiotom usług IaaS (Infrastructure as a Service) bądź PaaS (Platform as a Service) – za pośrednictwem współdzielonej platformy edge computingu. Usługodawca może ją stworzyć samodzielnie lub wraz z specjalizującymi się w tym obszarze partnerami.
Potęga automatyzacji
Czynnikiem, dzięki któremu to wszystko działa, jest automatyzacja. W kontekście przetwarzania w chmurze to ona ma szczególne znaczenie dla programistów, którzy szybko i zwinnie publikują nowe wersje kodu.
W świecie sieci opartych na NFV automatyzacja jest kluczem do obniżenia kosztów operacyjnych usługodawcy. Wcześniej, dostarczanie sieci i usług było pracą manualną, czasochłonną. Obecnie, choć cele zespołów sieciowych i programistów mogą się różnić, narzędzia oraz techniki stają się takie same lub są wymienne. W środowisku przetwarzania brzegowego aplikacje i funkcje sieciowe współistnieją ze sobą.
Sposób na automatyzację wdrażania aplikacji i powiązanych z nimi usług aplikacyjnych w chmurze
Na potrzeby tego artykułu skoncentrujmy się na automatyzacji usług aplikacyjnych. Warto zauważyć, że kroki opisane poniżej można łatwo zintegrować z popularnymi narzędziami do zarządzania konfiguracją i infrastrukturą, takimi jak Ansible lub Terraform, których uzupełnieniem są narzędzia CI/CD, np. Jenkins.
Pierwszym krokiem jest bootstrapping (uruchomienie) bądź wprowadzenie maszyny wirtualnej w celu dostarczania usług aplikacyjnych do wybranej chmury.
Kolejnym krokiem jest onboarding (wstępne wdrożenie), w którym wprowadzona zostaje podstawowa konfiguracja z parametrami sieciowymi i uwierzytelnianiem (np. adresami IP, serwerem DNS itp.). Wreszcie mamy właściwe wdrożenie usług aplikacyjnych – takich jak ADC lub polityki bezpieczeństwa – przy użyciu deklaratywnych interfejsów API. Ten ostatni punkt jest krytyczny.
Wykorzystując imperatywne interfejsy API, stosowane przez większość dostawców, mówimy systemowi, co ma robić w każdym momencie. Dobrym przykładem są firewalle. Musimy stworzyć listy adresów i przyporządkować je do reguł zapory. Są one następnie grupowane w politykach przypisywanych potem do interfejsu. Wywołania interfejsu REST API wymagają sekwencji odrębnych kroków, w przeciwnym razie wszystko zawiedzie. Zintegrowanie tego w narzędziu do automatyzacji jest kosztowne i pochłania dużo czasu.
Zupełnie inaczej jest w przypadku deklaratywnych interfejsów API. Możemy powiedzieć systemowi, czego chcemy, a on wyznaczy kierunek. Używając jednej deklaracji (w formacie JSON lub YAML), możemy np. zdefiniować wszystkie parametry ADC i usługi bezpieczeństwa, by następnie przekazać je do systemu za pomocą pojedynczego wywołania REST API. W tym przypadku wynikiem jest sukces (usługa została wdrożona) albo porażka, ale cały system pozostaje nienaruszony. System automatyki nie wymaga inteligencji. Pozostaje ona w systemach, które konfigurujemy, co znacznie obniża koszty automatyzacji.
Dokładne te same kroki można podjąć w celu zapewnienia funkcji sieci wirtualnej w środowisku NFV. Deklaratywny interfejs API bardzo upraszcza integrację z kompleksowymi narzędziami do orkiestracji NFV. Przeprowadzający orkiestrację nie musi znać poszczególnych działań, aby skonfigurować usługę lub funkcję sieci - po prostu używa pojedynczej deklaracji JSON z parametrami potrzebnymi do skonfigurowania usługi. I znowu inteligencja dotycząca sposobu konfiguracji usługi pozostaje w konfigurowanym systemie.
Dzięki większej integracji sieci i programowania, możemy obecnie tworzyć rozproszoną chmurę telekomunikacyjną o wspólnym schemacie automatyzacji aplikacji i funkcji sieciowych. Ten schemat jest zwinny i bezpieczny w każdej warstwie stosu – od centrum danych aż po odległy brzeg, i może nawet objąć chmurę publiczną.
Możemy się spodziewać, że wspólne schematy automatyzacji umożliwiające wdrażanie aplikacji, usług aplikacyjnych oraz funkcji sieciowych, staną się w nadchodzących latach normą dla całej branży. Wpływać będzie na to postęp we wdrażaniu 5G na całym świecie. Presja, jaką czują dostawcy usług, sprawia, że muszą oni likwidować silosy, działać zwinnie i poświęcać więcej uwagi brzegowi sieci.
Kamil Woźniak, Senior Manager, Security Operations F5 Poland
