Logo of Osakidetza, the Basque Health Service, featuring a modern design with clouds and abstract elements.

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 

Abstract digital background featuring interconnected lines and glowing points in shades of blue and green.

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

Logo of Zen Software in white on a transparent background.

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Projectversterking

Nieuw Softwareproject / Modernisering

Tech Consultancy

Cloud Consultancy

Onze expertises

Cases

Over ons

Nieuws

Contact

Succes! Je bent toegevoegd aan onze e-maillijst.

Abonneer u op onze e-maillijst en we houden u op de hoogte van nieuws en publicaties van ZEN Software

Abonneer op de nieuwsbrief van ZEN Software

Ontwikkeling op afstand in de cloud

Ontwikkelen op afstand is de afgelopen jaren steeds populairder geworden. Het stelt ontwikkelaars in staat om te profiteren van krachtige cloud computing resources en overal beschikbaar te zijn met behulp van een beheerde centrale configuratie. Er zijn verschillende cloudgebaseerde oplossingen beschikbaar voor ontwikkeling op afstand, waaronder Google Cloud Workstations, AWS Code Catalyst en traditionele virtuele machines (VM's). In dit artikel vergelijken we de kosten en voordelen van elke optie.

Ontwikkelen op afstand is de afgelopen jaren steeds populairder geworden. Het stelt ontwikkelaars in staat om te profiteren van krachtige cloud computing resources en overal beschikbaar te zijn met behulp van een beheerde centrale configuratie. Er zijn verschillende cloudgebaseerde oplossingen beschikbaar voor ontwikkeling op afstand, waaronder **Google Cloud Workstations, AWS Code Catalyst** en traditionele virtuele machines (**VM's**). In dit artikel vergelijken we de kosten en voordelen van elke optie.

Google Cloud Workstations is een cloud-gebaseerde ontwikkelomgeving die een volledig beheerde ontwikkelomgeving in de cloud biedt, inclusief populaire tools zoals de JetBrains IDE's zoals IntelliJ Ultimate, IntelliJ IDEA en PyCharm.

Het is ontworpen om een krachtige omgeving te bieden die zelfs de meest veeleisende ontwikkelingstaken aankan.  Google Cloud Workstations worden geleverd met een grote hoeveelheid aanpassings- en besturingsopties die kunnen helpen bij het beheren van kosten en productiviteit.

AWS Code Catalyst is een cloudgebaseerde ontwikkelomgeving van Amazon Web Services (AWS). Het is ontworpen om ontwikkelaars te helpen samen te werken aan code, workflows te automatiseren en projecten in de cloud te beheren. AWS Code Catalyst biedt een breed scala aan tools en services die ontwikkelaars kunnen helpen bij het bouwen, testen en implementeren van code.

Het gebruik van een virtuele machine (VM) gehost in Google Cloud Platform (GCP) of Amazon Web Services (AWS) kan een geweldige optie zijn voor ontwikkelaars die een flexibele en schaalbare ontwikkelomgeving nodig hebben. Deze VM-basisopties worden echter niet geleverd met vooraf geïnstalleerde ontwikkelaarstools en andere nuttige componenten en tools. Dit nadeel wordt gecompenseerd door het feit dat ze over het algemeen goedkoper zijn dan de Cloud-werkstations of CodeCatalyst-opties en nog goedkoper kunnen worden gemaakt door gebruik te maken van spotprijzen en kortingen.

Om de prijzen te vergelijken, heb ik de volgende tabel toegevoegd. In deze tabel staan de prijzen voor een machine met 4 vCPU's en 16 GB geheugen. Voor elke optie worden de kosten per uur en de maandelijkse kosten weergegeven.

above

Een manier om verbinding te maken met een van de services is via JetBrains Gateway; hier zal ik de stappen doorlopen voor AWS CodeCatalyst. Het gebruik van JetBrains Gateway is vrij eenvoudig, log in via de grote inlogknop en volg de stappen die op het scherm worden getoond. Deze stappen omvatten het aanmelden bij je AWS builder account en JetBrains Gateway toegang geven tot een aantal van je gegevens. Na het inloggen zie je het volgende scherm dat je projecten en ontwikkelomgevingen toont.

Hier kun je ook nieuwe ontwikkelomgevingen maken met de knop "Create Dev Environment". Als je op deze knop klikt, zie je dezelfde opties als in de webinterface. Na het configureren klik je gewoon op de knop om te creëren en een pop-up zou je moeten vertellen dat er aan gewerkt wordt. Zodra het klaar is, wordt de nieuw aangemaakte ontwikkelomgeving geopend.

Om verbinding te maken met je externe ontwikkelomgeving, klik je gewoon op de omgeving die je wilt opstarten. Dit proces kan een paar minuten duren en doorloopt meerdere stappen.

Zodra de ontwikkelomgeving klaar is, zal het de IDE openen, net zoals het zou doen als je het lokaal zou gebruiken. Het enige verschil is dat er linksboven een extra menu is dat de status en latency van de machine laat zien. Als je op dit menu klikt, zie je het geheugen-, opslag- en CPU-gebruik. 

En klaar! Je bent klaar om je ontwikkelomgeving op afstand te gebruiken!

Als het gaat om ontwikkeling op afstand, zijn er verschillende opties beschikbaar, elk met zijn eigen voordelen en kosten. Google Cloud Workstations en AWS CodeCatalyst bieden volledig beheerde en gebruiksklare ontwikkelomgevingen met een breed scala aan tools en services.Ze zijn ontworpen voor grote teams en projecten op bedrijfsniveau, maar de kosten kunnen aanzienlijk zijn.

Normale VM's bieden een aanpasbare en kosteneffectieve oplossing voor kleine teams of individuele ontwikkelaars, maar hebben niet enkele van de gebruiksvriendelijke functies die Google Cloud Workstation of AWS CodeCatalyst heeft. 

Een ding om op te merken is dat AWS Code Catalyst aanzienlijk goedkoper is dan de meeste andere opties. De beperkte beschikbare zones kunnen de werkervaring echter aanzienlijk slechter maken en daarom kan een alternatieve service interessant zijn om te gebruiken, ook al is deze duurder. 

Uiteindelijk hangt de keuze van de optie af van de specifieke behoeften van het project, de grootte van het team en het beschikbare budget.

Zo voorkom je nachtmerrie-achtige cloudrekeningen: API-quota en budgetwaarschuwingen

Slapeloze nachten over stijgende cloudkosten? Maak je geen zorgen, wij hebben een open-source en gratis oplossing! In dit artikel duiken we dieper in op het opzetten van een hackathon met behulp van de unieke generatieve AI- en machine learning-mogelijkheden van Google Cloud. We waarborgen daarbij de veiligheid door gebruik te maken van Budget Alerts en API-quota.

Slapeloze nachten over stijgende [cloudkosten](/onze-diensten/oplossingen/zen-cloud-landing-zone)? Wij hebben een open source en gratis oplossing!

In dit artikel gaan we dieper in op het opzetten van een hackathon met behulp van de unieke Generative AI en Machine Learning mogelijkheden van Google Cloud. We doen dit op een veilige manier door gebruik te maken van Budget Alerts en API-quota. Met behulp van deze eenvoudige oplossing kun je

:heavy_check_mark:  Focussen op innovatie en baanbrekende nieuwe functies    
:heavy_check_mark:  Hyperontwikkelingssnelheid   
:heavy_check_mark:  Alle juiste middelen binnen handbereik   
   
   
En voorkom vervelende dingen zoals:   

:x:  Duizenden dollars uitgeven aan Google Cloud voor 24 uur gebruik   
:x:  ML-modellen trainen op enorme ongefilterde gegevenssets   
:x:  Per ongeluk een DDOS-aanval lanceren en de ontvangende kant ervan financieren

Probeer het uit: een Hackathon met beveiligde sandboxprojecten

Hackathons zijn dynamische evenementen waar teams samenkomen om innovatieve projecten of functies te creëren binnen een beperkt tijdsbestek. Maar te midden van de opwinding van ideevorming en ontwikkeling is er een dreigende zorg voor projectorganisatoren: het potentieel voor op hol geslagen cloudkosten.

Maar waarom is dit zo belangrijk? Hoewel GCP een overvloed aan krachtige services en middelen biedt, kunnen enthousiaste teams gemakkelijk onbedoeld hoge kosten maken, vooral wanneer ze experimenteren met geavanceerde functies. Om zulke budgettaire nachtmerries te voorkomen en een soepele hackathonervaring te garanderen, zullen we de ingewikkelde details van het configureren van budget alerts en het omgaan met servicequota's via Terraform onderzoeken.

Onderweg gaan we in op de uitdagingen die gepaard gaan met het integreren van servicequota's met Terraform, waarbij we licht werpen op de lastige aspecten van dit proces en inzicht geven in hoe je hier effectief mee om kunt gaan. Aan het einde van dit artikel zul je goed uitgerust zijn om een kosteneffectieve en veilige GCP-omgeving te creëren voor je hackathon, zodat teams kunnen innoveren zonder bang te hoeven zijn voor onverwachte financiële gevolgen.

Google Cloud-projecten en -rollen aanmaken (handmatig?)

Het handmatig aanmaken van meerdere projecten in Google Cloud Platform (GCP), vooral wanneer ze verschillende gebruikerstoegang en rollen vereisen, is tijdrovend en vatbaar voor menselijke fouten. Dit proces kan vooral een uitdaging zijn bij het opzetten van projecten voor meerdere hackathon teams. Om deze problemen op te lossen, kan het gebruik van Infrastructure as Code (IaC) tools zoals Terraform de provisioning van projecten, het beheer van gebruikers en de toewijzing van rollen vereenvoudigen. Deze aanpak zorgt voor consistentie, schaalbaarheid en minder administratieve overhead. ZENsoftware biedt een open-source project dat essentiële functies bevat zoals budgetwaarschuwingen, gebruikersrollen en servicequota om deze uitdagingen aan te gaan. Het GitHub -[ zensoftwarenl/google-cloud-hackathon](https://github.com/zensoftwarenl/google-cloud-hackathon) project.

Het instellen van quota's voor Google Cloud Platform (GCP) resources is een essentiële stap in het efficiënt beheren van je cloudinfrastructuur. In een ideale wereld zou dit proces eenvoudig en probleemloos moeten zijn, maar in werkelijkheid is het allesbehalve dat. Hoewel de aanvankelijke verwachting is dat het instellen van quota's eenvoudig zou moeten zijn, gezien het feit dat het een essentieel onderdeel is van kostenbeheer, bleek het een onverwachte uitdaging te zijn toen we Terraform gebruikten om deze taak uit te voeren. Deze moeilijkheden komen voort uit een combinatie van factoren, waaronder ontoereikende documentatie, verwarrende terminologie, een gebrek aan duidelijkheid over eenheidsformaten en de inherente handmatige aard van het proces. We zullen deze uitdagingen in detail onderzoeken en licht werpen op de complexiteit die kan ontstaan bij het werken met GCP quota's via Terraform.

Ten eerste kan de documentatie wat ontoereikend en onsamenhangend zijn. GCP en Terraform hebben de neiging om verschillende terminologie te gebruiken als het gaat om quota en limieten. Terwijl Terraform consequent de term "limiet" gebruikt, labelt GCP ze als "eenheden". Dit verschil in terminologie kan verwarring creëren, waardoor het een uitdaging wordt om de Terraform-code af te stemmen op het quotabeheer van GCP.

Bovendien kan het formaat van de "eenheid" cryptisch zijn. GCP introduceert verschillende "unit" formaten, zoals ```/d/project``` in de ene context en ```/min/project/user``` in een andere (andere voorbeelden zijn ```/project/regio```, ```/min/project```) . Het ontcijferen van deze variaties en het begrijpen welk formaat van toepassing is op een specifiek quotum kan een bron van verbijstering worden.

Bovendien is het begrijpen van het precieze eenheidsformaat voor een bepaald quotum niet gemakkelijk toegankelijk via documentatie. Deze belangrijke informatie blijft vaak verborgen, waardoor gebruikers zich moeten verdiepen in de commandoregeltools of webinterfaces van GCP om de details te achterhalen. In de GCP-documentatie wordt bijvoorbeeld vermeld dat het "unit" formaat vereist dat de waarden worden geformatteerd met ```{}``` in de unit, maar in Terraform zal het gebruik van deze haakjes in de unit niet werken. Zelfs bij het inspecteren van de verzoeken die worden verzonden door de [console.cloud.google.com](https://console.cloud.google.com) wordt de request unit geschreven met ```{}``` terwijl dit in Terraform absoluut niet werkt.

Samengevat, terwijl Terraform uitblinkt in het automatiseren van verschillende aspecten van infrastructuurbeheer, blijven de fijne kneepjes rondom GCP quotabeheer een uitdagend en minder gestroomlijnd facet van cloud resource provisioning. Het navigeren door onduidelijke documentatie, inconsistente terminologie en niet-standaard eenheidsformaten kan wat een eenvoudige procedure zou moeten zijn veranderen in een formidabele taak, wat de behoefte aan verbeteringen op dit gebied benadrukt om de efficiëntie en ervaring van gebruikers te verbeteren.

Om het complexe proces van het instellen van GCP quota's met behulp van Terraform te ontrafelen, zijn we op ontdekkingsreis gegaan en hebben we de ingewikkelde details van elk quotum blootgelegd. Dit is hoe we het labyrint van quotabeheer hebben doorlopen.

Onze reis begon met het inspecteren van de uitgaande verzoeken die werden gegenereerd door de GCP Console. Deze oefening stelde ons in staat om een kijkje te nemen in het interne formaat en de structuur die GCP gebruikte voor het beheren van quota. Het "leuke" was echter dat de API die door Terraform wordt gebruikt, verschilt van de API die door de console wordt gebruikt. Hierdoor was het formaat niet correct en werd het een nutteloze oefening.

We gingen verder met de gebruikersinterface (UI) voor meer inzichten. Het inschakelen van een specifieke service binnen de GCP Console en het opsommen van de bijbehorende quota's in de UI onthulde niet alleen de quota Metric, maar begon ook het onderliggende formaat voor de eenheid te onthullen. Hier komt de inconsistentie in de documentatie weer terug. In deze UI heet de waarde voor de eenheid "Limit name" en is niet in het formaat van schuine strepen, maar in plaats daarvan is het geschreven als een tekst, bijvoorbeeld: ```WritesPerMinutePerProjectPerRegion```, ```subscriberPerMinutePerProjectPerRegion```, ```default/USER-100s```. Voor sommige quota's kon je het juiste formaat van de op slash gebaseerde "unit" waarde schatten, maar voor sommige quota's werkte dit niet (zoals het laatste voorbeeld dat ik eerder liet zien).

Gewapend met de kennis van de namen van quota's en een aantal geformatteerde eenheden, gebruikten we de kracht van de gcloud commandoregeltool. Specifiek gebruikten we het commando: ```gcloud alpha services quota list --service=<service> --consumer=projects/<projectid> --format=json > output.json``` Met deze opdracht konden we de lijst met quota exporteren in een leesbaarder JSON-formaat, waarbij cruciale informatie over elk quotum werd geconsolideerd. Het uitvoerbestand was onze schat aan quota-inzichten. Hier konden we het formaat van elke service-quota combinatie onderscheiden. Deze kennis was van onschatbare waarde omdat het een basis vormde om te begrijpen hoe quota waren gestructureerd. Het is echter belangrijk om op te merken dat, hoewel we een aantal unit formats uit deze uitvoer konden halen, ze niet allemaal correct of compleet waren en ze waren geformatteerd met het ```{}``` formaat, het formaat dat niet ondersteund wordt door Terraform. Deze discrepanties betekenden dat we nog steeds een nauwgezet proces van trial and error moesten doorlopen, waarbij we systematisch verschillende variaties van het eenheidsformaat moesten onderzoeken totdat we de juiste vonden voor elk specifiek quotum.

Met behulp van dit proces waren we in staat om een lijst met quota's te genereren die we hebben opgenomen in ons open-sourceproject GitHub - [zensoftwarenl/google-cloud-hackathon](https://github.com/zensoftwarenl/google-cloud-hackathon). Naast het feit dat je deze quotalijst en dit project kunt gebruiken om je quota's via Terraform te beheren, hoop ik ook dat de kennis van de stappen die ik nam om het juiste formaat voor de eenheidswaarde van elk quotum te vinden, je helpt bij een effectiever beheer van je projecten.

Met behulp van ons gratis en open-source project

Ons open-sourceproject is ontworpen om het proces van het instellen van GCP-quota's met behulp van Terraform te stroomlijnen. Het is flexibel inzetbaar, zowel lokaal als binnen een Terraform Cloud-provider, waardoor het beheren van je cloudbronnen nog eenvoudiger wordt.

De tool is net zo toegankelijk als het aanpassen van variabelen aan de behoeften van je specifieke team- en rolindeling voor hackathonprojecten. Of je nu quota's voor meerdere teams met verschillende toegangsniveaus moet instellen of specifieke rollen wilt definiëren voor elke deelnemer, deze open-source oplossing biedt de aanpassingen die je nodig hebt.

Onze toewijding aan jouw succes in de cloud gaat verder. Als je deskundige begeleiding en ondersteuning nodig hebt voor je cloudservices, bieden we uitgebreide consultancydiensten aan. Ons ervaren team staat klaar om je te helpen je cloudinfrastructuur te optimaliseren, met aandacht voor kosteneffectiviteit, veiligheid en prestaties. [Neem contact met ons op](https://www.zensoftware.nl/contact) voor meer informatie.

Of je nu net begint met ons open-source project of hulp zoekt om je cloudservices te upgraden, bij ons ben je aan het juiste adres. Neem vandaag nog contact met ons op en ontdek hoe we jouw hackathonteams kunnen versterken en je cloudactiviteiten kunnen verbeteren.

Paul Backs