6min

Tags in dit artikel

, , , ,

Kubernetes krijgt op steeds meer plaatsen voet aan de grond, zo ook aan de edge. Volgens Symworld Cloud, zoals Robin.io sinds afgelopen november heet, is het dan wel cruciaal dat de onderliggende infrastructuur dit aankan. Wij waren op bezoek bij deze business unit van de Japanse technologiereus Rakuten om te horen wat het hier precies mee bedoelt.

Symworld Cloud draait om wat Partha Seetala tijdens een presentatie die we bijwoonden Distributed Stateful Edge noemt. Seetala is de oprichter van Robin.io. Hij heeft dat bedrijf samen met zijn medewerkers vanaf de grond af aan opgebouwd met een duidelijk doel. Het idee was vanaf het begin om een Kubernetes-platform te bouwen dat zich richtte op de zwaardere use cases. Met zwaardere use cases doelen we specifiek op workloads die een zware wissel trekken op netwerk en opslag. De compute moet in deze omgevingen ook zo dicht mogelijk op de workload zitten. Aan de edge dus.

Symworld Cloud is niet voor iedereen

De meest voor de hand liggende toepassing is 5G, waar heel veel gedaan moet worden met data voordat een gedeelte ervan verder gestuurd wordt. Dat is vanuit moederbedrijf Rakuten een inkoppertje. Toch benadrukt Seetala meerdere keren tijdens zijn presentatie dat de edge meer is dan alleen 5G. Als voorbeeld noemt hij fastfoodrestaurants met drivethroughs. Daar moet ook compute aan de edge aanwezig zijn op alle vestigingen. Dat wordt in combinatie met Kubernetes al snel een deployment van duizenden, zo niet tienduizenden clusters.

In bovenstaand scenario is het platform van Symworld Cloud in zijn element. Bij een dergelijke gedistribueerde edge-omgeving komen namelijk ook de nodige uitdagingen kijken op het gebied van netwerk en opslag. En dat is precies waar het om te doen is bij het Distributed Stateful Edge Platform.

Om waarde uit het platform van Symworld Cloud te halen, moet je wel echt voldoen aan de hierboven geschetste voorwaarden. Er moet dus wel daadwerkelijk (veel) data aan de edge opgeslagen worden (het moet stateful zijn dus). In principe kun je ook in stateless omgevingen met Symworld Cloud aan de slag, maar dan haal je er niet alles uit. Dan kun je beter aan de slag gaan met andere, wat meer generieke platformen op de markt, geeft Seetala aan. Denk hierbij aan VMware Tanzu en Red Hat OpenShift.

De drie producten van Symworld Cloud

Het gaat bij Symworld Cloud dus eigenlijk niet eens zozeer over Kubernetes, maar om het platform eronder. Seetala ziet nog te vaak dat organisaties maar gewoon aan de slag gaan met Kubernetes, zonder dat daar goed naar gekeken wordt. Dat is geen goed plan en zal ook niet werken.

Symworld Cloud richt zich specifiek op drie onderdelen die ervoor zorgen dat cloud-native stateful workloads aan de edge optimaal presteren. Allereerst is er Symworld CNP (Cloud Native Platform), het volledige geïntegreerde en voor specifieke workloads geoptimaliseerde full-stack Kubernetes platform. Het tweede product is Symworld CNS (Cloud Native Service). Dit is de cloud-native storage stack van Symworld CNP, die je vervolgens bovenop een andere Kubernetes-stack kunt gebruiken. Hiermee concurreert Symworld Cloud rechtstreeks met Portworx, inmiddels onderdeel van Pure Storage. Als derde en laatste product is er de Symworld Orchestrator. Deze draait volledig om het beheren van de baremetal servers waar Kubernetes-clusters op draaien.

In de rest van dit artikel gaan we nog iets verder in op deze drie producten.

Symworld CNP

Symworld CNP is zoals al aangegeven een Kubernetes-platform zoals VMware Tanzu en Red Hat OpenShift dat ook zijn. Seetala wil tijdens zijn presentatie echter duidelijk benadrukken dat Symworld CNP toch echt anders is. Waar Tanzu en OpenShift breed toepasbaar zijn, richt Symworld CNP zich echt alleen op de zware gebruikstoepassingen waar we het hierboven over hebben gehad. Hieronder zie je schematisch hoe Symworld CNP is opgebouwd.

Zowel op het gebied van storage als netwerk zorgt Kubernetes zeker bij grote aantallen clusters voor de nodige uitdagingen. In de basis is storage een probleem dat we opgelost hebben, geeft Seetala aan, maar toch moeten we bij ieder nieuw platform (zoals Kubernetes) storage opnieuw tegen het licht houden om te kijken of de architectuur anders moet. Voor Kubernetes geldt bijvoorbeeld dat DevOps de storage beheert. Die willen vooral snel storage kunnen toevoegen aan wat ze ontwikkelen. Daarnaast zijn databases ook gedistribueerd. Die draaien over verschillende servers heen. Tot slot is er ook nog de kwestie van het maken van snapshots. Dat is binnen een gedistribueerde omgeving ook een ander verhaal dan in traditionele omgevingen.

Storage moet app-aware worden, zoals dat zo mooi heet. Een applicatie geeft inzicht in zaken zoals topologie en beperkingen, maar stelt ook eisen. Als de storage hiermee overweg kan, kun je in een paar klikken een volledige storage-stack uitrollen. Zeker als je het hebt over stateful edge deployments, waar het gaat om tienduizenden clusters, kun je met Symworld CNP veel winst behalen. Dat lijken de hyperscalers ook in te zien, want Symworld Cloud is in gesprek met hen om het ook daar beschikbaar te maken. Welke hyperscalers het zijn, wil Seetala niet zeggen, wel dat er wordt gewerkt aan een persbericht.

Voor het netwerk geldt dat Kubernetes van nature geen rekening houdt met het inzetten van de fysieke infrastructuurlaag om dit te optimaliseren. Dat wil zeggen, Kubernetes wil zoveel mogelijk abstractie aanbrengen. Dit terwijl applicaties met name in veeleisende omgevingen met enige regelmaat een accelerator (FPGA) nodig hebben. Dan moet je die koppeling wel kunnen maken. Dat is wat Symworld CNP kan doen.

Symworld CNP is overigens niet alleen ontworpen om containers te draaien. Men snapt bij Symworld Cloud ook wel dat de wereld niet van de ene op de andere dag overstapt op containers. Het is dus mogelijk om deze op baremetal naast VM’s tegelijkertijd te draaien.

Symworld CNS

Met Symworld CNS hebben we zoals eerder al aangegeven alleen de storage-stack van Symworld CNP te pakken, die je vervolgens op om het even welk Kubernetes-platform kunt draaien. In principe kun je nu dus alles wat je op storage-gebied binnen Symworld CNP kan doen, ook buiten dat Kubernetes-platform doen.

We hebben het tijdens de presentatie rondom Symworld CNS vooral over hoe de benadering van Symworld Cloud verschilt van die van met name Portworx. Volgens Seetala kan Symworld CNS beduidend betere prestaties leveren en is het ook efficiënter, omdat dit niet leunt op een bestaand filesystem. De oplossing van Portworx is gebaseerd op Btrfs (Butter FS). Dat betekent dat Portworx daar verder weinig tot niets mee kan doen, mocht het dat willen. Robin (zoals het toen nog heette) is vanaf de grond af aan zelf gebouwd. Dat zorgt voor meer controle over de hele stack. Onderaan de streep betekent dit volgens Seetala een betere gebruikservaring en betere prestaties.

Symworld Orchestrator

Het laatste onderdeel is zeker niet het minst belangrijke. Sterker nog, Seetala benoemt het expliciet als een superbelangrijk product. Deze uitspraak is niet verrassend, gezien de nadruk die hij al de gehele tijd legt op het belang van de onderliggende infrastructuur. Symworld Orchestrator is namelijk ontwikkeld om de baremetal servers waarop de vele tienduizenden clusters draaien, te beheren. Doe je dat niet goed, dan kun je volgens hem nooit opschalen naar dat soort aantallen.

Conclusie

De drie producten van Symworld Cloud geven deze business unit binnen Rakuten een behoorlijk compleet verhaal richting de markt. De keuze om zich vooral op specifieke (edge) use cases te richten, kan nog weleens gunstig uitpakken, als de edge dan uiteindelijk toch echt gaat exploderen. Als de beweringen kloppen dat het aanbod van Symworld Cloud zoveel beter is dan het ‘ouderwetse’ op het twintig jaar oude Ceph gebaseerde Red Hat OpenShift en het op vSAN gebaseerde VMware Tanzu, kan dat het bedrijf weleens heel hard doen opschalen. Ook de ontwikkelingen met de hyperscalers kunnen Symworld Cloud een enorme boost geven uiteraard. Dit zou niet enorm lang meer moeten duren.

Verder blijft Symworld Cloud ook niet stilzitten, horen we tegen het einde van de presentatie. Zo komt het aankomende zomer met een zelfgebouwde object store en staat ook ondersteuning voor Arm op de roadmap. Arm is tot nu toe nog niet echt interessant voor zware use cases. Dat heeft er vanuit telco-perspectief onder andere mee te maken dat FlexRAN alleen nog maar op Intel draait. Dus ze zijn daarvoor ook enigszins afhankelijk van wat andere partijen in de markt doen. Marvell schijnt bezig te zijn om dit ook op Arm te krijgen, maar is nog niet zo ver. Zodra dat het geval is, zullen de zware toepassingen binnen de telco-industry op Arm ook vanzelf komen.