Een experiment om GitHub Actions te gebruiken als besturingsvlak voor een PaaS

Een onverwachte unie: Git en het platform

De wereld van DevOps is gebouwd op automatisering. We scripten implementaties, beheren de infrastructuur als code en streven ernaar om elk proces herhaalbaar en betrouwbaar te maken. De kern hiervan voor talloze ontwikkelingsteams is GitHub, het alomtegenwoordige platform voor code-samenwerking. Maar wat als de kracht ervan zou kunnen worden uitgebreid tot voorbij versiebeheer en CI/CD? Dit is het verhaal van een experiment om de grenzen van GitHub Actions te verleggen, door het te transformeren van een build-and-test-orkestrator naar het centrale zenuwstelsel – het controlevlak – voor een volledig Platform as a Service (PaaS).

Het besturingsvlak opnieuw definiëren

Traditioneel is een PaaS-besturingsvlak een complex, op maat gemaakt stukje software. Het is een centrale autoriteit die opdrachten ontvangt (implementeer dit, schaal dat) en orkestreert de onderliggende infrastructuur om dit mogelijk te maken. Het verzorgt de inrichting, netwerken, beveiliging en levenscyclusbeheer. Het bouwen ervan is een aanzienlijke technische onderneming. De hypothese van ons experiment was simpel: kunnen we de bestaande, krachtige en vertrouwde workflow van GitHub Actions gebruiken om dezelfde taken uit te voeren? In plaats van een monolithisch controlevlak te schrijven, zouden we YAML-bestanden, pull-requests en het robuuste, gebeurtenisgestuurde ecosysteem van GitHub gebruiken om ons platform te beheren.

"De krachtigste tool is degene die je team al weet te gebruiken. Door GitHub Actions als ons besturingsvlak te gebruiken, hoefden we geen gebruikersinterface te bouwen of nieuwe concepten aan te leren; we breidden de bestaande, op Git gerichte workflow-ontwikkelaars uit."

Het ontwerpen van de GitHub-aangedreven PaaS

De architectuur was gericht op het behandelen van infrastructuurdeclaraties en applicatieconfiguraties als code binnen een repository. De workflow van een ontwikkelaar om een nieuwe microservice te implementeren zou er bijvoorbeeld als volgt uitzien:

Een ontwikkelaar maakt een nieuwe map voor zijn service en voegt een `mewayz.app.yaml`-bestand toe waarin de behoeften worden gedefinieerd: CPU, geheugen, omgevingsvariabelen en domein.

Ze committen dit bestand en openen een Pull Request. Alleen al het openen van de PR activeert een GitHub Actions-workflow.

De workflow, die fungeert als controlevlak, parseert het YAML-bestand, valideert de configuratie en voert een proefrit uit van de infrastructuurwijzigingen.

Zodra de PR is samengevoegd, wordt een afzonderlijke implementatieworkflow geactiveerd. Deze workflow bevat de logica om te communiceren met verschillende cloud-API’s (Kubernetes, AWS, etc.) om daadwerkelijk de benodigde resources te leveren en de service uit te rollen.

De workflow geeft vervolgens commentaar op de commit met een live link naar de nieuw geïmplementeerde service, waardoor de lus wordt voltooid.

Deze aanpak sloot naadloos aan bij de Mewayz-filosofie van modulariteit en ontwikkelaarservaring. De status van het hele platform was versiegestuurd, controleerbaar en volgde hetzelfde gezamenlijke beoordelingsproces als de applicatiecode zelf.

Lessen uit de grens

Het experiment was een doorslaand succes wat betreft het aantonen van de haalbaarheid. We bereikten een volledig functionele, Git-ops-gestuurde PaaS waarbij elke verandering traceerbaar en omkeerbaar was. Het bracht echter ook belangrijke overwegingen aan het licht. Complex statusbeheer verlegde soms de grenzen van wat elegant was in een YAML-bestand. Hoewel GitHub Actions ongelooflijk schaalbaar is, kunnen voor grootschalige platforms de wachtrij- en uitvoeringstijd van workflows een knelpunt worden vergeleken met een speciale controlevlak-API met lage latentie. Veiligheid stond voorop; we moesten geheimen en machtigingen nauwgezet beheren om ervoor te zorgen dat de GitHub Action Runner precies de minimale toegang had die nodig was om zijn taken uit te voeren - een concept dat perfect in lijn was met de 'secure-by-design'-principes van Mewayz.

Een glimp van een Git-centrische toekomst

Dit experiment laat zien dat de tools die we gebruiken voor samenwerking en CI/CD krachtig genoeg zijn om opnieuw te worden ingezet in de basis van onze platforms. Het vervaagt de grens tussen het ontwikkelen van een applicatie en het beheren van de omgeving waarop deze draait, waardoor ze onder één geheel worden verenigd

Frequently Asked Questions

An Unexpected Union: Git and the Platform

The world of DevOps is built on automation. We script deployments, manage infrastructure as code, and strive to make every process repeatable and reliable. At the heart of this for countless development teams is GitHub, the ubiquitous platform for code collaboration. But what if its power could be extended beyond version control and CI/CD? This is the story of an experiment to push the boundaries of GitHub Actions, transforming it from a build-and-test orchestrator into the central nervous system—the control plane—for an entire Platform as a Service (PaaS).

Redefining the Control Plane

Traditionally, a PaaS control plane is a complex, bespoke piece of software. It's a central authority that receives commands (deploy this, scale that) and orchestrates the underlying infrastructure to make it happen. It handles provisioning, networking, security, and lifecycle management. Building one is a significant engineering undertaking. The hypothesis of our experiment was simple: could we leverage the existing, powerful, and familiar workflow of GitHub Actions to perform these same duties? Instead of writing a monolithic control plane, we would use YAML files, pull requests, and GitHub's robust event-driven ecosystem to manage our platform.

Architecting the GitHub-Driven PaaS

The architecture centered on treating infrastructure declarations and application configurations as code within a repository. A developer's workflow to deploy a new microservice, for instance, would look like this:

Lessons from the Frontier

The experiment was a resounding success in proving feasibility. We achieved a fully functional, Git-ops driven PaaS where every change was traceable and reversible. However, it also revealed important considerations. Complex state management sometimes pushed the boundaries of what was elegant in a YAML file. While GitHub Actions is incredibly scalable, for massive-scale platforms, the queueing and execution time of workflows could become a bottleneck compared to a dedicated, low-latency control plane API. Security was paramount; we had to meticulously manage secrets and permissions to ensure the GitHub Action runner had the exact minimum access required to perform its duties—a concept perfectly aligned with Mewayz's secure-by-design principles.

A Glimpse into a Git-Centric Future

This experiment demonstrates that the tools we use for collaboration and CI/CD are powerful enough to be repurposed into the very foundation of our platforms. It blurs the line between developing an application and managing the environment it runs on, unifying them under a single, Git-based workflow. For companies like Mewayz, which are building the next generation of business OS platforms, this exploration is invaluable. It challenges conventional architecture and opens doors to incredibly intuitive and integrated developer experiences. While it may not replace every custom control plane, it stands as a powerful testament to the idea that the best solution might already be in your toolkit.