Het cloudeigen pad naar gegevens overal

Duizenden ondernemingen in verticale sectoren, variërend van financiële diensten en verzekeringen tot productie en gezondheidszorg, merken dat ze publieke en private cloud-, hybride en edge-implementaties nodig hebben om het beste te passen bij hun behoeften op het gebied van gegevensbeheer en analyse. Het is dus geen verrassing dat het concept van gedistribueerde cloud deel uitmaakt van de ontwikkeling van de cloud. Het brengen van datawarehouses, datameren en geavanceerde analyses naar een gedistribueerde cloudarchitectuur is waar markten naartoe gaan. Het uitbreiden van deze architectuur om databeheer- en analysediensten op een hoger niveau te omvatten, leidt natuurlijk tot het idee van een gedistribueerde datacloud . Binnen een gedistribueerde datacloud zullen enterprise datawarehouses niet alleen worden gebruikt om analyses te leveren aan een paar honderd bedrijfsanalisten of datawetenschappers in een bedrijf, maar zullen ze uiteindelijk ook in staat zijn om realtime analytische applicaties aan te sturen die direct door de onderneming worden gebruikt klanten die in de tienduizenden lopen. De gegevens zijn overal onmiddellijk toegankelijk en leveren inzichten op.

Zie ook: Cloud-adoptietrends van 2021 versterken in 2022

De bestemming verkennen

Cloud-native is een term die veel wordt gebruikt, maar het heeft echte betekenis wanneer software-architectuur van de grond af is ontworpen om te profiteren van de voordelen van gedistribueerde cloud. Een volledig gerealiseerd cloud-native datawarehouse zou logischerwijs gebruik moeten maken van een gedistribueerde datacloud-architectuur. In de breedste bewoordingen brengt dat analyses naar de gegevens waar deze zich ook bevinden (niet andersom), vermindert het concentratierisico, verhoogt het de efficiëntie aanzienlijk en luidt het modernisering in voor gecontroleerde uitgaven en een concurrentievoordeel.

Om het nog preciezer te zeggen:een cloud-native datamanagement- en analysetechnologie zou vijf belangrijke eigenschappen moeten vertonen om af te stemmen op de gedistribueerde datacloud-blauwdruk:

• Een platformonafhankelijke runtime waarmee gegevens en analyses overal kunnen worden geleverd
• Overal een algemene gebruikerservaring
• Algemene beveiligings- en beheerfuncties voor elk implementatiedoel
• Efficiëntie van kosten en technologie overal, minimale middelen en sterk kostenbeheer (FinOps) en uitgavenvangers
• Eén enkel controlevlak, dat alle implementaties samenbindt, openbare cloud, on-premises en aan de rand van het netwerk

Een volledig gerealiseerd cloud-native datawarehouse dat dit patroon volgt, kan overal op het moment van behoefte worden ingezet en zal ook de complexiteit van de cloud-, on-premises en netwerkrandinfrastructuur van eindgebruikers abstraheren. Het gaat erom ze te bevrijden van infrastructuurdetails en hen in staat te stellen zich te concentreren op het genereren van waarde uit analyses en het beheren van gegevens, terwijl ze toch de native kracht van de cloud meegeven.

De juiste gids kiezen

Dus, hoe wordt die bestemming bereikt? Kubernetes, de open-source tool voor het orkestreren van containers, biedt het meest populaire pad naar cloud-native operaties. Hoewel het idee om workloads in Unix te partitioneren al sinds de jaren zeventig bestaat, was het pas ongeveer tien jaar geleden dat containers op grote schaal werden geïmplementeerd om applicatie-ontwikkeling gemakkelijker, draagbaarder en efficiënter te maken in het gebruik van bronnen. Maar het implementeren van honderden of duizenden applicaties in een uitgebreide microservices-architectuur bleek uiterst lastig. Hoewel er andere opties bestaan, kreeg het open-source Kubernetes-project van Google, dat nu wordt beheerd door de Cloud Native Computing Foundation, bekendheid om de orkestratie van microservices-applicaties op te lossen, waardoor applicaties op een generieke infrastructuur kunnen worden uitgevoerd, op standaard manieren kunnen worden gecontroleerd en beheerd en kunnen worden geverifieerd met behulp van open standaarden.

Dat is goed en wel voor toepassingen. Maar hoe zit het met de wereld van data? Dezelfde fundamentele containerorkestratie is vereist voor cloud-native datawarehouses om elasticiteit en implementatieflexibiliteit te bieden in openbare en privéclouds, netwerkranden, hybride en volledig gedistribueerde clouds.

Cloud-native her-architectuur voor scale-out webapplicaties is gebruikelijk, maar databases zijn meestal net "lift-and-shifted" naar de cloud-native wereld. Door een database in een container te stoppen, kan deze in een moderne infrastructuur worden uitgevoerd, maar het biedt geen ervaring die alle voordelen van de cloud demonstreert. De software is grotendeels onwetend van het feit dat het in een containeromgeving draait, en bewerkingen zoals het beheren van elastische clusters moeten onhandig met de hand van buiten de database worden afgehandeld met behulp van Operators en het hacken van Helm-diagrammen. Functies zoals het toestaan ​​dat meerdere, elastische on-demand rekenclusters dezelfde onderliggende gegevens in objectopslag delen, zijn vaak niet beschikbaar. Gebruikers die zakelijke waarde willen halen uit een elastisch, cloudgebaseerd datawarehouse, willen niets weten over Helm-diagrammen, pods, knooppunten of configuratiebestanden. Ze willen alleen datawarehouses inrichten, elastische clusters beheren en inzichten uit hun gegevens halen.

Het bieden van een SQL-interface via Kubernetes om meerdere, elastische clusters op aanvraag te leveren en om Kubernetes-complexiteit te verbergen voor DBA's en eindgebruikers.

Op deze manier kunnen verschillende gebruikers worden toegewezen om workloads op verschillende rekenclusters uit te voeren, en het gebruikte rekencluster kan tijdens runtime worden gewijzigd via SQL, afhankelijk van toestemming. Clusters kunnen worden geconfigureerd om automatisch te stoppen na een periode van inactiviteit en op verzoek weer op te starten. Er kan bijvoorbeeld een afzonderlijk rekencluster worden gemaakt om ETL-processen uit te voeren wanneer dat nodig is, een voor ad-hoc business intelligence (BI) en meerdere datawetenschapsclusters. Rekenclusters kunnen online worden uitgebreid tijdens perioden van intensief gebruik of worden uitgeschakeld tijdens rustige perioden om geld te besparen. Er kunnen clusters worden gemaakt om dagelijkse, wekelijkse of maandelijkse batchrapportagetaken uit te voeren die alleen tijdens die perioden actief zijn. Zowel de grootte van de knooppunten in het rekencluster als het aantal knooppunten zijn beheersbaar in dit model en voor voorspelbaarheid kunnen limieten voor het resourceverbruik worden vastgesteld op instantieniveau. Evenzo is het mogelijk om een ​​goedkoop replicasysteem op te zetten dat replicatieverkeer ontvangt van een primaire datawarehouse-instantie, dat vervolgens op aanvraag kan worden opgeschaald wanneer de replica moet worden gebruikt.

Dit soort elasticiteit wordt niet alleen geïmplementeerd door diepe integratie met Kubernetes, maar door SQL zelf te gebruiken als de "gebruikersinterface" voor het maken, opschorten, hervatten en beheren van clusters in plaats van ontwikkelaarstools. Kubernetes is de gezaghebbende bron van waarheid voor de toestand van alle clusters. Systeemweergaven die de status van de clusters tonen, halen hun gegevens uit Kubernetes met behulp van de bijbehorende API's. Wanneer SQL-statements voor clusterbeheer worden ingevoerd, neemt het cloud-native datawarehouse contact op met Kubernetes om de gewenste status van een instance te wijzigen; Kubernetes voert vervolgens de nodige wijzigingen door. Als een knooppunt in het cluster niet meer werkt, brengt Kubernetes een vervanging online.

Dit vertegenwoordigt een unieke, inside-out relatie met Kubernetes:in plaats van dat Kubernetes de 'gebruikersinterface' is voor het aansturen van de status van het cluster, wordt de database zelf, die wordt beheerd door Kubernetes, de gebruikersinterface. Deze architectuur creëert een symbiotische relatie die een unieke, volledig gerealiseerde cloudervaring oplevert. De kracht en platformonafhankelijke flexibiliteit van Kubernetes komt beschikbaar voor een datawarehouse, volledig aangestuurd door SQL.

Naarmate er meer gegevens worden gegenereerd en meer use-cases worden ingezet, is het voor ondernemingen gemakkelijk om in een vicieuze cirkel te komen waarin hun ecosysteem steeds meer verankerd raakt in een bepaalde cloud. Er kunnen systeemrisico's ontstaan ​​in die ene cloud die te veel blootstelling biedt aan kritieke IT-infrastructuur in zwaar gereguleerde sectoren zoals financiële diensten en verzekeringen. Architecten met Kubernetes is niet het enige kernconcept dat een volledig gerealiseerd cloud-native datawarehouse tot leven brengt. Het is niet de enige architecturale component die is afgestemd op het gedistribueerde datacloudpatroon. Maar het is het onmisbare middelpunt dat data-analyse uitzonderlijk flexibel maakt, overal kan worden uitgevoerd op het punt van de zakelijke behoefte - en dit op schaal en met hoge gelijktijdigheid, prestaties, efficiëntie en beschikbaarheid. Het resultaat is dat duizenden gebruikers in een bepaalde onderneming, in verschillende bedrijfsonderdelen en geografische regio's, extreem snelle beslissingen kunnen nemen en in bijna realtime waarde kunnen genereren uit analyses in beweging.