Leestijd 3 min

Bregt Coenen

In de complexe wereld van moderne softwareontwikkeling worden bedrijven geconfronteerd met de uitdaging om verschillende applicaties die door verschillende teams worden ontwikkeld en beheerd, naadloos te integreren. De Service Mesh is van onschatbare waarde bij het overwinnen van deze uitdaging. In dit blogartikel verdiepen we ons in Istio Service Mesh en onderzoeken we waarom investeren in een Service Mesh zoals Istio een slimme zet is." Wat is Service Mesh? Een Service Mesh is een softwarelaag die verantwoordelijk is voor alle communicatie tussen applicaties, in deze context services genoemd. Het introduceert nieuwe functionaliteiten om de interactie tussen services te beheren, zoals monitoring, logging, tracing en verkeerscontrole. Een service mesh werkt onafhankelijk van de code van elke individuele service, waardoor het over netwerkgrenzen heen kan werken en kan samenwerken met verschillende beheersystemen. Dankzij een service mesh kunnen ontwikkelaars zich richten op het bouwen van toepassingsfuncties zonder zich zorgen te maken over de complexiteit van de onderliggende communicatie-infrastructuur. Istio Service Mesh in de praktijk Denk aan het beheren van een groot cluster waarop meerdere applicaties draaien die ontwikkeld en onderhouden worden door verschillende teams, elk met verschillende afhankelijkheden zoals ElasticSearch of Kafka. Na verloop van tijd resulteert dit in een complex ecosysteem van applicaties en containers, overzien door verschillende teams. De omgeving wordt zo ingewikkeld dat het voor beheerders steeds moeilijker wordt om het overzicht te bewaren. Dit leidt tot een reeks pertinente vragen: Hoe ziet de architectuur eruit? Welke applicaties interageren met elkaar? Hoe wordt het verkeer beheerd? Bovendien zijn er specifieke uitdagingen die voor elke afzonderlijke applicatie moeten worden aangepakt: Het afhandelen van aanmeldingsprocessen Implementeren van robuuste beveiligingsmaatregelen Netwerkverkeer beheren dat naar de applicatie wordt geleid ... Een Service Mesh, zoals Istio, biedt een oplossing voor deze uitdagingen. Istio fungeert als een proxy tussen de verschillende applicaties (services) in het cluster, waarbij elk verzoek door een component van Istio gaat. Hoe werkt Istio Service Mesh? Istio introduceert een sidecar proxy voor elke service in het microservices ecosysteem. Deze sidecar proxy beheert al het inkomende en uitgaande verkeer voor de dienst. Daarnaast voegt Istio componenten toe die het inkomende en uitgaande verkeer van het cluster afhandelen. Istio's control plane maakt het mogelijk om beleidsregels te definiëren voor verkeersbeheer, beveiliging en monitoring, die vervolgens worden toegepast op de toegevoegde componenten. Voor een beter begrip van de functionaliteit van Istio Service Mesh, zie ons blogartikel "Istio Service Mesh installeren: A Comprehensive Step-by-Step Guide" , een gedetailleerde, stapsgewijze uitleg over de installatie en het gebruik van Istio. Waarom Istio Service Mesh? Verkeersbeheer: Istio maakt gedetailleerd verkeersbeheer mogelijk, waardoor ontwikkelaars eenvoudig verkeer tussen verschillende versies van hun services kunnen routeren, verdelen en controleren. Beveiliging: Istio biedt een robuuste beveiligingslaag met functies zoals verkeersversleuteling met behulp van eigen certificaten, Role-Based Access Control (RBAC) en mogelijkheden voor het implementeren van authenticatie- en autorisatiebeleid. Waarneembaarheid: Door middel van ingebouwde instrumentatie biedt Istio diepgaande observeerbaarheid met tools voor monitoring, logging en gedistribueerde tracering. Hierdoor kunnen IT-teams de prestaties van services analyseren en snel problemen opsporen. Vereenvoudigde communicatie: Istio neemt de complexiteit van servicecommunicatie weg van applicatieontwikkelaars, zodat zij zich kunnen richten op het bouwen van applicatiefuncties. Is Istio geschikt voor uw opstelling? Hoewel de voordelen duidelijk zijn, is het essentieel om te overwegen of de extra complexiteit van Istio past bij jouw specifieke opstelling. Ten eerste is er een sidecar container nodig voor elke ingezette service, wat kan leiden tot ongewenste geheugen- en CPU overhead. Daarnaast kan het zijn dat je team niet beschikt over de specialistische kennis die nodig is voor Istio. Als je overweegt om Istio Service Mesh te gaan gebruiken, vraag dan begeleiding aan specialisten met expertise. Vraag onze experts gerust om hulp. Meer informatie over Istio Istio Service Mesh is een technologische game-changer voor IT-professionals die streven naar geavanceerde controle, beveiliging en observeerbaarheid in hun microservices-architectuur. Istio vereenvoudigt en beveiligt de communicatie tussen services, waardoor IT-teams zich kunnen richten op het bouwen van betrouwbare en schaalbare applicaties. Snel antwoord nodig op al uw vragen over Istio Service Mesh? Neem contact op met onze experts

Leestijd 7 min

ACA Group Team

Bent u dit jaar niet op KubeCon geweest? Lees dan mee voor onze hoogtepunten van de KubeCon / CloudNativeCon-conferentie van dit jaar door het Cloud Native-team van ACA Group! Wat is KubeCon / CloudNativeCon? KubeCon (Kubernetes Conference) / CloudNativeCon , jaarlijks georganiseerd op EMAE door de Cloud Native Computing Foundation (CNCF), is een vlaggenschipconferentie die adopters en technologen van toonaangevende open source en cloud native gemeenschappen op één locatie samenbrengt. Dit jaar kwamen ongeveer 5.000 fysieke en 10.000 virtuele deelnemers opdagen voor de conferentie. CNCF is de open source, leverancier-neutrale hub van cloud native computing, die projecten zoals Kubernetes en Prometheus host om cloud native universeel en duurzaam te maken. Er waren meer dan 300 sessies van partners, industrieleiders, gebruikers en leveranciers over onderwerpen als CI/CD, GitOps, Kubernetes, machine learning, observeerbaarheid, netwerken, prestaties, service mesh en beveiliging. Het is duidelijk dat er altijd iets interessants te horen is op KubeCon, ongeacht je interessegebied of expertiseniveau! Het is duidelijk dat het Cloud Native ecosysteem is uitgegroeid tot een volwassen, trendsettende en revolutionaire game-changer in de industrie. Alles staat in het teken van de Kubernetes-trend en een enorme hoeveelheid organisaties die cloud native producten ondersteunen, gebruiken en hun bedrijf hebben laten groeien door ze te bouwen of te gebruiken in bedrijfskritische oplossingen. De belangrijkste thema's van 2022 Wat ons opviel tijdens KubeCon dit jaar waren de volgende hoofdthema's: De eerste was toenemende volwassenheid en stabilisatie van Kubernetes en bijbehorende producten voor monitoring, CI/CD, GitOps, operators, costing en service meshes, plus bug fixing en kleine verbeteringen. De tweede is een meer uitgebreide focus op beveiliging . Het veiliger maken van pods, het voorkomen van pod trampoline breakouts, end-to-end encryptie en het maken van volledige analyses van bedreigingen voor een complete k8s bedrijfsinfrastructuur. De derde is duurzaamheid en een groeiend bewustzijn dat systemen waarop k8s en de apps erop draaien veel energie verbruiken terwijl 60 tot 80% van de CPU ongebruikt blijft. Zelfs talen kunnen energie(on)efficiënt zijn. Java is een van de meest energie-efficiënte talen, terwijl Python dat blijkbaar veel minder is door de aard van de interpreter/compiler. Bedrijven moeten allemaal plannen maken en werken aan het verminderen van de energievoetafdruk in zowel applicaties als infrastructuur. Autoscaling zal hierbij een belangrijke rol spelen. Hoogtepunten van de sessies Duurzaamheid Datacenters verbruiken wereldwijd 8% van alle opgewekte elektriciteit. We moeten dus nadenken over het effectieve gebruik van onze infrastructuur en inactieve tijd vermijden (gemiddeld is het CPU-gebruik slechts tussen 20 en 40%) als servers draaien, laat ze dan werken met zoveel mogelijk werklasten resources afsluiten wanneer ze niet nodig zijn door het toepassen van autoscaling benaderingen de coderingstechnologie die gebruikt wordt in je software, sommige programmeertalen gebruiken minder CPU. CICD / GitOps GitOps automatiseert infrastructuur updates met behulp van een Git workflow met continue integratie (CI) en continue levering (CI/CD). Wanneer nieuwe code wordt samengevoegd, voert de CI/CD pijplijn de verandering door in de omgeving. Flux is hier een goed voorbeeld van. Flux biedt GitOps voor zowel apps als infrastructuur. Het ondersteunt GitRepository, HelmRepository en Bucket CRD als de enige bron van waarheid. Met A/B- of Canary-implementaties is het eenvoudig om nieuwe functies te implementeren zonder dat dit gevolgen heeft voor alle gebruikers. Als de implementatie mislukt, kan deze eenvoudig worden teruggedraaid. Bekijk het schema van KubeCon voor meer informatie! Kubernetes Hoewel Kubernetes 1.24 een paar weken voor de start van het evenement werd uitgebracht, waren er niet veel gesprekken gericht op de kern van Kubernetes. De meeste gesprekken waren gericht op het uitbreiden van Kubernetes (met behulp van API's, controllers, operators, ...) of best practices rond beveiliging, CI/CD, monitoring ... voor wat er ook draait binnen het Kubernetes-cluster. Als je geïnteresseerd bent in de nieuwe functies die Kubernetes 1.24 te bieden heeft, kun je de officiële website bekijken . Waarneembaarheid Inzicht krijgen in hoe je applicatie draait in je cluster is cruciaal, maar niet altijd even praktisch. Dit is waar eBPF om de hoek komt kijken, dat wordt gebruikt door tools zoals Pixie om gegevens te verzamelen zonder codewijzigingen. Bekijk het schema van KubeCon voor meer informatie! FinOps Nu steeds meer mensen Kubernetes gebruiken, zijn er veel workloads gemigreerd. Al deze containers hebben een voetafdruk. Geheugen, CPU, opslag, ... moeten worden toegewezen, en ze hebben allemaal een kostprijs. Kostenbeheer was een terugkerend onderwerp tijdens de gesprekken. Het gebruik van autoscaling (capaciteit toevoegen maar ook verwijderen) om de benodigde resources aan te passen en het identificeren van ongebruikte resources maken deel uit van deze nieuwe beweging. Nieuwe diensten zoals 'kubecost' worden steeds populairder. Prestaties Een van de meest voorkomende problemen in een cluster is niet genoeg ruimte of resources hebben. Met behulp van een Vertical Pod Autoscaler (VPA) kan dit tot het verleden behoren. Een VPA analyseert en slaat geheugen- en CPU-metriek/gegevens op om zich automatisch aan te passen aan de juiste CPU- en geheugenlimieten. De voordelen van deze aanpak laten je geld besparen, verspilling voorkomen, de onderliggende hardware optimaal dimensioneren, resources op worker nodes afstemmen en de plaatsing van pods in een Kubernetes cluster optimaliseren. Bekijk het schema van KubeCon voor meer informatie! Servicemesh We weten allemaal dat het heel belangrijk is om te weten welke applicatie data deelt met andere applicaties in je cluster. Service mesh biedt verkeerscontrole binnen uw cluster(s). Je kunt elk verzoek dat wordt verzonden of ontvangen van een applicatie naar andere applicaties blokkeren of toestaan. Het biedt ook Metrics, Specs, Split, ... informatie om de gegevensstroom te begrijpen. In de lezing Service Mesh op schaal: Hoe Xbox Cloud Gaming 22k Pods beveiligt met Linkerd , legt Chris uit waarom ze voor Linkerd hebben gekozen en wat de voordelen zijn van een service mesh. Bekijk het schema van KubeCon voor meer informatie! Beveiliging Trampoline pods, klinkt leuk, toch? Tijdens een lezing van twee beveiligingsonderzoekers van Palo Alto Networks leerden we dat ze niet zo leuk zijn. Kort gezegd zijn dit pods die gebruikt kunnen worden om cluster admin privileges te krijgen. Om meer te leren over het concept en hoe ermee om te gaan, raden we je aan om de slides op de KubeCon schedule pagina te bekijken! Lachlan Evenson van Microsoft gaf een duidelijke uitleg over Pod Security in zijn The Hitchhiker's Guide to Pod Security talk. Pod Security is een ingebouwde toelatingscontroleur die Pod-specificaties evalueert aan de hand van een vooraf gedefinieerde set Pod Security-standaarden en bepaalt of de pod moet worden toegelaten of geweigerd. - Lachlan Evenson , Programmamanager bij Microsoft . Pod Security vervangt PodSecurityPolicy vanaf Kubernetes 1.23. Dus als je PodSecurityPolicy gebruikt, is dit misschien een goed moment om Pod Security en het migratiepad verder te onderzoeken. In versie 1.25 wordt de ondersteuning voor PodSecurityPolicy verwijderd. Als je PodSecurityPolicy of Pod Security niet gebruikt, is het zeker tijd om het verder te onderzoeken! Een ander terugkerend thema van deze KubeCon 2022 waren operators. Operators maken het mogelijk om de Kubernetes API uit te breiden met operationele kennis. Dit wordt bereikt door Kubernetes-controllers te combineren met bekeken objecten die de gewenste toestand beschrijven. Ze introduceren Custom Resource Definitions, custom controllers, Kubernetes of cloud resources en logging en metrics, wat het leven makkelijker maakt voor zowel Dev als Ops. Tijdens een lezing van Kevin Ward van ControlPlane leerden we echter dat er ook risico's aan verbonden zijn. Bovendien, en dat is nog belangrijker, vertelde hij ook hoe we die risico's kunnen identificeren met tools zoals BadRobot en een operator thread matrix . Bekijk de KubeCon roosterpagina voor meer informatie! Planning Telemetry Aware Scheduling helpt u om uw workloads te plannen op basis van de statistieken van uw worker nodes. U kunt bijvoorbeeld een regel instellen om geen nieuwe werklasten te plannen op worker nodes met meer dan 90% gebruikt geheugen. Het cluster zal hier rekening mee houden bij het plannen van een pod. Een andere leuke functie van deze tool is dat het ook pods opnieuw kan inplannen om ervoor te zorgen dat uw regels in lijn blijven. Bekijk de KubeCon planningspagina voor meer informatie! Cluster autoscaling Een geweldige manier voor stateless workloads om kosteneffectief te schalen is het gebruik van AWS EC2 Spot, wat reserve VM-capaciteit is die met korting beschikbaar is. Om Spot-instanties effectief te gebruiken in een K8S cluster, moet je aws-node-termination-handler gebruiken. Op deze manier kun je je werklasten van een worker node verplaatsen wanneer Spot besluit deze terug te vorderen. Een ander goed hulpmiddel is Karpenter , een hulpmiddel om Spot-instanties precies op tijd te leveren voor je cluster. Met deze twee tools kun je je stateless workloads kosteneffectief hosten! Bekijk de KubeCon schedule pagina voor meer informatie! Event-gedreven autoscaling Het gebruik van de Horizontal Pod Autoscaler (HPA) is een geweldige manier om pods te schalen op basis van statistieken zoals CPU-gebruik, geheugengebruik en meer. In plaats van te schalen op basis van statistieken, kan Kubernetes Event Driven Autoscaling (KEDA) schalen op basis van gebeurtenissen (Apache Kafka, RabbitMQ, AWS SQS, ...) en het kan zelfs schalen tot 0 in tegenstelling tot HPA. Bekijk het schema van KubeCon voor meer informatie! Wrap-up We hebben dit jaar genoten van de conferentie. We vertrokken met een geïnspireerd gevoel dat we ongetwijfeld zullen vertalen naar interne projecten, nieuwe klantprojecten zullen aanvragen en waar van toepassing zullen bespreken met bestaande klanten. Niet alleen dat, maar we zullen ook onze collega's informeren en een afterglow sessie organiseren voor de geïnteresseerden thuis in België. Als je ons blogartikel leuk vond, stuur ons dan gerust een berichtje. We zijn altijd blij als de inhoud die we publiceren ook voor jou waardevol of interessant is. Als je denkt dat we jou of je bedrijf kunnen helpen bij de adoptie van Cloud Native, stuur me dan een berichtje op peter.jans@aca-it.be. Als laatste willen we Mona bedanken voor de logistiek, Stijn en Ronny voor deze kans en de rest van het team dat achterbleef om de systemen van onze gewaardeerde klanten in de gaten te houden.

Leestijd 3 min

Robin Janssens

Op 7 en 8 december 2023 namen verschillende ACA-leden deel aan CloudBrew 2023 , een inspirerende tweedaagse conferentie over Microsoft Azure. In het decor van de voormalige Lamot brouwerij kregen bezoekers de kans om zich te verdiepen in de nieuwste cloudontwikkelingen en hun netwerk uit te breiden. Met verschillende tracks en boeiende sprekers bood CloudBrew een schat aan informatie. De intieme setting stelde deelnemers in staat om direct contact te leggen met zowel lokale als internationale experts. In dit artikel lichten we graag enkele van de meest inspirerende lezingen van deze tweedaagse cloudbijeenkomst uit: Azure-architectuur: Verstandig kiezen Rik Hepworth , Chief Consulting Officer bij Black Marble en Microsoft Azure MVP/RD, gebruikte een klantvoorbeeld waarbij .NET ontwikkelaars verantwoordelijk waren voor het beheer van de Azure infrastructuur. Hij betrok het publiek in een interactieve discussie om de beste technologieën te kiezen. Hij benadrukte verder het belang van een gebalanceerde aanpak, waarbij nieuwe kennis wordt gecombineerd met bestaande oplossingen voor effectief beheer en ontwikkeling van de architectuur. Van gesloten platform naar landingszone met Azure Policy David de Hoop , Special Agent bij Team Rockstars IT, vertelde over de Azure Enterprise Scale Architecture, een template van Microsoft die bedrijven ondersteunt bij het opzetten van een schaalbare, veilige en beheersbare cloud-infrastructuur. De template biedt richtlijnen voor het ontwerpen van een cloudinfrastructuur die kan worden aangepast aan de behoeften van een bedrijf. Een cruciaal aspect van deze architectuur is de landingszone, een omgeving die zich houdt aan ontwerpprincipes en alle applicatieportfolio's ondersteunt. Het maakt gebruik van abonnementen om applicatie- en platformbronnen te isoleren en te schalen. Azure Policy biedt een reeks richtlijnen om Azure-infrastructuur open te stellen voor een onderneming zonder in te boeten aan beveiliging of beheer. Dit geeft engineers meer vrijheid in hun Azure-omgeving, terwijl beveiligingsfuncties automatisch worden afgedwongen op tenantniveau en zelfs applicatiespecifieke instellingen. Dit zorgt voor een evenwichtige aanpak om zowel flexibiliteit als beveiliging te garanderen, zonder dat er aparte tools of technologieën nodig zijn. De grootste Azure fouten van België waarvan ik wil dat jij ervan leert! Tijdens deze sessie presenteerde Toon Vanhoutte , Azure Solution Architect en Microsoft Azure MVP, de meest voorkomende fouten en menselijke vergissingen, gebaseerd op de ervaringen van meer dan 100 Azure engineers. Aan de hand van waardevolle praktijkvoorbeelden illustreerde hij niet alleen de fouten zelf, maar bood hij ook duidelijke oplossingen en preventieve maatregelen om soortgelijke incidenten in de toekomst te voorkomen. Zijn waardevolle inzichten hielpen zowel beginnende als ervaren Azure engineers hun kennis aan te scherpen en hun implementaties te optimaliseren. Kritieke ICS SCADA-infrastructuur beschermen met Microsoft Defender Deze presentatie van Microsoft MVP/RD, Maarten Goet , richtte zich op het gebruik van Microsoft Defender voor ICS SCADA infrastructuur in de energiesector. De spreker deelde inzichten over het belang van cyberbeveiliging in deze kritieke sector en illustreerde dit met een demo waarin de kwetsbaarheden van dergelijke systemen werden gedemonstreerd. Hij benadrukte de noodzaak van proactieve beveiligingsmaatregelen en benadrukte Microsoft Defender als een krachtige tool voor het beschermen van ICS SCADA-systemen. Azure Digital Twin gebruiken in productie Steven De Lausnay , Specialist Lead Data Architecture en IoT Architect, introduceerde Azure Digital Twin als een geavanceerde technologie om digitale replica's te maken van fysieke omgevingen. Door inzicht te geven in het proces achter Azure Digital Twin, liet hij zien hoe organisaties in productieomgevingen gebruik kunnen maken van deze technologie. Hij benadrukte de waarde van Azure Digital Twin voor het modelleren, monitoren en optimaliseren van complexe systemen. Deze technologie kan een cruciale rol spelen bij het verbeteren van de operationele efficiëntie en het nemen van datagestuurde beslissingen in verschillende industriële toepassingen. Azure Platform aanbevelingen omzetten in goud Magnus Mårtensson , CEO van Loftysoft en Microsoft Azure MVP/RD, had de eer om CloudBrew 2023 af te sluiten met een boeiende samenvatting van de hoogtepunten. Met zijn onderhoudende presentatie bood hij waardevolle reflectie op de verschillende thema's die tijdens het evenement waren besproken. Het was een perfecte afsluiting van een zeer succesvolle conferentie en gaf iedere deelnemer zin om de opgedane inzichten direct in de praktijk te brengen. We kijken nu al uit naar CloudBrew 2024! 🚀

Leestijd 5 min

Peter Jans

Zoals elk jaar hield Amazon zijn AWS re:Invent 2021 in Las Vegas. Hoewel we vanwege de pandemie niet persoonlijk aanwezig konden zijn, wilden we als AWS-partner het digitale evenement graag volgen. Hieronder volgt een kort overzicht van onze hoogtepunten van het evenement voor het geval je het gemist hebt! AWS dichter bij huis AWS zal in 2022 30 nieuwe ' Local Zones' bouwen, waaronder één in onze thuisbasis: België. AWS Local Zones zijn een soort infrastructuuroplossingen die compute-, opslag-, database- en andere geselecteerde AWS-diensten in de buurt van grote bevolkings- en industriecentra plaatsen. De Belgische Local Zone zou in 2023 operationeel moeten zijn. Daarnaast zijn de mogelijkheden van AWS Outposts toegenomen . De belangrijkste verandering is dat je nu veel meer diensten op je eigen server kunt draaien die door AWS worden geleverd. Korte samenvatting: AWS Outposts is een familie van volledig beheerde oplossingen die AWS-infrastructuur en -services leveren aan vrijwel elke on-premise of edge locatie voor een consistente hybride ervaring. Outposts was voorheen alleen beschikbaar in een 42U Outposts rack-configuratie. Vanaf nu biedt AWS verschillende vormfactoren, waaronder Outposts-servers van 1U en 2U voor als er minder ruimte beschikbaar is. De verleiding is groot om er eentje voor op kantoor aan te schaffen... AWS EKS Anywhere was al eerder aangekondigd, maar is nu werkelijkheid! Met deze dienst is het mogelijk om een Kubernetes cluster op te zetten op je eigen infrastructuur of infrastructuur van je favoriete cloud provider, terwijl je het toch beheert via AWS EKS. Alle voordelen van keuzevrijheid gecombineerd met het uniforme overzicht en dashboard van AWS EKS. Wie zei dat je niet ook je cake kunt eten? Low-code om primaire focus terug te krijgen Met Amplify Studio zet AWS de volgende stap in low-code ontwikkeling. Amplify Studio is een volwaardig low-code generatorplatform dat voortbouwt op het bestaande Amplify-framework. Het platform stelt gebruikers in staat om applicaties te bouwen door middel van slepen en neerzetten met de mogelijkheid om aangepaste code toe te voegen waar nodig. Zeker iets waar we naar zullen kijken op onze volgende Ship-IT Day! Machine Learning gaat sterk(er) Altijd al willen beginnen met machine learning, maar nog niet helemaal klaar om wat van je zuurverdiende geld te investeren? Met SageMaker Studio Lab kondigde AWS een gratis platform aan waarmee gebruikers AI/ML-tools kunnen verkennen zonder zich te registreren voor een AWS-account of creditcardgegevens achter te laten. Je kunt het zelf gratis uitproberen in je browser via Jupyter notebooks ! Daarnaast kondigde AWS SageMaker Canvas aan : een visuele, no-code machine learning mogelijkheid voor business analisten. Hiermee kunnen ze aan de slag met ML zonder uitgebreide ervaring te hebben en meer inzichten krijgen in data. Het derde hoofdstuk in de SageMaker saga bestaat uit SageMaker Ground Truth Plus . Met deze nieuwe dienst huur je een team van experts in om je data te trainen en labelen, een traditioneel zeer arbeidsintensief proces. Volgens Amazon kunnen klanten verwachten tot 40% te besparen met SageMaker Ground Truth Plus. Er waren nog twee kleine aankondigingen: het AI ML Scholarschip Program , een gratis programma voor studenten om kennis te maken met ML-tools, en Lex Automated Chatbot Designer , waarmee je snel een slimme chatbot kunt ontwikkelen met geavanceerde ondersteuning voor natuurlijke taalverwerking. Netwerken voor iedereen Heb je genoeg van minder dan optimale ontvangst of een trage verbinding? Waarom bouw je niet je eigen privé 5G-netwerk? Yep: met AWS Private 5G levert Amazon de hardware, het beheer en de simkaarten waarmee je je eigen 5G-netwerk kunt opzetten. Use cases (naast het feit dat je genoeg hebt van je huidige mobiele netwerk) zijn bijvoorbeeld magazijnen of grote locaties (zoals een voetbalstadion) die een lage latency, uitstekende dekking en een grote bandbreedte vereisen. Het beste deel? Klanten betalen alleen voor het gebruik van het netwerk door de eindgebruiker. Om het netwerkthema voort te zetten, is er nu AWS Cloud WAN . Met deze dienst kunnen gebruikers een beheerd WAN (Wide Area Network) bouwen om cloud- en on-premise omgevingen te verbinden met een centrale beheer-UI op netwerkcomponentniveau en serviceniveau. Tot slot is er ook AWS Workspaces Web . Via deze dienst kunnen klanten medewerkers veilig toegang geven tot interne websites en SaaS-toepassingen. Het grote voordeel hier is dat informatie die kritisch is voor het bedrijf nooit de omgeving verlaat en geen sporen achterlaat op werkstations, dankzij een niet-persistente webbrowser. Iemand Kubernetes? Geen AWS-evenement gaat zonder Kubernetes te vermelden, en AWS re:Invent 2021 is niet anders. Amazon kondigde twee nieuwe diensten aan op het gebied van Kubernetes: AWS Karpenter en AWS Marketplace for Containers Anywhere . Met AWS Karpenter wordt het beheren van autoscaling Kubernetes-infrastructuur zowel eenvoudiger als minder beperkend. Het zorgt voor het automatisch starten van compute wanneer de belasting van een applicatie verandert. Interessant is dat Karpenter volledig open-source is, een trend die we volgens Amazon steeds meer zullen zien. AwS Marketplace for Containers Anywhere is vooral nuttig voor klanten die zich al volledig hebben gecommitteerd aan container managed platforms. Gebruikers kunnen hiermee Kubernetes-apps van derden zoeken, abonneren en implementeren vanuit de AWS Marketplace in elk Kubernetes-cluster, ongeacht de omgeving. IoT-updates Er zijn tal van kleinere updates geweest voor AWS's IoT-diensten, met name voor: GreenGrass SSM , waarmee je nu je apparaten veilig kunt beheren met AWS Systems Manager Amazon Monitron om te voorspellen wanneer onderhoud nodig is voor draaiende onderdelen in machines AWS IoT TwinMaker , om eenvoudig Digital Twins van echte systemen te maken AWS IoT FleetWise , dat gebruikers helpt om voertuiggegevens in de cloud te verzamelen in bijna-realtime. De serverloze game verbeteren In het serverloze landschap kondigde AWS serverloze Redshift , EMR , MSK en Kinesis aan . Dit maakt het mogelijk om diensten op te zetten terwijl het juiste instance-type automatisch wordt gekoppeld. Als de dienst niet in gebruik is, stopt de instance automatisch. Op deze manier betalen klanten alleen wanneer een service daadwerkelijk wordt gebruikt. Dit is vooral interessant voor experimentele services en integraties in omgevingen die niet vaak worden gebruikt. Duurzaamheid Net als ACA Group's toewijding aan duurzaamheid , is AWS serieus bezig met hun ambitie om in 2040 klimaatneutraal te zijn. Ze hebben de AWS Customer Carbon Footprint tool ontwikkeld, waarmee gebruikers de CO2-uitstoot via hun website kunnen berekenen. Andere aankondigingen waren AWS Mainframe Modernization , een verzameling tools en gidsen om bestaande mainframes over te nemen met AWS, en AWS Well-Architected Framework , een verzameling ontwerpprincipes, richtlijnen, best practices en verbeteringen om duurzaamheidsdoelen te valideren en rapporten op te stellen. We kunnen niet wachten om te gaan experimenteren met alle nieuwe toevoegingen en verbeteringen die tijdens AWS re:Invent 2021 zijn aangekondigd. Bedankt voor het lezen! Ontdek onze cloudhostingdiensten

Leestijd 4 min

Patrik Söderström

De jaarlijkse inspirerende Azure conferentie CloudBrew georganiseerd door de Azure User Group vond plaats op 12 en 13 december 2024. De beste sprekers uit heel Europa waren uitgenodigd om hun ervaringen en kennis te delen over de laatste ontwikkelingen in Azure. ACA Group is een van de partners van CloudBrew en de Azure User Group in België . Dit stelde ons niet alleen in staat om deel te nemen, maar ook om geselecteerde klanten mee te nemen in de steeds evoluerende wereld van Azure op het evenement. Met twee dagen vol actie willen we de onderwerpen die ons geraakt en geïnspireerd hebben uitlichten. Openingstoespraak: De opening keynote werd verzorgd door niemand minder dan Sakari Nahi , de CEO van Zure. Hij sprak over de vooruitgang op het gebied van AI en in het bijzonder hoe dit een impact zal hebben op de hardwerkende ingenieurs en architecten in de public cloud. Het valt niet te ontkennen dat AI een impact zal hebben op hoe we Azure gebruiken en ermee werken. Dit kan ons op verschillende niveaus zorgen baren, sommigen maken zich zorgen dat we worden vervangen door AI, terwijl anderen zich zorgen maken over privacy. Waar je je ook bevindt op deze schaal, de AI-revolutie is positief voor iedereen. We moeten onszelf zien als operators van AI, niet als vervangers. Het is altijd DNS Rik Hepworth en zijn prachtige grijze haar waren aanwezig om uit te leggen hoe het altijd DNS is. Het is altijd DNS in de zin dat wat je ook besluit te implementeren, er rekening moet worden gehouden met DNS. Hier leerden we het belang van het centraliseren van DNS met een HUB en SPOKE configuratie. De Azure Private DNS Resolver neemt het over als de go-to oplossing voor DNS Conditional Forwarding. Door dit te centraliseren in de HUB is het mogelijk om de omgeving op te schalen naar zoveel virtuele netwerken en abonnementen als nodig. Vermijd het opzetten van Private DNS-zones in individuele SPOKE-abonnementen, want dit is een recept voor rampzalig beheer als de omgeving groeit. Orkestratie vs Choreografie Aangezien we in ons dagelijks werk zelden te maken hebben met softwarearchitectuur, wisten we niet zeker wat we van deze lezing moesten verwachten. We waren echter aangenaam verrast toen Laila Bougria een van de boeiendste sessies gaf over het bouwen van op microservice gebaseerde applicatiearchitecturen. Orchestratie gebruikt een coördinatie- en beheersysteem tussen de verschillende softwarecomponenten. Choreografie daarentegen biedt decentraal aan en zorgt in sommige gevallen voor eenvoudiger onderhoud. Er is geen kaart die ze allemaal overtroeft, het hangt allemaal af van je situatie. Na deze geweldige sessie van Laila raakten we nog meer geïnteresseerd in het onderwerp. Je kunt hier meer over haar werk vinden. GPT-4 vs Starcraft II - Strategische besluitvorming met behulp van grote taalmodellen AI is overal en CloudBrew is geen uitzondering. Deze sessie van Alan Smith gaf een praktisch voorbeeld van hoe je GPT-4 kunt integreren in een bestaand systeem, in dit geval Starcraft II . Starcraft II is een strategiespel dat in 2010 is uitgebracht en waar op internet een schat aan informatie te vinden is over hoe je je tegenstander kunt verslaan. Al deze informatie is opgepikt door GPT-4 en als je het vraagt, gebaseerd op de status van het spel, zoals wat de tegenstander doet, kan het een strategie in tekstformaat bedenken om dit tegen te gaan. Dit was een live demonstratie van hoe de schermuitvoer van Starcraft II naar GPT-4 werd gestuurd. GPT-4 stuurde een reeks instructies terug over wat de volgende acties zouden zijn om je tegenstander tegen te werken en te verslaan. Deze werden vertaald naar activiteiten in het spel en we konden vol ontzag toekijken hoe GPT-4 de tegenstander versloeg. Toegegeven, in dit scenario speelde GPT-4 tegen de computer, die ook wordt beschouwd als een soort AI. AI die AI verslaat voelt alsof de cirkel rond is, op een verrassend positieve manier 🙂 Een Azure PaaS-applicatie serieus beveiligen Joonas Westlin gaf een lezing over Azure-beveiliging voor PaaS-oplossingen, en hij deed dat met een flinke dosis humor en relateerbare voorbeelden uit de praktijk. We begonnen met de basis: betaalbare, standaardoplossingen zoals Private Endpoints en Network Security Groups. Lekker eenvoudig en budgetvriendelijk. Maar hoe verder je de beveiligingsschuif opschuift, hoe serieuzer het wordt. Denk aan WAF (Web Application Firewall) en Application Gateway , die je omgeving volledig afsluiten - maar ook je budget aanzienlijk kunnen oprekken. Joonas presenteerde zijn verhaal op een manier die je regelmatig aan het lachen maakte omdat het zo relateerbaar was. Zijn anekdotes raakten precies de juiste snaar, terwijl ze ook nuttige inzichten gaven. Vooral over hoe je een slimme balans kunt vinden tussen veiligheid en kosten, zonder het gevoel te hebben dat je een fort runt. Eindigend met verbazing: Hoewel CloudBrew nog maar net voorbij is, kunnen we niet anders dan met een glimlach terugkijken. De conferentie, de sprekers en hun boeiende onderwerpen waren niets minder dan uitzonderlijk. De kennis en inzichten die we in slechts twee dagen hebben opgedaan, zouden maanden hebben gekost om elders te vergaren. We kijken nu al uit naar CloudBrew 2025 en hopen u daar ook te zien!

Leestijd 4 min

Robin Janssens

Met de groeiende behoefte aan naadloze gebruikerservaringen en robuuste beveiligingsmaatregelen is de integratie van geavanceerde oplossingen voor identiteitsbeheer zoals Azure AD B2C met platforms zoals Liferay essentieel geworden. In dit artikel wordt onderzocht hoe ACA Group een bedrijf heeft geholpen bij het succesvol implementeren van Azure B2C om hun klantenportaal te verbeteren, zodat hun gebruikers een gestroomlijnde en veilige ervaring hebben. Van het begrijpen van de grondbeginselen van Azure B2C tot het aanpakken van de integratie-uitdagingen, deze casestudy biedt waardevolle inzichten in het proces en de voordelen van moderne oplossingen voor identiteitsbeheer . Wat is Azure AD B2C? Azure AD B2C is een cloudgebaseerde identiteitsprovider die is ontworpen voor bedrijven om gebruikersidentiteiten veilig en eenvoudig te beheren. Het richt zich op externe gebruikers zoals klanten, partners en verkopers en biedt een schaalbare oplossing voor inloggegevens en identiteitsverificatie. Azure B2C is gericht op het vereenvoudigen van aanmeldings- en registratieprocessen voor gebruikers, terwijl het uitgebreide aanpassingsopties biedt om de gebruikerservaring op maat te maken en naadloos te integreren met bestaande applicaties. Belangrijkste kenmerken van Azure B2C Ondersteunt verschillende identiteitsproviders, waaronder Facebook, X en LinkedIn. Biedt een veilig kader voor het beheren van persoonlijke gegevens en zorgt voor naleving van regelgeving. Beheert de toegang tot meerdere applicaties met één account, waardoor de beveiliging wordt verbeterd. Verbetert de algehele gebruikerservaring door het belang van digitale identiteit in online interacties te erkennen. Klantcase: authenticatie klantportaal Context Deze case betreft een bedrijf dat het luchtverkeer in het Belgische luchtruim beheert en zorgt voor de veiligheid, efficiëntie en punctualiteit van vluchten. Ze houden toezicht op vluchtbeheer, navigatie, communicatiesystemen en meteorologische diensten en werken nauw samen met luchtvaartmaatschappijen, luchthavens en internationale luchtverkeersleidingscentra. Hun klantenportaal dient als een gecentraliseerd platform voor klanten om toegang te krijgen tot vitale informatie over operaties en diensten en zorgt voor transparantie en efficiënte communicatie. Met honderden dagelijkse gebruikers speelt de portal een cruciale rol in het onderhouden van efficiënte communicatie en klanttevredenheid. Aanpak oplossing We hebben deze case methodisch en gezamenlijk benaderd. We begonnen met een testontwerp om onze oplossing te schetsen, waarbij we ervoor zorgden dat deze aansloot bij de behoeften van de klant. Vervolgens bespraken we de oplossing met de klant om feedback te verzamelen. Nadat we hun input hadden overwogen, gingen we terug om onze aanpak te verfijnen. We realiseerden ons dat een op maat gemaakte oplossing nodig was en besloten om aangepaste beleidsregels te implementeren. Dit iteratieve proces stelde ons in staat om onze oplossing aan te passen en te verfijnen, zodat deze perfect voldeed aan de verwachtingen van de klant. Uitdagingen Aangepaste beleidsregels ontwikkelen om volledig te integreren met Liferay, vereiste gedetailleerde aanpassingen met behulp van XML-bestanden. Het inlogproces werd op maat gemaakt voor SAML 2.0-authenticatie, waarbij alles werd aangepast, van persoonlijke gegevens zoals namen tot voorkeuren zoals taal en zakelijke telefoon. Voldoen aan de eisen van de klant was cruciaal, dus bepaalde velden waren verplicht en andere hadden specifieke opmaakbehoeften. Elke stap, van het aanmaken van profielen tot het verzenden van gegevens naar Liferay, werd nauwkeurig aangepast aan de doelstellingen van het project. Hoewel dit project complex was, was het een spannende uitdaging die het probleemoplossend vermogen en de creativiteit van ons team liet zien. Geleerde lessen Testen door niet-technische gebruikers was een spelbreker en hielp ons problemen in een vroeg stadium op te sporen. Regelmatige updates met de klant hielden iedereen op de hoogte en stelden ons in staat om tijdig wijzigingen aan te brengen. Door niet-technische belanghebbenden erbij te betrekken en de communicatie open te houden, konden we problemen snel aanpakken en een oplossing van topkwaliteit leveren. Deze gezamenlijke aanpak bouwde vertrouwen op en zorgde ervoor dat iedereen op één lijn zat, wat leidde tot een succesvol projectresultaat. Onze bijdragen aan Azure B2C Het werken met Azure B2C liet ons zien hoe cruciaal aangepaste beleidsregels zijn voor een soepel systeem. Deze policies vormen de ruggengraat van onze SAML 2.0 integratie, waardoor identiteitsbeheer veilig en efficiënt wordt. Om de gebruikerservaring te verbeteren, ontwikkelden we een aangepast B2C inlogportaal dat is afgestemd op de behoeften van de organisatie. Dit portaal vereenvoudigt de registratie en fungeert als brug, waarbij gebruikersinformatie naar Liferay wordt overgebracht. Na registratie stromen de gebruikersgegevens naar Liferay, waar automatisch een gebruikersprofiel wordt aangemaakt. Deze integratie maakt onboarding eenvoudig, waardoor ons customer affairs team snel accountrechten kan toewijzen. Door profielen aan te maken in zowel Azure B2C als Liferay blijven de gegevens consistent op alle platforms. Zodra profielen zijn aangemaakt, controleren we de nauwkeurigheid en legitimiteit van de gebruikersinformatie. Na verificatie krijgen gebruikers toegang tot een veilig en gepersonaliseerd klantenportaal op Liferay, dat een gecentraliseerde en gestroomlijnde ervaring biedt voor alle interacties. Optimalisatie van gebruikersreizen Door aangepaste beleidsregels, SAML 2.0, Azure B2C en Liferay te integreren, hebben we een soepelere en efficiëntere gebruikerservaring gecreëerd. Deze naadloze verbinding automatiseert taken zoals het aanmaken en verifiëren van gebruikers, waardoor registratie een fluitje van een cent wordt. Het resultaat? Een sneller proces dat tijd bespaart, frustraties vermindert en de betrokkenheid en tevredenheid van gebruikers verhoogt. Conclusie De integratie van aangepaste beleidsregels, SAML 2.0, Azure B2C en Liferay creëert een solide basis voor veilige gebruikersregistratie en toegangsbeheer. Deze tools helpen organisaties bij het leveren van gepersonaliseerde, vertrouwde gebruikerservaringen. Klaar om uw user journeys te optimaliseren? Neem contact op met ons team op hello@acagroup.be. We helpen u graag op weg!

Leestijd 3 min

Peter Jans

De wereld verandert snel, zowel vanuit technologisch als milieuoogpunt. Vaak gaan deze uitdagingen hand in hand. Bijvoorbeeld door de drang naar elektrische voertuigen, slimme huizen en duurzame energie. Maar terwijl er al lange tijd aandacht is voor de auto-, productie- en landbouwindustrie, is er geen weg naar een schoner milieu zonder het aanzienlijke energieverbruik van datacenters en cloud computing aan te pakken. De koolstofvoetafdruk van cloud computing Volgens het laatste rapport van het Internationaal Energieagentschap (IEA) verbruiken datacenters wereldwijd in 2021 220 tot 320 TWh elektriciteit, wat ongeveer 0,9 tot 1,3% van de wereldwijde vraag naar elektriciteit is. Daarnaast verbruiken wereldwijde datatransmissienetwerken 260-340 TWh, of 1,1 tot 1,4% van de elektriciteit. Samen dragen datacenters en transmissienetwerken bij aan 0,9% van de energiegerelateerde uitstoot. Hoewel dit vrij lage cijfers lijken, stijgt de vraag naar datadiensten exponentieel. Het wereldwijde internetverkeer is de afgelopen tien jaar sterk toegenomen , een ontwikkeling die tijdens de pandemie nog is versneld. Sinds 2010 is het aantal internetgebruikers wereldwijd meer dan verdubbeld en is het wereldwijde internetverkeer 15 keer zo groot geworden, oftewel 30% per jaar . Dit betekent dat de ecologische voetafdruk van cloud computing iets is waar alle bedrijven, groot of klein, rekening mee moeten houden. Maar wat kun je doen zonder de rekenkracht op te offeren die nodig is om innovatie te ondersteunen en goederen en diensten te leveren zoals beloofd? Amazon Web Services (AWS) Hoewel cloud computing ook een voetafdruk met zich meebrengt, is het een veel milieuvriendelijkere manier om uw IT-systemen te beheren dan lokale servers. Daarom geloven wij dat een cloud-first benadering de sleutel is tot een duurzamere bedrijfsvoering. Vooral wanneer cloudgebaseerde technologieën worden aangedreven door hernieuwbare energie. Daarom kiest ACA Group zorgvuldig zijn partnerschappen en evalueert de impact van deze partners op het milieu. In deze context hebben we gekozen voor AWS als cloudprovider. In combinatie met onze flexibele Kubernetes-opstellingen, stelt het ons in staat om te kiezen voor de minste CO2-uitstoot terwijl we toch voldoen aan de verwachtingen van onze klanten (en deze zelfs overtreffen). Het laat zien dat de behoefte aan cloud computing niet ten koste gaat van de planeet. Maar waarom AWS? Als 's werelds meest vooraanstaande cloudprovider richt Amazon Web Services zich op efficiëntie en voortdurende innovatie in zijn wereldwijde infrastructuur. Ze zijn zelfs hard op weg om in 2025 100% hernieuwbare energie te gebruiken voor hun activiteiten. Amazon is onlangs de grootste zakelijke inkoper van hernieuwbare energie ter wereld geworden; hun investeringen leveren genoeg elektriciteit om 3 miljoen Amerikaanse huishoudens een jaar lang van stroom te voorzien. Efficiënt computergebruik Het creëren van schone energiebronnen is essentieel, maar niet minder belangrijk is het heroverwegen van de manier waarop computermiddelen worden toegewezen. In een rapport over cloudefficiëntie toonde 451 Research aan dat de infrastructuur van AWS 3,6 keer energiezuiniger is dan de mediaan van de datacenters van Amerikaanse bedrijven die zij onderzochten. Amazon schrijft deze grotere efficiëntie onder andere toe aan het verwijderen van de centrale ononderbreekbare stroomvoorziening uit hun dataontwerp en het integreren van kleine batterijpakketten en aangepaste voedingen in de serverracks. Deze veranderingen samen verminderen het energieomzettingsverlies met ongeveer 35%. De servers zelf zijn ook efficiënter: hun Graviton2 CPU's zijn extreem energiezuinig en bieden betere prestaties per watt dan elke andere processor die momenteel in gebruik is in Amazon datacenters. AWS biedt onbeperkte toegang tot cloud computing en diensten. Hoewel hier een prijskaartje aan hangt, verlaagt efficiënt gebruik van bronnen niet alleen de kosten, maar indirect ook de CO2-uitstoot. Hoe kun je dit bereiken? Bouw applicaties die efficiënt gebruik maken van hulpbronnen. Verbruik resources met de laagst mogelijke voetafdruk. Maximaliseer de output van de gebruikte bronnen. Verminder de hoeveelheid gegevens en de afstand die over het netwerk wordt afgelegd. Gebruik bronnen just-in-time. ➡️ Benieuwd hoe we bij ACA Group onze cloudstacks opzetten voor maximale duurzaamheid zonder in te leveren op stroom, beschikbaarheid en flexibiliteit? Praat hier met ons !

Leestijd 7 min

Bregt Coenen

Binnen ACA werken meerdere teams aan verschillende (of dezelfde!) projecten. Elk team heeft zijn eigen expertisedomeinen, zoals het ontwikkelen van software op maat, marketing en communicatie, mobiele ontwikkeling en meer. De teams die gespecialiseerd zijn in Atlassian-producten en cloud-expertise combineerden hun kennis om een zeer beschikbare Atlassian-stack op Kubernetes te creëren. Niet alleen konden we op deze manier onze interne processen verbeteren, we konden deze oplossing ook aan onze klanten aanbieden! In deze blogpost leggen we uit hoe onze Atlassian- en cloudteams een hoogbeschikbare Atlassian-stack bovenop Kubernetes hebben gebouwd. We bespreken ook de voordelen van deze aanpak en de problemen die we onderweg zijn tegengekomen. Hoewel we er verdomd dichtbij zijn, zijn we toch niet perfect 😉 Tot slot bespreken we hoe we deze setup monitoren. De opzet van onze Atlassian-stack Onze Atlassian stack bestaat uit de volgende producten: Amazon EKS Amazon EFS Atlassian Jira Data Center Atlassian Confluence gegevenscentrum Amazon EBS Atlassian Bitbucket datacenter Amazon RDS Zoals je kunt zien, gebruiken we AWS als cloud provider voor onze Kubernetes setup. We maken alle resources aan met Terraform. We hebben een aparte blogpost geschreven over hoe onze Kubernetes setup er precies uitziet. Je kunt het hier lezen ! De afbeelding hieronder zou je een algemeen idee moeten geven. Het volgende diagram geeft je een idee van de opzet van ons Atlassian Data Center. Hoewel er een paar verschillen zijn tussen de producten en de opstellingen, blijft de kern hetzelfde. De applicatie wordt gestart als een of meer pods die worden beschreven door een StatefulSet. De pods worden node-0 en node-1 genoemd in het bovenstaande diagram. Het eerste verzoek wordt naar de load balancer gestuurd en wordt doorgestuurd naar de node-0 pod of de node-1 pod. Verkeer is sticky, dus al het volgende verkeer van die gebruiker wordt naar node-1 gestuurd. Zowel pod-0 als pod-1 hebben persistente opslag nodig die gebruikt wordt voor de plugin cache en indexen. Op elk van de pods wordt een ander Amazon EBS volume gemount. De meeste gegevens zoals je JIRA issues, Confluence ruimtes, ... worden opgeslagen in een database. De database wordt gedeeld, node-0 en node-1 maken beide verbinding met dezelfde database. We gebruiken meestal PostgreSQL op Amazon RDS. De node-0 en node-1 pod moeten ook grote bestanden delen die we niet in een database willen opslaan, bijvoorbeeld bijlagen. Hetzelfde Amazon EFS volume wordt op beide pods gemount. Wanneer er wijzigingen worden aangebracht, bijvoorbeeld een bijlage wordt geüpload naar een issue, is de bijlage onmiddellijk beschikbaar op beide pods. We gebruiken CloudFront (CDN) om statische assets te cachen en de responstijden op het web te verbeteren. De voordelen van deze opzet Door deze opzet te gebruiken, kunnen we gebruikmaken van de voordelen van Docker en Kubernetes en de datacenterversies van de Atlassian-tooling. Er zijn veel voordelen verbonden aan deze manier van werken, maar we hebben de belangrijkste voordelen hieronder opgesomd. Het is een zelfherstellend platform : containers en worker nodes vervangen zichzelf automatisch als er een storing optreedt. In de meeste gevallen hoeven we niets te doen en zorgt de stack voor zichzelf. Natuurlijk is het nog steeds belangrijk om storingen te onderzoeken, zodat je ze in de toekomst kunt voorkomen. Precies nul downtime implementaties : wanneer we de eerste node binnen het cluster upgraden naar een nieuwe versie, kunnen we de oude versie nog steeds aan onze klanten serveren op de tweede. Zodra de upgrade is voltooid, wordt de nieuwe versie geserveerd vanaf het eerste knooppunt en kunnen we het tweede knooppunt upgraden. Op deze manier blijft de applicatie beschikbaar, zelfs tijdens upgrades. Deployments zijn voorspelbaar : we gebruiken dezelfde Docker-container voor ontwikkeling, staging en productie. Daarom hebben we er vertrouwen in dat de container in onze productieomgeving kan starten na een succesvolle deploy naar staging. Applicaties met hoge beschikbaarheid: als er een storing optreedt op een van de nodes, kan het verkeer worden omgeleid naar de andere node. Op deze manier heb je de tijd om het probleem te onderzoeken en de kapotte node te repareren terwijl de applicatie beschikbaar blijft. Het is mogelijk om gegevens van het ene naar het andere knooppunt te synchroniseren . Zo kan het synchroniseren van de index van de ene node naar de andere om een corrupte index te herstellen in slechts enkele seconden gebeuren, terwijl een volledige herindexering veel langer kan duren. Je kunt een hoog beveiligingsniveau implementeren op alle lagen (AWS, Kubernetes, applicatie, . ..) AWS CloudTrail voorkomt ongeautoriseerde toegang op AWS en stuurt een waarschuwing in geval van een afwijking. AWS Config voorkomt wijzigingen in AWS-beveiligingsgroepen. Je kunt meer te weten komen over hoe je je cloud kunt beveiligen met AWS Config in onze blogpost. Terraform zorgt ervoor dat wijzigingen op de AWS-omgeving door het team worden goedgekeurd voordat ze worden uitgerold. Aangezien het upgraden van Kubernetes master en worker nodes weinig tot geen impact heeft, draait de stack altijd op een recente versie met de laatste beveiligingspatches. We gebruiken een combinatie van namespacing en RBAC om ervoor te zorgen dat applicaties en implementaties alleen toegang hebben tot bronnen binnen hun naamruimte met de minste privileges . Netwerkbeleid wordt uitgerold met Calico. We weigeren standaard al het verkeer tussen containers en staan alleen specifiek verkeer toe. We gebruiken recente versies van de applicaties van Atlassian en implementeren beveiligingsberichten wanneer deze door Atlassian worden gepubliceerd. Geïnteresseerd om zelf de kracht van Kubernetes te benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen! {% module_block module "widget_3d4315dc-144d-44ec-b069-8558f77285de" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Apply the power of Kubernetes"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %} De kracht van Kubernetes toepassen Problemen die we tegenkwamen tijdens de installatie De migratie naar deze stack was niet alleen maar leuk en aardig. We zijn onderweg zeker een aantal moeilijkheden en uitdagingen tegengekomen. Door ze hier te bespreken, hopen we dat we jouw migratie naar een vergelijkbare setup kunnen vergemakkelijken! Sommige plugins (meestal oudere plugins) werkten alleen op de standalone versie van de Atlassian applicatie. We moesten een alternatieve plugin vinden of ondersteuning van een leverancier gebruiken om dezelfde functionaliteit op Atlassian Data Center te krijgen. We moesten enkele wijzigingen aanbrengen in onze Docker-containers en netwerkbeleid (bijv. firewallregels) om ervoor te zorgen dat beide nodes van een applicatie met elkaar konden communiceren. De meeste applicaties hebben wat extra tools in de container. Bijvoorbeeld Synchrony voor Confluence, ElasticSearch voor BitBucket, EazyBI voor Jira, enzovoort. Deze extra tools moesten allemaal gerefactored worden voor een multi-node opstelling met gedeelde gegevens. In onze vorige opstelling draaide elke applicatie op zijn eigen virtuele machine. In een Kubernetes-context zijn de applicaties verspreid over een aantal worker nodes. Daarom kan één worker node meerdere applicaties draaien. Elke node van elke applicatie wordt gepland op een worker node die voldoende resources beschikbaar heeft. We moesten een goed plaatsingsbeleid implementeren zodat elk knooppunt van elke applicatie voldoende geheugen beschikbaar heeft. We moesten er ook voor zorgen dat een applicatie een andere applicatie niet kon beïnvloeden als deze om meer resources vroeg. Er waren ook enkele uitdagingen met betrekking tot load balancing. We moesten een aangepast sjabloon maken voor nginx ingress-controller om ervoor te zorgen dat websockets correct werken en dat alle gezondheidscontroles binnen de applicatie een gezonde status rapporteren. Daarnaast hadden we een andere loadbalancer en URL nodig voor ons BitBucket SSH-verkeer in vergelijking met ons webverkeer naar de BitBucket UI. Onze vorige installatie bevatte veel gegevens, zowel op het bestandssysteem als in de database. We moesten alle gegevens migreren naar een Amazon EFS-volume en een nieuwe database in een nieuw AWS-account. Het was een uitdaging om een manier te vinden om een consistent synchronisatieproces te hebben dat ook niet te lang duurde, omdat tijdens de migratie alle applicaties down waren om gegevensverlies te voorkomen. Uiteindelijk konden we aan deze criteria voldoen en konden we succesvol migreren. Onze Atlassian-stack monitoren We gebruiken de volgende tools om alle resources binnen onze setup te monitoren Datadog om alle componenten te monitoren die zijn gemaakt binnen onze stack en om logging van alle componenten te centraliseren. Je kunt meer lezen over het monitoren van je stack met Datadog in onze blogpost hier . NewRelic voor APM-monitoring van het Java-proces (Jira, Confluence, Bitbucket) binnen de container. Als onze monitoring een afwijking detecteert, wordt er een alert aangemaakt binnen OpsGenie . OpsGenie zorgt ervoor dat deze waarschuwing naar het team of de oproepkracht wordt gestuurd die verantwoordelijk is voor het oplossen van het probleem. Als de oproepkracht de waarschuwing niet op tijd bevestigt, wordt de waarschuwing geëscaleerd naar het team dat verantwoordelijk is voor die specifieke waarschuwing. Conclusie Kortom, we zijn erg blij dat we zijn overgestapt op deze nieuwe stack. De combinatie van de voordelen van Kubernetes en de Atlassian Data Center versies van Jira, Confluence en BitBucket voelt als een grote stap in de goede richting. We hebben elke dag profijt van de verbeteringen op het gebied van self-healing, deployment en monitoring en het onderhoud is een stuk eenvoudiger geworden. Geïnteresseerd in je eigen Atlassian Stack? Wil je ook de kracht van Kubernetes benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen ! Ons Atlassian hostingaanbod

Leestijd 7 min

Patrik Söderström

Stel je voor dat je je cloudstrategie zou kunnen omvormen tot een fijn afgestelde machine die de kosten verlaagt en maximale bedrijfswaarde oplevert. Dat is precies wat we voor een van onze klanten hebben gedaan door FinOps met Azure te implementeren. Door middel van gerichte optimalisaties en een sterke focus op organisatorische afstemming hebben we onze klant geholpen duizenden euro's te besparen op zijn Azure-factuur, terwijl we een duurzaam raamwerk hebben opgezet om de cloudkosten onder controle te houden. Nieuwsgierig naar hoe FinOps je kan helpen om werkkosten te optimaliseren en beter te schalen? Lees er alles over in deze blog. Langlopende geschiedenis in CapEx-kostenbetaling Deze grote organisatie is al een paar jaar klant bij ACA Group. Sinds een tijdje verplaatsen ze steeds meer workload van on premise naar Azure. De financiële afdeling was nog steeds bezig met de budgettering en vertrouwde op Capital Expenditure (CapEx) , waarbij de IT-infrastructuurkosten vooraf worden betaald en bekend zijn. Dit in tegenstelling tot Operational Expenditure (OpEx) , waarbij de kosten dagelijks fluctueren op basis van het daadwerkelijke gebruik van de digitale middelen die in Azure worden verbruikt. Onze klant had een substantieel maandelijks budget toegewezen voor Azure, dat consequent werd nageleefd. Daardoor was er geen interne aanleiding om FinOps-praktijken te onderzoeken. Hoe ACA een aanzienlijke IT-kostenbesparing ontdekte Terwijl ACA deze klant hielp met de migratie van zijn werklast, zagen we een bekend patroon: FinOps was nooit overwogen. Virtuele machines voor alle omgevingen draaiden 24/7 zonder Reserved Instances en niet-productie Storage Accounts maakten gebruik van dure Geo-replicatie. Dit zette ons aan tot het maken van een snel overzicht van mogelijke besparingen, die we samen met een volledige FinOps-oefening voorstelden. De onmiddellijke besparingen waren zo overtuigend dat de klant snel akkoord ging met ons voorstel. Wat is een FinOps-oefening? Als we het hebben over FinOps, verwijzen we naar de standaarden die zijn opgesteld door de FinOps foundation . Dit is een groot project van de Linux Foundation met een enorme community van meer dan 23.000 leden en 10.000 bedrijven. In een FinOps-oefening begeleiden we onze klanten door twee deliverables: FinOps beoordeling: Dit richt zich op de organisatorische afstemming van onze klant, waarbij we benadrukken dat FinOps een gedeelde verantwoordelijkheid is. Een technicus die een resource inzet in Azure moet rekening houden met kosten zoals grootte en SKU, terwijl de zakelijke afdeling moet zorgen voor voldoende budget voor projecten en resources. Deze mentaliteit moet zich uitstrekken over de hele organisatie. Technische evaluatie: Dit richt zich op de huidige setup en hoe deze kan worden geoptimaliseerd om kosten te besparen. We analyseren de volledige Azure-omgeving om optimalisatiekansen te detecteren. Kostenbesparing vs. waardemaximalisatie Het doel van FinOps is niet om de clouduitgaven te minimaliseren, maar om de waarde die onze klanten krijgen door het gebruik van cloudservices te maximaliseren . Dit onderscheid is essentieel, maar wordt vaak verkeerd begrepen. Elke resource in Azure moet worden gebruikt op een manier die de hoogst mogelijke bedrijfswaarde oplevert. Het maximaliseren van de bedrijfswaarde helpt ook de ecologische voetafdruk van onze klanten te minimaliseren. Het is een resultaat dat nauw aansluit bij ACA's streven naar duurzaamheid . De webapplicatie van de klant optimaliseren Laten we eens kijken naar de webapplicatie van onze klant die draait op een Azure App Service. Elke gebruikersinteractie genereert een belasting voor het systeem en waarde voor het bedrijf. Laten we voor het gemak zeggen dat de bedrijfswaarde 1 EUR is elke keer dat een gebruiker de webapplicatie opent. Met duizenden gebruikers levert de applicatie 1000 euro aan waarde. Het is onze taak om ervoor te zorgen dat de App Service is geoptimaliseerd om deze vraag effectief af te handelen, zodat de bedrijfswaarde wordt gemaximaliseerd. Als we de App Service moeten opschalen, is dat een goede zaak! Zolang we de meest efficiënte middelen en instellingen gebruiken, vergroten we de capaciteit en helpen we de klant om nog meer waarde te genereren. Selecteren van de belangrijkste aandachtspunten met alle belanghebbenden Het FinOps Assessment omvat meerdere workshops met de belangrijkste stakeholders van onze klant. We brachten de Finance, Business, Engineering en Operations van de klant samen om te laten zien hoe zij allemaal een rol spelen in de cloudkosten. Met meer dan 20 Target Capability Scopes in FinOps selecteert de klant een paar belangrijke gebieden om zich op te richten voor optimalisatie. In dit geval selecteerde de klant het volgende: Anomaliebeheer Anomaliebeheer richt zich op onverwachte of abnormale uitgavenpatronen in de cloud. In 2024 ervoer de klant bijvoorbeeld een stijging in de kosten voor een schaalset voor virtuele machines gedurende een paar weken. Ze realiseerden zich dat detectie te lang duurde en wilden betere controles om dit te voorkomen. Tariefoptimalisatie Tariefoptimalisatie zorgt ervoor dat de meest kosteneffectieve prijsmodellen en kortingen worden gebruikt. Voordat we met de FinOps-oefening begonnen, hadden we al potentiële besparingen geïdentificeerd, bijvoorbeeld door Reserved Instances te gebruiken. Daarnaast analyseerden we het tarief dat ze betaalden voor Azure resources. Werklast optimalisatie Workload Optimization zorgt ervoor dat resources zoals App Services en Virtual Machines efficiënt worden gebruikt. Is het bijvoorbeeld zinvol voor een niet-productieomgeving om de resources 24/7 te laten draaien? Doelmogelijkheden beoordelen via workshops Samen met de klant stellen we doelen voor elke Target Capability. Ze zeiden bijvoorbeeld dat Anomaly Management erg belangrijk voor ze is en dat ze op dat gebied een Knowledge Leader willen worden. Tijdens de workshops met alle belanghebbenden was het onze rol om de juiste vragen te stellen om de geselecteerde Target Capability Scopes te beoordelen. Voor Anomaly Management werd het duidelijk dat ze nog in de beginfase zaten, waardoor ze een "1/Deeltelijke Kennis" evaluatie kregen in dat onderdeel. Toen alle workshops waren afgerond, konden we een eindoordeel vellen over alle Target Capability Scores. Dit gaf de klant een benchmark, wat betekent dat we bij de volgende evaluatie over 4 maanden kunnen zien hoe ver ze zijn gekomen met betrekking tot hun doelen. In technische details duiken Nu de workshops achter de rug waren, konden we ons richten op het geschreven rapport en verder duiken in de technische details van de Azure-omgeving van de klant. Dit bestond uit twee delen: Deel 1: Gegevens verzamelen We draaiden scripts voor het verzamelen van informatie om configuratiedetails te extraheren en in een leesbaarder formaat te presenteren. Deel 2: Handmatige beoordeling We analyseerden handmatig de resultaten van tools zoals Azure Cost Management en Advisor . De belangrijkste gebieden voor kostenbesparingen Met zowel de uitvoer van de scripts als de gegevens van de portal, zagen we dat de volgende gebieden de grootste besparingen konden opleveren: Een besparingsplan implementeren / gereserveerde instanties Herconfigureer redundantie voor alle Storage Accounts , ze waren allemaal ingesteld op: Geo Redundante Opslag (GRS) Niet-productie naar lokale redundante opslag (LRS) Productie naar Zone Redundante Opslag (ZRS) Afsluiten en verwijderen van computermiddelen plannen voor niet-productie Implementeer Governance framework (Azure Policies ) om inzet van overmatige SKU's te voorkomen. Bijvoorbeeld, dure Azure Virtual Machines met nVidia-videokaarten moeten worden verboden. Implementeer budgetdrempels en waarschuwingen bij afwijkingen Implementeer de FinOps Toolkit samen met de PowerBI-rapportage Gebruik maken van Anodot voor één enkel venster op hun meerdere omgevingen We hebben onze bevindingen en aanbevelingen gebundeld in een schriftelijk rapport. Samen met de klant beoordeelden we het rapport en stippelden we vervolgstappen uit. 💡 Een van de aanbevelingen was om de FinOps Toolkit te implementeren. Dit is een set besturingselementen, Power BI-rapporten en werkboeken die zijn afgestemd op het FinOps-raamwerk. We waren blij om te zien dat ze dit samen met onze andere aanbevelingen hebben omarmd. Vooruitkijken met hernieuwde focus op bedrijfswaarde In de toekomst zal de klant Azure blijven gebruiken voor zijn workload. Het verschil vanaf nu is dat ze het zullen doen met de mindset van het maximaliseren van de bedrijfswaarde. Over vier maanden zal ACA de status van de FinOps-reis opnieuw beoordelen en hen helpen meten hoe ver ze zijn gekomen. De langetermijnstrategie houdt ook in dat ACA gebruikmaakt van de strategische samenwerking met Anodot voor FinOps . Samen verleggen we de grenzen van FinOps door kostenefficiëntie te combineren met carbon accountability. Dit zorgt voor een standaard toolset en een uniforme zichtbaarheid van FinOps in al hun omgevingen. ➡️ Bij ACA Group zijn we experts in FinOps! Laat ons u begeleiden tijdens het FinOps-traject om ervoor te zorgen dat u het volledige potentieel van uw cloudinvestering benut. {% module_block module "widget_a0726d77-6dd9-452b-ade6-cf5fd08a91b1" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Check out FinOps services"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 6 min

Patrik Söderström

In België is er een gezegde: "Elke Belg wordt geboren met een baksteen in de maag". Dit weerspiegelt de diepgewortelde drang van het land om huizen te bouwen die lang meegaan. Maar dit principe is niet alleen van toepassing op huizen, het geldt ook voor je cloudinfrastructuur. Zonder een sterke fundering lopen je Azure workloads het risico instabiel, inefficiënt of zelfs kwetsbaar te worden. Dat is waar het Well Architected Framework (WAF) van Microsoft om de hoek komt kijken. Lees verder om te ontdekken hoe de vijf pijlers van dit framework je cloud workload kunnen veranderen in een structuur die gebouwd is om lang mee te gaan. Wat is het Well Architected Framework (WAF)? Het Well Architected Framework helpt je bij het bouwen van veilige, goed presterende, veerkrachtige en efficiënte infrastructuurapplicaties op Azure. Door de richtlijnen in dit framework te volgen, zorg je ervoor dat je cloudinfrastructuur de aanbevelingen en standaarden van Microsoft volgt. Dit framework bestaat uit vijf pijlers: Betrouwbaarheid Beveiliging Kostenoptimalisatie Operationele uitmuntendheid Prestatie-efficiëntie ( Afbeeldingsbron: https: //learn.microsoft.com/en-us/azure/well-architected/) Elk van deze pijlers biedt waardevolle richtlijnen en best practices, maar ze brengen ook compromissen met zich mee. Elke beslissing - financieel of technisch - heeft zijn eigen overwegingen. Het beveiligen van werklasten is bijvoorbeeld belangrijk, maar brengt extra kosten en mogelijke technische implicaties met zich mee. Laten we de vijf pijlers van het Well Architected Framework eens nader bekijken. Betrouwbaarheid Storingen zijn onvermijdelijk, hoe graag we ook anders zouden willen. Daarom is het ontwerpen van systemen met faalmogelijkheden in gedachten cruciaal. Een workload moet storingen overleven en toch diensten blijven leveren zonder onderbreking. Dit vereist meer dan alleen het ontwerpen van je werklast voor storingen, het betekent ook het stellen van betrouwbare hersteldoelen en het uitvoeren van voldoende testen. Eerst moet je de betrouwbaarheidsdoelen vaststellen. Immers, alles Geo redundant maken is geweldig - maar komt met een prijs voor het bedrijf. Zodra je betrouwbaarheidsdoelen zijn geïdentificeerd, is de volgende stap om het redundantieniveau in kaart te brengen voor de Azure-technologie. Alleen rekening houden met de computerdelen van een applicatie is niet genoeg, je moet ook rekening houden met de ondersteunende componenten, zoals netwerk, data en andere infrastructuurlagen. Diepgaande duik in de Microsoft checklist: https://learn.microsoft.com/en-us/azure/well-architected/reliability/checklist Beveiliging Alle workloads moeten worden gebouwd rond de zero-trust benadering. Een veilige workload is bestand tegen aanvallen en zorgt tegelijkertijd voor vertrouwelijkheid, integriteit en beschikbaarheid. Net als beschikbaarheid zijn er voor vertrouwelijkheid en integriteit meerdere opties - elk met hun eigen impact op kosten en complexiteit. Hoe belangrijk is bijvoorbeeld encryptie in gebruik ? Het beantwoorden van deze vraag kan uw oplossing aanzienlijk beïnvloeden. Beveiliging is geen oplossing die uit één laag bestaat; het moet op elk niveau worden toegepast. Hoewel het standaard is om al het inkomende verkeer (ingress) door een firewall te leiden, moet hetzelfde worden gedaan voor het uitgaande verkeer (egress). Het is essentieel dat al het uitgaande verkeer wordt goedgekeurd en door een firewall wordt geleid. Er zijn extra manieren om de communicatie binnen uw Azure-omgeving te beveiligen. Het gebruik van Private Endpoints is essentieel voor veilige communicatie tussen applicatiecomponenten en biedt een betere bescherming in vergelijking met Service Endpoints , die goedkoper zijn maar het risico van data exfiltratie met zich meebrengen. Vergeet ook Azure DDoS Protection niet . DDoS-aanvallen kunnen elk publiek toegankelijk eindpunt aanvallen, mogelijk downtime veroorzaken en uw omgeving dwingen om op en uit te schalen. Dit vertraagt niet alleen je werklast, maar laat je ook achter met een hoge verbruiksrekening. De uitgebreide checklist van Microsoft is hier beschikbaar: https://learn.microsoft.com/en-us/azure/well-architected/security/checklist Kostenoptimalisatie Elk architectuurontwerp en elke workload wordt gedreven door bedrijfsdoelen. De focus van deze pijler ligt niet op het minimaliseren van de kosten. Het gaat om het vinden van de meest kosteneffectieve oplossing. Deze pijler sluit nauw aan bij het FinOps-raamwerk dat we hier hebben behandeld . Een goede eerste stap is het maken van een kostenmodel om de initiële kosten, run rates en lopende kosten in te schatten. Dit model biedt een basislijn om de werkelijke kosten van de omgeving op dagelijkse basis te vergelijken. Het werk stopt hier niet, het is essentieel om anomaliemeldingen in te stellen die je op de hoogte stellen wanneer de verwachte basislijn wordt overschreden. Het is ook belangrijk om de schaalbaarheid van je applicatie te optimaliseren. Kunnen uw resources zowel naar buiten als naar boven worden geschaald? Welke aanpak is het meest kosteneffectief en levert de beste resultaten? Bepaalde applicaties kunnen een prestatieplateau bereiken bij het opschalen, wat het moment is waarop je cpu en geheugen toevoegt. Misschien kan de applicatie slechts een kleine extra belasting aan wanneer u 256 GB geheugen bereikt. In plaats daarvan kan het voordeliger zijn om uit te schalen door meer instanties toe te voegen in plaats van simpelweg op te schalen met extra rekenkracht. De uitgebreide checklist van Microsoft is hier beschikbaar: https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/checklist Operationele uitmuntendheid De kern van Operational Excellence zijn DevOps-praktijken, die de operationele procedures definiëren voor ontwikkelpraktijken, observeerbaarheid en releasebeheer. Een belangrijk doel in deze pijler is het verminderen van de kans op menselijke fouten. Het is belangrijk om implementaties en werklast te benaderen met een langetermijnvisie. Neem het onderscheid tussen ClickOps en DevOps als voorbeeld. Hoewel het verleidelijk is om snel resources in te stellen met behulp van de Azure Portal (ClickOps), bouwt dit een technische schuld op. In plaats daarvan helpt een DevOps-aanpak je om een duurzamere, efficiëntere en geautomatiseerde workflow voor de toekomst op te bouwen. Lees onze blog over de overstap van ClickOps naar DevOps voor meer informatie. Gebruik altijd een gestandaardiseerde Infrastructure as Code (IaC) aanpak. Formaliseer de manier waarop je operationele taken afhandelt met duidelijke documentatie, checklists en automatisering. Dit sluit aan bij wat we hebben besproken onder Veerkracht , maar richt zich op processen. Zorg ervoor dat je een strategie hebt om onverwachte uitrolproblemen aan te pakken en snel te herstellen. De uitgebreide checklist van Microsoft is hier beschikbaar: https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/checklist Prestatie-efficiëntie Bij deze pijler gaat het om het vermogen van je workload om zich aan te passen aan een veranderende vraag. Je applicatie moet een verhoogde belasting aankunnen zonder dat dit ten koste gaat van de gebruikerservaring. Denk na over de drempels die je gebruikt om je applicatie te schalen. Hoe snel kunnen Azure resources op- of afschalen? Denk aan verkeerspatronen, want er kan een hoge belasting zijn tijdens bepaalde uren, zoals 's ochtends. Misschien kun je het schalen van tevoren plannen om ervoor te zorgen dat resources beschikbaar zijn wanneer dat nodig is. De algemene aanbeveling is om van performance een prioriteit te maken in elke fase van het ontwerp. Tijdens elke fase moet je de prestaties regelmatig testen en meten. Dit levert waardevolle inzichten op en helpt je potentiële problemen te identificeren en aan te pakken voordat het problemen worden. De checklist van Microsoft is waardevol: https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/checklist Begin vandaag nog met het optimaliseren van je Azure workload! Ons team van experts staat klaar om je te helpen bij het toepassen van het Well Architected Framework op je Azure omgeving. Laten we ervoor zorgen dat je workload veilig, kosten-geoptimaliseerd en klaar voor de toekomst is. {% module_block module "widget_0f5df892-336b-43b8-ad2c-759301a948f2" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Reach out to us now"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 7 min

Patrik Söderström

Voor effectief cloudbeheer in de huidige digitale wereld eisen organisaties snelheid, veiligheid en efficiëntie. Veel organisaties vertrouwen echter nog steeds op een handmatige configuratieaanpak die bekend staat als ClickOps , waarbij het Azure-portaal wordt gebruikt voor implementaties. Hoewel ClickOps eenvoudig is om mee te beginnen, kan het resulteren in tragere implementatietijden, verkeerde configuraties en beperkte schaalbaarheid. De oplossing is een Infrastructure as Code (IaC) en DevSecOps mentaliteit. Deze blog behandelt: De zes belangrijkste uitdagingen van ClickOps Hoe IaC en DevSecOps deze uitdagingen oplossen Praktische stappen om je Azure-omgeving te beveiligen en te schalen De uitdagingen van ClickOps (en hun DevSecOps-oplossingen) Volgens het Global DevSecOps-rapport van juli 2024 heeft slechts 56% van de organisaties DevSecOps-praktijken geïmplementeerd. Hierdoor vertrouwen veel organisaties op ClickOps, waarbij ze handmatig infrastructuur implementeren via de Azure portal GUI. ClickOps biedt een lage instapdrempel, waardoor het verleidelijk is voor teams om snel infrastructuur op te zetten zonder enig governance framework. Hoewel deze aanpak eenvoudig is om mee te beginnen, zal het na verloop van tijd leiden tot een groeiende technische schuld en operationele uitdagingen. Hieronder verkennen we de zes grootste uitdagingen van ClickOps en hoe IaC en DevSecOps deze kunnen overwinnen . 1) Technische schuld met verborgen kosten ClickOps lijkt misschien een eenvoudige manier om resources in Azure in te zetten. Het is tenslotte maar een paar klikken in het portaal, toch? Maar naarmate organisaties schalen, wordt deze aanpak een kostbaar knelpunt. Bijvoorbeeld: Het inzetten van een virtuele machine in de Azure portal vereist het navigeren door acht tabbladen, elk met belangrijke informatie die correct moet worden ingevuld voordat de resource kan worden ingezet. Hoewel dit beheersbaar is voor een enkele virtuele machine, wordt het steeds moeilijker om consistente en foutloze invoer te garanderen voor grotere implementaties. Na verloop van tijd worden de beperkingen van ClickOps pijnlijk duidelijk. Routinetaken, zoals het toevoegen van extra schijven aan meerdere virtuele machines met specifieke configuraties, zijn tijdrovende en repetitieve processen. De oplossing: Het automatiseren van implementaties met IaC vermindert de technische schuld Met DevSecOps en Infrastructure as Code (IaC) worden implementaties geautomatiseerd en ingezet volgens het gedefinieerde beveiligingsbeleid. Aanpassingen, zoals het wijzigen of bijwerken van resources zoals virtuele machines, is een kwestie van parameters bijwerken en de deployment pipeline starten. 2) Langzamere time-to-market met repetitieve taken ClickOps brengt veel handmatig en repetitief werk met zich mee en verhoogt het risico op menselijke fouten. Het instellen van meerdere resources met vergelijkbare instellingen vertraagt de time-to-market, vooral in cloudomgevingen waar snelheid cruciaal is. De oplossing: Gestroomlijnde implementatie met herbruikbare IaC-sjablonen IaC biedt herbruikbare bibliotheken en catalogi van vooraf geconfigureerde resources. Teams kunnen omgevingen sneller implementeren en kostenefficiëntere setups van cloudresources gebruiken. 3) Meerdere omgevingen beheren ClickOps maakt het moeilijk om consistentie te behouden tussen verschillende omgevingen, zoals test en productie. Handmatige setup vereist vaak handmatige controles om ervoor te zorgen dat omgevingen identiek zijn, wat niet alleen inefficiënt is, maar ook vatbaar voor fouten. De oplossing: Consistentie door IaC automatisering Infrastructure as Code stelt teams in staat om een testomgeving te gebruiken als blauwdruk voor andere soorten omgevingen, zoals productie. De blauwdruk voorkomt handmatig vergelijken en zorgt ervoor dat beide omgevingen identiek zijn. Hetzelfde geldt voor wijzigingen op infrastructuur. Een wijziging kan worden voorbereid, getest en gevalideerd in een testomgeving, waardoor de uitrolstress en fouten in de productieomgeving worden verminderd. 4) Gebrek aan samenwerking en versiebeheer In ClickOps ontbreekt het bij wijzigingen aan de infrastructuur vaak aan versiebeheer en transparantie. Het is moeilijk voor teams om effectief te coördineren en bij te houden wie welke wijzigingen heeft gemaakt. De oplossing: IaC als de enige bron van waarheid Zelfs als je met kleine teams werkt, fungeert IaC als de enige bron van de waarheid. Het beschrijft de feitelijke configuratie en inrichting van de cloudomgeving. Wijzigingen worden ook bijgehouden op wie, wat en wanneer ze zijn toegepast. Het werken met Pull Requests op GIT kan teams dwingen om wijzigingen aan te vragen voordat ze worden toegepast op de daadwerkelijke omgeving, waardoor een extra validatielaag wordt gecreëerd. 5) Beperkingen voor noodherstel In het geval dat een omgeving wordt gemanipuleerd of door een menselijke fout geheel of gedeeltelijk corrupt raakt, biedt ClickOps geen realistische manier om deze opnieuw op te bouwen. Kun je je voorstellen dat je honderden Azure resources handmatig moet instellen in een andere regio? 🥲 De oplossing: Veerkracht opbouwen met DevSecOps: IaC en DevSecOps stellen je in staat om de volledige omgeving opnieuw te bouwen vanaf broncode. Deze aanpak resulteert in een kortere Recovery Time Objective (RTO) en Recovery Point Objective (RPO) tijdens disaster recovery. 6) Risico's voor beveiliging en compliance Het is waar dat het configureren van nieuwe resources via ClickOps wordt geregeld door uw gevestigde raamwerk van Azure-beleidsregels. Toch is het belangrijk op te merken dat deze controles alleen plaatsvinden tijdens of na het aanmaken van de resource. De oplossing : Compliance waarborgen vóór implementatie Als je de configuratie van je cloudinfrastructuur in code hebt staan, kunnen compliance- en beveiligingsscans direct bij de bron worden uitgevoerd. Alle wijzigingen in de infrastructuur worden gecontroleerd en alle niet-complianties worden gemarkeerd voordat ze daadwerkelijk worden geïmplementeerd. Door alle afwijkingen op te lossen voordat ze daadwerkelijk worden geïmplementeerd, blijft de beveiliging intact. Het afdwingen van een aanpak waarbij alleen de CI/CD toestemming krijgt om de infrastructuur te wijzigen, zorgt voor een extra beveiligingslaag. ClickOps uit, DevSecOps in Om deze uitdagingen te overwinnen, moeten organisaties Infrastructure as Code (IaC) en DevSecOps implementeren . Samen automatiseren ze volledige implementaties en zorgen ze ervoor dat de best practices op het gebied van beveiliging worden gevolgd. De juiste IaC-taal kiezen Bij het kiezen van een IaC-taal liggen er twee sterke opties op tafel: Bicep : De eigen taal van Azure, naadloos geïntegreerd met Azure en direct ondersteund door Microsoft. Nieuwe Azure services worden onmiddellijk ondersteund in Bicep. Terraform : Een cloud-agnostische optie, breed ondersteund in verschillende omgevingen. Een populaire keuze voor organisaties met multi-cloud behoeften. Hoewel de adoptie van Terraform voor nieuwe Azure services snel gaat, is het niet altijd beschikbaar op de eerste dag van de release. De algemene aanbeveling is om Terraform te kiezen als je implementaties automatiseert voor virtualisatieomgevingen, multi-cloud scenario's of on-premises workloads. Microsoft biedt een uitstekende vergelijking, die hier beschikbaar is . 💡Tip : Tools zoals Aztfexport kunnen je huidige Azure-omgeving exporteren naar Terraform-code. Deze code kan vervolgens worden herzien, opgeslagen in een repository en gebruikt om resources consistent te provisionen. De omgeving kan worden vergrendeld om wijzigingen via het portaal te voorkomen, zodat alle wijzigingen via IaC worden doorgevoerd en configuratiedrift wordt voorkomen. IaC en DevSecOps aanpak: succesverhaal bij ACA Group Voor een van onze klanten hebben we hun bestaande setup reverse-engineered in Terraform-code, waardoor een herbruikbare template ontstond. Deze IaC- en DevSecOps-aanpak verminderde misconfiguraties met 40% en verkortte de implementatietijd voor nieuwe omgevingen met 50%. Bij ACA Group volgt elke Azure-omgeving die we beheren de principes van IaC en DevSecOps. Dit is hoe we nieuwe en bestaande omgevingen benaderen: Greenfield-aanpak (vanaf nul beginnen): Het opzetten van een nieuwe landingszone vanaf nul is eenvoudig. We gebruiken governanceraamwerken, sjablonen en pijplijnen die volledig zijn afgestemd op het Microsoft Cloud Adoption Framework om compliance en efficiëntie te garanderen. Brownfield-aanpak (bestaande omgevingen optimaliseren) : Bestaande opstellingen vereisen een meer aangepaste strategie. We gebruiken tools zoals Aztfexport , geïntegreerd in onze bestaande workflows, om de omgeving om te zetten in IaC-sjablonen en te zorgen voor een naadloze overgang. Voorbereiden op de DevSecOps-transformatie De overgang naar DevSecOps omvat meer dan alleen technische veranderingen, het is een mentaliteitsverandering. Organisaties moeten hun interne beleid en processen aanpassen om IaC-praktijken te ondersteunen en over te stappen op een efficiënte en veilige cloudomgeving. Bij de ACA Group zijn we gespecialiseerd in het begeleiden van organisaties bij deze transformatie. Of u nu opnieuw begint of een bestaande Azure-omgeving optimaliseert, wij helpen u graag. ➡️ Klaar om verder te gaan dan ClickOps? {% module_block module "widget_a0f585f9-5198-4517-990c-933ef498b09a" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Let us help"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %} Laat ons helpen Of praat meteen met onze expert Peter!

Leestijd 6 min

Patrik Söderström

Cyberbeveiliging is niet langer optioneel - het is een hoeksteen van de operationele veerkracht en de compliance-strategie van elke organisatie. Met de introductie van de NIS2-richtlijn van de EU moeten Europese organisaties dringend voldoen aan strenge beveiligingsnormen. Hoewel de NIS2-richtlijn van de EU duidelijke normen stelt voor netwerk- en informatiebeveiliging, kan het een uitdaging zijn om de mandaten te vertalen naar uitvoerbare stappen, vooral voor bedrijven die gebruikmaken van cloudplatforms zoals Microsoft Azure. Gelukkig biedt Azure een reeks tools die ontworpen zijn om compliance te vereenvoudigen en je beveiligingsraamwerk te versterken. In dit bericht leggen we uit hoe Azure je kan helpen om je aan te passen aan NIS2, waarbij we het proces opsplitsen in beheersbare stappen om je te helpen je omgeving te beveiligen en compliant te blijven. Wat is NIS2? De NIS2 van de EU (Network and Information Security Directive 2) is een cyberbeveiligingsrichtlijn die door de Europese Unie is geïntroduceerd om de veerkracht en beveiliging van kritieke infrastructuur en essentiële diensten in de lidstaten te verbeteren. De richtlijn vervangt de oorspronkelijke NIS-richtlijn uit 2015 en is sinds 18 oktober 2024 opgenomen in de nationale wetgeving van elke EU-lidstaat. NIS2 standaardiseert cyberbeveiligingspraktijken voor een breed scala aan sectoren en organisaties, van digitale diensten, gezondheidszorg en energie tot transport en openbaar bestuur. Niet-naleving kan leiden tot hoge boetes en zelfs reputatieschade, dus voor betrokken organisaties is naleving cruciaal. Uitdagingen van NIS2 NIS2 omvat een breed scala aan cyberbeveiligingsdoelstellingen, waaronder governance, risicobeheer en incidentrespons. Met zoveel doelstellingen kan het voor organisaties een ontmoedigende taak zijn om ze te vertalen naar uitvoerbare stappen. Bevindt uw infrastructuur zich in de publieke cloud Azure? Weet u dat Azure belangrijke tools biedt om audits uit te voeren en ervoor te zorgen dat uw omgeving voldoet aan NIS2. Hoe begin je met de implementatie van NIS2? De eerste stap voor het implementeren van NIS2 is het opdelen van de richtlijn in kleinere beheersbare controles. Zodra dit is gedaan, kan het werk van het in kaart brengen van de controles naar de beste technologie en het beste proces beginnen. In deze blog splitsen we een specifieke set controles op en brengen ze in kaart bij een technologie, met de nadruk op Microsoft Azure en Microsoft Entra ID . Microsoft Entra ID: identiteits- en toegangsbeheer voor NIS2-compliance Een van de belangrijkste vereisten van NIS2 is ervoor te zorgen dat alleen geautoriseerd personeel toegang heeft tot kritieke systemen en gegevens . Met Microsoft Entra ID beschikt u over een zeer robuuste set tools voor identiteits- en toegangsbeheer (IAM). Multi Factor Authenticatie Multi Factor Authenticatie (MFA) is de de facto standaard beveiligingsmethode geworden. Het vereist dat een gebruiker minstens twee verificatiefactoren opgeeft om toegang te krijgen tot de omgeving. Voorwaardelijk toegangsbeleid Conditional Access Policies worden vaak over het hoofd gezien omdat ze optioneel lijken, maar ze zijn essentieel voor een veilige omgeving. Ze definiëren de voorwaarden waaraan gebruikers moeten voldoen om toegang te krijgen tot de omgeving. Ze kunnen toegang verlenen of weigeren op basis van parameters zoals: IP-adres (locatie) Lidmaatschap van gebruikersgroep in Entra ID Apparaathouding en compliance Just-in-time toegang Bijkomende veiligheidsmaatregelen zoals Just-in-Time-Access , die specifieke rechten voor een beperkte tijd verleent, moeten ook worden geconfigureerd. Als beheerder moet u standaard alleen-lezen toegang behouden en Just-in-Time-Access gebruiken om de rechten tijdelijk te verhogen tijdens goedgekeurde wijzigingsvensters. Beveiligingsinformatie en gebeurtenissenbeheer Alle veiligheidsmaatregelen in de wereld betekenen niets als je geen effectieve manier hebt om continu te monitoren en adequaat te reageren. Er zijn verschillende SIEM-oplossingen (Security Information and Event Management) beschikbaar. Je kunt Microsoft Sentinel gebruiken, dat zowel hybride als cloud native ondersteuning biedt. Microsoft Sentinel Bij ACA raden we aan om uw beveiligde score nauwlettend in de gaten te houden in Microsoft Entra ID tenant. Het biedt een snel en duidelijk overzicht van de voortgang van je compliance. Azure tools voor NIS2-compliance Het Azure platform biedt veel tools en technologieën om je te helpen met NIS2 compliance. Microsoft Defender voor Cloud Microsoft Defender for Cloud is een uitstekende tool om realtime bedreigingsdetectie te bieden, samen met beveiligingsaanbevelingen voor verschillende Azure-bronnen zoals VM's, SQL-databases, opslag en nog veel meer. Dit omvat ook het monitoren op kwetsbaarheden, naleving van beleidsregels en verkeerde configuraties. Azure beleid Azure policy is de basis om je infrastructuur compliant te houden, en legt de basis van je governance framework voor je hele landingszone. Voordat je je eerste werklasten in Azure beschikbaar stelt, moet je ervoor zorgen dat je Azure beleid is geconfigureerd en voldoet aan de NIS2 richtlijn. Heb je al workloads in Azure? Dan wordt het afdwingen van beleid iets complexer, omdat ze vaak zijn ingesteld zonder strikte handhaving. In dergelijke gevallen moet het beleid in 'audit'-modus draaien. Dit is waar elke niet-naleving wordt gemarkeerd, maar niet afgedwongen. Met deze aanpak kunnen organisaties de impact bekijken en beoordelen voordat de beleidsregels volledig worden afgedwongen. Hoe beheer je respons en herstel in NIS2? NIS2 gaat niet alleen over beveiliging, maar heeft ook een compliance-sectie over " Response en herstel ". Dit is waar je gebruik kunt maken van Azure Backup , Azure Site Recovery en natuurlijk Infrastructure as Code . Als we ons verder richten op de feitelijke gegevens, moeten we de verschillende soorten gegevens vertrouwelijk behandelen. Encryptie is hier de sleutel omdat het ervoor zorgt dat je gegevens alleen toegankelijk zijn voor geautoriseerde personen en systemen. Er zijn drie hoofdtypes van versleuteling beschikbaar: 1. Gegevens in rust Wanneer je een bestand opslaat in een Azure Storage Account , wordt dit automatisch versleuteld met behulp van Service-side encryption (SSE). Er zijn verschillende soorten encryptie at Rest in Azure, afhankelijk van welke service je gebruikt. 2. Gegevens onderweg Wanneer gegevens over het netwerk worden verzonden, zijn er verschillende manieren om ze te versleutelen. De meest gebruikte is Transport Layer Security (TLS). Dit is de primaire methode die wordt gebruikt wanneer je verbinding maakt met en interageert met Azure services. 3. Gebruikte gegevens Gegevens die worden gebruikt voor verwerking, zoals opgeslagen in het geheugen, kunnen ook worden versleuteld. Dit wordt vaak over het hoofd gezien omdat het complexer is en de implementatie varieert afhankelijk van welke service je gebruikt. Als je virtuele machines in Azure gebruikt, is er een heel gebied dat Vertrouwelijke gegevensverwerking behandelt . Voor het geval iemand het geheugen van de host probeert te lezen, is het versleuteld en onleesbaar. Worstel je met NIS2-compliance? De reis naar NIS2-compliance is spannend, maar kan ook complex zijn. Alleen al de technologische aspecten omvatten talloze controles op verschillende publieke cloudtechnologieën. Het bereiken van echte compliance vereist echter een evenwichtige aanpak die de technologieën integreert met robuuste processen en governance. ➡️ Bij ACA hechten we veel waarde aan beveiliging. Waar u zich ook bevindt in het NIS2-traject, u kunt op ons rekenen om u te begeleiden op weg naar NIS2-compliance. Vragen over NIS2-compliance? {% module_block module "widget_978e9903-327a-46e1-b6ad-b0d5e972d0de" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Contact our NIS2 experts"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":null,"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}