What is StaCommu
A new service called StaCommu was released at the beginning of December. StaCommu is a video streaming service for Stardust Planet. In this article, I will explain the technology, architecture, and background of the backend tech stacks.
Architecture overview
The main computing part uses Google Cloud Platform (GCP), while the video streaming and payment infrastructure use Amazon Web Services (AWS).
Serverless architecture
All server-side applications are written in Go and run using Cloud Run. We are utilizing GCP’s Cloud Run due to its powerful capabilities, such as a maximum of 1000 concurrent requests and 1000 container instances (autoscaling), which allows us to focus more on application development. Additionally, GCP provides Serverless VPC Connector, enabling us to use Cloud Memorystore with Cloud Run and more.
Monolith
Our team consists of one to a maximum of three members, and we chose a monolithic architecture to maintain development speed. However, it is designed for easy migration to microservices as the development scale increases.
Trunk-based development
Trunk-based development is one of the capabilities driving higher software delivery and organizational performance. For more details, please see here. It significantly reduces the time to deploy and release, but please note that it may not fit every team.
Multi-Region application architecture
Cloud Run supports almost all regions, and GCP provides Serverless NEG, which can be used in combination with Cloud Load Balancing to abstract serverless services and enable various features such as Managed SSL certificates, Redirection, and Customized URL.
i18n
We have introduced Localizely for software localization, supporting various functions and offering the convenience of exporting in JSON format.
Feature Flags
Feature Flags is a software engineering technique that allows the selection of functionality to be turned on and off during runtime without deploying new code. Please see here for more details. This enables staggering deployment and release timings, allowing us to deploy to development and production environments simultaneously.
CI/CD
We used to use CircleCI as our Continuous Integration tool. However, we completely switched to GitHub Actions because we’re using GitHub as VCS. For Continuous Delivery, we use PipeCD, an Open Source project supporting multiple providers and multi-tenancy.
Monitoring and Alert
We selected Cloud Monitoring for its compatibility with GCP and ease of use. However, we found that displaying metrics could sometimes take time as the volume of metrics increased. For On-call management, we integrated Cloud Monitoring with PagerDuty.
Visualization of team performance
In addition to request numbers and SLI visualization, we have visualized our Four Keys. There is an open-source project to help generate these metrics for your team. Visualizing these metrics has made us more aware of review speed and deployment speed.
Conclusion
I’m happy to have been developing for about one and a half years and finally releasing the app. I’ve learned a lot and faced many challenges. Looking back, I made many mistakes, but I intend to continue doing my best and learning from them. Thank you very much for reading :)