00:00 - 00:03
I recently made a video on the Strangler
00:01 - 00:05
pattern which provides a safer
00:03 - 00:07
incremental migration path by allowing
00:05 - 00:09
new microservices to gradually strangle
00:07 - 00:11
the monolith without significant changes
00:09 - 00:13
to the existing code Base Service
00:11 - 00:15
decomposition focuses on breaking down
00:13 - 00:18
the monolith based on logical boundaries
00:15 - 00:20
and business domains often involving
00:18 - 00:21
Direct refactoring in today's video
00:20 - 00:23
we'll explore why breaking down
00:21 - 00:25
monolithic systems through service
00:23 - 00:27
decomposition is essential for modern
00:25 - 00:29
software development we'll explore key
00:27 - 00:30
strategies for breaking down monoliths
00:29 - 00:33
and look at how companies like Netflix
00:30 - 00:35
and Spotify use service decomposition to
00:33 - 00:38
achieve scalability resilience and
00:40 - 00:45
Innovation as your application expands
00:43 - 00:47
sticking with a monolithic architecture
00:45 - 00:48
can create significant challenges in a
00:47 - 00:50
monolith all functions are tightly
00:48 - 00:53
coupled with a single code base which
00:50 - 00:54
leads to several issues think of a
00:53 - 00:56
monolithic application like a joint
00:54 - 00:58
machine with interconnected Parts if one
00:56 - 01:01
part malfunctions you must take the
00:58 - 01:03
entire machine offline to fix it as the
01:01 - 01:05
machine gets bigger fixing even small
01:03 - 01:08
issues become increasingly complex and
01:05 - 01:10
scaling it is cumbersome and expensive
01:08 - 01:12
service decomposition is the process of
01:10 - 01:14
identifying and extracting these smaller
01:12 - 01:17
services from the monolith but how do
01:14 - 01:18
you effectively decompose a monolith
01:17 - 01:20
that's where the service decomposition
01:18 - 01:22
pattern comes into play when it comes to
01:20 - 01:24
service decomposition there are several
01:22 - 01:26
strategies that can help structure your
01:24 - 01:29
microservices effectively each with its
01:26 - 01:31
own set of benefits first you can
01:29 - 01:33
decompose by business capability this
01:31 - 01:36
means breaking down Services based on
01:33 - 01:38
core business functions for example in
01:36 - 01:39
an e-commerce platform you might have
01:38 - 01:42
separate services for inventory
01:39 - 01:45
management order processing payment and
01:42 - 01:47
shipping the key benefit this approach
01:45 - 01:49
align services with your organizational
01:47 - 01:51
structure making it easier for teams to
01:49 - 01:53
own and manage their specific areas of
01:51 - 01:56
expertise an advanced and effective
01:53 - 01:57
strategy is to decompose by subdomains
01:56 - 02:00
which is a concept from domain driven
01:57 - 02:01
Design This approach allows you to hand
02:00 - 02:03
complexity by organizing your system
02:01 - 02:05
around business domains ensuring that
02:03 - 02:08
each service has clear boundaries and
02:05 - 02:11
specific business logic in DDD we use
02:08 - 02:13
the idea of bounded context to divide
02:11 - 02:15
our system into smaller more manageable
02:13 - 02:17
areas a bounded context represents a
02:15 - 02:19
specific part of your business domain
02:17 - 02:20
with its own language and Logic for
02:19 - 02:22
example instead of having a single
02:20 - 02:24
payment service we might break it down
02:22 - 02:26
into smaller services like invoice
02:24 - 02:28
processing and transaction management
02:26 - 02:30
each focused on its own task this
02:28 - 02:32
approach helps reduce comp lexity and
02:30 - 02:34
keeps the business logic clear and
02:32 - 02:36
isolated and if you're new to the idea
02:34 - 02:38
of DDD do not worry I'll cover it in
02:36 - 02:40
more depth in an upcoming video where
02:38 - 02:43
we'll explore how to effectively use
02:40 - 02:45
bonded context and DDD principles an
02:43 - 02:48
alternative approach is to decompose by
02:45 - 02:49
use case or user Journey for instance
02:48 - 02:52
think of the checkout process on an
02:49 - 02:53
e-commerce platform in this approach
02:52 - 02:55
services are designed around specific
02:53 - 02:57
user interactions or workflows a
02:55 - 02:59
dedicated checkout service would handle
02:57 - 03:01
everything from card validation to
02:59 - 03:03
payment and all a confirmation the main
03:01 - 03:04
benefit here is that the services are
03:03 - 03:06
optimized for performance during
03:04 - 03:09
critical user path phas enhancing the
03:06 - 03:11
overall user experience lastly you can
03:09 - 03:13
decompose by resource this involves
03:11 - 03:16
creating services around entities that
03:13 - 03:19
perform create read update and delete
03:16 - 03:20
operations for example a product catalog
03:19 - 03:22
service would manage all operations
03:20 - 03:25
related to product information this
03:22 - 03:26
method simplifies data management and
03:25 - 03:29
aligns your services closely with
03:26 - 03:30
underlying database structures each of
03:29 - 03:32
these strategies whether based on
03:30 - 03:35
business capabilities subdomains user
03:32 - 03:38
Journeys or resources offers distinct
03:35 - 03:39
advantages as you decompose your MTH
03:38 - 03:42
into microservices managing them
03:39 - 03:44
efficiently is key tools like kubernetes
03:42 - 03:46
and sto are essential for this
03:44 - 03:48
kubernetes automates the deployment
03:46 - 03:50
scaling and management of containerized
03:48 - 03:52
applications ensuring your services can
03:50 - 03:54
Scale based on demand without manual
03:52 - 03:56
intervention I'll be doing a deep dive
03:54 - 03:59
on kubon netes in an upcoming video so
03:56 - 04:01
stay tuned for that for managing service
03:59 - 04:03
communication stto a service mesh offers
04:01 - 04:06
traffic management security and
04:03 - 04:07
observability across Services I've
04:06 - 04:09
covered this in detail in my previous
04:07 - 04:11
video on service mesh it allows you to
04:09 - 04:13
Trout traffic intelligently and ensure
04:11 - 04:16
availability even if some service fail
04:13 - 04:18
by using kues and sto you are not only
04:16 - 04:20
simplifying microservices orchestration
04:18 - 04:23
but also gaining visibility into service
04:20 - 04:25
performance and ensuring robust security
04:23 - 04:27
between Services these tools take care
04:25 - 04:29
of the operational complexities allowing
04:27 - 04:30
you to focus on delivering features
04:29 - 04:32
faster and with with greater confidence
04:30 - 04:34
When approaching service decomposition
04:32 - 04:37
it is crucial to follow some key best
04:34 - 04:39
practices to ensure success start small
04:37 - 04:41
by breaking down non-critical components
04:39 - 04:42
first this allows your team to gain
04:41 - 04:45
hands-on experience without affecting
04:42 - 04:47
core functionalities clearly Define the
04:45 - 04:49
boundaries of each service by leveraging
04:47 - 04:51
domain models and aligning with business
04:49 - 04:54
capabilities ensuring each service has
04:51 - 04:56
distinct purpose Embrace automation to
04:54 - 04:58
simplify the complexity automating
04:56 - 05:01
testing deployment and monitoring will
04:58 - 05:03
make your process more efficient
05:01 - 05:05
collaboration across teams is essential
05:03 - 05:07
to manage the interdependencies that
05:05 - 05:08
arise in microservices architecture so
05:07 - 05:11
keep communication channels open and
05:08 - 05:13
active and remember service
05:11 - 05:14
decomposition is an ongoing process
05:13 - 05:16
continuously assess and refine your
05:14 - 05:18
services to keep up with evolving
05:16 - 05:20
business needs and technological
05:18 - 05:22
advancements Netflix serving millions of
05:20 - 05:24
users worldwide needed an architecture
05:22 - 05:26
that could support rapid feature
05:24 - 05:28
releases and high availability behind
05:26 - 05:30
this effortless user experience lied a
05:28 - 05:32
complex technological evolution
05:30 - 05:34
a journey from monolithic system to a
05:32 - 05:35
Cutting Edge microservices architecture
05:34 - 05:37
through the power of service
05:35 - 05:39
decomposition let's RND to the early
05:37 - 05:41
2000s when Netflix was a DVD by mail
05:39 - 05:43
service with a relatively
05:41 - 05:45
straightforward technological setup as
05:43 - 05:46
the company grew and ventured into the
05:45 - 05:48
streaming media their monolithic
05:46 - 05:50
application began to show cracks under
05:48 - 05:52
the pressure of Rapid expansion and
05:50 - 05:54
increasing user demands the monolithic
05:52 - 05:56
system was a single unified code based
05:54 - 05:58
where all functionalities were tightly
05:56 - 06:00
interwoven this architecture made it
05:58 - 06:02
difficult to implement new features
06:00 - 06:04
scale specific components or recover
06:02 - 06:07
quickly from system failures any change
06:04 - 06:10
no matter how small required redeploying
06:07 - 06:12
the entire application a risky and timec
06:10 - 06:14
consuming process and recognizing these
06:12 - 06:15
limitations Netflix embarked on a
06:14 - 06:17
transformative journey to decompose
06:15 - 06:20
their monolithic application into
06:17 - 06:22
microservices Netflix's shift to service
06:20 - 06:23
decomposition wasn't just about breaking
06:22 - 06:25
down their system it was about
06:23 - 06:28
empowering teams to own specific
06:25 - 06:29
services and innovate quickly for
06:28 - 06:31
example their recommendations service
06:29 - 06:33
become a standalone microservice
06:31 - 06:35
allowing teams to rapidly innovate run
06:33 - 06:37
experiments and improve the user
06:35 - 06:38
experience without disrupting other
06:37 - 06:40
parts of the system in the
06:38 - 06:42
recommendation service for instance by
06:40 - 06:44
isolating it Netflix could innovate
06:42 - 06:46
rapidly deploying Advanced algorithms
06:44 - 06:48
and AV testing new features without
06:46 - 06:50
impacting other parts of the system this
06:48 - 06:52
agility resulted in highly personalized
06:50 - 06:54
content suggestions keeping users
06:52 - 06:56
engaged and satisfied by decoupling
06:54 - 06:58
Services Netflix achieved unparalleled
06:56 - 07:00
scalability during peak hours or the
06:58 - 07:02
release of a popular show only the
07:00 - 07:04
necessary Services scaled up to handle
07:02 - 07:07
the load optimizing resource utilization
07:04 - 07:09
and reducing cost resilience was another
07:07 - 07:11
significant gain in a microservices
07:09 - 07:13
architecture if one fails say the
07:11 - 07:15
billing service the rest of the system
07:13 - 07:17
continues to function users can still
07:15 - 07:18
browse and watch content while the issue
07:17 - 07:21
is resolved enhancing overall
07:18 - 07:23
reliability service decomposition also
07:21 - 07:25
allowed Netflix to embrace technological
07:23 - 07:27
diversity teams could choose the best
07:25 - 07:29
tools and languages suited for the
07:27 - 07:31
specific service some Services adopted
07:29 - 07:34
Java other nodejs or Python and
07:31 - 07:36
databases range from Cassandra to mySQL
07:34 - 07:38
each optimized for particular needs and
07:36 - 07:41
to ensure robustness Netflix introduced
07:38 - 07:42
kios monkey a tool that intentionally
07:41 - 07:44
disrupts services in the production
07:42 - 07:46
environment this might sound
07:44 - 07:48
counterintuitive but by simulating
07:46 - 07:50
failures they strengthen the system's
07:48 - 07:52
ability to handle real world issues
07:50 - 07:54
gracefully today Netflix serves over 200
07:52 - 07:56
million subscribers worldwide streaming
07:54 - 07:58
billions of hours of content each month
07:56 - 08:00
and this success is in part thanks to
07:58 - 08:02
the Strategic implementation of service
08:00 - 08:04
decomposition Netflix's Journey
08:02 - 08:06
illustrates the transformative power of
08:04 - 08:08
breaking down complex systems into
08:06 - 08:09
manageable independent Services service
08:08 - 08:11
decomposition not only solved their
08:09 - 08:13
immediate challenges but also paved the
08:11 - 08:15
way for Innovation scalability and
08:13 - 08:17
resilience another great example of
08:15 - 08:19
service decomposition comes from Spotify
08:17 - 08:21
a company that serves millions of users
08:19 - 08:23
with realtime music streaming as Spotify
08:21 - 08:25
scaled rapidly their initial monolithic
08:23 - 08:27
architecture couldn't keep up with user
08:25 - 08:30
demand and the need for frequent feature
08:27 - 08:32
releases in the early days spotify's
08:30 - 08:34
architecture was monolithic with tightly
08:32 - 08:35
coupled components handling everything
08:34 - 08:37
from users playlist to music
08:35 - 08:38
recommendations the structure made it
08:37 - 08:41
difficult for teams to work
08:38 - 08:43
independently changes in one part of the
08:41 - 08:45
application could easily impact other
08:43 - 08:47
parts slowing down development and
08:45 - 08:50
deployment and to solve this bottlenecks
08:47 - 08:52
Spotify embraced service decomposition
08:50 - 08:55
breaking down their monolith into
08:52 - 08:56
smaller more manageable microservices
08:55 - 08:57
and each of these microservices were
08:56 - 08:59
designed around specific business
08:57 - 09:01
capabilities like the playlist
08:59 - 09:03
management recommendation algorithms or
09:01 - 09:05
music delivery this allowed individual
09:03 - 09:08
teams to own and manage their respective
09:05 - 09:10
Services improving both productivity and
09:08 - 09:12
Agility for instance the playlist
09:10 - 09:14
service became its own microservice this
09:12 - 09:15
allowed sptify Engineers to iterate
09:14 - 09:17
quickly and adding new features like
09:15 - 09:19
collaborative playlist and personalized
09:17 - 09:22
recommendations without affecting other
09:19 - 09:25
parts of the system like Netflix Spotify
09:22 - 09:27
also benefited from independent scaling
09:25 - 09:29
so during Peak usage such as when a new
09:27 - 09:32
album drops or user flirts with platform
09:29 - 09:33
for a major event Spotify can scale only
09:32 - 09:35
the services that needs it like the
09:33 - 09:37
music streaming service this prevents
09:35 - 09:40
over provisioning and ensures efficient
09:37 - 09:42
resource use another key benefit of
09:40 - 09:44
service decomposition at Spotify was the
09:42 - 09:47
ability to experiment and innovate by
09:44 - 09:49
isolating Services Spotify could also
09:47 - 09:51
run AV test on specific features without
09:49 - 09:53
worrying about the impact on the entire
09:51 - 09:55
application for example the
09:53 - 09:57
recommendation service could test new
09:55 - 09:58
algorithms to improve song suggestions
09:57 - 10:01
leading to more personalized and
09:58 - 10:03
engaging user experiences and today
10:01 - 10:05
Spotify runs hundreds of microservices
10:03 - 10:07
each responsible for a specific function
10:05 - 10:08
of their platform this microservices
10:07 - 10:11
architecture has enabled them to scale
10:08 - 10:14
globally while continually innovating
10:11 - 10:14
and adding new features
video to article