Welcome to part 5 of a multiple part course on passing your AWS Architect, Developer & Sysops Associate exams. The best part…this course is totally free of charge!
Simple Workflow Service (SWF) and Simple Notification Service are admittedly not major players in any of the AWS certifications. But we should at least know the basics of both of these services to cover our bases for the few questions that may show up around them.
You’ll find that where SNS is concerned the exam questions tend to focus purely on knowing the difference between SNS and SQS. So, we’ll dive into what those exactly are in this article.
Spoiler alert, generally speaking you can identify the difference between SNS and SQS is that SNS is a Push based system for sending messages over Email, SMS etc.. and SQS is a Poll based message queue system.
Don’t worry if this is a little brief, keep reading and I’ll explain a little deeper later on.
If you are studying for the:
- AWS Associate Architect
- AWS Associate Developer
- AWS Associate SysOps
Or you are using AWS and want to learn more about SWF & SNS then this is the article for you.
Simple Notification Service is AWS’s allows you to configure and send a variety of different message types including (but not limited to) Email, SMS, SQS queue triggers, API endpoints and triggering lambda functions.
It’s a great cloud based resource that allows you to forget about the nitty gritty of handling various message platforms and focus on what’s important in the first place. The messages themselves.
It exposes functionality via a simple to use web interface which we’ll show you have to set up later in a brief demo on how to use SNS.
In addition you get what generally expect from AWS services. Where you have a configuration and messages stored across multiple availability zones to give high levels of redundancy.
As with most AWS services SNS its based on a pay as you use pricing model and the cost per message differs based on the message type Email, SMS etc…
SNS is PUSH based!
This contrasts starkly with SQS which is PULL based. This question is likely to come up if you are asked to note the main differences between these technologies.
Ok, let’s go through a super simple setup for a SNS topic. In this tutorial we’ll set up a SMS topic that will notify all it’s subscribers.
Let’s start by selecting Simple Notification Service from the Application Integration section of the AWS console.
Here we can see that you are presented with the SNS dashboard. Since we want to create a topic to subscribe to, we click the Create topic option.
This screen is fairly self explanatory. Just give the topic a name and description and we’re good to go. Note that for the topic name you must not include spaces. The form will prompt you if you try. On to the next step!
At this stage you have successfully created a topic. But what use is a topic without subscribers! So lets click Create subscription and add one.
On the create subscription modal window you can see that the protocol can be different per subscriber. So you could notify multiple recipients on the same topic over different message mediums. I.e one over email and another over SMS.
For now let’s select SMS.
Finally we have a subscription setup. Note that I’ve edited out the endpoint for this screen shot, but it would be a mobile phone number.
That’s it, all you need to now is send a message on the topic and this subscriber will be notified over SMS. Simple!
- Messages are instantly pushed to their recipients. In a fire and forget fashion.
- SWF is exposed via an API and Management console interface which are both simple and easy to integrate with applications.
- Multiple message transport emails supports including Email, SMS, Mobile push notifications, API triggers and Lambda triggers.
- Pay as you go model. The pricing structure depends on the message transport medium you chose. For instance SMS messages are significantly more expensive than say Email delivery.
- The functionality is exposed via a simple to use web based AWS management console interface. Which we’ve demonstrated in the previous section.
- Logical grouping of recipients (subscribers) by topics allowing you to target when messages reach a particular group. Handy for things like email subscriptions.
- For more information check out SNS’s FAQ page.
As I said earlier, you’re likely to be asked a question regarding the difference between SQS (Simple Queue Service) and SNS (Simple Notification Service). The main points to know are that SNS is a PUSH based service where messages are pushed out to their recipients.
And SQS is POLL based, where the recipient worker nodes have to ask the server for more work.
The other thing to note are that the pricing plans between these services are difference. Where as with SQS you tend to have a flat usage fee. SNS differs based on the type of message sent. With SMS messages being the most expensive.
So that’s pretty much it for SWF and SNS. Obviously we’ve only scratched the surface of what these services and provide. But if you understand the points highlighted in this article for the exam then you should be in good shape.
In our next lesson we’ll take a look at Amazon’s API gateway, a topic I find really interesting and definitely useful to know for day to day AWS usage and especially the exam certifications.
Simple Workflow is a service designed to map and track background jobs that have parallel or sequential steps at scale. On AWS’s website they describe SWF as “a fully-managed state tracker and task coordinator in the Cloud.”
SWF is really good at tracking the state of an application or process flow. It does this while having a clear separation between the background application logic. This means you can change the underlying implementation of these logical steps without having to worry about affecting the control flow of the application.
What does all that mean?
Put simply, SWF lets you map the steps that make up a system and lets other services worry about the implementation of those steps.
- HA data centers
- Stores task redundantly
- Dispatches them to application components
- Tracks their progress
- Keeps their latest state
- Replaces complexity of custom code workflow solutions
- Eliminates the need for developers to manage the infrastructure plumbing of process automation.
- Seamless scales with your applications usage
- No manual admin of the workflow service is required
- SWF will simply scale based on demand
- Let’s you write you application components and coordination logic in any programming language and run them in the cloud or on premises.
If there’s proof that that Amazon really believes in its products. Then using them to control the inner process flow of its distribution centers is surely it.
For instance, let’s take a look at what those steps may be:
- An order is placed by a customer
- The order is dispatched to the most appropriate Amazon distribution center
- A human worker then locates the item and packages it
- The package is shipped and the order status is updated
Ok I admit, this is a massively oversimplified version of how the process would actually happen. But you get the idea and it highlights 4 logical steps that must occur for this order to be completed.
Remember earlier how I said that the SWF is great at separating implementation logic and control flow. Well let’s do that right now using the scenario above.
Image 2 orders are placed. The first one, is for a DVD. Amazon employee Jeff locates the item in this instance. With the second order, this time for a teddy bear Amazon employee Jenny locates this item.
This is an example of the “business logic” changing but the overall process step remaining the same. Of course this time its people changing instead of underlying computer code.
SWF presents task orientated API, SQS presents message oriented API
SWF keeps track of task & events in application, SQS you have to implement your own tracking
Only assigned once and never duplicated