Sirus Solution Architect Tim presenting a microservice architecture diagram on a large screen during a technical team meeting

Agnostic Integration Patterns: rethinking cloud-native architecture

June 26, 2026
Merelbeke-Melle

This blog is a preview of our session at Sirus Connects on October 9, 2026, where we rethink cloud-native architecture through agnostic integration patterns, Dapr and API Management.

"Agnostic Integration Patterns" is not about replacing what we know, it's about refining how we apply it. By combining proven integration patterns with tools like Dapr and API Management, we can build systems that are truly cloud-native in spirit: portable, resilient, and independent by design.

When people talk about building cloud-native applications, the conversation often centers around adopting managed cloud services, Kubernetes, or serverless technologies. While these are important, they only scratch the surface. In reality, cloud-native is not about where your application runs, it’s about how it is designed to adapt, integrate, and evolve independently of its environment.

In my talk, “Agnostic Integration Patterns”, I invite you to rethink cloud-native as infrastructure-agnostic architecture.

Moving beyond the buzzword

“Cloud-native” has become a buzzword that is often equated with vendor ecosystems. This creates a dangerous side effect: applications become deeply tied to specific infrastructure choices. While this might accelerate initial development, it can limit flexibility in the long run.

True modern applications should be:

  • Portable across environments (on-premises, cloud, edge)
  • Flexible in their infrastructure choices
  • Resilient to change and failure

This is where the concept of infrastructure-agnostic design becomes critical. Rather than building directly against specific services, we focus on decoupling application logic from infrastructure concerns.

Integration without infrastructure assumptions

Integration is at the core of distributed systems. Whether it’s synchronous APIs or asynchronous eventing, services need to communicate reliably. Historically, we’ve relied on a set of well-known integration patterns such as request/response, messaging queues, and publish/subscribe.

These patterns are still relevant, but the way we implement them must evolve.

In an infrastructure-agnostic world, we should avoid assumptions like:

  • Which message broker is used
  • How services are discovered
  • Where state is stored

Instead, we define integrations using contracts and abstractions, ensuring that the underlying implementation can change without impacting the application itself.

Dapr: a practical abstraction layer

One of the key enablers of this approach is Dapr (Distributed Application Runtime). Dapr provides a set of building blocks that abstract common distributed system challenges such as service invocation, state management, and pub/sub messaging.

What makes Dapr powerful is its pluggability. Applications interact with consistent APIs, while the actual implementation can be swapped without modifying the application code.

This approach allows developers to:

  • Focus on business logic instead of infrastructure plumbing
  • Avoid vendor lock-in
  • Build applications that can run consistently across environments

Dapr doesn’t introduce new patterns, it decouples existing patterns from infrastructure dependencies, making them more portable and adaptable.

The role of API management

While Dapr handles internal communication between services, API Management (APIM) provides control at the boundaries of your system. I show you how API Management can act as an intelligent integration orchestrator, not just a gateway or façade. It becomes the central abstraction layer for integration itself.

Rather than exposing services directly or forcing consumers to understand how communication is implemented, the API manager fully decouples the requester from the integration mechanics. Whether a request is handled synchronously through direct service invocation or asynchronously via messaging and eventing is no longer the concern of the caller.

This means:

  • Consumers simply interact with a consistent API contract
  • The routing, transformation, and delivery mechanism are handled transparently
  • Integration patterns (request/response, pub/sub, workflows) can evolve without impacting clients

By shifting this responsibility into the API management layer, we gain the ability to change how systems communicate without changing how they are consumed. A synchronous API today can become an event-driven flow tomorrow, all without breaking clients or requiring redesign.

Revisiting Integration Patterns

A key takeaway from this journey is that traditional integration patterns are far from obsolete. Instead, they are more relevant than ever and I will show you how to implement them.

For example:

  • Request/response becomes resilient service invocation with retries and circuit breakers
  • Event-driven architecture leverages abstracted pub/sub systems
  • Stateful services use pluggable state stores

The patterns remain familiar, but their implementation becomes more flexible and portable.

Conclusion

“Agnostic Integration Patterns” is not about replacing what we know, it’s about refining how we apply it. By combining proven integration patterns with tools like Dapr and API Management, we can build systems that are truly cloud-native in spirit: portable, resilient, and independent by design.

The cloud is just one environment. Great architecture transcends it.

Curious how to apply this in practice? Join my session at Sirus Connects on October 9.

Want to follow this live?

Join this session at Sirus Connects on October 9, 2026, from 10h35 to 11h20. Register and secure your spot.

Can’t make it? Reach out to us, we are happy to share our experience and discuss how agnostic integration patterns could strengthen your architecture.

Share via:
Facebook
Twitter
LinkedIn