Shadowing Practice: Microservices explained - the What, Why and How? - Learn English Speaking with Video
Les maken...
1
In this video, I'm going to talk about microservices.
2
First, I'm going to start by explaining what a monolith application architecture is, what were some of the challenges of a monolith architecture,
3
and why the industry moved slowly towards the microservices architecture.
4
Then we'll see what microservices or microservice architecture is exactly, as well as best practices,
5
benefits, and how the communication between microservices actually works.
6
We will also see different ways to manage code for microservices application
7
and talk about monorepo versus polyrepo and advantages and disadvantages of both.
8
So let's get started.
9
Before microservices, the standard way of developing applications was with a monolithic architecture.
10
This means all the components of the application, the whole code basically is part of a single unit.
11
For example, if we had an online shop application, all of its parts like the user authentication,
12
shopping cart, product catalog, sales campaigns,
13
notification, and so on, all the code for these functionalities would be in one code base as part of one monolithic application.
14
Everything is developed, deployed, and scaled as one unit.
15
This means the application must be written in a single language with one technology stack with a single runtime.
16
And if you have different teams working on different parts of the application, they will need to coordinate to make sure they don't affect each other's work.
17
Also, if developers change code for the payment functionality, you would need to build the whole application and deploy it as one package.
18
You can't just update and deploy only the payment functionality changes separately.
19
So this was a standard way of developing applications, but as applications grew in size and complexity, this led to different challenges.
20
First of all, the coordination between teams became more difficult
21
because the code was much bigger and parts of the application were more tangled into each other.
22
Also, if suddenly you had a usage spike in shopping cart, for example, on holiday dates and you would want to scale only that part of the application,
23
you can't do it.
24
You need to scale the whole application.
25
This in turn means higher infrastructure costs and less flexibility in scaling your application up and down.
26
Another issue is, for example, if a payment functionality used a third-party module with a version 1.8,
27
while notifications featured needed the same module but required the version 1.7 instead, in a monolith application you would have to pick one
28
or the other because it's a single application and you can only have one dependency of the same module.
29
Another major issue with monolith applications is
30
that the release process of such applications takes longer
31
because for changes in any part of the application in any feature you need to test
32
and build the whole application to deploy those changes.
33
And the answer to all these issues was a microservices architecture.
34
So what is microservices exactly?
35
With microservices, we break down the application in essentially multiple smaller applications.
36
So we have several small or micro applications that make up this one big application.
37
Now we have a couple of very important questions when we create a microservices architecture.
38
First of all, how do we decide how to break down the application?
39
What code goes where and how many such micro applications or microservices do we create?
40
How big or small should these microservices be?
41
And finally, how do these services then talk to each other?
42
First of all, the best practice is to break down the application into components
43
or into microservices based on the business functionalities and not technical functionalities.
44
So the microservices of an online shop application will be products, shopping cart, user accounts, checkout and so on.
45
Because all these are basically business features.
46
And in terms of the size, each microservice must do just one isolated thing.
47
So you shouldn't have a microservice that is responsible for shopping cart logic and the check out.
48
You should always strive to keep one service doing one specific job.
49
And a very important characteristic of each microservice is that they should be self-contained and independent from each other.
50
This means each service must be able to be developed, deployed and scaled separately without any tight dependencies on any other services,
51
even though they are part of the same application.
52
And this is called loose coupling.
53
So with this best practice approach, if you change something in the payment service, you will only build and deploy the payment service,
54
nothing else will be affected.
55
And this means the services have their own individual versions, which are not dependent on others.
56
So if I release one service, I don't need to release any other service.
57
So this release cycle has to be completely independent.
58
Now, if these services are isolated and self-contained, how do they connect to each other?
59
Because obviously the payment service will need something from the user account to process the payment, or the checkout service will need something from the shopping cart.
60
A very common way for microservice communication is using API calls.
61
So each service has an endpoint on which it accepts requests from other services.
62
So services can talk to each other by sending each other HTTP requests on these endpoints.
63
This is a synchronous communication where one service sends a request to another service and waits for the response.
64
So the user account service can send an HTTP request to payment service on its API endpoint and vice versa.
65
Another common way of communication between microservices is using a message broker with an asynchronous communication.
66
Here, services will send messages first to the intermediary message service or a broker, such as RabbitMQ, for example,
67
and then the message broker will forward that message to the respective service service.
68
So again, user account will send the message to the broker saying,
69
please pass this message on to the payment service and message broker will then forward that message to the payment service.
70
And a third way of communication between microservices, which is becoming pretty popular, especially in the field of Kubernetes,
71
is using a service mesh.
72
With service mesh, you have kind of a helper service
73
which takes over the complete communication logic
74
so you don't have to code this logic into the microservices
75
and have this communication logic kind of delegated to this external service.
76
So these are different communication options and since the services are all isolated
77
and talk to each other either with API calls or using additional services, you can even develop each service with a different programming language.
78
And you can have dedicated teams for each service
79
that can choose their own technology stack and work on their service without affecting or being affected by other service teams.
80
And this is exactly the most important advantage of microservices architecture compared to the monolith.
81
However, these benefits come with the price.
82
So while microservices made developing and deploying applications easier in many aspects, it also introduced some other challenges that weren't there before.
83
When you break down the application into these multiple pieces, this introduces a lot of complexities and challenges.
84
One of the main complexities may be configuring the communication part between the services.
85
Because a microservice may be down or unhealthy and not responding yet,
86
while another service starts sending requests to its API expecting a fulfilled response, in which case you may get unexpected results.
87
Also, with microservices deployed and scaled separately, it may become difficult to keep an overview and find out
88
when a microservice is down or which service is actually down when something in the application is not working properly.
89
So you definitely need a proper configuration of your application setup
90
and its pieces to make sure your application as a whole functions well.
91
But there are various tools for making all this easier.
92
So even though the microservices architecture is complex,
93
there are a lot of tools and still more being developed regularly to make running microservices applications easier.
94
The most popular one you probably already know is Kubernetes, which is a perfect platform for running large microservices applications.
95
Now, before moving on, I'm very excited to give a shout out to HashiCorp,
96
which is a company that many of you probably already know about and has a lot of really cool technologies,
97
many of those that actually solve various challenges when working with microservices applications.
98
From the infrastructure provisioning tool Terraform, to the secret management tool Vault,
99
which is pretty much becoming a standard already in the industry for managing and protecting your sensitive data.
100
HashiCorp also has a service mesh product called Consul which helps you securely connect and observe your microservices running in any environment.
101
So with various tools that HashiCorp offers you can actually provision,
102
secure, connect, and run cloud infrastructure for your most important applications and specifically for your microservices applications.
103
If you want to learn more about any of these technologies, be sure to check out the whiteboard sessions of HashiCorp's co-founder and CTO,
104
who gives really good introductions of all these technologies on YouTube.
105
And now let's move on.
106
Now obviously an important element of deploying microservices is a CI-CD pipeline.
107
In fact, there are many companies with microservices applications that deploy multiple times a day.
108
Companies like Amazon, Google and Netflix, they have applications with hundreds of microservices that they deploy thousands of times per day.
109
So you can imagine the complexity and the sophistication of their CICT pipelines.
110
So in the modern world and workplace, you will be most probably working with microservices
111
and in this case you would need to know how to configure release process with a CI-CD pipeline for microservices.
112
Now we said microservices is when application components get developed and deployed separately as individual micro applications.
113
So the question is how do we manage the code for
114
microservices application in a git repository like gitlab for example with one project it's simple we just have one application
115
and it gets its own git repository with microservices application we
116
have two options for how the code is managed monorepo
117
which stands for single repository and polyrepo also multi-repository so monorepo
118
or single repository is having one gitlab repository for all the services
119
so we would create one project for m1 repo
120
so what's the difference here
121
or how do we structure multiple micro applications inside one application repository well a common way is using folders
122
so you have folders for each service like shopping cart payment notifications etc
123
and all the code for those services are in those respective folders And having a monorepo,
124
meaning all the services still in one repository,
125
makes the code management and development easier because you only have to clone and work with one repository.
126
So it simplifies things.
127
Plus, if you have some shared code between the services like Kubernetes manifest templates or Helmchart or Docker Compose,
128
whatever, you can put them in the root of the project and all the services can basically reuse them.
129
But monorepo also comes with some challenges.
130
As I mentioned, the most important criterion of microservices is to be completely independent and isolated.
131
So no tight coupling between the services inside the code.
132
And it becomes easy to break this criterion when you have a monorepo.
133
So you have junior developers with less experience in the monorepo setup.
134
It's easier to make such mistakes and develop tightly coupled logic or code in your services.
135
Another downside of monorepo is when the application becomes really big,
136
cloning, fetching and pushing becomes slow because your project is huge.
137
And in terms of the CI-CD pipeline, in most of the CI-CD platforms like GitLab CI-CD or Jenkins, you can only create one pipeline for one project.
138
So you are building multiple services with a single project pipeline.
139
And that means you need to add additional logic in your pipeline code
140
that makes sure to only build and deploy the service which has changed.
141
So if you make code changes in the payment service, your pipeline code should detect that and only that service should be built, tested and deployed.
142
And it is possible to do that, but it's a little bit more challenging.
143
One more issue with a monorepo is that since you have just one main branch because you have one repository,
144
if developers of one of the services break the main branch, other services and their pipelines will be blocked as well.
145
But there are a lot of companies, including very big ones like Google who actually use Monorepo for their applications.
146
The second option, which is probably a bit more preferred one, is Polyrepo or multiple repositories.
147
With this approach, for each service, we create a separate Git project.
148
So the code is completely isolated.
149
You can clone and work on them separately because they are in separate repositories.
150
Now, even though they are separate application repositories, they are still part of this bigger application.
151
So of course, you would want to still have some kind of connection of these repos for an easy management and overview.
152
So if you're hosting your code repositories on GitLab,
153
for example, you can use GitLab's feature of groups in order to group code for all the microservices
154
that belong to the same application in one group to make managing those repositories easier.
155
So essentially, you would create a GitLab repository group for your application called My Online Shop,
156
and inside this group you can create a separate project for each microservice that belongs to that application.
157
If your company has multiple microservices applications, of course this will help keep an overview of what projects belong together.
158
But also within the group you can actually create secrets
159
or other CI variables that can be shared by all the projects in that group.
160
Now what about the CI CD pipeline for a polyrepo?
161
Well for polyrepo the CI CD configuration is more straightforward
162
because you just have own pipeline for each repository
163
so no extra logic is needed to differentiate between the services now of course everything has advantages and disadvantages
164
so for polyrepo as well you have some downsides like having
165
application code in multiple repositories can make working on the project as a whole harder especially
166
if you need to change two or more services at once
167
because a feature or a bug fix affects multiple services
168
if you need to switch between the services often this can
169
also be tedious plus things like searching something across multiple projects from the code editor can be difficult
170
or impossible also in the poly repo you can't really share files in the project like kubernetes
171
or hell manifest docker compose and
172
so on you would either have to duplicate them in each project's repository or have to create dedicated
173
project and reference them from there.
174
So as you see, both options have their advantages and disadvantages, but the general rule is that if you have a small project with just several microservices,
175
you should stick to monorepo and save the overhead of creating and managing and checking out multiple repositories.
176
On the other hand, if you have separate teams for each service, if you want to have complete isolation, smaller code base to clone,
177
own pipelines, and so on, then of course the polyrepo would be a better option.
178
Now I hope this gave you a great introduction to microservices
179
and now you understand what it is and why everyone is using it.
180
If you're interested to know how to build CI-CD pipelines for microservice applications, then you can check out my complete GitLab CI-CD course in
181
which I actually show hands-on demos of how to build CI-CD
182
pipelines for microservice applications in a monorepo as well as polyrepo as well as deploying a microservice application to a Kubernetes cluster.
183
And generally, if this video was useful, please give it a like and share with your colleagues and subscribe for more content like this.
184
With this, thank you for watching and see you in the next video.
๐บ Zelfde Kanaal
C1Redis Crash Course - the What, Why and How to use Redis as your primary database
University StudentsBusiness English+1
C12
What is Docker? Docker container concept explained || Docker Tutorial 1
University StudentsBusiness English+1
B21
Every Networking Concept Explained In 20 Minutes
University StudentsBusiness English+1
B2CI/CD Explained in 5 Minutes
University StudentsBusiness English+1
C12
NGINX Explained - What is Nginx
University StudentsBusiness English+1
C12
Kafka Tutorial for Beginners | Everything you need to get started
University StudentsBusiness English+1
C17
If I would start DevOps from 0 - How would I start and what would I learn
University StudentsWorking Adults
โจ Aanbevolen Video
C12
49 zinnen
What Are Microservices Really All About? (And When Not To Use It)
University StudentsBusiness English+1
C11
197 zinnen
Unreal Engine 5.8 - Experimental MCP Server Support Walkthrough | State of Unreal 2026
University StudentsBusiness English+1
C15
106 zinnen
A Career in IT
University StudentsBusiness English+1
C11
96 zinnen
Design Patterns in Java Theory
University StudentsBusiness English+1
C11
132 zinnen
Video
University StudentsBusiness English+1
C11
177 zinnen
Mini Project - Implementing a Simple Web Identity Federation Application
University StudentsBusiness English+1
C14
36 zinnen
Overcoming Service Blueprinting Frustrations
University StudentsBusiness English+1
C11
43 zinnen
What is an Organization? - the Nature of Organizations
University StudentsBusiness English+1
C11
189 zinnen
Using AI to read research articles
University StudentsBusiness English+1
C11
497 zinnen
Technical deep dive on Managed Instance for App Service | BRK102
University StudentsBusiness English+1
C1105 zinnen
100+ Docker Concepts you Need to Know
American Accent, en-USUniversity Students+2
Over deze les
Wat is de Shadowing-techniek?
Shadowing is een wetenschappelijk onderbouwde taalleermethode die oorspronkelijk is ontwikkeld voor professionele tolkentraining en gepopulariseerd door polyglot Dr. Alexander Arguelles. De methode is eenvoudig maar krachtig: je luistert naar native Engelse audio en herhaalt het onmiddellijk hardop โ als een schaduw die de spreker volgt met slechts 1โ2 seconden vertraging. In tegenstelling tot passief luisteren of grammaticadrills, dwingt shadowing je hersenen en mondspieren om echte spraakpatronen tegelijkertijd te verwerken en te reproduceren. Onderzoek toont aan dat het de uitspraaknauwkeurigheid, intonatie, ritme, verbonden spraak, luisterbegrip en spreekvaardigheid aanzienlijk verbetert โ waardoor het een van de meest effectieve methoden is voor IELTS Speaking-voorbereiding en echte Engelse communicatie.