What are application services?
There are three major application services available in AWS. These enable us to deliver ‘canned’ functionality, without needing to build bespoke systems ourselves. We will cover off these services through this section.
Where do application services fit in your environment?
Application services interact with all parts of your AWS environment. Although they are shown as part of the VPC below, they are far-reaching and can interact with nearly every element of your AWS deployment.
SNS (Simple Notification Service) is a service that automates the sending of email or text messages based on an event in your AWS account. It does this by working in conjunction with Cloudwatch to produce alarms when a certain threshold is exceeded, when there is downtime or a change in the environment. That alarm then prompts an SNS topic to be sent to the topic subscribers.
The supported channels are SQS, HTTP, HTTPS, Email, SMS, app notifications and Lambda.
A topic is a label or grouping of events. So you could have a topic called ‘EC2 failure’. The subscribed users (endpoints) of that topic will be the email address or phone number of your EC2 administrators. Note: a subscriber of an email notification must confirm / authorise their subscription before any notifications can be sent to them.
The publisher in SNS is the human, alarm or event that provides the message to the SNS topic.
SQS (Simple Queue Service) is a service that allows messages between servers to be queued. Once they arrive in a queue, the queue is polled by a worker instance rich reads & acts upon the message.
SQS lends itself to the deployment of decoupled applications.
Note: decoupled applications are those in which each component is independent of other components in the application. So, let’s say you have a website where users upload images and then those images are automatically processed to remove the background. You can decouple this application so that component 1 uploads the image and sends a message to an SQS queue. Component 2 then takes that message from the SQS queue and processes the background removal. In this instance, if component 1 failed, component 2 could continue to process messages in the queue & continue to apply effects to those queued jobs.
To handle loads during peak hours, autoscaling can be applied to a queue and the number of worker instances can also be scaled.
SQS is fully managed by AWS and is therefore highly available and redundant. AWS automatically backs up messages across multiple availability zones within a region.
Message retention can be set to between 1 minute and 14 days. The default is 4 days. Messages will be automatically deleted once this retention period is reached.
You can set a visibility timeout on a queue message. This is where a message is not visible to any other reader of the queue for a designated amount of time after it is read from a message queue. The timeout should be set to be greater than the time it will take to process and delete a message from the queue. Note: the maximum visibility timeout is 12 hours.
A queue can be polled in two ways (they’re both billed in the same way):
- Short polling – Returns a response immediately, even if the message queue is empty and as a result the response is empty. Short polling should be used if your application expects an immediate response.
- Long polling – Doesn’t return a response until a message arrives in the queue, making it less expensive as you can reduce the number of polling requests and can reduce the number of empty responses. Long polling is almost always more suitable than short polling as it provides higher performance at a lower cost. The max timeout for long polling should be 20 seconds and the minimum timeout should be 1 second.
There are two types of SQS queues, FIFO queues and standard queues:
- FIFO queues – Preserve the exact order in which messages are sent and received and will not process duplicate messages. These queues are currently limited to 300 transactions per second and are not available in all regions. You can have a maximum of 20,000 in-flight messages on FIFO queues.
- Standard SQS queues do not guarantee the order the messages are sent in. Unlike FIFO queues, these can cope with virtually unlimited transactions per second. A single queue can hold 120,000 in-flight messages.
SQS has a number of securityxxx:
- You can control who can send messages to a queue & who can retrieve them
- You can build your application to encrypt messages before sending them to the queue
- Server side encryption enables us to transmit sensitive data in encrypted queues using keys stored in AWS KMS
- SQS complies with PCI-DSS level 1 and is also HIPAA eligible
- Each message can be up to 256kb in size
- SQS guarantees delivery of messages but does not guarantee the order they’ll arrive in
- SQS does not guarantee that there will be no duplicate messages
- There is no limit to the number of queues you can make
- You can share queues with other AWS accounts
- You cannot share messages between queues in different regions
- Messages can be in XML, JSON or unformatted text
- You can subscribe to queue SNS topics
- You can send identical messages to multiple SQS queues. You can do this by subscribing multiple queues to an SNS topic.
SWF (Simple Workflow) is a fully managed workflow service which enables us to build distributed applications. It co-ordinates activities and can guarantee the order that tasks are executed (it also ensure no tasks are executed twice).
A workflow can run for up to 1 year and comprises of:
- Workflow: the sequence of steps to be completed
- Activities: the steps within the workflow
- Tasks: the things that interact with workers in the workflow. This can be an activity that needs to be completed or a decision that needs to be made
- Worker: the people or AWS resources that execute tasks
SWF is an ideal solution for order management through a website. It can manage everything from placing the order to payment to packing the order to delivery.
In SWF, we have workers and deciders:
- Workers take items out of the workflow, process them and return results.
- The decider controls the co-ordination of tasks (order, scheduling etc..). The decider receives information as to the progress of tasks, enabling it to continue to initiate new tasks as old ones become complete.
The deciders will receive decision tasks whenever a workflow changes state. For example, when a task completes or times-out, it’ll receive a decision task. It’ll then determine its next steps, enabling the decider to continue to manage the co-ordination of tasks.