Azure

The message size limit for Service Bus is 1 MB (premium tier).

This video (GERMAN) demonstrates how to expose Azure Service Bus as REST service by using of Azure API Management.

Source: Exposing ServiceBus via Azure API Management | Microsoft Docs

Video: https://docs.microsoft.com/video/media/1de8e6a2-c0ae-4565-902a-be1534538bff/apimsb_mid.mp4

Azure Services map with workload type

See details at Azure Solution Architect Map.pdf · GitHub

How to stay up-to-date with Microsoft Azure
Microsoft Azure is huge and changes fast! At this point in time, there are more than 200 services in Azure, with many, many features. The rate at which services evolve is amazing. New services come out all the time, and services are constantly being improved with new features. Microsoft is able to do this because most services are owned by separate teams that develop functionality.

This high rate of change is great because it keeps providing new ways to solve problems. However, it is very hard to stay up-to-date. It is very hard to keep track of new services; and what their purpose is in the world of Azure.
So the question is how to stay up-to-date? Here are some important information sources:
- Azure Friday | Microsoft Docs
- Azure This Week - A Cloud Guru
- Azure updates | Microsoft Azure
- Announcements | Azure Blog and Updates | Microsoft Azure
- Azure Blog and Updates | Microsoft Azure
- Azure App Service Team Blog
And also, the Azure Developer's Cheat Sheet at GitHub - milanm/azure-cheat-sheet: Azure Cheat Sheet

Message Bus Queues and Topics provide

• Temporal decoupling as message producers and consumers do not have to be online at the same time
• Load leveling to smooth out peaks in load by allowing the consuming application to be provisioned for average load rather than peak load
• Load balancing to have multiple consumers listening on a single subscription with each message being handed off to only one of the consumers, thereby balancing load
• Loose coupling to evolve the messaging network without imcating existing endpoints, e.g. adding subscriptions or changing filters to a topic to accommodate new consumers

With Queues, you can have multiple senders, but only one message-consumer receives and process each message.

Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components.

With Queues, there are two different modes available to process messages.

Received & Delete

This mode is suitable where the system can tolerate not processing messages in case of failure. In this mode, once the consumer service reads the message, it will be deleted from the Queue irrespective of the status of the message process.

Peek

This mode is suitable where the system cannot tolerate ignoring messages in case of failure. So here, messages are processed in two stages, as below.

• Finds the next message to be consumed, locks it to prevent other consumers from receiving it, and then return the message to the application.
• After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receiving process. Then, the service marks the message as being consumed.

Senders send messages to a topic in the same way that they send messages to a queue, but it varies on a slight factor where 'Topics' can have multiple, independent 'Subscriptions'. Subscriptions are durable by default but can be configured to expire and then be automatically deleted.

We can define rules on a subscription. A subscription rule has a filter to define a condition for the message to be copied into the subscription and an optional action that can modify message metadata.

Enable higher throughput levels for Azure Service Bus premium via two new features in public preview today.

First, we are releasing scaling partitions, allowing the use of partitioning for the premium messaging tier. Service Bus partitions enable messaging entities to be partitioned across multiple message brokers. This means that the overall throughput of a partitioned entity is no longer limited by the performance of a single message broker. Additionally, a temporary outage of a message broker, for example during an upgrade, does not render a partitioned queue or topic unavailable, as messages will be retried on a different partition.

Second, we are making a change to our infrastructure, which will result in more consistent low latency. This is accomplished by switching our storage to a different implementation called local store. During public preview we will create partitioned namespaces using this new feature, but in the future all new namespaces will be created on local store.

Source: Public preview: Performance improving features for Azure Service Bus premium

• Managed Identities
  • User Assigned Managed Identities (UAMI)
• Service Principals
• Service Connections

Azure Key Vault is a cloud-based secrets store for holding app secrets, including configuration values like passwords and connection strings that must always remain secure. It keeps secrets in a single central location and provides secure access, permissions control, and access logging.

Use Azure Key Vault to store secrets like Passwords, Shared Access Signature (SAS) tokens, Application Programming Interface (API) keys, and Personal Access Tokens (PAT).

Microsoft Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics.

Service Bus is used to decouple applications and services from each other, which help us to balance workload.