Docker vs Kubernetes: Scaling Simplified
Key Points
- Sai Venom explains that the common misconception of having to pick either Docker or Kubernetes is wrong—Kubernetes can orchestrate the Docker containers you already use while handling the added complexity of scaling.
- He illustrates a typical cloud‑native stack (React/Node front‑end, Java for database access, Python/Flask for external APIs) and walks through a pure‑Docker deployment workflow: Ubuntu host → Docker daemon → `docker build`, `docker push`, SSH, and `docker run`/Compose.
- While Docker makes a single‑instance deployment easy, manually replicating containers and provisioning new hardware quickly becomes fragile as traffic grows, new micro‑services are added, and operational consistency is required.
- Kubernetes addresses these pain points by providing automated scaling, service discovery, and orchestration, allowing teams to extend the same Docker‑based workloads without the manual scripting and hardware‑management overhead.
Full Transcript
# Docker vs Kubernetes: Scaling Simplified **Source:** [https://www.youtube.com/watch?v=2vMEQ5zs1ko](https://www.youtube.com/watch?v=2vMEQ5zs1ko) **Duration:** 00:08:03 ## Summary - Sai Venom explains that the common misconception of having to pick either Docker or Kubernetes is wrong—Kubernetes can orchestrate the Docker containers you already use while handling the added complexity of scaling. - He illustrates a typical cloud‑native stack (React/Node front‑end, Java for database access, Python/Flask for external APIs) and walks through a pure‑Docker deployment workflow: Ubuntu host → Docker daemon → `docker build`, `docker push`, SSH, and `docker run`/Compose. - While Docker makes a single‑instance deployment easy, manually replicating containers and provisioning new hardware quickly becomes fragile as traffic grows, new micro‑services are added, and operational consistency is required. - Kubernetes addresses these pain points by providing automated scaling, service discovery, and orchestration, allowing teams to extend the same Docker‑based workloads without the manual scripting and hardware‑management overhead. ## Sections - [00:00:00](https://www.youtube.com/watch?v=2vMEQ5zs1ko&t=0s) **Docker vs Kubernetes Explained** - IBM developer advocate Sai Venom clarifies the misconception that Docker and Kubernetes are mutually exclusive, showing how Kubernetes can orchestrate existing Docker containers for a multi‑service cloud‑native app while outlining the basic Docker‑only deployment stack. ## Full Transcript
hi everyone my name is sai venom and I'm
a developer advocate with IBM here at
IBM were always enabling developers to
be able to use the latest and greatest
technologies when developing their
applications but a question I almost
always seem to be running into is
whether or not you should use docker
versus kubernetes I think there's the
small misconception out there that you
have to be using one or the other but
the fact is kubernetes allows you to use
your existing docker containers and
workloads but allows you to tackle some
of the complexity issues you run into
when moving to scale to better answer
this question let's start with a simple
cloud native application sketched out up
here and let's just say that the front
end of this application is something
that we wrote with react backed by
nodejs we'll say that this database
access application a fan of using Java
for database access so we'll say Java up
here and for accessing external API s
maybe we use Python on maybe a flask
application that allows us to serve rest
endpoints now putting on my hat as a
docker ops engineer using a purely
docker approach to deploying an
application let's take this app and move
over to a sample server stack that we
have sketched out over here on every
service stack you're gonna have the the
basics right so we'll have the hardware
we'll have the OS which is generally
going to be ubuntu when you're working
with docker and we'll have the doctor
daemon installed on top of that OS
that's what allows us to spin up
containers so docker actually provides
us a number of great tools for working
with our containerized applications so
once we take these applications create
neat docker containers out of them will
do docker build docker push up to a
registry and then SSH into our stack and
do docker run commands or even use
doctor compose to spin up our containers
so let's take a look at what that would
look like so we've got our jsn we've got
our java app as well as the Python
and let's go ahead and scale out these
individual pieces as well so take
advantage of all the resources we have
so we'll scale them out and we can do
this as many times as we want but let's
assume that we scale them out twice for
now to make effective use of all the
resources that we have available so
using docker and the tools that docker
makes available a simple deployment is
very easy but let's imagine that our
application starts to get a lot more
load a lot more people are hitting it
and we realize hey we need to scale out
to be able to provide a better user
experience so it's an ops engineer my
first instinct might be hey I've already
got scripts to make this stack let's
just simply create new get new hardware
and do that exact same deployment
multiple times this can fall apart for
many reasons when you start moving to
scale for example what if your dev team
has to create a new micro service to
support a new requirement where do we
piece those in especially if you already
have effective use of the hardware and
the ops and dinner would have to find
that out and in addition a big advantage
of micro service based applications is
being able to scale out individual
components individually so that's
another thing that the ops engineer
would have to write scripts for and find
the most effective way to scale things
out in response to load to identify and
address user experience issues when
moving to scale so this is where an
orchestration tool comes in something
like kubernetes which is going to allow
you to use your existing darker eyes
applications but orchestrate them and do
make it more effective use of your
servers in space so what we have
sketched out down here is a number of
boxes which represent a server stack but
in the kubernetes land we call them
worker nodes so we're gonna have
kubernetes installed on every single one
of these worker nodes and the main one
is going to be the master node whereas
the other ones or workers this master
node is actually connected to all the
worker nodes and decides where to host
our applications our docker containers
how to piece them together and even
manages orchestrating them starting
stopping updates that kind of thing I'd
say there's three major advantages that
could
Nettie's provides that I want to walk
through deployment making development
easier and providing monitoring tools
the first step as expected is going to
be deployment so coming back to our
application architecture let's say we
want to deploy that react app about
eight times so we'll say we want eight
instances each of them let's say we
expect it to consume about 128 megabytes
and then we can actually specify some
other parameters in there as well
policies like when to restart that kind
of thing and when we box that up what we
get is a kubernetes deployment so a
kubernetes deployment is not a one-time
thing but it's something that grows and
lives and breathes with the application
and our and our full stack so for
example if the react app happens to
crash kubernetes will automatically be
started to get back to that state that
we've identified when we first created
that deployment so deployment is always
growing and always living with our
application so I think we can
effectively say that it's made
deployment in addition to scaling easier
let's talk about development you might
be wondering so once we've created like
the deployments for each of these
individual services and scaled all of
them out we have a lots of different
micro services out there with different
endpoints so for example if our
fernández de debase there might be maybe
8 different versions of that Java app
that that talk to that database we have
to talk to one of them to get our kind
of request fulfilled right so what
kubernetes does is deploys load balances
for all of our micro services that we
scaled out and in addition takes it
takes advantage of service registry and
discovery capabilities to allow our
applications to talk to each other using
something called a kubernetes service so
for each of these kubernetes will also
create a service which we can simply
label service a B and C obviously you
can have more meaningful names for those
as well but very simply these
applications can now speak to each other
just by using those
service names that are laid out in
kubernetes so essentially I could say
that kubernetes has made development
easier and the last thing I want to
touch on is monitoring kubernetes has a
lot of built-in capabilities to allow
you to kind of see logs see CPU load all
in there neat UI but the fact is it
there's sometimes more that you want to
see with your application and the open
source community out there has developed
a number of amazing tools to give you
introspection into your running
application so the main one I'm thinking
about right now is sto and although
that's a little bit more of an advanced
topic will likely hit that in a future
whiteboarding session so back to our
main topic using kubernetes versus
docker it's definitely not a choice of
using one or the other it's one of those
things where kubernetes allows you to
take advantage of your existing docker
workloads and run them at scale tackle
real complexities kubernetes is great to
get started with even if you're making a
small app if you anticipate that one day
you'll have to move to scale if you're
already taking advantage of docker and
containers with your applications moving
them onto kubernetes can really help you
tackle some of the operations overhead
that almost every application is going
to run into when moving to scale thank
you for joining me today I hope you find
this useful and definitely stay tuned
for additional whiteboarding sessions in
the future