Welcome to 'Back to Basics', I'm Gonzalo Ron.
In this episode we're going to talk about
how to manage the communications between your application services.
Some time ago, I was developing a distributed application for an e-commerce website.
In the early days of my development,
I made a mistake of not thinking enough about the communications between the services.
I ended swimming in problems... like errors that were difficult to debug
and delays that were propagated between the applications.
Those were long nights of production support!
One problem I remember was a set of synchronous calls between our services.
The user was calling a service to buy a product.
Then this service was orchestrating calls to other services to reduce inventory,
charge for the transaction, and send some marketing emails.
The problems started when, for instance, the service to send marketing emails was taking too long!
That delay in the response was propagated to the "buy product service"
and then to the customer!
Even worse... when the "marketing service" was down, the customer just received an error.
Those problems impacted many of our customers.
How could you avoid problems like this?
What about sending messages to an Amazon SQS queue to communicate with the "marketing service"?
In that way you recover the services and return the control to the customer quickly.
Even better; if the marketing service is down, the messages are still in the queue
until the service is back and ready to pick up each of them.
But let's think about something else...
Asynchronous calls are great to simplify and de-risk your deployment processes.
For instance, consider this architecture.
What would be the steps to release a new version of your service?
The service is going down and the messages sent by the client
start accumulating in the queue.
Then you deploy your new version of the service and it starts consuming those messages.
You are not producing any downtime.
This is an example of how Amazon SQS could help you to make your deployments more reliable.
There are many patterns for asynchronous communications.
You can have one to one communications using a queue with Amazon SQS,
or you can have one to many communications using services like Amazon Simple Notification service
or Amazon EventBridge.
They can help you to simplify your distributed applications.
Sometimes you want to have synchronous communications.
For instance, if you have hard real-time distributed systems.
In those cases, it's important to avoid propagating delays and errors between your applications.
That's why it's important to review the time-outs in those communications.
And also, implement a concept called circuit breakers.
The circuit breaker's pattern is about wrapping a call into an object.
This object can be used to monitor for failures.
When the failures reach a threshold, the circuit breaker trips
and the next calls automatically return with an error
without propagating any delays to the client.
You could implement circuit breakers by yourself or using any library in the market.
However, when you scale to hundreds of applications,
the changes in your code and configurations could become very challenging.
A better option could be letting a service-mesh handle the circuit breakers for you.
A service-mesh is a software layer that can handle all the communications for your services.
It has features like circuit breakers, health checks, and retries.
AWS has a service for this that is called AWS App Mesh.
AWS App Mesh is a service that helps you to config, control, and monitor your services
without making any code changes.
AWS App Mesh configures services so you can explore monitoring data,
metrics, and logs into CloudWatch.
It highly simplifies your visibility and communications.
In this pattern, every member of your service has a proxy
that in the case of AWS App Mesh, is an open source tool called Envoy.
This proxy abstracts the network communication for your services.
It's essential to take the time to think about the communication between your services.
In both cases, synchronous or asynchronous communications,
I recommend using high level of extractions and take advantage of available services.
Click the links below for more information.
Thank you for watching 'Back to Basics'.
See you next time.