Translated from the Korean original. Some screenshots show the original Korean interface.
After GitOps, are operations really automated?
With the shift to cloud native, many teams are adopting GitOps, especially tools like Argo CD. Declarative configuration, Pull Request-based approval, automatic sync. Deployments got much faster and more reproducible. You rarely need to log in to a server to change infrastructure settings anymore. But you have probably run into something like this at least once.
"The deployment succeeded, but users keep complaining that it's slow."
The moment the code is merged and the deployment success message appears, a whole different kind of problem starts for the service. Performance issues such as transaction processing bottlenecks, database load, and network latency quietly surface, and users start to feel the pain. The more often you deploy, the more often, more subtly, and more quickly these changes appear.
In this post, we talk about why you need APM (Application Performance Monitoring) in a GitOps/ArgoCD environment. We look at why it matters to observe the performance of running applications in real time from the moment a deployment ends, catch warning signs early, and analyze causes quickly, and how InterMax plays that role.
1. The operations paradigm GitOps changed
The core of GitOps is "managing operations as code." Instead of editing configuration files directly or applying changes immediately with CLI commands as before, you now declare the desired state with a single Pull Request and track every change in the Git repository.
💡 GitOps is an approach that uses Git as the single source of truth to manage operations as code, and ensures consistent, reproducible deployments by automatically syncing the actual system state with the state declared in Git.
1-1. Core principle: code is infrastructure
DZone describes GitOps as "an approach that uses Git as the Single Source of Truth to automatically detect drift and keep environments consistent." The state of the Git repository becomes the standard for the actual production environment, and every change is traceable and applied through an approval process.
According to the CNCF GitOps Microsurvey, 60% of respondents have already been using GitOps for more than 1 year, and 31% adopted it within the last 12 months. Among organizations that have not adopted it yet, 67% said they plan to start GitOps within 1 year. These numbers show that GitOps is no longer an experimental concept but has become the de facto default operating model in most cloud and Kubernetes environments.
The reason respondents cited most for adopting GitOps was "faster software delivery (71%)," followed by "better configuration management (66%)" and "more consistent deployments (66%)." This shows that GitOps is not just a tool for automating deployments but has become a key strategy for securing both operational efficiency and stability.
1-2. The operations team's role: from managing to observing
But as automation has grown, the operations team's role has changed too. Instead of managing servers directly, operations teams now focus on observing "how the actual service behaves after deployment." If performance degrades even though the code change was deployed correctly, the problem is not the deployment process. It comes from runtime characteristics such as resource contention in the execution environment, transaction bottlenecks, and delays in external dependencies. Deployment is automated, but whether the deployed service actually works and keeps its performance still requires real-time observation and analysis.
1-3. The blind spot of automation: uncertainty after deployment
GitOps automates the process of "code change → approval → deployment," but the world after deployment is far more complex. When a new version is deployed, many microservices are affected at once, and if even one of them hits a bottleneck, overall performance suffers. This is an area GitOps does not watch: problems that are not in the code but exist at runtime. That is exactly why operations teams still have to track real-time performance metrics, analyze transactions, and find the root cause of incidents.
1-4. What GitOps automation means as it extends to DevOps and SRE
If DevOps emphasizes collaboration between development and operations, GitOps manages operations as code and automates that collaboration. But from the SRE (Site Reliability Engineering) perspective, the ultimate goal of automation goes beyond efficiency: it is to guarantee service reliability at a measurable level. GitOps automates "how to deploy," but SRE needs a system that quantitatively verifies "whether the service is maintaining its target availability and performance levels (SLO)."
This is where APM acts as a bridge between GitOps and SRE. By observing the state of deployed services in real time, detecting transaction slowdowns and errors against SLO criteria, and quickly identifying the root cause, it helps operations teams manage service quality as a measurable goal. Deployment automation (GitOps) and service reliability management (SRE) only connect into a complete operations system through real-time observation (APM).
2. APM fills the gap in automation
For example, right after a new microservice is deployed, transaction response time may increase, the database connection pool may run out, or network latency may occur between services. These problems do not show up in the code itself or in the deployment pipeline. They are runtime issues that only appear when the service runs in the actual production environment.
The problem is that GitOps automation does not reach this far. GitOps automates "code change → approval → deployment," but it does not check whether the deployed application actually works. So operations teams are still left reading monitoring dashboards and logs themselves to judge whether things are normal. The real task after GitOps is building a system that observes the performance and quality of deployed services in real time and detects problems early. This is exactly where APM (Application Performance Monitoring) comes in. APM tracks in real time how an application actually behaves and where performance degrades, and lets you identify the root cause of the problem.
3. A real scenario: tracing failures after deployment
Imagine user inquiries spiking right after a new version is deployed. The GitOps pipeline only reports 'Synced & Healthy,' but real users are experiencing slow responses and timeout errors. Here, APM tracks transaction performance changes from the time of deployment and visualizes in real time which service saw its error rate spike and where the latency occurred.
The operations team can immediately pinpoint when the problem started and which components were affected, without digging through the logs of dozens of services one by one. As a result, both mean time to detect (MTTD) and mean time to recovery (MTTR) go down. In this way, APM works as a key element that extends GitOps deployment automation into operations automation centered on service quality.
4. InterMax: the APM that completes the GitOps environment
InterMax is the APM that completes operations after GitOps. It tracks performance at the transaction level from right after deployment and shows in real time how code changes affect actual response time, error rate, and throughput.
- Before/after deployment performance comparison → see changes in response time and error rate right after a new version ships
- Automatic detection of abnormal transactions → catch problems early, before users feel them
- Root cause analysis (RCA) → shorter recovery time (MTTR) and fewer recurring incidents
It is not just a tool that reports errors. It quantifies performance changes before and after deployment and enables data-driven operational decisions.
InterMax analyzes a service's response patterns, transaction paths, and user session data in real time and presents the cause of a problem as clear data. Instead of reacting after an incident, the operations team can catch performance warning signs right after deployment and respond proactively. As a result, you can achieve true End-to-End automation, from code change to deployment, performance analysis, and optimization.
Extend GitOps automation into operations automation.
👇 Learn more about InterMax
Sources
dzone.comWhy GitOps Is Gaining Popularity in DevOps
Why GitOps Is Gaining Popularity in DevOps
GitOps revolutionizes infrastructure management with Git, boosting automation, speed, and collaboration making it a game-changer for DevOps.
Related articles
