DEV Community: Bhavesh Panchal

From Prometheus to ARMS: How We Simplified Observability for a Multi-Tier App on Alibaba Cloud

Bhavesh Panchal — Wed, 07 Jan 2026 12:16:07 +0000

If you’ve ever lost sleep debugging a latency spike across microservices, you know observability isn’t just about metrics—it’s about context.

For months, my team ran a multi-tier SaaS application on Alibaba Cloud using Prometheus on ACK (Alibaba Cloud Container Service for Kubernetes). It worked—until scaling demands, fragmented tooling, and alert fatigue caught up with us.

We recently migrated to Application Real-Time Monitoring Service (ARMS), Alibaba Cloud’s managed observability platform. The result? 40% faster incident resolution, far less operational overhead, and a unified view across our entire stack.

Here’s how—and why—it worked for us.

Why We Hit Prometheus’ Limits

Prometheus is fantastic for metrics—but in a production-grade, multi-environment setup, we kept running into walls:

Operational drag: Managing HA Prometheus, storage, retention, and scrape configs across clusters ate up valuable engineering time.
No end-to-end visibility: Metrics lived in Prometheus, logs in a separate system, and traces in another. Correlating a frontend slowdown to a slow database query meant manual detective work.
Scaling unpredictably: During traffic spikes, we either over-provisioned (wasting money) or risked metric gaps.
Noisy, low-context alerts: “High CPU” or “API error rate up” without knowing which service or which dependency was the root cause.

We needed something that gave us metrics + traces + logs in one place, with minimal maintenance.

Why We Chose ARMS

ARMS isn’t just “Prometheus-as-a-service.” It’s a unified observability platform that supports:

Full Prometheus remote write/pull compatibility
Automatic discovery of cloud resources (Kubernetes workloads, load balancers, managed databases, etc.)
Built-in distributed tracing (with auto-instrumentation for Java, Python, Go, and more)
Tight integration with Alibaba Cloud services—no extra agents or complex networking

Most importantly: we didn’t have to throw away our existing investment. ARMS ingested our existing Prometheus metrics while adding deeper context from the underlying cloud infrastructure.

Our Migration Strategy: Safe and Incremental

We didn’t flip a switch. Observability is too critical for that. Here’s our phased approach:

Parallel ingestion: Configured ARMS to receive metrics via Prometheus remote write—same exporters, same metrics.
Validation period: Ran both systems side-by-side for 2 weeks, comparing dashboards, alert fidelity, and data completeness.
Gradual cutover: Shifted Grafana dashboards to use ARMS as a data source, then migrated alert rules.
Decommission: Once confident, we scaled down our self-managed Prometheus stack and reclaimed resources.

Zero downtime. Minimal risk.

💡 Pro tip: Start with ARMS’ Prometheus Monitoring mode—it’s the gentlest on-ramp if you’re already using Prometheus.

Observability Across All Tiers—Finally

Our stack spans:

Frontend (CDN + static assets on OSS)
API gateway (via Application Load Balancer)
Stateless microservices (on ACK)
Caching layer (managed Redis)
Persistent storage (managed PostgreSQL)

Before ARMS, answering “Why is checkout slow?” meant jumping between 3+ tools.

Now, in a single ARMS dashboard, we see:

Frontend performance (real user metrics)
API latency and error rates
Service dependency map with live traces
Slow database queries auto-linked to calling services

It’s no longer about “collecting data”—it’s about understanding behavior.

Results That Mattered

40% reduction in mean time to resolution (MTTR)
60% less time spent managing observability infrastructure
Fewer but higher-signal alerts (with service-level context)
Faster onboarding—new engineers explore the system through ARMS, not tribal knowledge

If You’re Considering a Similar Move

Here’s what helped us:

Use ARMS’ Prometheus-compatible endpoint to avoid config rewrites.
Enable Application Monitoring for auto-instrumentation—just add a few JVM args or SDK calls.
Set up RAM roles (Alibaba Cloud’s IAM) for secure, credential-free access.
Still push custom metrics? ARMS supports OpenTelemetry and Prometheus client libraries.

Final Thought

This wasn’t just a tool swap—it was a shift from reactive monitoring to proactive understanding. By leaning into a managed, cloud-native observability platform, we got our weekends back and our SLOs under control.

If you’re running Prometheus on Kubernetes and feeling the pain of scale, it might be time to explore what a unified observability platform can do for your team—regardless of your cloud provider.

Have you migrated from self-managed Prometheus to a managed solution? I’d love to hear your lessons in the comments!

About the author: I’m a DevOps engineer and 2x Alibaba Cloud MVP. I spend my days building resilient, observable systems in the cloud—and sharing what works (and what doesn’t).

I Set Up a Real CI/CD Pipeline in 20 Minutes Using Alibaba Cloud—Here’s How

Bhavesh Panchal — Tue, 06 Jan 2026 07:12:26 +0000

A few weeks ago, I was tired of manually building, testing, and deploying a little side project every time I made a change. You know the drill:

“Did I push the right image?”

“Wait, is this the staging or prod cluster?”

“Why did it work locally but fail in the cloud?!”

So I decided to finally set up a proper CI/CD pipeline. But I didn’t want to wrestle with Jenkins or stitch together five different services. I wanted something simple, integrated, and—ideally—free to start.

That’s when I gave Alibaba Cloud DevOps a shot. And honestly? It surprised me.

In under 20 minutes, I had a working pipeline that:

Builds a Docker image on every git push
Runs tests
Deploys to Kubernetes (ACK) with zero manual intervention

No YAML nightmares. No self-hosted runners. Just… it worked.

Here’s how I did it—and how you can too.

Why I Chose Alibaba Cloud DevOps (And Why You Might Like It)

I’m already using Alibaba Cloud for hosting, so I figured: why not keep everything in one place?

Turns out, their DevOps platform comes with:

A built-in Git repo (like GitHub, but inside Alibaba Cloud)
Visual + YAML pipeline editor
Direct integration with their Kubernetes service (ACK), container registry (ACR), and monitoring tools
Free tier that’s generous enough for personal projects

No extra accounts. No secret management headaches. Just code → build → deploy.

Step 1: Create a Project (Takes 30 Seconds)

Log into the Alibaba Cloud Console, go to Application Services → DevOps, and click Create Project.

I named mine my-tiny-api and chose “Create a new code repository.”

Boom—now I had a Git URL like https://code.aliyun.com/yourname/my-tiny-api.git.

Step 2: Throw in a Simple App

I used a bare-bones Node.js server—nothing fancy.

// index.js
const http = require('http');
http.createServer((req, res) => {
  res.end('Hello from CI/CD land! 🌍\n');
}).listen(8080);

And a minimal package.json with a fake test script (hey, it’s a demo!):

{
  "scripts": {
    "start": "node index.js",
    "test": "echo '✅ All good!'"
  }
}

Then:

git add .
git commit -m "Hello, pipeline!"
git push origin main

Step 3: Build the Pipeline (The Fun Part)

In the DevOps dashboard, I clicked Pipelines → Create Pipeline and picked Custom Pipeline.

Instead of clicking through a UI (though you can!), I switched to YAML mode and pasted this:

version: "0.1"
stages:
  - stage:
      name: Build
      steps:
        - step: build@docker
          name: Build Docker image
          properties:
            dockerfile: |
              FROM node:18-alpine
              WORKDIR /app
              COPY . .
              RUN npm ci --only=production
              CMD ["npm", "start"]
            imageName: registry.cn-hangzhou.aliyuncs.com/my-namespace/my-tiny-api
            imageTag: ${BUILD_NUMBER}

  - stage:
      name: Test
      steps:
        - step: script
          name: Run tests
          properties:
            commands: ["npm test"]

  - stage:
      name: Deploy
      steps:
        - step: deploy@kubernetes
          name: Ship it!
          properties:
            clusterId: "cls-xxxxxx"  # ← your ACK cluster ID
            namespace: "default"
            manifests:
              # Your Deployment + Service YAML goes here
              # (see full example in the expanded version)

🛠️ Gotchas I hit:

Make sure your Container Registry namespace exists

Grant your DevOps project permissions to ACK and ACR (it prompts you!)

Use npm ci, not npm install, for reproducible builds

I clicked Run, held my breath… and watched it build, test, and deploy—successfully!

Step 4: Automate It

Back in pipeline settings, I turned on “Trigger on push to main”.

Now, every time I git push, magic happens:

Code lands in the repo
Pipeline starts automatically
New version is live in my cluster in ~2 minutes

It feels like cheating. In a good way.

Bonus: It’s Not Just for Alibaba Fans

Even if you’re used to GitHub Actions or GitLab CI, give this a look if:

You’re already on Alibaba Cloud
You want less context-switching
You value “it just works” over maximum flexibility

Is it as customizable as Jenkins? No.

Do I care for a small project? Also no.

Sometimes, simplicity is the real superpower.

Final Thoughts

I walked in expecting complexity. I walked out with a working CI/CD pipeline and time to spare.

If you’ve been putting off automating your deployments—especially on Alibaba Cloud—just try it. You might be done before your coffee gets cold.

🔗 Get started: Alibaba Cloud DevOps

(Yes, there’s a free tier!)

Have you tried Alibaba Cloud DevOps?

Or do you swear by another CI/CD tool? I’d love to hear your take in the comments! 👇

—

Built something cool with cloud automation? Share it! We’re all learning.

#devops #cicd #alibabacloud #kubernetes #webdev #beginners #programming #automation

P.S. No, I don’t work for Alibaba—I’m just a dev who hates manual deploys. 😅