Connect to and consume Azure services and third-party services
Implement Azure API Management
Azure API Management (often called APIM) is a service that sits in front of your APIs and controls how people access them. Think of it as a gatekeeper that stands between the outside world and your backend services. When a developer wants to use an API, they first go through the API Management layer, which can require authentication, limit how many requests they can make, and log what they're doing. This layer also transforms requests so that different clients can talk to different backend services without needing to know the details of each implementation.
The service has three main parts that work together. The API gateway receives all incoming requests, checks if they are allowed, applies any rules like rate limits, and forwards them to the right backend service. The developer portal is a website where developers can sign up, read documentation, test APIs, and see how their usage is tracking. The management plane is where administrators configure the service, set up security policies, and monitor how APIs are performing. Traffic flows from the client to the gateway, then to the backend, and responses follow the same path in reverse.
Organizations choose API Management when they need to expose APIs to external developers, partners, or other departments in a controlled way. It handles cross-cutting concerns like security and monitoring in one place, so each individual API team does not have to build these features themselves.
Develop event-based solutions
Event-based solutions allow different parts of an application to react to things that happen without directly calling each other. Instead of one service telling another what to do, a service simply announces that something occurred, and any interested parties can respond. This makes systems more flexible because services do not need to know about each other ahead of time.
Azure Event Grid moves events from one place to another like a postal system for notifications. When something happens—a file is uploaded, a database changes, a user signs in—an event is published to a topic. Services that care about that type of event subscribe to the topic, and Event Grid delivers the event to them. The flow is simple: a publisher sends an event to a topic, Event Grid routes it to the right subscribers, and each subscriber handles it independently. This works well for reactive scenarios where different parts of the system need to know about actions as they happen.
Azure Event Hubs handles a different scenario: collecting massive streams of events in real time, like millions of sensor readings, click streams, or log entries. It works like a very large, durable inbox that can receive events as fast as producers can send them. Applications then read from the hub at their own pace for processing, analysis, or storage. Event Hubs organizes data into partitions so that multiple readers can process the stream simultaneously without interfering with each other.
The key difference between these services is the scale and purpose of the communication. Event Grid is for discrete notifications that trigger immediate reactions, while Event Hubs is for continuous high-volume data streams that are captured for later processing.
Develop message-based solutions
Message-based solutions use persistent messages to pass information between services, ensuring that data is not lost even if a receiving service is temporarily unavailable. Unlike event-based communication where the focus is on "something happened," message-based communication focuses on "something needs to be done." The sending service puts a message in a queue, and the receiving service picks it up when ready.
Azure Service Bus provides enterprise-grade messaging with features like transactions, duplicate detection, and complex routing. It supports two patterns: queues and topics. A queue works like a to-do list where one service puts items and another service processes them one at a time. A topic works like a mailing list where one service publishes a message and multiple services can each receive their own copy. Topics enable a publish-subscribe pattern where one sender notifies many receivers.
Azure Storage Queues offers simpler queue functionality for basic scenarios. It integrates with Azure Storage accounts and works well when you need straightforward message passing without advanced features. The trade-off is that Storage Queues has fewer enterprise features compared to Service Bus, but it is easier to set up and costs less for simple use cases.
When deciding between Service Bus and Storage Queues, consider whether you need advanced features like topics, transactions, or message sessions. Choose Service Bus for complex enterprise integrations and choose Storage Queues for simpler applications that just need reliable message delivery.