AWS Solutions Architect – Associate 2018 – Decoupling

Solutions Architect

As you might know – decoupling is a big deal in the new blueprint for the AWS Certified Solutions Architect – Associate level exam. In this post, I want to take a moment to outline some of the highlights of this interesting term and approach.

First of all, what the heck does it even mean – decoupling – it sure sounds like divorce! Decoupling refers to components remaining autonomous and unaware of each other as they complete their work for some greater output. This decoupling can be used to describe components that make up a simple application, or the term even applies on a broad scale. For example, many point to the fact that in public cloud computing, the architecture is decoupled in that someone like Amazon will completely handle the physical infrastructure of the network for us, while we work with the data and applications hosted on this hardware. We are not really sure what they are up to, while they are not entirely positive what the heck we are doing!

For your exam, you also need to be able to distinguish between two valid decoupling techniques in AWS – synchronous decoupling and asynchronous decoupling. Because, you know, we need to apply these two terms (synch/asynch) to just about any computer technology 😉

With synchronous decoupling, you have two components (for example) that must both always be available in order for the overall resource to function properly. While they both must always be available, they certainly are “unaware” of each other as this means they are truly decoupled.

With asynchronous decoupling, communication can still be achieved between the components even if one of the components is temporarily unavailable.

An example of synchronous decoupling in AWS would be using Elastic Load Balancing (ELB) to distribute traffic between EC2 instances that are hosted in multiple Availability Zones. Note that in order for this to function properly, you need at least one EC2 instance in each AZ. They are unaware of each other – but they both better be there or you have no load balancing. What is also great is the fact that you can add nodes to this configuration, and even later remove them, without disrupting anything!

An example of asynchronous decoupling is using the Simple Queue Service (SQS) to handle messaging between components. You can have a component temporarily go offline, and the message can be properly queued until the component is back online.

I hope this post has peeled back any curtains that might have been hanging in front of these concepts for you!