Decoupling Workflows in Cloud

Hi guys , we are going to cover some topics related to Decoupling workflows in AWS cloud .

What is Tight coupling and Loose coupling
Why to have loose coupling architecture while putting applications in cloud
How to handle messaging with SQS
How do you sideline messages with dead letter queues
Standard SQS vs SQS FIFO
Delivering messages with SNS
API Gateway

Tight Coupling

In the image below you can see if any component goes down, then connection is broken leading to downtime and dissatisfied users. To get around this situation we need to have Loose coupling , which we can achieve by having redundancy and adding load balancers.

Loose coupling

In loose coupling the the request from the user is passed to the load balancer which in turn passes that request to the fleet of EC2 instances behind the load balancer which in turn passes the request through another load balancer on its way to the database. So even if any component goes down , we do not have to worry as the load balances is intelligent when passing the request to the healthy architecture . Based on how we configure the load balancer it will detect if the server is up or down on the basis of health check and will route the request accordingly .If any server is unhealthy the load balancer will deregister that server.

So even if we have have one instance running at the front end and one instance running at the back end we should be ok and there will be no downtime.

We always want highly available , scalable services in all services we design .

SQS- Simple Queue Service in AWS

Poll Based Messaging – Poll based messaging is based around a simple fundamental . The producer of the queue will write a message and leave it in the SQS queue. Now when the receiver is ready , it will come and fetch the message from the queue. So SQS is basically delivering the message to the end consumer .

If we define it then Simple Queue Service is a messaging queue that allows asynchronous processing of work. Once resource will write a message to the SQS queue , then another resource will retrieve that message from SQS.

There are few settings that we need to be aware of:

Delivery Delay: Default is 0; but it can be set upto 15 minutes. This means that if the delay is set to 0 , the message is immediately available to the user receiver and it can collect the message once its written by the producer. But if there is a delay, the message will be hidden for that duration before it becomes available .

Message Size : Messages can be upto 256 KB of text in any format.

Encryption : Message are encrypted in transit by default , but you can add -rest.

Message Retention : Default is 4 days; can be set between 1 min and 14 days.

Long vs short : Long polling isn’t by default , but it should be .Long polling is the preferred way of configuring SQS as the EC2 will wait for the new message when it connects to SQS . In short polling connection happens and if there is not message , it disconnects and this can results in high costs in API costs to the SQS service.

Queue Depth: This can be used as a trigger warning from cloud watch to go ahead with auto scaling .

Visibility Timeout: Usually when we have SQS we follow the diagram below, the user will write an order through EC2 instance and place it in the SQS queue, and the backend EC2 will come and retrieve the order from the SQS queue . But when you enable visibility timeout , the message is downloaded by the backend Ec2 and once that is done a lock is placed on the message and it is hidden , till the time SQS receives a confirmation back from the EC2 that the transaction has been completed , once that is done the message is deleted. The benefit of this function is if there is a failure , the message is not lost and the message will re-appear. This function is not enabled by default but we need to enable this function when setting SQS.

Dead Letter Queues

Usually when we are dealing with SQS and if there is a wrong entry from the user in creating an order for the receiver that is not matching the requirement , the receiver will poll for the message , and it will be unable to process the message due to which the message will not be deleted from the queue and it will pop back up. This will keep happening till message retention times out which can be 14 days.Once it reaches 14 days then the message will be deleted. To get around this situation we can sideline the messages in the Dead letter queue .

So it’s just another SQS queue which we can use to temporally sideline the messages which are having issues. Instead of having the message languish in the main SQS queue we can move the message to the DLQ after hitting the number of retries that we have configured.

Few important things for Dead letter queues :

Monitor the queue and set up a alarm and alert on the queue depth before it fills up.
It’s not any special queue but just another SQS queue whose function is to receive the rejected messages.
The retention period is same as in SQS , which is max 14 days.
We can also set up a DLQ for SNS topics.

Example of how Dead letter queue works in AWS

SQS Message Ordering and FIFO

Standard vs FIFO

Standard :

Best effort ordering
Duplicate messages might happen
Nearly unlimited transactions per second

FIFO

Guaranteed ordering
No message duplication
300 messages per second.
Is more expensive than the standard ordering.

Delivering Messages with SNS

SNS is push based messaging service . It will proactively deliver messages to the endpoints subscribed to it . This can be used to alert a system or a person.

Subscribers: So what is subscribed to your SNS topic. Eg: Kinesis Data Firehose, SQS, Lambda, email, HTTPS(S), SMS, Platform application endpoint.
Message size : 256 KB of size in any format.
DLQ Support : Messages that fail to be delivered can be stored in an SQS DLQ.
FIFO or Standard: SNS supports mostly SQS .
Encryption : Message are encrypted in transit by default, but you can add at-rest.
Access Policy: A resource policy can be added to a topic , just like S3. We can control who or what can publish information into these SNS topics.

Few things about SNS Messages:

Push – Remember SNS is push based service.
Cloudwatch – SNS and Cloudwatch are the way to alert you if something happens in your environment .
Subscriber details – Remember all the subscribers of SNS messages.
Retry – SNS will only retry HTTP(S) endpoints and nothing else.

API Gateway

What is API gateway:

Amazon API gateway is a fully managed service that allow you to easily publish , create , maintain , monitor, and secure your API. It allows you to put a safe “Front door” on your application .

Features of API Gateway

Security : The main reason why we use API gateway is that is allows you to protect your endpoints by attaching a web application firewall(WAF).
Stop Abuse : Users can easily implement DDoS protection and rate limiting to curb abuse of their endpoints.
Ease of you : You do not have to be a developer to get started with API gateway. This service easily helps you build calls that will kick off other AWS services in your account.

One thing before we finish the blog, you might be thinking why we need API gateway: The simple reason is that you do not have to use your AWS credentials and this services really helps when you want someone else to consume a service.