Simple AWS: Using SNS to Decouple Components
What is SNS and how it's used to decouple components. Some cool tips for SNS, a fantastic tool, and a haiku.
Welcome to Simple AWS! A free newsletter that helps you build on AWS without being an expert. This is issue #7. Shall we?
Using SNS to decouple components
AWS Service: Amazon SNS
tl;dr: SNS is a managed publish-subscribe service. The whole idea of the publish-subscribe model is that producers send messages to topics and consumers subscribe to those topics to receive the messages. In SNS you create a topic, subscribe to it, and when a producer publishes a message to it, SNS automatically delivers the message to all of the subscribers of that topic. Subscribers can be email addresses, phone numbers (using SMS), HTTPS endpoints, application endpoints (other protocols), Lambda functions (directly invoked), SQS queues, Kinesis streams or ECS services.
In the last issue we discussed a bit about event-driven architectures. SNS fits in there too, acting as a central hub over which different components communicate. Publishers don't know anything about consumers, so those components are decoupled. Also, since multiple consumers can subscribe to a topic, SNS is used to "fan out" a message (i.e. get it to many subscribers).
Cool things that you can do with SNS:
- SNS can be used to send SMS messages to phones. It's not the cheapest option ($0.00847/message (US) vs $0.0079/message (US) of Twilio), but it's super simple to set up.
- You can trigger Lambda functions when messages are published to a topic. Great for serverless workflows and event-driven architectures!
- Use SNS to fan out messages to multiple recipients. For example, instead of having Service A send a message to Service B and to Service C, you can send the message to an SNS topic where Services B, C and maybe others are subscribed to. Every subscriber gets a copy of the message.
- You can send cross-account messages!
- If some consumers are not guaranteed to be able to handle the message right away, you should add an SQS queue between the SNS topic and the consumer. The queue is subscribed to the topic, and the consumer reads from the queue. Like this: Producer --> SNS topic --> SQS queue --> Consumer. Why use SNS then? To fan out the message to multiple consumers (maybe multiple queues!).
This issue's tool is not exactly related to SNS, but is super cool, and very useful if you're building serverless architectures.
Presenting Application Composer, a new service launched by AWS just this month. It's a tool where you build your architecture diagram using a visual editor (like LucidChart or Draw.io), and it generates the CloudFormation code to implement it.
One service to another
Without coupling them
I hope you had a great Christmas!
I'm worried that I might be diving too much into serverless. Is that a problem? What kind of architectures are you working on? Hit reply and let me know!
Also, I'm adding a Sponsors section. I'm testing out a few monetization options. Let me know if you find it annoying in any way.
As the new year approaches, so do new year's resolutions. If one of yours is to get AWS Certified, I highly recommend Adrian Cantrill's courses. With their mix of theory and practice, they're the best I've seen. I've literally bought them all (haven't watched them all yet).
The above link is an affiliate link, I will earn a small commission if you purchase from that link. I still highly recommend Adrian's courses, even if I didn't get a commission. I'm just being open about it.
Thank you for reading! See ya on the next issue.