In this video, Jeff Winesett introduces using Amazon SNS as a publish subscribe protocol for achieving parallel workflows. Simple Notification Service allows push notifications to be added so a system architecture.
- [Narrator] Amazon Simple Notifications Service, or SNS, provides a simple way to notify applications or people from the cloud, by creating topics and using a publish-subscribe protocol. SNS allows messages to be published from within an application or directly from the console, and have those messages be delivered to subscribers via several protocols. Messages are first published to a centralized topic, then subscribers to the topic receive the messages.
It is used in cases where the same single message needs to be sent to many subscribers. Take, for example, an IT production support team that needs to be notified when there are issues with a production server. The team is using a monitoring system to monitor the health of the application. For example, Amazon CloudWatch can monitor application health. And when using CloudWatch, alarms can be raised when specific events occur.
These alarms can be configured such that when raised, they publish a message to an SNS topic, then subscribers to this topic will receive the message. Here is what this might look like when the alarm is triggered. It places a message on the SNS topic, then this message is sent to multiple sources at once. In this example, it results in an email being sent to the entire support team, notifying them of a production issue.
SNS supports different protocols, with email being one. Another protocol it supports is SMS text messages. So in this example, it could be configured to send an SMS text message to the single team member who was on-call that week to handle off-hour emergencies. You can also configure it to send different messages based on the different protocols. So in the example of the emergency support team, the email sent to the entire team could be different from the SMS text message sent to the individual on-call.
Here is an example of how to accomplish that configuration. This is an example request that will put a message with the body of, "Hello world," and a subject of, "My first message," on a topic named, "My Topic." If you want to specify different messages for different protocols, you use the JSON structure for the message, rather than a simple string, as shown here. As mentioned, SNS supports different protocols for different endpoints.
Currently, SNS supports the following protocols: HTTP and HTTPS, where the expected receiving endpoint is a URL. Email, which allows for the delivery of a message via SMTP, and where the expected receiving endpoint is an email address. Also one called, "Email-JSON," which allows for JSON-encoded messages to be delivered via SMTP and where the endpoint is also an email address.
There's SMS, which allows for the delivery of messages via SMS, where the endpoint is a phone number. SQS, which allows for the delivery of JSON-encoded messages to an Amazon SQS queue. There is an application protocol which allows for the delivery of JSON-encoded messages to an application. And also a Lambda protocol, where the expected endpoint is an identifier for an AWS Lambda function. SNS allows for the configuration of what are referred to as push notifications.
Posting a message to an SNS topic causes the message to be immediately sent to all subscribers to that SNS topic. And since we can use applications as the endpoints for these messages, SNS allows us to set up a push notification as a means for application components to communicate. This is one way in which SNS differs from Amazon SQS. SQS requires an application to constantly poll for new messages on the queue. This is commonly referred to as a pull approach.
SNS allows us to introduce a push approach as a solution to keep system components independent and decoupled. Also, since SQS message queue itself can be an endpoint, SNS can be used to trigger messages to multiple SQS queues. Doing so not only helps with the coupling system components, but also helps in building out parallel workers. Take for example once again the watermarking application, which was used as an example when discussing SQS and SWF.
This time around there's a new requirement. During the resizing step, a new image should be created in multiple formats, both JPEG and PNG. So in this case, when the image is first uploaded, rather than send a message to an SQS queue, a message can be sent to an SNS topic, to which two SQS queues are subscribed. This immediately drops the same message in both queues and allows each separate process to kick off.
One to resize to JPEG and another to PNG format. When each completes their resizing, they send a message to the watermarking queue and the workflow continues as before. This demonstrates how SNS can be used to distribute the workload in parallel across multiple components. Decoupling components: Lesson number three. Take advantage of the SNS push approach to help with communication between system components, as well as having those components work in parallel for highly efficient and scalable systems.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures