Which AWS service decouple application components so that the components run independently?

Several smaller services reduces overall complexity. We will in this article list some of the goodies achieved with application decoupling.

In microservice architectures, applications are built and deployed as highly decoupled, focussed services. A decoupled application architecture allows each component to perform its tasks independently - it allows components to remain completely autonomous and unaware of each other. A change in one service shouldn't require a change in the other services. It is the process of separating services so that their functionality is more self-contained.

Easier to maintain code and change implementations

Smaller code blocks are known to be easier to manage and understand. By building your application as multiple connected services, parts of your application can evolve independently and each service can be maintained by separated developer teams. It is easier to read each other's code since you don't have to understand the whole app in order to understand how a small part of your app works.

If you have a decoupled system, where you need to change a component, you can do that as long as the API remains intact. If you want to use a different database backend or structure, you are good to go. You just need to replace that part instead of walking through the whole project looking for references and dependencies to the old service.

Different parts of your app can evolve independently if your architecture is decoupled.

Cross-platform, different languages and technologies

Different application services have different needs. Maybe you would like to implement your solution so that different components are running on different platforms, or are built by different programming languages or technologies. One part of your service might be better suited for Java, while another part might be better suited for Ruby - you are able to choose the right tool for the job. The decoupled nature of the sender and the receiver can help to remove any implementation dependencies between them.

Independent releases

In a monolithic architecture (non decoupled architecture), you might need to deploy the complete application in once, and this might affect critical steps for your service. You do not want the signup process to break or be in-responsive for a while just due to a deploy. It's good to be able to deploy an application's components separately.

How to decouple your application

Decoupling between services could be achieved by simply adding a layer of technical abstraction, like a message queue or a well written interface, between the content producer and the content consumers.

Message queues decouple your processes. All that is required is that the sender and the receiver agree on a common format for messages and their content and that they are using the same message broker. When part of your architecture fails, it doesn’t need to take the entire system down with it. Messages can still be added to the queue and be processed when the system has recovered. If a message fails to be delivered, the message can be redelivered until the message is processed.

Distributed workload and Scalability

A message queue makes it easy to scale up a decoupled application. When the incoming message rate is higher than the consumer rate; you can simply add more workers, receivers, whose job is to work off the queues faster.

If you have a web application, you can let this web application generate messages in response to user inputs. The receivers can retrieve these messages and process them and return a response when it is finished. By doing it this way, the user interface can remain responsive. It is not blocked while the messages are handled asynchronously. Many websites have peak hours, where the activity burst. A large number of website users might suddenly generate a large volume of messages. If you add a message queue in-between the sender and the receiver, the message queue will act like a buffer, and receivers can gradually drain the queue at their own pace and the website visitor will remain a happy visitor.

If you are new to message queueing, I recommend you to read this article about message queuing in general or RabbitMQ for beginners for information about message queueing with RabbitMQ.

Please email us at if you have any suggestions, questions or feedback.

Hello and welcome to this lecture where I want to explain what we mean by decoupled and event-driven architectures.

Firstly, let me focus on decoupled architecture, and to understand decoupling, we first need to address monolithic architectures which is how applications have been done in the past. Monolithic applications were built with a close and tight-knit relationship to each other, for example, between the front end and back end of an application. If a change was made the back end, it could easily disrupt services and operation in the front end, and that's because they were very tightly coupled together and had a lot of built-in dependencies against each other. Although this had some advantages, it wasn’t able to offer what a decoupled architecture could.

When you implement and design a solution using a decoupled architecture you are building a solution put together using different components and services that can operate and execute independently of one another, instead of being closely coupled to each of its connecting components to operate and function. Each component in a decoupled solution is effectively unaware of any other changes to other components due to the segregation of boundaries applied.

Each service within a decoupled environment communicates with others using specific interfaces which remain constant throughout its development regardless of what configurations are made. By having this layered and independent approach, you are able to design, develop and configure each component without worrying about any dependencies within your solution. This allows your development teams to work faster and more efficiently as their scope of operation is refined on a particular service or component. They can make changes to a specific area of the application without having to worry about affecting other components, this helps to drive innovation and progress at a far greater rate.

As you go through this course, I will introduce you to an AWS service that is commonly used in a decoupled architecture, this being Amazon SQS, the Simple Queue Service.

Let me now look at Event-Driven Architectures.

Event-driven architectures closely relate and interact with decoupled architectures, however, services in an event-driven architecture are triggered by events that occur within the infrastructure. So what is an event? Well, an event can be a number of things, for example, a change of state, so a resource such as an EC2 instance changing from ‘running’ to ‘stopped’—that is a change of state, or perhaps an order has been placed on your website and an item has been moved from for sale to sold, that could be a change of state within your application.

When utilizing and implementing event-driven architectures in AWS, they will typically have three components: a producer, an event router, and consumers.

A producer is the element within the infrastructure that will push an event to the event router. The event router then processes the event and takes the necessary action in pushing the outcome to the consumers. By having the event router sat between both the producer and consumers, each of these two components are decoupled from each other and carry the benefits of a decoupled architecture that I discussed previously.

As we go through this course, I will introduce you to a number of different event-driven services, which act as the event routers, and these include Amazon SNS (the Simple Notification Service), Amazon Kinesis, and AWS Lambda.

About the Author

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.

Which AWS services can be used to decouple components?

What is decoupling services in AWS?

What can you do to decouple the resources in AWS?

What service can you use to decouple applications and allow the different application components tiers to process requests as they can?