From Manual Deployments to an Automated Microservice Platform: A Startup’s Journey

Technology itself is neutral; its value depends on the scenario.

The uread team started with a single backend system, using Git for collaboration and a simple shell script that performed git pull, killed the old process, and restarted the service.

Stage 1: Monolithic Application – Manual Deployment

Initially, deployment was entirely manual.

Stage 2: Service Splitting – Interaction Challenges

As features grew, the monolith became hard to understand and caused merge conflicts, prompting the team to consider microservices. New large features were split into independent projects, but the main issue became inter‑service communication, often requiring multiple services per feature and handling long‑running tasks via HTTP callbacks.

Stage 3: Message‑Queue Interaction

The team introduced RabbitMQ to replace HTTP calls, eliminating address‑change problems and easing scaling, but eventually abandoned it because the added complexity overwhelmed the small, inexperienced team.

Stage 4: SDK‑Based Interaction

Developers began providing an SDK for each microservice; callers only needed to import the SDK, and service changes could be handled by updating the SDK while keeping function signatures compatible.

Stage 5: Service Discovery System

Because each SDK still required hard‑coded addresses, the team built a simple discovery system that maps a service name to its real address at runtime.

Stage 6: Automated Deployment

Deployment automation became a priority. The team containerized services with Docker, wrote Dockerfiles, and used Docker Swarm to distribute containers across machines. Git hooks triggered scripts that automatically built and deployed new versions.

Stage 7: Application Logging

Logs inside containers across multiple servers were collected by capturing errors in a common handler and posting them to a notification bot, allowing immediate visibility of failing requests without the heavyweight ELK stack.

The next step is to implement elastic scaling, though the current workload does not yet require large‑scale expansion.