Zephyrnet-logo

Fouten in de cloudarchitectuur: verlies van zichtbaarheid en controle over gegevensverwerking

Datum:

Dit is een vijfdelige serie artikelen waarin vijf kritieke fouten worden onderzocht waarmee organisaties worden geconfronteerd bij het bouwen van een cloudarchitectuur, en hoe die fouten kunnen leiden tot torenhoge kosten en inefficiënt – zelfs riskant – gegevensbeheer. 

Bij het maken van hun digitale transformatiesverliezen organisaties vanaf het begin te vaak de zichtbaarheid en controle over hun gegevens. Ze kunnen de fout maken om zelf een cloudnetwerk te bouwen, wat resulteert in een logge mengelmoes van oplossingen. Het ontbreken van een goed kostendelingsmodel kan de kosten opdrijven, terwijl een organisatie achterblijft met onderbenutte middelen en een foutgevoelige financiële planning die de bedrijfsvoering verstoort. In plaats van beveiliging te integreren, behandelen veel organisaties het afzonderlijk, wat leidt tot vastgeschroefde oplossingen die de kwetsbaarheid vergroten en de naleving negatief beïnvloeden. En het niet implementeren van een dataherstelplan - te veel vertrouwen op wat een cloudserviceprovider (CSP) native biedt - kan resulteren in een langere gemiddelde hersteltijd (MTTR).

Al deze fouten dragen bij aan de kosten van de cloud. Maar ze kunnen worden vermeden. In deze serie leg ik uit hoe, te beginnen met de eerste stap om ervoor te zorgen dat naar de cloud gaan niet betekent dat je de controle over je gegevens verliest.

Iemand deelde onlangs een artikel over een bedrijf dat uit de cloud bestond, daarbij verwijzend naar de wolken zijn erg duur. Ik heb besloten dit artikel te schrijven omdat verhalen als deze anderen kunnen aanmoedigen om nodeloos af te zien van ongelooflijke cloudvoordelen door de waarheid over cloudkosten en hoe deze te beheersen te verdoezelen. Ik wil de schat aan ervaring delen die ik heb opgedaan tijdens het werken met CIO's, CTO's en hoofdarchitecten in de bedrijfsgemeenschap om uit te leggen waarom 'cloud' en 'duur' niet noodzakelijkerwijs hand in hand gaan. 

Wolk is nog steeds nieuw voor veel bedrijven en heel anders dan op locatie. Er zijn een nieuwe cloudarchitectuur en -discipline nodig om de cloud te runnen en te laten werken met de kostenbewakers op hun plaats. Er is geen weg terug naar het bedrijfsmodel op locatie. Elke organisatie die erover nadenkt om terug te keren naar het on-premise model of de acceptatie van de cloud uit te stellen, zal al snel irrelevant en vergeten worden. 

Realiteit van cloudkosten

Het is waar dat public cloud kostbaar kan zijn als het niet goed wordt gedaan. Een andere realiteit is dat teruggaan naar on-premise hetzelfde is als teruggaan naar een tijdperk waarin de smartphone nog niet bestond. Onze wereld draait om apps, services en alles-als-een-service (ook bekend als XaaS). De openbare cloud heeft ons veel voordelen binnen handbereik van een onderneming gegeven, zoals verbeterde flexibiliteit, innovatie, concurrentievoordeel en snelle time-to-market, waardoor onze bedrijven kunnen profiteren van de XaaS-economie.

Vijf grote fouten in de cloudarchitectuur van organisaties

Hoewel de cloudkosten kunnen worden opgesplitst in verschillende segmenten, kunnen de kosten van de cloudinfrastructuur zelf worden gecontroleerd, geoptimaliseerd en verlaagd wanneer netwerken en beveiliging goed worden uitgevoerd. 

Toen ik de gegevens analyseerde, kwam ik tot de conclusie dat er vijf belangrijke redenen of fouten zijn die organisaties maken die worden toegeschreven aan de stijgende kosten van cloudinfrastructuur. Er kan meer zijn dan wat ik hier opsom, maar ik garandeer je dat als je deze vijf gebieden onder controle hebt, je veel zorgen over de cloudkosten wegneemt die door het bestuur, de CEO, de CIO of de CFO zijn geuit.   

  1. Gebrek aan inzicht in en controle over de gegevensverwerking
  2. DIY (ik doe het zelf wel) mentaliteit
  3. Ontoereikende showback- en chargeback-opties
  4. Slechte beveiligingsarchitectuur
  5. Hogere gemiddelde tijd tot herstel (MTTR)

Laten we de eerste fout aanpakken: het verlies van zichtbaarheid en controle over gegevensverwerking.

Een van de grootste schrikreacties voor bedrijven komt van kosten in verband met gegevensverwerking, gegevensopslag en uitgaande gegevensoverdracht. Ondernemingen die alleen cloud-native services gebruiken, moeten klaar zijn om deze extra kosten te verwerken. Bedrijven zouden deze kosten niet waarnemen bij implementaties op locatie, omdat ze eigenaar zijn van de hardware, software en architectuur voor datacenters, filialen, enz. Ze krijgen volledig inzicht in en controle over de gegevens die worden verwerkt en overgedragen. Ook andere kosten, zoals de kosten van MPLS-circuits, internet, enz., zijn beheersbaar en voorspelbaar bij lokale implementaties. 

Helaas moet u in de cloud betalen voor de kosten van gegevensoverdracht, gegevensopslag, gegevensverwerking en soms zelfs de kosten van het uitvoeren van een eenvoudige ping-type connectiviteitstest. In de cloud worden de gegevens in elke fase in rekening gebracht, zozeer zelfs dat u ervoor moet betalen kosten van logboekverwerkingBijvoorbeeld. NAT-gateways en kosten voor uitgaand internet vallen ook in het hoogste prijsniveau en kunnen de organisatie veel kosten. 

Als aanvulling op dit probleem heb ik ook gezien dat sommige kleine en middelgrote organisaties en/of op DevOps gerichte cloudteams kiezen voor een suboptimale architectuur. Ze sturen hun gevoelige en kritische netwerkverkeer of data naar een buitenlands NaaS (Network-as-a-Service) of SaaS (Software-as-a-Service) of CASB (Cloud Access Security Broker) type product. 

Deze buitenlandse producten van het type NaaS/SaaS/CASB voegen nog een laag complexiteit toe. Ze bieden niet de zichtbaarheid en controle die de meeste bedrijven vereisen. Bovendien is het een gebrekkige architectuur om gevoelig en productieverkeer buiten de controle van de organisatie te sturen voor netwerk- en beveiligingsbehoeften. Deze praktijk zal de kosten voor gegevensoverdracht en -verwerking verhogen, en het zal extra kosten om de noodzakelijke controle-, nalevings- en governance-vangrails te implementeren. 

Aanbevelingen voor cloudarchitectuur

Voor ondernemingen die worstelen met zichtbaarheid en controleproblemen, overweeg het volgende: u bezit de hardware in lokale implementaties, beheert het verkeer met zichtbaarheid en bouwt uw eigen architectuur - zou u niet hetzelfde moeten doen voor uw cloudnetwerken en beveiligingsbehoeften? 

Gebruik een oplossing waarmee u uw cloudarchitectuur kunt bouwen onder uw cloudaccounts, abonnementen en projecten in uw VPC, VNet en VCN - NaaS van een onderneming, geen buitenlandse NaaS. Deze cloudnetwerkoplossing moet consistent zijn in enkele of meerdere clouds. Het moet u in staat stellen uw netwerk te beheren en ingebedde telemetrie- en beveiligingsservices te bieden. 

Deze oplossing mag geen kosten in rekening brengen voor het verwerken en overdragen van de gegevens via het gegevensvlak, waar de kosten snel kunnen oplopen. Het moet bovenop uw favoriete clouds worden gebouwd, zoals AWS, OCI, Azure, GCP of Alibaba, en u in staat stellen native services zoals EKS, Anthos, Serverless, etc. te gebruiken, maar zonder uw applicaties en DNS-beleid aan te passen .

Raadpleeg voor meer informatie dit Gartner-onderzoek waarin verschillende leveranciers in de multi-cloud netwerksoftware (MCNS) ruimte.

Conclusie

Werkzaamheden op locatie gaan misschien in de richting van de telefoon met draaischijf, maar niet elk aspect van het on-prem-model moet worden opgegeven. De zichtbaarheid en controle die teams hebben gehad over hun datacenters, moet worden overgenomen in hoe organisaties hun cloud-architecturen beheren. Als u een oplossing kiest waarmee u een architectuur over meerdere clouds kunt bouwen terwijl u de controle over uw netwerk behoudt, verlaagt u de extra kosten voor gegevensverwerking, -overdracht en -opslag. Het zal u ook helpen de fout te vermijden om gevoelige en/of kritieke gegevens buiten de organisatie te verzenden.

In deel twee van deze serie onderzoek ik de valkuilen van een doe-het-zelfbenadering van de cloud, die snel onhandelbaar en kostbaar kan worden.
 

spot_img

Laatste intelligentie

spot_img