Memi: Our next topic
is API gateway and discovery.
So, the gateway and discovery patterns
solve the loose coupling challenge of services.
To make it more clear,
let's talk about a full blown application.
This application will probably have
at least six services.
Naturally, they are going to communicate with each other.
Now, if they communicate directly like this,
we will have what is known as the "spider web",
I guess you can understand why.
Now, imagine what will happen
if a single service will change its URL;
see how many services will be affected?
If your services map looks like a spider web,
be ready for a nasty surprise
when even one of the URL is changed.
The spider web is a true sign
of a strong coupling system.
Now, there are a couple of ways
to solve this coupling:
One, build a Yellow Pages directory for the service.
Whenever the service needs to communicate
with other service,
it asks the directory for the URL
of the service it wants to access,
and uses the URL it gets.
This way, the URL is not hard coded into the service,
and when it changes,
the change affects only a single service,
the directory.
In this solution,
there is only a single URL
the services need to know,
the directories.
And so if it changes,
which won't happen frequently,
the change will be limited to a single URL only.
You can develop one of your own,
and there are some great tools that do just that,
such as Consul.
Another way, is to build a middleman or gateway.
In this scenario,
the service accesses the middleman
and asks it to go to the stock service,
and make a query.
The middleman holds an internal mapping table
which maps tasks to URLs,
and so it knows which URL to access
in order to fulfill the task
given by the calling service.
The calling service has no idea
what the URL of the stock service is,
or even if there is a stock service,
all it knows is that he asks
the middleman to do something,
and it was done.
It doesn't care how, where, and by whom.
In this solution, also,
there is only a single URL
the service need to be aware of,
the middleman,
so changes will be limited to this single URL.
So we talked about the gateway
and the discovery patterns,
and let's compare between them.
So, the first thing to note,
is that API gateway
is quite difficult to implement,
especially in an on-premise environment.
There are many cloud implementation
of API gateways,
and they are much easier to use,
but if you want to set up an API gateway
on your server form,
then be ready for a long setup.
On the other hand,
discovery tools such as Consul
are very easy to implement,
and can usually be set up
in a matter of hours.
API gateway, as we saw,
is man in the middle.
So API gateway stands
between the services that call each other,
and the services actually do not call other services,
but they call the API gateway.
On the other hand,
the discovery is an external service,
so when the service wants to communicate
with other service,
it first goes to the discovery service,
gets the URL,
or the endpoint of the other service,
and then performs a direct call
to the other service.
API gateway,
in addition to providing, well, gateway,
can provide many other useful features
such as authentication and authorization,
monitoring, routing policies,
load balancing, and lots more.
Discovery provides mainly URLs,
and sometimes also provides
some basic load balancing services,
but it cannot be used for all the other services
that the API gateway can provide.
So this is definitely something
that you should keep in mind
when choosing between API gateway and discovery,
and you must take into account
the ease of implementation,
as opposed to the richness of the features
offered by the API gateway.
Now, when talking about API gateway engines,
there are a handful of them,
and you can see here a sample
of the most popular API gateway engines,
either on the cloud,
such as Azure API Management,
or AWS API Management,
or Apigee of the Google Cloud.
And the on premises engines,
such as WS02, and Tyk.
So, if you are using cloud environment,
I strongly recommend to check out the API management
of the cloud you are using,
and if your application is on premises,
then take a look at both those engines,
WS02, and Tyk.
Now again,
API gateway is not a must,
there are a lot of applications out there
with a lot of services and a lot of APIs,
that don't use API gateway.
But you should definitely take a look at them
and make an informed decision
whether to use them or not.