Designing cloud computing with DevOps for GenggamMakna

GenggamMakna is a sign language detection app built to support communication inclusivity for people with hearing and speech disabilities. It uses deep learning to recognize hand gestures from images or video and translate them into text or speech in real time. The stack combines TensorFlow for machine learning, a Golang REST API with PostgreSQL on Cloud SQL, and a Kotlin mobile client with Firebase authentication.

This article summarizes unpublished research on designing that system with cloud computing and DevOps-focusing on how Continuous Integration and Continuous Deployment (CI/CD) on Google Cloud Platform change delivery speed, failure visibility, and scalability compared with manual release work.

Why DevOps on the cloud

DevOps removes the wall between development and operations so teams can ship faster without sacrificing quality. On cloud infrastructure, that usually means automated builds, tests, and deploys, plus elastic compute when traffic or model workloads spike. For an accessibility product like GenggamMakna, those traits matter: models and APIs need frequent iteration, while users still expect stable response times.

Cloud Computing gives on-demand access to servers, storage, and managed services with little fixed capacity planning. DevOps layers CI/CD on top so every meaningful change can be validated and released through the same path. Together they support a microservices layout that can grow with demand instead of a single brittle release train.

Architecture and pipeline

The system is designed as containerized microservices on Google Cloud Platform. Core services include Cloud Run for web workloads, Compute Engine for backend and machine learning inference, Cloud SQL for PostgreSQL, Cloud Storage for uploads and model artifacts, Redis Memorystore for caching, and Cloud Build with GitHub Actions and Docker for the CI/CD path.

A typical release starts when the production branch updates on GitHub. GitHub Actions builds and pushes Docker images, refreshes containers, and runs integration checks across backend, ML, and frontend services before production receives the change. Backend services accept uploads, call ML prediction, persist data in Cloud SQL, and cache hot data in Redis. ML services run on Compute Engine, pull models from Cloud Storage, and return predictions that the mobile and web clients consume.

What the measurements showed

Over roughly a year of pipeline metrics, backend CI/CD averaged about two minutes of execution time and about six seconds in queue. That is a clear gain over manual iterations that often took twenty to thirty minutes per cycle. Machine learning pipelines were slower-about three minutes sixteen seconds to three minutes twenty-five seconds-because training, validation, and large datasets cost more wall-clock time, but queue times stayed low (around six to seven seconds).

Failure rates remained a hard problem: backend pipelines failed around forty-four percent of runs, with an overall average near forty percent across services. Failures were usually visible early and logged automatically, which is still better than opaque manual mishaps, but the rate shows weak spots in dependencies, configuration, and test maturity. Total time lost on failed jobs was relatively small when failures aborted early, yet the signal still calls for tighter local simulation, clearer error handling, and better dependency control.

CI/CD versus manual delivery

Compared with a fully manual path, CI/CD was faster on execution, better at parallel jobs, and more transparent through centralized logs and monitoring. Automated validation reduced reliance on individual operator experience. Manual work stays useful for rare or highly creative steps that resist automation, but for frequent backend and ML releases the automated pipeline was the stronger default.

Takeaways

Integrating DevOps with cloud computing made GenggamMakna’s delivery loop more reproducible and observable. GCP-backed microservices and CI/CD shortened integration and deploy cycles without requiring a permanent ops presence for every push. The remaining work is cultural and technical at once: lower failure rates through debugging and dependency hygiene, protect user data in storage and inference paths, and keep teams collaborating so continuous delivery stays sustainable-not just automated.