What is Messaging?
Messaging is a technology that enables high-speed, asynchronous, program-to-program communication with reliable delivery.
How messaging systems work?
- Create — The sender creates the message and populates it with data.
- Send — The sender adds the message to a channel.
- Deliver — The messaging system moves the message from the sender’s computer to the receiver’s computer, making it available to the receiver.
- Receive — The receiver reads the message from the channel.
- Process — The receiver extracts the data from the message.
What are the advantages of messaging systems?
- Send and forget — The sending application sends the message to the message channel. Once that send is complete, the sender can go on to other work while the messaging system transmits the message in the background. The sender can be confident that the receiver will eventually receive the message and does not have to wait until that happens.
- Asynchronous communication: Once the message is stored, the sender is then free to perform other work while the message is transmitted in the background
Message vs Event
- What is an event? An event encapsulates a change in state (what has happened).
- What is a message ? A message encapsulates the intention / action (what has to happen)
- How are events distributed? Streaming and Messaging systems
- How are messages distributed? Messaging systems
What is a stream?
- A stream consists of immutable data, only inserting new events, whereas existing events cannot be changed.
- Streams are persistent, durable and fault tolerant.
What is streaming?
- Streaming of data is the constant flow of events where each event should contain enough information to reflect the change in state.
- It allows for the processing of data to occur in real-time (data in motion) and is different from the traditional approach for the processing of static data to occur (data at rest) at a later point in time, known as batch processing
- Streaming data is unbounded, meaning it has no real beginning and no real end
- Each event is processed as it occurs and is managed accordingly
Services in AWS for messaging and streaming
- Amazon MQ
- Use case: Migrate to a managed message broker to automate software administration and maintenance, without having to rewrite existing applications
- Use case: Build decoupled, highly scalable microservices, distributed systems, and serverless applications in the cloud
- Use case: Push messages to a variety of endpoints and clients in distributed systems, microservices, and serverless applications and enable event-driven architecture
- Kinesis Streams
- Use case: Build custom, real-time applications that process data streams using popular stream processing frameworks
- IOT Message broker
- Use case: Send messages to/from devices and AWS IoT apps in a secure fashion using MQTT, HTTP, and WebSockets
- Queue Types :
- Standard :
- Messages are delivered at least once.
- You can use standard message queues in many scenarios, as long as your application can process messages that arrive more than once and out of order
- Messages are delivered exactly once.
- FIFO queues are designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can’t be tolerated
- Standard :
- What is polling? A way that one system continuously checks other systems to see what state they are in and if they have any message to communicate.SQS supports two types of polling short polling and long polling
- Short polling:
- Long polling: When a consumer poll’s the queue and if it doesn’t find a message it could still wait for up to 20 seconds and receive the message instantaneously if a message comes into the queue.
- When to use short polling?
- If your application expects an immediate response.
- Example: If your application uses a single thread to poll multiple queues, switching from short polling to long polling will probably not work, because the single thread will wait for the long-poll timeout on any empty queues, delaying the processing of any queues that might contain messages.
- Visibility timeout
- When a customer receives a message, it must delete the message from the queue.
- But it is not guaranteed that the customer really received the message.
- So to prevent other consumers from processing the message again, Amazon SQS sets a visibility timeout, a period of time during which Amazon SQS prevents other consumers from receiving and processing the message.
- Dead letter queue: The Dead Letter Queue is a secondary queue that receives messages from the first queue after a certain number of times the message wasn’t processed on the main queue. It’s a way to store problematic messages in a separate queue for further analysis.
Many businesses worldwide are using two kinds of message-oriented middleware or message
brokers, 1/ Commercial Brokers such as IBM MQ & TIBCO EMS, and 2/ Open-sourced brokers such as Apache ActiveMQ & RabbitMQ. These businesses often discover some challenges in managing these brokers.
Amazon MQ is a managed message broker service, which makes it easy to set up and operate message brokers in AWS.
- Advantage :Customers can leverage Amazon MQ to connect new cloud-native applications to their on-premise systems or to migrate one or more existing applications to the cloud while maintaining interoperability with back end systems and standards compliance.
- Broker engine types
- Apache ActiveMQ Deployment modes
- Single instance
- Active / standby
- Network of brokers
- RabbitMQ deployment modes
- Single Instance broker
- Cluster deployment
- MQ ENI : When you first create an Amazon MQ broker, Amazon MQ provisions an elastic network interface in the Virtual Private Cloud (VPC) under your account. The network interface allows your client (producer or consumer) to communicate with the Amazon MQ broker.
- Active MQ
- Native Active MQ authentication
- LDAP Authentication
- Rabbit MQ
- Native RabbitMQ authentication
- Active MQ
- At rest : Data can be encrypted by using security keys stored in KMS
- In transit : All connections between Amazon MQ brokers use Transport layer Security (TLS) to provide encryption in transit.
SNS is a fully managed pub/sub messaging service that lets you fan out messages to large numbers of recipients at one time, using topics.
- SNS Topic: An Amazon SNS topic is a logical access point that acts as a communication channel. A topic lets you group multiple endpoints (such as AWS Lambda, Amazon SQS, HTTP/S, or an email address).
- SNS Topic FIFO:
- Using SNS FIFO topics and SQS FIFO queues enables the processing of messages in order and with no duplication.
- Message filtering:
- By default, each subscriber receives every message published to the topic.
- To receive a subset of the messages, a subscriber must assign a filter policy to the topic subscription.
- A filter policy is a simple JSON object containing attributes that define which messages the subscriber receives.
- Message security: Server-side encryption protects the contents of messages that are stored in Amazon SNS topics, using encryption keys provided by AWS KMS.
- Dead letter queue:
- A dead-letter queue associated with an Amazon SNS subscription is an ordinary Amazon SQS queue.
- Messages that can’t be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing. A dead-letter queue associated with an Amazon SNS subscription is an ordinary Amazon SQS
Kinesis Data Stream
- Stream: A Kinesis data stream is a set of shards. Each shard has a sequence of data records. Each data record has a sequence number that is assigned by Kinesis Data Streams
- Shard: Every record you write to the stream ends up in exactly one shard, where it is stored in the same order it was written, until it expires. To decide which shard to put a record to, Kinesis uses a so-called partition key. Reference and image credit: https://dev.solita.fi/2020/05/28/kinesis-streams-part-1.html
- Producer: A producer is an application that writes data to Amazon Kinesis Data Streams. You can build producers for Kinesis Data Streams using the AWS SDK for Java and the Kinesis Producer Library.
- Kinesis Producer Library (KPL) (application)
- Amazon Kinesis Data Streams API with the AWS SDK
- Kinesis agent: Kinesis Agent is a stand-alone Java software application that offers an easy way to collect and send data to Kinesis Data Streams
- Consumer: A consumer is an application that processes all data from a Kinesis data stream
- Kinesis data analytics
- Kinesis data firehose
- Kinesis client library
- Data protection: Server-side encryption using AWS Key Management Service (AWS KMS) keys makes it easy for you to meet strict data management requirements by encrypting your data at rest within Amazon Kinesis Data Streams.
IOT Message broker ( IOT Core )
AWS IoT Core provides the services that connect your IoT devices to the AWS Cloud so that other cloud services and applications can interact with your internet-connected devices.
The message broker distributes device data to devices that have subscribed to it and to other AWS IoT Core services, such as the Device Shadow service and the rules engine