Understanding Microservices vs Monoliths
Key Points
- A micro‑service architecture splits each function of an application into its own containerized service that communicates via APIs, unlike a monolith where all functionality lives in a single deployable unit.
- Monolithic applications are simple to develop and deploy initially, but they create tightly coupled code, shared libraries, and language/framework lock‑in, making changes risky and hard to manage.
- As a monolith grows—adding new features like inventory, recommendations, carts, payments, and reporting—it becomes increasingly complex for teams to understand, harder to modify, and requires large, disruptive deployments.
- Scaling a monolith is inefficient because any high‑load component (e.g., the payment service) forces the entire application to be redeployed or scaled together, whereas micro‑services can scale individual services independently.
Full Transcript
# Understanding Microservices vs Monoliths **Source:** [https://www.youtube.com/watch?v=CdBtNQZH8a4](https://www.youtube.com/watch?v=CdBtNQZH8a4) **Duration:** 00:06:39 ## Summary - A micro‑service architecture splits each function of an application into its own containerized service that communicates via APIs, unlike a monolith where all functionality lives in a single deployable unit. - Monolithic applications are simple to develop and deploy initially, but they create tightly coupled code, shared libraries, and language/framework lock‑in, making changes risky and hard to manage. - As a monolith grows—adding new features like inventory, recommendations, carts, payments, and reporting—it becomes increasingly complex for teams to understand, harder to modify, and requires large, disruptive deployments. - Scaling a monolith is inefficient because any high‑load component (e.g., the payment service) forces the entire application to be redeployed or scaled together, whereas micro‑services can scale individual services independently. ## Sections - [00:00:00](https://www.youtube.com/watch?v=CdBtNQZH8a4&t=0s) **Microservices vs Monolithic Architecture** - The speaker explains microservice architecture as containerized, API‑driven services contrasted with traditional monolithic applications, using a ticket‑selling system example to highlight dependencies and deployment differences. ## Full Transcript
hi I'm Darren Bettinger with the IBM
cloud team today I'm here to enter the
question what are micro-services for
those who don't know a microservice is
an application architecture that takes
every application function and puts it
in its own service that runs in a
container and these containers then
communicate over api's to better
understand what a micro-service is we
should probably look into understand
what a monolith is the monolithic
architecture is a server-side system
based on a single application in a Java
world for example the the application
would be put into a jar or war file and
deployed as a whole into a production
environment the thing about a monolith
is they're easy to develop deploy and
manage but things happen over time
Lesly use an example in this case
pretend we are a ticketing service one
that sells tickets to sporting events
and concerts etc in a monolithic world
the architecture might look like this
where we have a user interface we have
some semblance of an inventory component
a recommendation engine that provides
outputs based on user inputs maybe a
cart service we'd have a payment service
and then some type of reporting function
to generate reports so that's great the
thing you can realize right off the bat
is that these are highly dependent
systems or highly dependant software
meaning that there are shared libraries
within this architecture if you make a
change you have to understand what other
components rely on those those libraries
so they're easy to break over time
another challenge we have around model
ifs are that their language and
framework dependent so when the in this
case if this is a java application any
additional component that has to be
written needs to be written in java so
you're somewhat limited by decisions
made in the past another thing that
happens and another challenge with
monoliths is growth over time user input
comes back into the product team and
they need to add additional
functionality so initially it's small
but over time you might need to add
capability hey or capability B for
example or capability C now as a whole
the application is getting much larger
it's harder for a team to actually
understand what's happening to it and
hard for a team to know every little
intricacy about the thing as it grows as
it also becomes bigger
it takes heroic efforts to deploy the
monolith meaning that on a Friday night
you would have to shut down the original
application and then actually deploy the
new production application and the team
the ops team would spend all weekend
trying to stabilize it and get it to run
so at Monday it can be up and functional
again and that can be very painful for
teams and it can be really hard another
challenge we have around monoliths is
the way they scale if it's really busy
and there's lots of people trying to buy
tickets in this example maybe the
payment part of the application is under
duress and it needs some additional
capabilities what happened is you would
have to redeploy the whole application
to help satisfy that that demand and
that need so in this instance we would
maybe need to go ahead and redeploy
another version of this system what that
looks like is right now is we have one
system running when this is under a
contention we need to redeploy another
version of that application there's
number two the challenge is it might
take a lot of time to go add that new
application the new instance of the
application and by the time it's up and
running that peak may have already
subsided and effectively you've done
nothing to help your users so that's a
challenge around the monolith as well
let's look at the same example of the
ticketing company in the micro services
based environment so again a micro
service environment we'd have the same
functionality you'd have your user
interface it would be in its own
container as a service you'd have your
inventory service as well
your recommendation engine would be in
its own service your your cart is in its
service we had the payment service and
we had reporting so it's the same as the
the monolith that
differences these all talk over api's
and right off the bat you can see
something that's kind of interesting
because they're independent the team
responsible for the reporting engine for
example can choose a language and
framework that they want to use
themselves they are not beholden to
choices made by the team that run the
cart toward the UI or the payment system
so that's really good it gives those
teams flexibility so that's the language
part another benefit is the ability to
iterate because these are independent
components and they just talk over api's
the team responsible for the reporting
engine for example can commit code that
goes through the DevOps pipeline and one
site gets tested and it's proven to work
it can automatically be deployed to the
to the environment so thereby these
teams can iterate as fast as they need
to bringing value to your to the
customers so that's fantastic
additionally these changes are minimal
at best
if there is an instance where a service
does fail the rest of the application is
still functional so that's less risk we
also can scale these independently
meaning that in the case where there's a
user or a number of users that drive
load and that payment service needs some
additional help what needs to happen is
the system can actually add capability
automatically just for that particular
service until the until that libs load
subsides so eventually what happens is
when the load goes back to its regular
regular cadence for example those
systems and those additional services
can scale back to normal so again just
to reiterate the micro services
architecture is where every application
function is its own service deployed
inside of a container environment they
communicate via api's their language and
framework independent we iterate at will
through a devops pipeline this reduces
some of the risk that we we see and then
we can scale these components
independently so thank you for your time
today if you like to learn more and see
more light boarding videos check us out
on the IBM cloud blog