Why Container Orchestration Matters
Key Points
- Container orchestration was introduced to manage multiple inter‑dependent microservices—frontend, backend, and database access—once they’re packaged as containers.
- Developers typically focus on a single application stack inside containers (app code, OS, dependencies), while operations teams must oversee the entire underlying infrastructure.
- An orchestration platform like Kubernetes adds a master layer that controls worker nodes (VMs or containers) where the actual compute resources (CPU, RAM) reside.
- The primary function of orchestration is to automate deployment of services across these worker nodes, even starting with a single node running one instance of each microservice.
- By abstracting the hardware layer, orchestration enables consistent scaling, management, and monitoring of complex multi‑service applications.
Sections
- Understanding Need for Container Orchestration - Sai Vennam of IBM Cloud explains why orchestration is essential by illustrating how a master node (e.g., Kubernetes) coordinates multiple containerized microservices—frontend, backend, and database—to deliver a cohesive application.
- Orchestrating Microservice Scaling & Networking - The speaker outlines how an orchestration platform schedules containers across added worker nodes, scales each microservice to the desired replica count, and automatically handles networking tasks such as creating services, load balancing, and service discovery.
- Visualizing Service Mesh Interactions - The speaker describes how an orchestration platform integrates open‑source tools like Prometheus and Istio to provide logging, analytics, and a visual map of microservice communication, illustrated with a simple three‑service mesh that lets operations monitor request flows and spot unexpected direct accesses.
Full Transcript
# Why Container Orchestration Matters **Source:** [https://www.youtube.com/watch?v=kBF6Bvth0zw](https://www.youtube.com/watch?v=kBF6Bvth0zw) **Duration:** 00:09:05 ## Summary - Container orchestration was introduced to manage multiple inter‑dependent microservices—frontend, backend, and database access—once they’re packaged as containers. - Developers typically focus on a single application stack inside containers (app code, OS, dependencies), while operations teams must oversee the entire underlying infrastructure. - An orchestration platform like Kubernetes adds a master layer that controls worker nodes (VMs or containers) where the actual compute resources (CPU, RAM) reside. - The primary function of orchestration is to automate deployment of services across these worker nodes, even starting with a single node running one instance of each microservice. - By abstracting the hardware layer, orchestration enables consistent scaling, management, and monitoring of complex multi‑service applications. ## Sections - [00:00:00](https://www.youtube.com/watch?v=kBF6Bvth0zw&t=0s) **Understanding Need for Container Orchestration** - Sai Vennam of IBM Cloud explains why orchestration is essential by illustrating how a master node (e.g., Kubernetes) coordinates multiple containerized microservices—frontend, backend, and database—to deliver a cohesive application. - [00:03:10](https://www.youtube.com/watch?v=kBF6Bvth0zw&t=190s) **Orchestrating Microservice Scaling & Networking** - The speaker outlines how an orchestration platform schedules containers across added worker nodes, scales each microservice to the desired replica count, and automatically handles networking tasks such as creating services, load balancing, and service discovery. - [00:06:17](https://www.youtube.com/watch?v=kBF6Bvth0zw&t=377s) **Visualizing Service Mesh Interactions** - The speaker describes how an orchestration platform integrates open‑source tools like Prometheus and Istio to provide logging, analytics, and a visual map of microservice communication, illustrated with a simple three‑service mesh that lets operations monitor request flows and spot unexpected direct accesses. ## Full Transcript
Hi everyone, my name is Sai Vennam,
and I'm with the IBM Cloud team.
Today, we want to talk about container orchestration.
I know that in the past, we've talked about containerization technology
- as well as dived into Kubernetes as an orchestration platform.
But, let's take a step back,
and talk about why container orchestration was necessary in the first place.
We'll start with an example.
Let's say that we've got 3 different microservices
that have already been containerized.
We've got the frontend,
we'll have the backend,
as well as a database access service.
These 3 services will be working together,
and are also exposed to end users,
so they can access that application.
The developer has a very focused look at this layout.
So, they're thinking about the end user,
the end user accessing that frontend application,
that frontend, which relies on the backend,
which may, in turn, store things using the database service.
The developer is focused entirely on this layer.
Underneath it, we've got an orchestration layer.
So, we can call that a master,
and I'm thinking about Kubernetes right now,
where you would have something like a master node
that manages the various applications
running on your computer resources.
But, again, a developer has a very singular focused look at this layout
and they're really only looking at this stack right here.
They're thinking about the specific containers
and what's happening within them.
Within those containers, there are a few key things.
So, there's going to be the application itself,
there's also going to be things like the operating system,
as well as dependencies.
And there are going to be a number of other things that you define,
but all of those things are contained within those containers themselves.
An operations team has a much larger view of the world.
They're looking at the entire stack.
So, an operations team:
there's a number of things that they need to focus on,
but we'll use this side to kind of explain how they work with
deploying an application that is made up of multiple services.
So, first, we'll talk about deploying.
So, taking a look here,
it's very similar to over here, but the key difference is
these are no longer containers,
but the actual computing resources.
This can be things like VMs (Virtual Machines)
or, in the Kubernetes world, we call these "worker nodes".
So, each one of these would be an actual
computing worker node.
So, you know, it could be something like
4 vCPUs (virtual CPUs) with 8 GB of RAM
per each one of these different boxes that we have laid out here.
The first thing you would use an orchestration platform to do
is something simple - just deploying an application.
Let's say that we start with a single node.
And, again, here we've got the master.
On that single node, we'll deploy 3 different microservices
- one instance each.
So, we'll start with the front end,
we'll have the backend,
as well as the database access service.
Already, let's assume that
we've consumed a good bit of the compute resources
that are available on that worker node.
So, we realize - let's add additional worker nodes to our master
and start scheduling out and scaling our application.
So, that's the next piece of the puzzle.
The next thing an orchestration platform cares about
is scaling an application out.
So, let's say that we want to scale out the frontend twice.
The backend, we'll scale it out 3 times.
And the database access service,
let's say we scale this one out 3 times as well.
An orchestration platform will schedule out our different
microservices and containers to make sure that
we utilize the computer resource in the best possible way.
One of the key things that an orchestration platform does is scheduling.
Next, we need to talk about
networking and how we enable
other people to access those services.
That's the third thing that we can do with an orchestration platform.
So, that includes creating things
like services that represent each of our individual containers.
The problem is: without having
something like an orchestration platform take care of this for you
- you would have to create your own load balancers.
In addition, you would have to manage your own services
and service discovery, as well.
So, by that, basically I mean
that if these services need to talk to one another,
they're not going to try to find the IP addresses of each different container
and resolve those and see if they're running.
That's something the orchestration platform needs to do
- is handle that system around it.
So, with this, we have the ability
to expose singular points of access
for each of those services.
And again, very similarly, an end user
might access that frontend application
- so the orchestration platform would expose that service to the world,
while keeping these services internal
- where the frontend can access the backend,
and the backend can access that database.
Let's say that that's the third thing
that an orchestration platform will do for you.
The last thing I want to highlight here is insight.
Insight is very important
when working with an application in production.
So, developers are focused on the applications themselves,
but let's say that one of these pods accidentally goes down.
What the orchestration platform will do
is it will rapidly bring up another one,
and bring it within the purview of that service.
It will do that for you automatically.
In addition, an orchestration platform has a number of pluggable points
where you can use key open source technologies
- things like Prometheus and Istio
- to plug in directly into the platform
and expose capabilities that let you do things like a logging,
analytics, and there's even a cool one,
something that I want to sketch out here,
- the ability to see the entire service mesh.
Many times, you might want to
lay out all of the different microservices that you have
and see how they communicate with one another.
In this example, it's fairly straightforward,
but let's go through the exercise anyway.
So, we've got our end user;
and the end user would likely be accessing the frontend application.
And, we've got the two other services as well:
the database, as well as the backend.
In this particular example, I'll admit,
we have a very simple service mesh
- we've only got three services.
But seeing at how they communicate with one another
can still be very valuable.
So, the user accesses the frontend,
the frontend accesses the backend,
and we expect the backend to access the database.
But, let's say the operations team finds that,
oh actually, sometimes the frontend
is directly accessing the database service.
They can see how often, as well.
With things like a service mesh,
you get insight into things like the operations per second.
Let's say that every time
- or let's say there are 5 operations per second hitting the frontend,
maybe 8 that go to the backend,
maybe 3 that go per second to the database service,
but then .5 requests per second
going from the frontend to the database service.
The operations team has identified,
by taking a look at the requests
and tracing them through the different services,
that here's where the issue is.
This is a simple example
about how you can use something out like Istio and Kiali
(which is a key service-meshing capability)
to gain insight into running services.
Orchestration platforms have a number of capabilities
that they need to support,
and this why operations teams
and these roles that we're seeing pop up
- things like SREs (Site Reliability Engineers)
- and we're seeing the growth of those roles because
there are a lot of things that they need to concern themselves with
when running an application in production.
Developers see a very singular view of the world,
where they're focusing on the things within the containers themselves.
Thanks for joining me for this quick overview
of container orchestration technology.
If you like this video please be sure to drop a comment below
or leave us any feedback and we'll get back to you.
Be sure to subscribe,
and stay tuned for more videos in the future.
Thank you.