- [Instructor] Microservice architectures
follow the principle that services can be created
and also taken down at any time.
Like when you scale up or down.
There is always an unknown number of instances
of a given service,
and of course each of those instances
might listen on a different IP endpoint.
This means that from the perspective
of a consuming application,
this might be also just another service.
There is no way to know where to find the endpoint
of the service you want to talk to.
That's why we need some infrastructure
that keeps track of the services that exist
and provides the information needed
to route requests to it.
Today there are two common ways to achieve that.
The first one is the service mesh.
It's commonly used in containerized applications
like when you are using Kubernetes.
In such infrastructures,
the containers run in a software-defined network,
and as such the container engine
can keep track of all services
and change the network settings in a way
that the request is routed to the right end point.
In Kubernetes for instance,
usually istio and envoy provide this functionality.
If you don't have control over the network
and over the engine that spins up the new services,
we cannot use the infrastructure layer
to do the routing for us.
In such scenarios,
the service registry is the pattern of choice.
It is an application-level component.
When a new service comes to life
it only has to know where to find the service registry,
and this can be provided through the network layer and DNS.
It will then register itself to the registry.
If we now want to know where the service can be found,
we simply have to query the registry for a given service,
and it will return the needed endpoint information.
Ideally, when there are several instances of one service,
the registry will not always provide the endpoint
for the same instance, but will try to distribute the load
either randomly or round robin.