Let’s start our session with messaging essentials.
There is a typical problem that messaging solutions are trying to solve.
Imaging two applications with a need to send data to each other.
There are many reasons for that, you can think of bank transfers, invoicing, some booking
information, order processing, delivery details, insurance or anything like that.
They could be located in the same datacenter, in different datacenters or cloud, but still
have a need to exchange the information.
It’s a simple task.
All you need to do is to send data from application 1 to application 2.
You can do it in a synchronous way, meaning application 1 can do a call, so it will try
and connect to application 2 saying “I have some data for you and I will sit here waiting
until you will receive it.”
Which is fine, if everything works.
But what happens if it doesn’t?
What if it is going to fail?
We are talking here about sending a business-critical data.
It doesn’t matter if you transfer 1 dollar, a hundred or a million - you simply do not
want it to fail.
Also, until the transfer is completed, application 1 keeping this spot open, which basically
means it is locked and will stay busy for some time.
There is a better way of solving this problem.
Let’s take those 2 applications, but instead of connecting directly, application 1 will
send that data to another service which will take care of delivering it to application
2.
We call this messaging.
You're essentially removing direct communication layer between apps and creating indirect connections.
Think of isolating and buffering which is great for reliability, but also great for
overall solution scalability.
I mean think of what will happen in our initial example if first application suddenly will
start sending lot’s and lot’s of data, while application 2 is not ready to receive
it?
What will happen?
While in the second example, those will be just placed in our service, a message queue
and a second application will take them one by one, working on its maximum rate without
going down.
So messaging, as an asynchronous way of connecting applications (because you are holding messages
in a queue) is an excellent way of solving that problem.
Now let’s get back to our applications sample.
Did I mention where these applications are running?
They could run in the same place, for example in one datacenter or different ones.
However, imagine that you are not using MQ.
At this point, it matters where those applications are.
You need to know the network, location.
You may be already moved part of your workload to the public cloud or planning to move it
to a private one.
So when you are not using MQ, which suppose to create isolation layer between applications
and their network, you would need to keep updating each application anytime you have
those changes - where those are deployed, what is the network route, latency and all
of that.
By adding MQ here, you simply allowing an app to ask where is my MQ today?
Underneath technology will always help to find the right path to queue disregard where
those applications are located.
So there is no real problem of running in the cloud, datacenter, containers - if you
have MQ, we have it covered for you.
MQ is perfect for flexible, reliable hybrid deployment.
So what if you want to run MQ in the cloud?
As soon as you start this discussion with scalability and flexibility in mind, it will
lead to containers.
One of the main buzzwords here is Docker and another word you will hear a lot is Kubernetes,
which essentially is a management layer for Docker containers.
Running MQ in containers is supported for several years now.
You basically have a pre-installed image of the product, which is extremely useful in
repeatable deployment scenarios.
For example when you need to scale and do not want to think about installation, initial
configuration, and management.
So those containers can be running anywhere you want, whether it will be public cloud
like IBM Cloud, AWS or Azure, private cloud like IBM Cloud Private or anywhere in your
datacenter as containers are very very flexible.
What if you need even more simplicity and flexibility?
Well, there is something that we used to call a managed service.
As an example, you can take a look at MQ on IBM Cloud offering, where IBM has taken MQ,
put it into a container and put that one into IBM Cloud.
And even further, as IBM now allows you to deploy an MQ that is managed by IBM onto AWS.
Now you can configure your MQ instance, but IBM will do a deployment and management of
that container for you, dealing with tasks like infrastructure and version maintenance.
So think of it as an MQ service in the cloud.
By the time you will get yourself a cup of tea, you can get your MQ instance running
in the cloud and ready for your enterprise load.
At this point, we closing our microlearning session.
If you are seeking more information about MQ deployments in the cloud follow the links
in the description.
Please subscribe to the channel, give us your feedback and ideas.
Thanks for watching!