This article is based on analysis originally published at itproportal.com (June 2019). It has been rewritten and expanded for a DevOps engineering audience.
Microservices: Legitimate Trend or Hype?
Microservices are not a fad. They represent a specific, well-grounded instance of a broader IT trend toward modularity and component miniaturisation. Where traditional system components were designed to remain stable for years, individual microservices can have lifespans measured in minutes or even seconds — particularly in ephemeral, container-based environments where services are spun up, used, and torn down on demand.
This shift toward smaller, short-lived, independently deployable units aligns with how modern engineering teams want to work: making local changes without needing deep knowledge of every other part of the system, and scaling individual capabilities rather than entire applications.
The Complexity Cost of Modularity
The primary motivation for adopting microservices is agility. DevOps teams can change discrete services to meet evolving business requirements without the risk and effort of modifying a monolithic codebase. From an infrastructure perspective, microservices also give teams more freedom when distributing workloads — for example, choosing which components migrate to the cloud and which remain on-premises, or how to spread services across multiple cloud regions or providers.
But there is no free lunch. Every gain in agility and development speed comes at the cost of increased operational complexity. This is not complexity in a vague sense — it is a measurable increase in system entropy.
In a low-entropy monolithic system, a handful of monitoring vantage points can give you a reliable picture of the overall system state. In a high-entropy microservices environment composed of dozens or hundreds of loosely coupled, independently operating services, you cannot infer the end-to-end state from a few snapshots. You need visibility into nearly every component simultaneously to understand what is actually happening — and that visibility must be continuous, not periodic.
Why Traditional Monitoring Tools Fall Short
Legacy monitoring tools were designed for the low-entropy world of monolithic applications. They work by collecting a manageable number of metrics from a stable set of components, correlating events against known thresholds, and alerting operators when something crosses a boundary.
That model breaks down in a microservices architecture for several reasons:
- Volume: The number of services, instances, and interactions generates orders of magnitude more data than traditional monitoring was designed to handle.
- Dynamism: Services appear and disappear rapidly; static threshold-based alerting cannot keep pace with a constantly shifting topology.
- Interdependencies: A failure in one service may manifest as degraded performance in a completely different part of the stack. Tracing the causal chain manually is impractical.
- Signal-to-noise ratio: Collecting all available data into a centralised big data platform is necessary but not sufficient. As the volume grows, so does the difficulty of identifying meaningful signals amid the noise.
Assembling all your telemetry data into a data lake or SIEM is only the first step. Without a way to find the needle in that haystack, the data is operationally useless.
Where AIOps Fits In
AIOps — the application of AI and machine learning to IT operations — addresses the core problem that high-entropy microservices environments create: pattern detection and root-cause analysis at a scale and speed that exceeds human cognitive capacity.
The fundamental premise is this: abnormal end-to-end system behaviour follows identifiable patterns, but those patterns are embedded in data streams too complex for human operators to parse in real time. An AIOps platform can:
- Ingest high-volume telemetry data from across the entire stack — metrics, logs, traces, and events.
- Identify statistical patterns that deviate from normal baseline behaviour, even when that baseline is itself constantly evolving.
- Correlate events across services to surface probable root causes rather than flooding operators with thousands of individual alerts.
- Present actionable insights that human operators can act on, or feed directly into an orchestration engine for automated remediation.
In short, AIOps does not replace human judgment — it makes human judgment possible again in environments where unassisted human analysis would simply be overwhelmed.
AIOps, Orchestration, and the Cloud
Microservices work best with automated orchestration — platforms such as Kubernetes that schedule, scale, and manage containerised services dynamically. For orchestration to be effective, the decisions driving it need to be grounded in accurate, real-time understanding of system state and business requirements.
This is where AIOps and orchestration intersect most powerfully. An AIOps platform that detects an emerging performance degradation pattern can feed that analysis directly into an orchestration engine — triggering a scale-out, a traffic reroute, or a service restart — before the issue becomes visible to end users.
The introduction of cloud infrastructure adds another layer of difficulty. Extracting telemetry from cloud-managed services can be harder than from on-premises infrastructure, and multi-cloud or hybrid architectures compound this further. However, cloud does not fundamentally change the role AIOps plays. The requirement — full-stack observability and intelligent pattern analysis — remains the same regardless of where the workloads run.
The Role of Healthy Scepticism
Every major technology transition attracts sceptics, and scepticism around microservices is not without merit. The operational burden of a large microservices estate is substantial, and organisations that adopt microservices without accounting for that burden can find themselves with systems that are harder to run than the monoliths they replaced.
In this context, sceptics who push for better observability, root-cause analysis capabilities, and honest total-cost-of-ownership accounting serve a genuinely useful function. If the cost of operating a microservices architecture is not factored in from the beginning, the economic case for the transition will be distorted — and the project risks becoming a technical success but an operational failure.
A related risk: organisations that adopt microservices only for new applications while leaving legacy monoliths untouched often end up with the worst of both worlds — the operational complexity of microservices layered on top of the rigidity of existing systems, without delivering the full modernisation benefits that motivated the change in the first place.
Topology and Graph-Based Analytics: The Next Frontier for AIOps
As AIOps matures alongside microservices adoption, one analytical capability is becoming increasingly central: topological and graph-based analysis.
Understanding causality in a microservices environment requires understanding the relationships between services — which services call which other services, how those relationships change over time, and what the propagation path of a failure looks like as it travels through the dependency graph. This is inherently a graph problem, not a simple time-series or threshold problem.
Some AIOps vendors have invested in graph-based algorithms to model service topology and trace causal paths. However, this is still an area of active development across the industry. As microservices architectures grow in scale and complexity, the ability of an AIOps platform to reason about topology — dynamically, in real time — will increasingly determine how effective that platform is at surfacing actionable root-cause insights.
The expectation is that topological analysis will move from a secondary AIOps capability to a primary one. The particular kind of complexity that microservices introduce — many small components, constantly changing connections, cascading failure modes — is precisely the kind of complexity that graph-based analytics is best suited to address.
Key Takeaways
- Microservices increase system entropy, making traditional monitoring approaches inadequate for understanding end-to-end system state.
- Collecting telemetry data at scale is necessary but not sufficient — AIOps provides the pattern recognition and causal analysis needed to make that data operationally useful.
- AIOps and orchestration engines are complementary: AIOps surfaces the insight; the orchestration engine acts on it.
- Cloud environments complicate telemetry extraction but do not change the fundamental role AIOps plays.
- Operational cost must be accounted for from the start of any microservices initiative — AIOps is part of that cost, and part of what makes the economics viable.
- Graph-based topological analytics is an emerging capability that will become central to AIOps as microservices architectures scale.