Un esperimento per utilizzare GitHub Actions come piano di controllo per un PaaS

Un'unione inaspettata: Git e la piattaforma

Il mondo di DevOps è basato sull'automazione. Eseguiamo script di implementazioni, gestiamo l'infrastruttura come codice e ci impegniamo a rendere ogni processo ripetibile e affidabile. Al centro di tutto ciò, per innumerevoli team di sviluppo, c’è GitHub, la piattaforma onnipresente per la collaborazione sul codice. Ma cosa accadrebbe se il suo potere potesse essere esteso oltre il controllo della versione e CI/CD? Questa è la storia di un esperimento per ampliare i confini di GitHub Actions, trasformandolo da un orchestratore di build e test nel sistema nervoso centrale, il piano di controllo, per un'intera Platform as a Service (PaaS).

Ridefinire il piano di controllo

Tradizionalmente, un piano di controllo PaaS è un software complesso e su misura. È un'autorità centrale che riceve comandi (distribuisci questo, ridimensiona quello) e orchestra l'infrastruttura sottostante per realizzarlo. Gestisce il provisioning, la rete, la sicurezza e la gestione del ciclo di vita. Costruirne uno è un'impresa ingegneristica significativa. L'ipotesi del nostro esperimento era semplice: potevamo sfruttare il flusso di lavoro esistente, potente e familiare di GitHub Actions per svolgere questi stessi compiti? Invece di scrivere un piano di controllo monolitico, utilizzeremmo file YAML, richieste pull e il robusto ecosistema basato sugli eventi di GitHub per gestire la nostra piattaforma.

"Lo strumento più potente è quello che il tuo team sa già come utilizzare. Utilizzando GitHub Actions come piano di controllo, non abbiamo dovuto creare un'interfaccia utente o insegnare nuovi concetti; abbiamo esteso il flusso di lavoro esistente incentrato su Git tanto apprezzato dagli sviluppatori."

Architettura del PaaS basato su GitHub

L'architettura era incentrata sul trattamento delle dichiarazioni dell'infrastruttura e delle configurazioni delle applicazioni come codice all'interno di un repository. Il flusso di lavoro di uno sviluppatore per distribuire un nuovo microservizio, ad esempio, sarebbe simile al seguente:

Uno sviluppatore crea una nuova directory per il proprio servizio e aggiunge un file "mewayz.app.yaml" che ne definisce le esigenze: CPU, memoria, variabili di ambiente e dominio.

Eseguono il commit di questo file e aprono una richiesta di pull. L'atto stesso di aprire il PR attiva un flusso di lavoro GitHub Actions.

Il flusso di lavoro, agendo come piano di controllo, analizza il file YAML, convalida la configurazione ed esegue un'esecuzione di prova delle modifiche all'infrastruttura.

Una volta uniti i PR, viene attivato un flusso di lavoro di distribuzione separato. Questo flusso di lavoro contiene la logica per comunicare con varie API cloud (Kubernetes, AWS, ecc.) per fornire effettivamente le risorse necessarie e distribuire il servizio.

Il flusso di lavoro commenta quindi il commit con un collegamento attivo al servizio appena distribuito, completando il ciclo.

Questo approccio si integra perfettamente con la filosofia Mewayz di modularità ed esperienza degli sviluppatori. Lo stato dell'intera piattaforma era controllato dalla versione, verificabile e seguiva lo stesso processo di revisione collaborativa del codice dell'applicazione stessa.

Lezioni dalla frontiera

L'esperimento è stato un successo clamoroso nel dimostrare la fattibilità. Abbiamo ottenuto un PaaS completamente funzionale e basato su Git-ops, in cui ogni modifica era tracciabile e reversibile. Tuttavia, sono emerse anche considerazioni importanti. La complessa gestione dello stato a volte spingeva oltre i limiti di ciò che era elegante in un file YAML. Sebbene GitHub Actions sia incredibilmente scalabile, per piattaforme su larga scala, i tempi di coda e di esecuzione dei flussi di lavoro potrebbero diventare un collo di bottiglia rispetto a un'API dedicata del piano di controllo a bassa latenza. La sicurezza era fondamentale; abbiamo dovuto gestire meticolosamente segreti e autorizzazioni per garantire che il runner GitHub Action avesse l'esatto accesso minimo richiesto per svolgere i suoi compiti: un concetto perfettamente in linea con i principi secure-by-design di Mewayz.

Uno sguardo a un futuro incentrato su Git

Questo esperimento dimostra che gli strumenti che utilizziamo per la collaborazione e CI/CD sono sufficientemente potenti da essere riproposti come le fondamenta stesse delle nostre piattaforme. Rende confuso il confine tra lo sviluppo di un'applicazione e la gestione dell'ambiente su cui viene eseguita, unificandoli sotto un unico

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.