Dogker: Simplifying Container Management in the Cloud

This project stands as the largest and most complex I've participated in so far. Developed for the Cloud Computing course (MII212610) under Mr. I Gede Mujiyatna, S.Kom., M.Kom., Dogker represents my first deep dive into cloud computing and containerization technologies. In essence, Dogker is an ambitious Container-as-a-Service (CaaS) platform that simplifies Docker container management in cloud environments, enabling users to host and monitor both stateless and stateful containers. Our team of five aimed to bridge the gap between complex vendor-specific tools (AWS, GCP, Azure) and the need for agile, user-friendly container management.

Requirements and Approach

While the course didn't require building a full-fledged application like Dogker, it emphasized key cloud-based solution characteristics such as resource provisioning, monitoring, and termination. Dogker is heavily inspired by the impressive Dockurr project led by my senior, Faiz Jazadi. We’re proud to carry forward this legacy and build upon it.

As a CaaS platform, our approach focused on scalability, security, and ease of use. Despite being an experimental class project rather than an MVP, we put significant effort into providing Dogker with a robust infrastructure. Here’s how we approached it:

1. Microservices: We adopted a microservices architecture, dividing our platform into distinct services: Authentication, Container Management, Monitoring, Billing, and Mailing. This challenge was particularly exciting for me, given my limited experience in managing such applications.

2. Cloud-Native Technologies: We leveraged Docker Swarm for orchestration, and Prometheus and Grafana for monitoring. These technologies, initially daunting, proved integral to our architecture.

3. Billing: To meet our lecturer's "bonus point" requirement, we implemented a deposit-based billing system using Midtrans as a payment gateway. Users top up their balance before using our services, with containers gracefully stopping if the balance is insufficient.

4. Front-end and Design: While Dogker primarily focuses on back-end architecture, our front-end engineer/UI/UX designer, David, efficiently used NextJS and ShadCN (Tailwind-based) to rapidly develop the prototype. Client-server communication is handled via NextJS' server functions.

Our final solution integrates various technologies, including Golang, NestJS, and Next.js, chosen for their performance, use-case compatibility, and our preferences.

Architecture

Dogker's architecture is composed of five main microservices, each handling distinct responsibilities within the platform. The services are designed to work together, ensuring scalability, security, and ease of use. Below is a detailed breakdown of each service, the technology stack used, and the reasoning behind these choices:

• Authentication Service (developed by Adam):The Authentication Service is responsible for user registration, login, and token management. It is built using NestJS and PostgreSQL.

  • NestJS was chosen for its powerful dependency injection system,

    which simplifies the development of scalable and maintainable server-side applications. Additionally, NestJS supports TypeScript out-of-the-box, aligning with our team's expertise.

  • PostgreSQL serves as the database, simply due to lack of interaction between users, does a simplistic solution will do.

• Container Service (developed by Lintang) handles the provisioning, scaling, and lifecycle management of Docker containers. Implemented using Golang and Docker Swarm, this service is the backbone of Dogker’s container management capabilities.

  • Golang was selected for its concurrency model, which is particularly well-suited for

    handling multiple container operations efficiently

  • Docker Swarm was chosen as the orchestration tool due to its native integration with Docker, ease of setup, and suitability for small to medium-sized deployments. Docker Swarm allows us to manage a cluster of Docker nodes and provides built-in load balancing.

• Monitoring Service (also developed by Lintang) collects and visualizes container metrics, providing insights into the performance and health of the containers. It is powered by Prometheus and Grafana.

  • Prometheus was chosen for its powerful querying language (PromQL) and

    its ability to scrape metrics from services at defined intervals. It’s well-suited for monitoring dynamic cloud environments where services are constantly scaling.

  • Grafana is used to create customizable dashboards that visualize the metrics collected by Prometheus. Grafana’s ease of use and wide array of plugins made it the ideal choice for presenting monitoring data in a clear and actionable manner.

• Billing Service (developed by myself) manages user deposits and usage charges, using Golang and Midtrans as the payment gateway.

  • Golang was chosen here for the same reasons as in the Container Service: its efficiency and performance in handling concurrent processes.

  • Midtrans was selected as the payment gateway due to its comprehensive API, ease of integration, and support for various payment methods commonly used in the region.

• Mailing Service (developed by David):The Mailing Service is responsible for sending notifications to users, such as payment confirmations or alerts about container statuses. It is also built using Golang for consistency and performance.

Communication Between Services:

• The microservices communicate via gRPC for efficient, low-latency interactions, and

  REST APIs for broader compatibility with other systems, such as client-side app.

• RabbitMQ is used for asynchronous communication between the Monitoring and Billing services, allowing for scalable and reliable message passing. Each hour, monitoring service will send asynchronous message to Billing Service, so that the user's balance will be charged accordingly.

Challenges

Our main challenges included:

• Steep learning curves for new technologies like gRPC, Docker Swarm, and Prometheus.

• Integrating multiple microservices, especially asynchronous processes.

• Lack of an automated CI/CD pipeline, resulting in time-consuming manual deployments.

Conclusion

Dogker pushed us to explore cutting-edge cloud technologies and best practices in software architecture. Throughout this project, I often relied on Lintang's expertise, particularly in areas where I was less familiar. This experience highlighted my need to deepen my understanding of cloud technologies and microservices architecture. Moving forward, I’m motivated to continue learning and improving my skills in these areas to contribute more effectively to similar projects in the future.