PRIYANKA VERGADIA: With almost 500 sessions at Next 2019,
it's understandable that you couldn't get to all of them.
So if you didn't see APIs, microservices, and service mesh
talk, then stay tuned, because here's the rewind.
[MUSIC PLAYING]
What is the relationship and interplay
between service mesh, infrastructure,
and API management?
When to use each?
Let's find out.
Companies are on this journey of moving from monoliths
to microservices.
In a microservice's infrastructure,
an application is really a collection
of loosely coupled services.
And we do this to gain increased product velocity,
manage complexity of code, admit heterogeneity,
and empower developers.
An alternative to decomposing systems
is to wrap them with an API to make them accessible.
Now, what is an API?
Well APIs are just communication contracts.
Every system that can receive requests has an API.
What is a service mesh?
It's a way to build more intelligence into the network.
Well what does that mean?
In a monolith, integration between modules
was presumed secure.
In a microservices architecture, the integration
between services and request traverse a network.
Therefore, we need mutual TLS to secure those requests.
But mutual TLS needs to be managed,
and we need each service to be able to discover
the other services that it might be calling.
And we want services to all [? adhere ?]
to communication policies related to retries, timeouts,
authentication, and we want all the telemetry data
from each service.
So we need some sort of system to support all of that.
Let us delegate all of that complexity of enforcing
the communication protocols to a standalone proxy known
as a sidecar proxy, or the envoy proxy.
This is the model that Istio uses
Istio still starts with the envoy proxy as a sidecar,
and adds a set of pieces to help manage and provision
the distributed set of proxies.
Envoy proxy allows you to manage the inbound calls
through ingress gateway, and outbound calls
through egress gateway.
So you can put the checks and regulations on inbound
and the outbound traffic.
This is what we can call a managed mesh of services.
Well, why use a service mesh?
It's to connect, secure, control, and observe
our microservices infrastructure.
Now let's talk about the management of APIs.
As we said, APIs represent the communication contract.
And as we share APIs to clients outside the network,
we want to manage requests that conform to those contracts.
You would use API management to help developers discover
the APIs, to modernize your old legacy APIs into a more
modern REST-based format, and to properly report and monitor
the usage of your APIs.
Let's combine the two concepts together, now.
Managing microservices and API management.
We've got our systems, a legacy system and a monolith.
The internal clients connect directly.
The external clients connect through the API gateway.
Because we are on the microservices journey,
we are decomposing the monolith into
multiple distinct services.
And we update the internal app to keep pace
with the changing endpoints.
And then, we introduce new services
to add more capabilities, which is the onset of complexity.
To simplify this, here's a clean way of doing it.
We want to use service mesh infrastructure, like Istio,
to manage the communication amongst and between services.
And the API management to manage the communication
from the clients.
To summarize, here's the mental model.
You select your infrastructure, your thousands of services
are built on that layer.
Those services are to be managed.
Some services expose shared APIs.
You need to manage all of those shared APIs as well.
And clients delivering end-user experiences then
use those APIs.
So that's the mental model that we found to be useful.
If you would like to see the full talk and the demo,
check out the link in the description below.
And don't forget to subscribe to Cloud YouTube channel
for more great Next Rewind content.
Thanks for watching.
[MUSIC PLAYING]