Harrigan.
And welcome back.
Now, in today's video, we'll be discussing about the basics of the Amazon US service.
Now, before we go ahead and discuss in detail about us, let's take a simple use case that will allow
us to understand the benefits that it offers.
Now, the use case for today's video is an application that primarily works for restoring an image.
So let's assume that a medium corp is designing an application that will enhance and restore the images
that users submit to the online portal.
So there are a lot of applications where you go ahead and give the image and they'll enhance it and
make it much more better.
So that is what the Medium Corp is building.
Now as part of the application architecture, there are two components that are involved.
First one is the image gatherer and second one is the image enhancer.
So image gatherer is responsible for taking the image from the user via the upload button.
So as soon as a user uploads the image, the image goes to the image gatherer application and then image
gatherer will send that image to image enhancer and image enhancer is responsible for enhancing as well
as doing some conversion on the image.
Now this type of architecture sounds good.
Now one of the challenges that comes is what happens when this image enhance the server goes down.
So the image gatherer is working fine, the user is able to upload the image, but when image gatherer
sends the image to the image enhancer, the server is done.
So this is one of the challenges that will be faced in a current set of architecture.
Now, second type of challenge is related to the high availability.
So let's assume that due to popularity of the application and huge spike traffic, medium core has decided
to add more number of enhancer servers.
So now you have two.
So now the medium corp has added two more enhancer servers.
So now in case if one of the server goes down, then the image gatherer will be able to send the traffic
to the other servers.
So for the image gatherer to discover the latest servers that are running, what needs to be done,
A database needs to be created at a configuration file with the relevant information needs to be created.
So in this case you have a configuration file that contains four servers.
So you have server A, server B, server C server D, and each server has this associated IP address.
And what image gatherer does, it goes ahead and send the images across each one of the IP addresses.
Now, although this seems good, but one of the challenge that comes is let's say that this server has
gone down now.
Image gatherer has no way of knowing that the server is down, so there needs to be an additional logic
at the image server that will check the health check of all of the servers.
And if the health check is failed, then the configuration file entry associated with that server also
needs to be removed.
So image gatherer application needs to do more than just the image gathering, and this will introduce
a lot of challenges.
So in order to overcome this, there is also a better architecture of using a queue.
So what happens here is that you design a queue and what image gatherer will do.
All it is responsible to do is to send the image to the queue and then the image enhancer.
All they're responsible to do is they are responsible to take the message from the queue and that's
it.
You do not really need to worry about anything else.
So at the image gatherer level, you do not really need to get the latest IP addresses of the servers,
doing the health check and creating additional logic.
All right.
So this is what queue is all about.
Now, one of the main function of the message queue service is to take a message from a publisher and
forward that to a consumer.
So in our architecture, the publisher becomes the image gatherer and the consumer becomes the image
enhancer.
So this is a high level architecture.
Now, one thing that needs to be ensured here is that since this image gatherer will be sending the
images to the queue, the queue needs to be always available because in case if the queue goes down,
then none of the images will be able to be taken by the image enhancer.
So this is one of the most critical architecture component in this specific use case that we were discussing,
and this challenge of having a highly available reliable queue is taken care by the Amazon queues service.
So at a high level overview, Amazon asks is a fast, reliable, scalable and fully managed message
queuing service, and it basically makes it simple and cost effective to decouple the components of
a specific application.
So now what you have to do, you already have an image gatherer, you already have an image enhancer.
What you do is you create a highly.
Reliable and reliable.
Q With the help of Sky Service and configure your image gatherer to send a message to the queue and
configure the image enhancer to take the message from the Q And that's about it.
So this is the basic architecture, so let's go ahead and try this out so that this becomes better understood.
So currently I'm in the Amazon console and currently we have one.
Q With the name of message.
Q And currently there are zero messages that are available.
Now we also have two EC two instances for today's demo.
One has the name of image, the second has a name of image enhancer.
So for today's demo, the image gatherer easy to instance, will send certain messages to this Q and
the image enhancer, easy to instance will fetch the message from the SKUs.
Q So that is the basic architecture, something to what we will see.
So let's try it out.
So currently within my search terminal, I have two tabs that are created.
First tab is associated with the Image Gallery.
The second tab is associated with the image enhancer.
So within let's go ahead and run the script and the name of a script is send messages.
So this will go ahead and send messages to the US.
Q So let me run it.
So currently you see that it has sent five messages to the US.
Q Now within here, if we quickly refresh the page, you see the messages that are available are five
now from the image enhancer, which is responsible for consuming the message.
We also have one more script available.
Colleagues receive message that is, Let's run it.
So now at this stage you see it has received one set of message from the US.
Q Now, if you run once more, it has received another set of messages from the US.
Q So for example, let's say that the first one is the image.
So it has taken the image, it has completed the work.
Now again, it will go ahead and fetch a new set of images that are part of the US.
Q And then it will process the images.
Once the processing is done, it will go ahead and fetch the newer images that are part of the US.
Q So if I quickly refresh the page, you see the available messages has now reduced to two.
Now in fact the messages that are part of the US.
Q You can also view it from the console.
So if I quickly do a full messages here, you should see that there are multiple messages that are available
and this is basically the message body.
Now that we understand the basics of voice.
Q Let's go ahead and understand some of the important concepts specifically related to a tightly coupled
system and a loosely coupled system.
So in a tightly coupled system, the component of a system architecture, they directly communicate
with each other and also have a hard dependency on each other.
So for example, you have a producer and you have a consumer.
So producer is directly sending a message to consumer.
So in case if a consumer is down, then the producer essentially will also start to send the other message
to the users.
So this is also referred as a tightly coupled system.
Now, the second type of system is referred as a loosely coupled system in which the components of a
system architecture that can process the information without directly being connected.
So you have a producer, you have a Q, you have a consumer.
So now if the consumer are down, then the producer essentially does not really need to worry.
So all producer can do is it can take the image from the user and it can send the image to the queue
and then it can give a success message back to the user.
That's about it.
Once the set of consumers are back on line again, they'll fetch the message from the queue and then
they'll do the necessary level of processing.
So this is a much more better type of architecture.
And in fact, most of the architecture that you will see the new ones in the production environment
are based on the loosely coupled system.
This is very important.
That's great.
So this is a very high level overview about the service and with this will conclude today's video.