Entrazure
What we build
API platform. Azure API Management as the front door: products and subscriptions per consumer, versioned contracts published from OpenAPI, rate limiting, request validation, JWT validation against Entra ID, and a developer portal that removes the emailed Postman collection from your life. Policies live in source control, not in the portal.
Asynchronous messaging. Azure Service Bus for ordered, transactional and session-based work, with dead-letter queues, duplicate detection and message deferral configured on purpose rather than left at defaults. Event Grid where the pattern is broadcast notification instead of a work queue. We name which one each flow uses and why.
Compute. Azure Functions for stateless handlers and transformations, with isolated worker model, managed identity to every downstream resource, and no connection strings in app settings. Logic Apps where a connector-heavy SaaS flow genuinely ships faster, chosen deliberately and documented as a portability trade-off.
Contracts and data shape. A schema per message and per endpoint, versioned, with an explicit compatibility rule. Breaking changes go through a deprecation window, not an email.
Failure behavior. Retry with exponential backoff and jitter, idempotency keys on every consumer, circuit breakers on outbound calls, dead-letter handling with a named owner, and a replay path that a support engineer can run without a developer.
Observability. Correlation IDs propagated end to end, Application Insights distributed tracing, and alerts on queue depth, dead-letter count and consumer lag rather than on CPU.
Power Platform governance. Environment strategy, DLP policies, Dataverse solution layering and ALM through pipelines, so the citizen-built app that became business-critical has a deployment path and an owner.
How we decide what goes where
Three questions settle most of it, and we answer them per flow in writing rather than adopting a house style.
Does the caller need the answer now, or can the work happen later? Synchronous requests go through API Management. Anything the caller does not have to wait for goes on Service Bus. The expensive mistake is putting a slow downstream system behind a synchronous call and then describing the resulting timeouts as an infrastructure problem.
Does the message describe something that happened, or something that must be done? Events are broadcast on Event Grid and may legitimately have zero consumers. Commands go on a queue and have exactly one owner. Conflating the two produces a system where nobody can say whether a given message was ever handled.
Is the process business-critical and long-lived? Then it is code in a repository with tests, not a canvas in a designer. Applied honestly, that rule keeps the Logic Apps conversation short and stops it being reopened every six months.
How the engagement runs
Week 1, inventory and contracts. We list every interface that exists today, including the scheduled SFTP job nobody documented, and record for each one the direction, volume, latency tolerance and what happens today when it fails. That last column is usually empty, and filling it is most of the value of the week.
Week 2, platform. API Management, Service Bus namespaces, Event Grid topics, Functions and the network path between them, deployed as Terraform into the landing zone with private endpoints and managed identity throughout.
Weeks 3 and 4, first two integrations. We build the two flows that carry the most risk, not the two that are easiest, because the hard ones reveal the platform decisions that were wrong while there is still time to change them.
Week 5, hardening. Load behavior, retry tuning, dead-letter runbooks, alerting thresholds, and a deliberate failure exercise where we take a downstream system offline and watch what the platform does.
Week 6, handover. Pipelines, documentation, the interface catalog, and a walkthrough with the engineers who will build the next twenty flows themselves.
What you keep
- A Terraform repository for the integration platform, in your Git organization.
- An interface catalog: every flow, its contract, its owner, its failure behavior.
- Versioned OpenAPI definitions and the API Management policies as code.
- Runbooks for dead-letter replay and for the three most likely failure modes.
- Deployment pipelines with environment promotion and rollback.
- A written list of what we chose not to integrate, and the reason.
Who this is for
Organizations with a growing estate of systems that were bought separately and now have to agree with each other: an ERP, a CRM, a warehouse system, a portal, and a data platform behind them. It fits particularly well after an Azure landing zone is in place, and immediately before a Microsoft Fabric program, because clean interfaces are what keeps a lakehouse from becoming a second copy of everyone’s mess.
It is also the right first step when an AI project is blocked. Most agent work stalls on data access, not on models, which is why AI engineering engagements so often begin here.
Who this is not for
If you have two systems and one nightly file transfer, an integration platform is overhead and we will tell you to keep the file transfer and add monitoring to it. If you want a point-to-point connector built this month with no interest in the contract or the failure path, that work is real but it is not what we do, and the debt lands on you in about a year.
If the underlying problem is that two departments disagree about which system holds the authoritative customer record, no amount of Service Bus fixes it. That is a governance decision, and it has to be made by a person, ideally the one described on the fractional CIO page.
Related
- DevOps and infrastructure as code: the pipelines this platform ships through.
- AI engineering on Azure AI Foundry: what the clean interfaces feed next.
- Compliance architecture: where message retention and audit logging get their requirements.
- Healthcare: integration under HL7, FHIR and residency constraints.
- All Azure services: where the integration platform sits in the wider estate.
Questions we get
Do we need API Management, or is a Function enough?
If you have three internal endpoints and one consumer, a Function behind Application Gateway is enough and we will say so. API Management earns its cost when you have multiple consumers, need per-consumer throttling and keys, publish versioned contracts, or have to show an auditor who called what. Below that threshold it is a subscription you pay for to feel governed.
Should we build on Logic Apps?
For scheduled connector-heavy work against SaaS systems, Logic Apps is faster to build and cheaper to maintain than the equivalent code. For a core business process that must be portable, testable in a unit test and diffable in a pull request, it is the wrong container. We decide per integration and write down which category each one falls into.
How do you stop integrations failing silently?
Every message carries a correlation ID from entry to completion, every consumer is idempotent, every queue and topic has a dead-letter path with an owner and an alert, and Application Insights traces the whole hop chain. Silent failure is almost always the absence of a dead-letter policy, not a bug in the code.
Can you integrate with our ERP or a system with no API?
Yes. Where a modern API exists we use it. Where it does not, the options are a database-level change feed, a file drop with a watcher, or a vendor adapter, and each has a different failure profile that we document before choosing. We are direct about which ones age badly.
Who owns the platform after go-live?
Your team, in your repository, with the Terraform and the pipelines. If you would rather we ran it, that is a separate managed arrangement priced separately, not a dependency we design into the build.
Does this cover Power Platform?
Yes, as the governance layer: environment strategy, DLP policies, Dataverse design, and the boundary between what belongs in Power Automate and what belongs in a Function. Ungoverned citizen development becomes shadow IT with a Microsoft logo on it.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.