Microservices is the New
Age Technological Marvel that is used by today's
Industries to create and deploy applications. So it's a great time for you to start learning
about this trending technology. Hi all I welcome you to
this Microservices full course and what follows is a session that will give you
a complete insight to get you started with Microservices. So without further Ado, let's take a look
at our agenda for today. So we're going to start
with introduction to Microservices where we will discuss what
microservices are their benefits and how they differ
from other architectures next. We'll talk about micro services with other Technologies such as
Docker and spring boot later on we'll compare microservices with other
service-oriented architectures and talk about Microsoft
versus with API moving on with our session. We understand how different
design patterns can be followed to create applications
using micro services. And then we'll talk about what tools can be used
with Microservices. After that. We look into the various ways through which we can secure
a micro Services applications. Finally towards the end. We'll talk about
the top interview questions of micro services that will help you Ace
your interviews with that. We come to the end
of today's agenda. Now before we begin kindly
take out a second to subscribe to our Edureka YouTube channel and don't forget
to hit the Bell icon to never miss an update
on the latest Technologies also, so if you're looking for
an online certification training on microservices do check out
the link in the description box below on that note. Let's get started why
we need Microservices so before microservices, We all know that there is
an architectural pattern called more of the architecture
that was used. All right, so there
are certain disadvantages of that architecture. But let me first explain you that architecture what exactly
monolithic architecture means so basically in this
the Ty software is composed in a single piece that is designed
to be self-contained. So what I mean by that
basically all the components of a monolithic program
are interconnected and interdependent or
in other words, if I have to put it I will say that it will give you
a tightly coupled software where each component along with its Associated
components must be present in order to execute
or compile the code. So all of these components
are actually dependent on each other. So if you notice a definition that is there in front
of your screen, it says that most
of the carcass Picture is like a big container right think
of it as a big container where in all the software
components of an application are assembled together
and tightly packaged. Right? So if you notice that there is an example
in front of your screen, so there's a
server-side application, right which executes a domain
specific logic it will retrieve an update data from the database
and at the same time populate. The HTML view is
to be sent to the browser. So it is basically
a big container or I can say that it is not divided
into small small services or not divided into
small small components. So even these components
that are there. Are pretty tightly
coupled right? So I will give you a better example of what exactly
monolithic architecture is. Let me just move forward. So let us discuss
a classic example of an e-commerce website
like Amazon and Flipkart. All right, so everyone actually visits
these websites quite often. So that's a perfect
example to you know, explain so let's understand what monolithic architecture
exactly means with this example. So as you see that
in basic e-commerce application, we have common option
of customer service, right products. Service and card service which a customer can access
through their browser. Right? And when you
launch the application, it is deployed as
a single monolithic application. There's only one single instance
if you can notice so we have customer service
product service and cart service and when you deploy
all these Services, it will be basically
a single monolithic application. Now, what you can do is in order to scale it you
can run multiple instances of this application behind
a load balancer right now. Let me discuss few advantages
of this application. So first of all
it is Very simple to develop right as a goal
of the development Tools in IDs is to support the development of
Monolithic application. It makes a development
really easy and One Direction. All right now is
pretty simple to deploy because you have to deploy
the executable file at the run time to
launch the application that executable file can be
a word file is there now this very simple scale
as well because you know in order to scale
your application. All you have to do
is run multiple copies of the application
behind a load balancer now since everything comes with its pros and cons
monolithic architecture. Also has few major drawbacks. Let's discuss about
them one by one. The first disadvantage is
large and complex applications. Now if you have
a large application or you can see with the increase
in size the application, it becomes really
complex to understand and modify such applications. Right and as a result
development slows down and modularity breaks down
over time more ever because it can be
difficult to understand how to correctly Implement
a change and due to that the quality of code
declines over time. Let's see what is
an excess Advantage. So the next
disadvantage is slow. So what I mean by that
as the application and the respective teams
grow the application becomes difficult to understand
and modify right because it's pretty huge in size and there are multiple
teams working on it. So it becomes really difficult
to understand and modify also the larger the codebase
leads to slower ID, which makes the
developers less productive. So the code base is pretty large
because the entire application is one monolithic
application, right? There are not different if it's overseas present not
blocks continuous development. So what I mean by
that a large monolithic application is An obstacle
to frequent deployments. Let me tell you how in order
to update one component. You have to redeploy the entire application which
interrupts the background task. So if I have to take the example
of the e-commerce website if I have to update
the card service, I have to redeploy the entire application
the entire application which includes the customer's
always a product service all these Services right? So there is also
a chance that components that haven't been updated
will fail to start correctly. Alright, because of many
dependency issues or anything, right and as a result
the risk associated. Redeployment increases which
discourages frequent updates. I hope you are getting my point. Let's see what we have next. So the next point is unscalable. I know I've told you
that it's pretty easy to scale. But let me tell you what are
the disadvantages when it comes to scalability and in terms
of Monolithic architecture. So each copy of application instance
will get access to all the data, right which makes
caching less effective and increase memory consumption along with input/output
traffic also different application components have
different resource requirements. One might be cpu-intensive right while other might be
Memory intensive and with a monolithic architecture. We cannot scale each component
in dependency, right? So if you can see the example that is there in front
of your screen. So here we have customer
service product service and guard service
is one instance. And this is how we
are scaling it. Right if I have to increase only the customer service after scale
up the customer service. I have to do that for product
and cart Services. Well right now it is
pretty unreliable as well. Let me tell you how so because of
the tightly coupled components if one of them. Goes down the entire system
will fail to run what I mean by that. If one of my say production
of space that will in turn lead to the downfall
of my entire application, right and because of all
the modules are running within the same process a bug in any module can potentially bring down the entire
process more ever since all the instance of the application
are identical the bug will impact the availability
of the entire application. This makes the monolithic
architecture highly unstable and unreliable. The last in the final
point is inflexible. So how is it inflexible guys
with the monastic architecture becomes really difficult
to adopt a new Frameworks and languages suppose you have
million lines of codes written with XYZ framework. Now, it would be
extremely expensive in terms of time as well as cost to
rewrite the entire application to use the newer ABC framework, right even if that framework
was considerably better and as a result, there is a huge barrier
to adopting new technologies. I hope you're getting my point. So why is it very expensive
because you know, you have written million lines
of code in some language now you To use some
other language, right? So it becomes really expensive
and time-consuming task. And even if the new language of the framework is considerably
better but you know, there's a huge barrier
in adopting such new technology. So I hope you have understood
the various disadvantages of Monolithic architecture now
is the time to understand what exactly is Microsoft with architecture microservices
also known as Microsoft is architecture is
an architectural style that structures and
application as a collection of small autonomous services. Modeled around a
business domain now if I have to put it
in simpler terms. Basically it is
a self-contained process which avails different and
unique business capabilities. Now, if you have large
applications built using this architectural pattern, it can be broken down
to small multiple Services which together access
one large system but behind the scenes, it's a Microsoft Office. So what I am trying to say here
is we have multiple services on all of these Services, they don't share
the data structure, but they will be communicating
through apis, right? A major advantage of breaking down the system
is now each microservice can focus on only
one single business capability which definitely leads
to a better quality and throw and it's obviously becomes easy for you to understand when I explain you
with a example again, I'm going to take
the e-commerce site example. Now if you remember
in monolithic architecture all the components were
in a single module, but if you see here
with Microsoft is architecture all the components are divided
into separate modules, which communicate with
each other using a well-defined. Interface usually rest our
messaging now the communication between the micro Services
is a stateless communication where each pair of request and response is
an independent transaction and because of this
microservices can communicate effortlessly moreover
in Microsoft's architecture. The data is Federated. All right. So let me just break
it down for you. Each microservice is responsible
for its own data model and data because of
which interaction with each microservices handled by different instants and like
in monolithic architecture where we had only
An instant head we have multiple instances for different
different microservices. So we have three microservices here customer Microsoft
waste product Microsoft which and card Microsoft's right? Each of them have
their own instances. They have their own data model
and they have their own data. So this is what exactly
Microsoft's architecture is. Now, let's dig a bit deeper
into its architecture and understand what it is. Now as you can see
in a Microsoft is architecture so which is a small independent
and Loosely coupled. So, let me just tell
you where it is. So with these are multiple so which is right
these A pretty small in size and they're independent and Loosely covered now each of these Services have
a separate code base, which can be managed by
a small development team and it is deployed
independently, right? So this service will have a code bases service
will have a code base. The service will
have a code bit. Similarly. All of them will
have a code base which will be not huge in size. And when you compare it with
the monolithic architecture, all of these services
are running in one instance. I hope you are getting
my point now basically a team can update an existing service without rebuilding in deploying
the entire application. For example, if I have to update
this particular service, I Have to do it
for the other services as well. I can just read deploy
this service independently now services are responsible
for persisting their own data or external State
internal implementation details of each services are hidden
from other services moreover. They don't need to share the
same technology stack libraries or Frameworks is well,
right you getting my points. They might not have
the same technology or same libraries
of the same framework and they have their own database
and things like that. So they are pretty independent
from each other besides for the microservices themselves some other components
appear in typical Mike. Service architecture. So let me just discuss that
so the first part is management. So the management component is
responsible for placing services or nodes identifying
failures rebalancing Services across nodes and so forth
right then let's talk about service discoveries. Now service Discovery
the task of this component is to basically maintain
a list of services and which nodes are located on it enables service look up to
find the endpoint for a service. Let's talk about
API Gateway now, right so API Gateway is
The entry point for clients. So this client won't call
all the services directly write will first go
to this API Gateway which will forward the call
to the appropriate services on the back end, right if I'm a client I'll request
for this particular service then after call the API Gateway and which will in turn call
the service on the back end now the API Gateway
might aggregate the responses from several services and return the
aggregator response. Now, it might be possible
to write a client request for multiple services. So at that time it
will aggregate the results from various services and Turn
the aggregated response. Right? So I hope I am clear
with the architecture. Let us focus on
what are the features of Microsoft has architecture. The first feature
is small focused. So what it means it means that the aim
of microservice Architecture is Simplicity, you know, so that it can be
re-written in maintained without any extra efforts
by the development team, right? That's what I mean
by small focused. The next point
is Loosely coupled. So as I've already
mentioned multiple times at each microservices
independent of Each other and do not need
to coordinate as well. This makes a development
as well as a deployment it real quick guys, right? So if I have to update
a particular service, I'll only update
that so which I won't, you know, update
the other services rights that way deployment
becomes really quick. So that's the big Advantage now, let's talk about
language neutral. So to be a good microservice,
it must be language neutral. So what I mean
by that for example in an application few Services
can be written in Python for fast deployment. Whereas few might
be written in Java because its speed
and extensive libraries. Right. So depends on the Microsoft
Office what kind of programming language
we are using so it doesn't really affect
the other services right now bound it context. So it means that each microservice
doesn't need to understand the implementation of other Microsoft's so
these are few features of Microsoft's architecture. Now, let's talk
about various advantages of microservice architecture the
firstly independent development. So each microservices
can be developed independently where a single development
team can build test and deploy service. I don't need
to explain this much independent development means if I have a product service and I can independently focus
on product service where a team of developers
are writing code for that particular service
testing it and deploying it now independent deployment means that you can update a service without having to redeploy
the entire application bug fixes and feature releases
are more manageable and less risky as well because you have to focus
on one particular service. You have to deploy
update one particular service. You don't have to care
about the other service or the entire application
as such right? So next is Vault isolation. So it is a very
big Advantage guys. It's basically if
a service goes down, it won't take the entire
application down with it. For example,
if my card service goes down. My entire application is largely unaffected
unlike the monastic architecture where if one of my component
goes down the entire application fails to work next is
mix technology start because of this feature teams
can pick any technology which fits best
for their service right and last but not the least
granular scaling which means that Services can
be scaled independently unlike my monastic architecture where you know
after A couple instances. So in order to scale are I can
only scale a particular service if I have to you know, increase the card service
then I can just scale up the card services instead of scaling up
the entire application. Let's let's move forward. So there's a lot of companies
which are using Microsoft which is we have Amazon Netflix. SoundCloud Twitter Who board
PayPal lot of companies, right and why this happens because the applications
become easier to manage when they're broken down
into smaller composable pieces. So without any further delay, let's begin with our hands
on will be using spring boot because it provides a a way
to provide Java applications quickly and simply
through an embedded server and by default. It is version of Tom cap. It will basically eliminate
the need of java ee containers and which springboard we
can expose component such as rest Services independently exactly
is proportionally Microsoft is architecture that we have just discussed in any maintenance
of the components. We no longer make the redeploy
of its consumers. I'll tell you
what exactly I mean, what is the consumer for this lab will be use
Eclipse oxygen and Maven 3? Now to illustrate
the concept of microservice. What we will do will create
3 Maven projects in this Hands-On and each
of them will symbolize back and functionality or you
can say reusable apis and one of them held a composition
fair to put it in simpler way. I will say it will be
a consumer of the other two. So one application
or one service will be a consumer of the other
two Services, right? So we'll be creating
three simple Maven projects that I've already done. I'll just open my clips
and show you that so my first Maven project is basically
diagnosed with Microsoft. He's then we have dr. Microservice and we
have patient microservice. So this doctor microservice is the consumer right and consumer
the other two microservices that is patient and a diagnosis. Alright, so that is
how it is done. Now if I have to explain one
of these Services, let me explain to the patient
microservice first so over here as you can notice that we have
a palme D'Or XML file. So basically this bombed or XML file will stablish
all the dependencies right before we start
coding the first class that we create that we call. Negation will be identical
in all three projects and it only works as
an initiator to Spring boot that we call a Spring
boot application annotation. So that's how it is. If you notice here,
we have application or Java. So it will be common
application or Java and application configuration
or Java the two packages that we have created
will be common for all the other
Microsoft uses as well. So if I show you a doctor's is
well now here also, we have application or Java and application config dot Java
similarly for diagnosis. As well. If you notice we have
both application or Java and the other things as well. Now, we have patient or Java and we have
patient rest dot Java, right? So the patient Java here, we have defined all
the variables like, you know, the email ID of the patient name
and things like that and this patient rest dot Java will be used to provide
the input the variables. I hope you are getting my point
but a patient rest or job is basically
to provide the input. I won't be explained in the code
here in the upcoming tutorials. I'll be explaining the entire
Microsoft which you know, how the code works and I think all the technical
details you can find the next tutorial and this I'm just giving you an overview
of how things work in Microsoft versus and we have this application config class
as well right the package. So let me tell you
why we actually use it is basically it is
a resource configuration class, which is basically
a resource manager responsible for exposing rest services
for application consumers, right so basically for messaging right so
the rest services for messaging and it is a stateless service
for application consumers and we can notice a patient
or Java and giant rest or Java are in the same
package right now. Let me tell you
how I've defined a ports here. So all I have to do
is right click go to properties click
on run debug settings. I mean I go to arguments right so I just have to write - the server dot Port 8:08 one
so you can see that my patient Microsoft is
will be running at a 14-0. It was when I started
let me just start all these Services one by one
so I'll start this first. Let's click on run a spring
boot app similarly click on right click on this and I'll just run it as
spring boot up again, and I'll run this also
as a springboard app. So does that now? Let me just open my browser. All right. So this is for Port 8:08 one writes
my poor a zero eight one is for patient to let me
just click over there. Let me reload this page again. So here I have my patient
Microsoft is similarly. My poor a0 A2 is for diagnosis, right so are high
of the diagnosis microservice and finally my port
8 0 8 3 basically is a consumer. All right. It's a doctor microservice
and in the URL if you notice I have written. Patient ID right diagnosis
and consultation, right? So basically we'll get you know, this particular patient
has been diagnosed with this disease and this
is the consultation right? So, let me just reload
this again for you so I can just go ahead and
change the diagnosis as well. I can make this as to write sobre child
has been diagnosed with a different
disease now similarly if I make it as one she
has been diagnosed with viral fever here, right? So that is what
the difference is. Basically this particular
Microsoft which is a consumer of the other
two Services, right? So you can even think of it
as an e-commerce application. I know it's not of that level
but consider it something like, you know customers
production orders. So this patient Microsoft
which will become the order Microsoft's right and the other two will become
customer and products. So this order Microsoft will be
a consumer of the product and customers a similarly
in this example. We have patient
and doctors we have patient. My resolve is and we have
diagnosis Microsoft OS and we also have
Doctor Microsoft Office, which is actually a consumer
of the other two service. Today, I'm going
to discuss Microsoft versus with spring boot. So let's move forward and have
a look at the agenda for today. So this is what we'll
be discussing today. We'll Begin by understanding. What are the various challenges
with the microservice architecture after
that will understand. What is the need
for spring Boot and how it overcomes the challenges
of a microservice architecture. Then we are going
to discuss a use case that we will Implement
practically in today's session and I will also tell you about
what are the various tools required in order
to execute that use case. So let's begin guys
will first start with what are the various challenges
with microservice architecture. The first challenge that we are going to discuss
is called perceptibility. Now as we know that in a Microsoft is there
are small components to deploy and maintain and there
are many of them. So there are
many small components that we need to
deploy and maintain and at times it becomes very
difficult guys to Monitor and identify problems, right if I take the classic
example of an e-commerce website so over there we have multiple
small small Services running for example the card so which it can be
the product service or the customer service. So there are multiple Services
running and we need to deploy and maintain those services. So at times it becomes
very difficult to Monitor and Aunt if I problems so what we require we require
great perceptibility around all of these components. The next challenge
is configuration management. Now, there is a great need
to maintain the configurations for the components
across the various environments because we have
small small components, right the idea behind
microservices to break down a notch break
down an application into small composable pieces that can talk to each other. So we need to
configure these components across various environments. That is also a very
big challenge guys. Now the next challenge
is debugging now, it becomes very Difficult
to probe each and every service for an error, right? So you have multiple Services
running now to debug error in each of those Services
is very difficult. So what we need,
we need centralized logging and dashboards to make
it easy to debug the problems, right then an excellent that we are going to discuss
is basically consistency now think about it guys. You cannot have a wide range of tools solving
the same problem, right? And we know that it is important
to Foster Innovation, but we also know that it is also important
to have some decentralized governance around The languages
platforms technology and tools which are used for implementing or deploying or even monitoring
the microservices, right? So I hope you
are getting my point. So maintaining consistency
is also a very big problem. Now, the next point
is automating the components. It becomes very difficult guys
to automate everything because there are a number
of smaller components instead of a moonlit that is built
deployment and monitoring. So in order to automate
this entire Cycles, it's very difficult. So these are the challenges with the micro
service architecture now, let us see the solution
so It's spring boot now spring boot enables building
production-ready applications quickly and provide
many non functional features. Let me discuss few of them. So the first feature that I'm going to talk
about is embedded servers. So these servers are easy
to deploy with the containers. Then the next point is it helps in monitoring
multiple components. So you have various various components
are various Services running. So in order to monitor
those Services we can do that with the help
of spring boot then and finally it facilitates in configuring
the components externally, so we saw whatever the Changes
were right the consistency perceptibility configuration
management Automation and all the challenges that we have just discussed
were completely removed with the help of spring boot. So let's move forward and now we are going to focus on
how to build a top sports bra. So this is our use case
guides will be building a top sports brand. Let us see how we
are going to do that. So in this pre-boot
microservice example, we'll be creating
top sports brand application, which will have three sources so you can see it
in the diagram is well, so we have three services
here one is Eureka's over then we have
item catalog server. And then we have
a church service. So these are the three services
that will be running now. Let me discuss each
of these one by one. So the first thing is
Eureka service now this service will register every microservice and then the client
microservice will look up to the you take us over to get a dependent microservice to get
the job done for I mean by that is a user will approach
this Eureka service which will have the other
two Services registered with it. So this is basically
called a registry service in this industry service. We have the other two Services
already registered so based on what the user. Zur want Eureka server will get a dependent microservice
to get the job done. So I hope you have understood
that now let's move forward and we are going to focus on
what our item catalog service. So item catalog service will generate the list
of sports brands which are popular in the market. So whatever the list
of sports band rather popular it will generate that and then the edge service
is also pretty much similar to the Standalone
item catalog service. However, it will have
fallback capabilities which prevent the client
from receiving an HTTP error when the service is
not available right now. We have understood
this architecture. Let me just repeat it once more. So we have a Eureka service
which is owned by Netflix. And this is basically
a registry service and we have the other microservices
registered in this service. The item catalog service
will have the sports brands. Then the edge service
will basically give us the op sports brand will filter
only the top sports brand. This is how the architecture of our a spring
boot application is. So we have given the numbers
as well in the diagram. So the first thing
is it will register the other two applications
in Eureka service. So first will register the eye. Item catalog then we
will register the edge service then will produce a sports
brand names item catalog service and the edge service will filter
only the top sports brats. So this is what is going
to happen in today's use case. Now. Let us see what are
the tools I'm going to use. So I'm going to use Java 8 Eclipse IDE oxygen
and the spring tools. So let me just quickly
open my Eclipse IDE, and I'll explain
you the code there. So this is my Eclipse IDE guys
and over here. I've already written the code in
order to execute the use case. I'll just take give
you a walkthrough of what I've done here. So I have all
the He's always had that I mentioned in the slide. So we have Eureka service. We have H of s and we
have item catalog. So start with
Eureka service first. I've already written it. So I'll just quickly show you
how you can do that. Click on new over here. Go to other and over here select
spring starter project click on next and just
a couple of minutes and then just give
the name to your service and then go ahead
and click on next and the dependency. So we want the Eureka server as a dependency in this
finally click on finish. So that's all you have to do
and real fine you Lakers over already created? And over here, the first thing that I wanted to show you is
application properties so over here I've mentioned the port
I've modified it a bit. So what modification
I've done I modify the file to add a port number and I've disabled the registration the port number
is eight seven six one and this and I've disabled
the registration right next what I'll open, I'll just open your a car service
application dot Java, right? So for that so this is
the file that I was talking about and over here. I've added a couple
of notation forces enabled you. Above the spring
boot application. So this Eureka server
that you are seeing. I've added that above
the spring boot application. Right? So this annotation
will configure a registry that will allow other
applications to communicate since I want the other applications
obviously communicate with it. So it will basically
configure a registry and it will allow the other
applications to communicate so that's all
for Eureka service. Let me just go ahead
and quickly run it to show you how it looks
like in the browser. So I'll just click on run
as a springboard application and you can see
that it has started running out. Ready, and I'll just
quickly open my browser and at Port eight seven six one so you can see that Eureka service is running
at Port eight seven six one, but currently you can see there are no instances which
are registered with Eureka. Right? So we need the other two
services to be registered here. So this is it for Eureka server. Now, let me talk
about item catalog. So for item catalog, what we need to do is
again click on new. Go to other
spring starter project. Like we have done it
in Eureka Services. Well given name whatever name
you want to give them in the dependencies are
a lot of dependencies that we need to import. So let me just talk about that. The first thing we need
to import is an actuator, right? So we need to click on this
and we need to import this. So what is an actuator
it is a feature that will help us
to Monitor and manage our application after actuator. I need to import
Eureka discovery. Yeah, so I need to import
this Eureka Discovery for Service registration since I want my service
to be registered in the Eureka server. So for this I need to impose
this particular dependency. Then I'm going to import jpa which is basically to save
or retrieve data after that. I'll import H2,
which is an in-memory database. All right, then I'm going
to import the rest repositories. I did these repositories are basically to expose JP
repositories as rest endpoints. Then I'm going to import web. Alright, so here we can see
that we have web here. So web will basically is nothing
but staying Embassy and embedded Tomcat then I'll import
Dev tools they have tools. All right. So this is to Auto reload
the application when there's any change in the file. Now, I'm going to import lombok
in order to you know, just to reduce
the boilerplate code. So since I've already done that I won't create
another project here. Another service are basically so
let me just give you a walkthrough of the code
that I've written here. So first, let me show
you the item catalog. application dot Java file So
this is how it looks like first of all the couple of annotation. So enable Discovery
client is basically to register my application
in the Eureka server. Then we have a one more annotation
springboard application. Right? And so after that
what I have written, so this is my main class. All right, the main class will
be executed for some application and this is responsible
for item catalog execution the item catalog
application execution. All right, then I have purel notations at the rate data
all argument Constructor. So in order to explain You
that let me just tell you what a Droid data is
a convenient shortcut annotation that bundles the features
of to string, you know equals
and hashcode getter Setter required argument
Constructor together. Alright, so people who are familiar with Java know all these annotations then
the second generation I'm using is all argument
Constructor generator. So basically it will generate
a Constructor with 1 parameter for each field in your class. All right, so Fields marked
with at the rate not null result in a null checks
on these parameters, then we have no argument
Constructor will generate a Constructor with
The no parameters. Yeah, after that we have
at the rate to string. So it will also pretty easy. So either a tostring
is basically, you know, it gives you the facility so that you don't have to start
a debugger to see your Fields. You can just let lombok generate
a tostring for you and then the entirety is basically is a lightweight
persistence domain object typically an entity
represents a table in a relational database and each entity instance
corresponds to a row in that table. So the primary programming
artifact of an entity is the entity class. Although entities can use
Helper classes as well. So this is
about the annotations. So the next thing that
I'm telling you about is a parameterised Constructor
of the item class. So let me just write
that here as well. So it is a bad a meter erised
Constructor of the item class. And here we are defining the class members along ID
and the string name. So next we have
a repository rest resource. So basically we have
an interface item repository that we are extending
with JP repository over here what we are doing we
are defining an implementation of the command line. Runner interface that we need
to override the run method and this method will be executed after the application context
is loaded and right before the spring application
run method is completed. So this is basically
generate the key value pair using the for each Loop and we are basically overriding the run method
to print our key value pair. So that's what we
are doing here. So, I believe you
have understood this code or people who are familiar
with Java for them. It's not a tough task, right? So it's a pretty basic code. So let me just say we
are creating an item entity a JP a repository for it and we are also creating
a command line burner to populate database
with the default data. All right, so that's
what we have done here. Now let me go to
the application dot properties and I wanted to show you
a couple of things that so yeah in this application dot
properties what we have done. We have added an application
name in the file to display the Eureka service
and set the port to 8:08 it now also
in the cloud properties file. So let me just show you the
cloud properties file as well. So you need to add all of these things in your Cloud
properties file is well. So this is the Eureka
instance hostname. Then we have the non
secure Port mention here the metadata map
to the instance ID. Over here we have it. Then you record
or instance lease renewal interval in seconds is
5 then Eureka client region, the default reason registry fetch interval
seconds is we have given it as 5 so all of these things
will be available with you. If you can mention your e-mail
ID in the comment section, you can find
the entire code there. So mention your email ID
in the comment section and will reply with the entire
code use in the video since I've configured Port 8:08
to let me just go ahead and quickly run this first
I'll clean it using Maven. So I'll just click
on Maven clean. And now I'm going to build
it using Maven again. So just click on run as go to. Maven build over here
type string - boot: run and just hit enter. So let me just go
to the you rake us over. Let me just refresh
this link one, right so you can see that item catalog
Services already registered my Eureka server now. Let me just go
to the port 8:08 to / items So it is displaying
basically all the items present in my item
catalog servers, right? So let's just go through it. It's pretty easy guys. So we have the name
of the sports brand right then we have again a bad boys. And you have Air
Jordan Mike added us although sports brands
that we were talking about and the size of the page
total elements and everything. You can have a look
and just play around with it. So I'll just go back
to my Eclipse IDE once more so now we are going to create
an edge service now add Services have told you
it is pretty similar to the Standalone item. So we That we have created. However, it will have
fallback capabilities which will prevent the client
from receiving an HTTP error when the service
is not available and how we are going to do
that similar fashion. Like we have
created item catalog. All you have to do is click
on file go to new. And go to other select
spring starter project here. Click on next give
a name to your service. Whatever name you feel like then
go to next then over here. We need to add dependencies. So let me just tell
you about that. The first dependency we
need is Eureka Discovery. So just type here Eureka
Discovery select that right. So this is basically
for Service registration like we have done
in the item catalog Services. Well, so this will be registered
in my Eureka solo. Then we are going to add
a fiend dependency. Let me just type that first. So yeah. Let's begin dependencies. Basically a declarative
web service client. All right, and now
once it is done, we are going to add Azul. So basically zul is provides
an intelligent routing system. So just click on Google as well. Once that is done. I am going to import
rest repositories. So these rest repositories
are have told you earlier as well is Bill expose the JP repositories as
rest endpoints then I'm going to again ADD web as well. So I've done that in
the item catalog as well. So just click on web. It is basically a spring MVC
with spring MVC architecture and embedded Tomcat. Right? So like we have MVC and MVP
architecture then I'm going to type in here hysterics. So this historic just let
me just check it once yeah, so it is a circuit breaker
to stop cascading failure and enables resilience, right? So that's what it is used
for then let's go ahead and add one more dependency. That is lombok. Lombok is basically to reduce
the boilerplate code that I've done in the past. U.s. Project as well. So I'll just click on cancel because I have
already done that. You can just go ahead
and click on finish and you will find the HOV is present here
something like this, right? So now let me just take you
through the edge Services well. We know that the item
catalog Services running on Port 8:08 to so
what we need to do. We need to configure
this application to run on a different port. Ah, now, this is pretty
obvious guys, right? So let me just open
this application dot properties and you can see
that I've configured at Port 8 0 8 9 right and I've given
the application name for a similar reason basically
to add my service in the Eureka. So right now I need to create
the cloud properties file that I've already done right? You can see it over here
the cloud properties file. It is already present. I need to add some code here that I have done it
in the item catalog Services. Well, so this code you can again find it once you you
know ba mention your email ID in the comment section will
reply you ASAP with the code. All right. All right. We just open Edge service
application dot Java file so that I can find it here
right now in order to you know enable Fein hysterics and registration with
the Eureka server add the appropriate and notation. So what are the properties
that annotations? We have enabled the inclines. We have enabled circuit breaker
we have discovery. Giant Zuul proxy and springboard application
obviously, right? So these are the annotations
that we are going to use and after that let
me explain you the code. Although it's pretty
simple guys people who know Java will find it
really easy to understand. So this is again the main class which Java will basically
execute the first in my application, right? Then I have a couple of Getters and Setters
methods defined here. I have an API adapter that will return the array list
of our items and the finally in see the public
collection item good item that you can see it in the end. Yeah, this is basically
for collecting items and adding it into a list. Finally. This private. Boolean is great item. This will return true and false if the item is not available
for a particular brand. All right, so this is
pretty easy guys now over here. I've created a D2 now. Let me just take you
through the core once more. So if you notice here, I've already created
a dto and item detail which means data transfer object
in this same file and at the long box
at the rate data will generate to In methods we Getters and Setters
the appropriate Constructor. All right, then I've created
item client interface. So if you scroll
down you can see that we have an item client
interface so we can see that we have
an item client interface that uses Fein to communicate
to the item catalog server. So we have talked
about item catalog service. So this item client interface
will use steam to communicate with the item catalog service. Right? Then we have a rest controller below the item client so over
here we have the rest controller that will filter out. Less than top brands
and shows a top brands endpoint. So slashed our
top brand endpoint. So it will filter out
the Brand's right it will it will add a filter
to all the brands that we have in order to get
the top brands, right? So that's what the rest
controller will do. Now what I'm going to do, I'm going to start
this service for you. So I have configured
this service at Port 8 0 8 9. So, let me just quickly go
ahead and run this for you. I'm going to first click on run
as Maven clean. So I'm going to quickly
run this as a springboard. Up and let us see what happens. All right. So let me just quickly open
the you take us over. Right and I'll just refresh this and you'll see that there are
two instances currently registered with Eureka, right? So you can see that there are
two instances currently registered with Eureka. Now, let me just quickly go
to a particular oat. That is a 0 8 9 so I'll just
type in here localhost:8080 9 / top - brands. And here we go,
so we have got the top brands. So we have lining Puma Bad Boys
in Air Jordan right now. What I'll do,
I'll just quickly shut down the item catalog service
application for that. Let me go back and I'm going to shut down
the item catalog application. So this is what we have done
in this particular use case. Now if we shut down the item
catalog service application, you'll get a 500 internal
server error, right? So just go ahead and try
it yourself and let us see if you get that or not. It's pretty easy guys pretty
basic application that we have. He added but a lot of things
to learn from today's session. I'm going to focus
on Microsoft restraining. So without any further Ado, let us move forward and have
a look at the agenda for today. So this is what we'll
be discussing today. We'll Begin by understanding. What is the use case that we are going to implement
in today's session after that. I'm going to tell you
about the few Basics which are required in order
to execute that use case. Like what exactly
is microservice? What is monolithic architecture? What is darker and how Docker
can be used in Microsoft? Isis and finally
I'm going to tell you how to implement the use case
using Docker after that. I'm going to discuss
the course content of microservices training
provided by a director. So let's move forward
and we'll discuss the use case that we are going to implement
in today's session. So this is a problem statement
of I use case guys. We have a node.js application and mySQL database running
in the same instance or you can say
in a local laptop. So this is a typical example
of a monolithic architecture. So let us just focus on few problems
with this architecture and then we'll see what is
the solution to it. So let us now discuss the problems associated with
this monolithic architecture. I'll just give you
a small introduction to all of these challenges later on. I'll discuss it once more when I'm talking
about monolithic architecture. So I hope that is fine
with you all. So the first thing is large
and complex applications. So if the size
of our application is pretty large and it becomes
really complex to understand and modify such applications when you use
a monolithic architecture, you'll actually understand
that when I'm talking about monolithic
architecture in detail, you'll understand why are
these problems there with such an architectural pattern? Then it also leads to slow
development as the application in the respective teams grow the application becomes
difficult to understand and modify and also the larger the codebase
it leads to slower ID. Then at the same time. It blocks countenance
development as well and it is pretty unscalable. So each copy of the application instance
will access all of the data which makes caching less effective and
increase memory consumption and input-output traffic
also different applications components have different
resource requirements. For example, Euro
one might be CP. Pensive while another
might be memory-intensive. So with the monolithic
architecture we cannot scale each component independently, then it is pretty unreliable because of the tightly
coupled components that we have here. All right. So if any of the component goes down the whole application
will fail to run and then finally it
is inflexible as well. So with more literature
architecture, it becomes really difficult to adopt
new Frameworks and languages. So this is the problem statement
of a use case guys. Let us see what are the solution
to such a problem. So it is nothing
but Microsoft has now what I'm going to do here
is I am going to To create two separate Services one
called user service. Another is test database running
on different Docker container. All right. So with this what we have
we have separate services or you can see we have
separate microservices compared to a monolithic architecture that we had just seen so what I've done here
is this monolithic architecture where my node.js and MySQL were running
on the same instance. I've divided them into two separate microservices
one is user service. Another is test database and both of these obviously are
running on a different doctor. And then so this is nothing but
an example of Microsoft Office. So this is a use case that we are going to implement
in today's session guys. So now we are going
to compare before and after Microsoft's is
basically we're going to find out the differences
between the micro services and a monolithic architecture. So let's begin guys. So let's take
the classic example of an e-commerce website now
from the diagram also, we can observe that
in the monolithic architecture. We have all the features running
at the same instance. For example, we
have customer service. We have product service we
have card service, right? All of these instances are Lying
on a single instance and sharing a common database. All right. So this is a typical example
of a monolithic architecture, but then with microservices each feature was allotted
a different micro service which handles their
own data and performs different functionalities. All right. So this is the basic difference
between the monolithic and Microsoft's architecture. So the idea behind Microsoft, which is that few applications
become easier to manage when they're broken down
into smaller composable pieces that talks to each other. So that is what
exactly microservice is. Let's move forward and we are going to focus
on I guess always architecture. So we are going to discuss it
in much more detail. So let me discuss
this architecture with you now over here. We have different clients coming
from different devices and they're trying
to use services such as search build configure
another management capabilities. Now, all of these services are
separated based on their domains and functionalities and a further allotted
to individual microservices. So you can see we have
microservice a b c and d probably this is
for your search service. This is for your build services
for configure like that. We have many other
services as well. Now these microservices have
their own load balancer and execution environment
to execute their functionalities and at the same time captures
data in their own databases. So microservice a will have
its own load balancer and execution environment and we'll have it its own
database as well similarly for other microservices. Also now all the microservices
communicate with each other through a stateless server, which is either rest or a message bus now the all the
functionalities performed are microservices are communicate
to the clients by API gate when a client gives a request it
will first go to the API Gateway and all the internal points are
connected from this API gate. So anybody who connects
to the API Gateway automatically gets connected
to the complete system. So I believe guys have given
you a good introduction to what exactly are microservices. What is monolithic architecture
why we use Microsoft Office is what are the various challenges
with monolithic architecture. Let's move forward and now we are going to discuss
what exactly is darker now, what is the occur if I have to give a definition
I would say At its heart the docker is a software which lets you create
an image image is nothing but a template
for a virtual machine and then run instances
of that image in a contain. So that's what Docker is. Alright. I have a question
popped on my screen. This is from Quinn. He's asking can you
tell me the differences between virtual machine and
Docker and which is better find so bitch is better. I would say talker. Let me just give you
a few reasons for that. First of all Docker is
pretty lightweight, right. You have all the binaries
and libraries there in your Tanner required
for your application which can be a Microsoft
Office application as well. Plus it's pretty lightweight plus it doesn't use as
your guest operating system. It uses the host operating
system unlike the virtual machines and you don't have to pre-allocate any Ram
in the containers and like your virtual machine. So, I believe you I've given
you enough differences between the two already is
Alpha is the answer now. Let me just take you
through the diagram that is there in front
of your screen. So here we have a host
operating system on top of that we have dr. Engine, right? So we have couple
of applications running on Top of Docker engine so we have couple
of containers as well. Alright, so basically what we have done
we have containerize the two applications
into different containers. So we have binaries in libraries
along with the application in one container and similarly
for the container to as well. We have similar configuration. So all the binaries
and libraries required for an application of present
inside a Docker container. All right. Now, let me just go ahead and discuss few
components of Docker. So I'm going to start with
what our Docker images and what are Docker containers. So Docker images
as I have told you are reading. A template which are used
to create containers now Docker maintains vast repository
of images called the docker Hub, which is nothing
but a git repository of Docker images now
with Docker images, we can create Docker containers. All right, and they
contain everything required to run your application. Now, this is all
about Docker images in Docker containers. So let me just quickly open
my Virtual Machine and I'll show you
a few basic commands of docker. So this is my Center as
virtual machine guys over here. I've already installed Docker. So let me just go ahead
and quickly start Docker. So the command to start Docker
is systemctl start talker. So it has started now. Let me just clear
my terminal again. And now I'm going
to try out few commands and then exit the container. So now what I'm going to do
is I'm going to show you how you can pull images
from Docker Hub. Right? So I'm going to pull
Ubuntu image from Docker Hub. So let me just tell you
how you can do that. All you have to do is Click. Occurred pull Ubuntu
that's all you have to do. It will first check
the local system if there are any images available if there are
no images available, then it will go ahead
and check it and Docker Hub and pull then image
for us from Doc it up. As you can see that it is pulling
from Docker Hub right now because it couldn't
find it locally. So it says that downloaded
newer image for Ubuntu latest, which means we have successfully
downloaded the Ubuntu image. Now. Let me just hit a command
called Docker PS and this will give me all
the images all the containers which are there
in my system right now. Now if I have to
run this container, what I have to do is I have type
in head Docker Run - it and at the name of my image or you
can even use the image ID. So I am in open to container right now so over
here you can you know, try out a few doc it commands. I'll Exit from here
now and yeah, let me just clear
my terminal again. So what we have done we
have basically pulled an image of Ubuntu from Docker Hub. And then we build a container
from that image. That's what we
have done till now. Let me show you how Docker Hub looks like so
for that I'll open my browser. Now this is the official website
that is half doctor.com. You need to go
to this particular URL and you can just go ahead and create an account
for free and get started. You can find all the images plus you can upload
your own images as well. If you want just going to type
my username and password. I'll be logged into Docker Hub. So this is how a doctor
of looks like guys. We have couple of tabs
here repository Stars contributed create a repository create an organization
explore repositories. So just go ahead
and play around with it and You'll understand it. I'm just going to tell you
how to search an image here. So if I want anyone to image, this is the official
Ubuntu image here guys. Similarly, you can go ahead
and search whatever images that you want. All right, so let me
just close it for now. So we have just discussed
what exactly is darker what our images and what our containers
I've also executed practically. I told you how you can pull
in a bun to image and create a container from that. Let's move forward and we'll
focus on Docker registry. Now, I won't spend a lot
of time on Docker registry because it is nothing
but a storage component of Docker images Docker
is own cloud. Depository for Docker
images similarly, you can have either public
or private repositories on Docker Hub as well. So it's basically
a storage component for all the docker images. Now, I'm going to talk
about Docker compose because this is what I am going to use
in today's session. Now what exactly
Docker compose has when you have
multiple containers then Docker compose makes it easier to configure
and run applications that are there
in those containers what I mean by that consider
the example that is there in front of your screen. So imagine I'm Able to Define
three containers one running a web app another
running a post Grace and a third rate is now
all-in-one yamen file and then running
those three connected containers with a single command. That's what Docker compose is. So we have three applications
and we write the configurations for all
of these three applications. We have defined all
of these three applications running on different containers
in a Docker compose pile. That is Docker compose
or Yaman and then with one single command, I can run all
of these three containers. That's what Docker compose is. All right, so I'm
going to show you. Really how it works. Let's move forward for now. Now this is basically a use case
of how Docker can be used in an industry. So I'm going to write a Docker
file complex requirements for a Microsoft Office
in an easy to write dockerfile. Now from that Docker file,
I can create Docker images and intern run as
many Docker containers as I want now that Docker image, I can upload that onto the docker hub from
which various teams beat staging or production can put that image and prepare as many containers
is they want now whatever was there in my Laptop is replicated in my staging as well as
in my production environment or it or you can say
throughout the sdlc. So this is how you
can use Docker. Although there are multiple
use cases right available. So you can just this is one way
of using Docker guys now doctor for Microsoft Office
is so just an example how we can use Docker
for microservice. Basically imagine. We have separate services
for an online shopping service. We have account service
product catalog card service and orders over right all
of them have their own database so we can turn all
of these services on a different Docker container. I'm going to show you
practically how you can do that. So let me just quickly go ahead
and discuss few advantages of Docker in Microsoft versus
what are the various advantages that we get when we run Docker with micro Services the First
Advantage is packaging. So a piece of software usually consists of
a number of components. Now these components
may be bundled together or distributed separately and I
usually themselves composed of various files. This can include executables
binaries documentation, etc. Etc. Now, Make software distribution
convenient there must be some way of assembling all
of these pieces together into one cohesive whole so
traditionally this was done using one of a number
of mechanisms like zip files or tar balls Debian
or RPM packages or language specific packages, for example, npm python
Wheels rubygems, etc, etc. So these all have
their own trade-offs, but they have
one thing in common. They do not solve
the entire problem. Zip files need an agreed-upon
format for their contents, Debian and RPM packages
are os specific. Vic and notoriously
difficult to work and the rest are
the language specific systems that do a proper job of handling application dependencies
outside of the scope of their language now Docker makes it possible
to achieve the granularity of portable microservices
through its packaging. So I hope you got my point now,
let's talk about distribution. So in order to share
software with others or to deploy some way
the software package needs to be tracked in a central place and accessible across
the organization now Docker solve this problem
by providing a standardized a Hi for a registry Service as well as an open source
implementation for now. The standard Docker
registry is not quite user-friendly right and lack
some features available. In other systems
such as yam and app. However, this will
improve with time and that will happen definitely
guys runtime isolation. Now, if you worry about
efficient resource utilization, you're likely tempted
to run multiple microservices per host or right now. This is definitely doable
but can present some challenges. Let me discuss those challenges. So I just discuss
one such challenge, which is called. Dependency management, for example if service one
requires the library with version one point XY service
to require the same library, but with an incompatible
version 2 point x will likely run into a problem. If you are using
a package manager that installs packages
system-wide such as after yum some ecosystems provide a way to isolate
the application environment into a specific directory
one example of this is pythons virtual environment node.js npm also does this
by default as well? However, the isolation
offered by these system is far from perfect
any dependency on Freeze or executables outside of the language is
sandbox can still result in conflicts another issue that comes up and running
multiple Microsoft offices on the same host is protection
against Rogue processes that use more than their fair
share of memory or CPU prior to container technology
or Docker containers. The main way to achieve
this would have been to run multiple virtual machines right now Docker solve this
dependency isolation Problem by packaging the entire OS image along with all
the dependencies. It solves the The isolation
Problem by providing and enforcing explicit CPU and memory constraints similarly
Dockers runtime isolation allows you to run
multiple API microservices side by side on the same host
with greater ease and maintainability. So different teams working on different microservices will
not affect the runtime of others if I have to give
an example think of it, like if a revision of an API is needed
the APA microservice running in a Docker container
can be redeployed without affecting other apis and finally the
installation process lasts. Wantage of Docker
in Microsoft Office, is it how simple it is to install you
can just go ahead and refer if you installation videos. So these are various advantages
of using Docker n microservices. Now, let us discuss
the implementation of the use kit already told you
what I'm going to do here. I have a monolithic architecture
that has node.js and MySQL running
on one single instance. I'm going to create
two microservices user service and database running
on two different containers, and I'm going to run those
containers using Docker compose. I'll just quickly open
my Virtual Machine and I'll show you how I have implemented
this use case. So this is my Center is
virtual machine again guys. Now for doing local development
will need to install MySQL and create a test database for
us now for local development. We need to install MySQL and created test database now
creating a local database and running scripts
on it is an easy start but can get messy lots
of uncontrolled stuff going on. It might work. We could even control it with some shell scripts
checked into our repo, but what if other I was
already have my SQL installed. What if they have a database
already with creative name users which we want to create. So because of all of these reasons we
are going to create a - database server n Docker. So I'll just tell you
how to do that. So this is a great talker use
case guys be might not want to run our production
database in Darker, but we can spin up
a clean my SQL database in no time as a Docker container for development leaving
a development machine clean and keeping everything we
do controlled and repeatable. So in order to do
that that the command that I'm going to type in
here is pretty easy guys. Let me just go ahead
and quickly do that. So it is Docker Run - - name now after give
the name to my database. So let that be DB
then my SQL password. I need to give root password. Which is equal
to 1 2 3 whatever password that you want to give
just go ahead and do that now Define a port here. So double 3:06 of my host and I will 3:06
of my container as well and the image so I just want
the my SQL: latest image. All right, so it's pretty easy. So here we go. So that started now it
is giving us a few warnings. You don't need
to worry about that. So this starts a my SQL instance
running allowing access through port double 3:06 using the root password
1 2 3 so we know that Docker and tells that the engine we want
to run an image and the name of the image is MySQL: latest. All right, so let me just
quickly open one more Tab and over here. What I'm going to show
you is that image that we have just downloaded. So this is the name
of our image. This is the port plus we have downloaded created
about a minute ago, right? We can find all
the details here now. I'll do let's connect to
this image and see what's there. Alright, so I'm just going
to type in here Docker execute - it the name of my image is
DB slash bin slash bash. And here we go. Now over here
if I type here my SQL - user that is root. And the password
is one two three, so you can see
that so over here. I will just type
my SQL databases. Semicolon so my SQL
database I'm sorry. It will be show
databases by mistake. I've typed MySQL databases. So here it is. You can see all
the information here. Right? So what we did we basically
executed a talker exe see - it´d be tells Docker
we want to execute a command in the container name DB we can also use the ID or just the first few letters
of the idea is well and - it ensures that we have
an interactive terminal MySQL - you wrote - P 1 2 3 We have given
that is a command. We actually run as
a process in the container which in this case is just
the my SQL time so we can create databases tables users. Whatever we need. Basically now, let me
just move out of this. Let's type in here exit
and one more exit. Alright, so we're done now
now running my SQL inside a container has already
introduced, you know, if you Docker tricks, so we are running MySQL
inside a Docker container. So now what we need to do
is we need to create a test database folder with a script to start
the database stop the database and set
up the test database. So let me just tell you
what I'm talking about. So I'll just go
to a particular directory now, we'll have to create
a test database folder with a script to start
the Database Top the database and set up
the test data now for that what I will do I'll just
quickly go to a directory that is documents
over here are enter. So this is my application guys. Let me just clear
my terminal now over here. I Directory called test database
so let me just show you that me clear
my terminal so over here I have three scripts one is
to start the database that is start out. Sh. Another is to stop the database. And then the final one is
to set up the database is well. Now, let me just show you what I have written
in each of these files. So let me just start with the startup
script start or sh and you can use
whatever editor you want. You can even use a cat command that will display it
on your terminal itself. So this is a script to start
my S database right? It's pretty self-explanatory. You can go ahead
and Have a look at this. All right. So this is my startup script. Now. Let me show you the setup script
that I'm talking about. So I'm just going to do a cat
command here set up dots equal. So this has all of my data. So it has my email addresses and various phone numbers
and things like that. It is available here. This is my setup script. Now, what I need to do is I need
to create a stop Crypt as well. Stop dog. Sh, so here we have
stopped the database and remove the container
so docker Stop DB and Docker remove DB. So before removing
any container, you need to first stop it and that's
what we are doing here as well. And then we are removing it r m stands for removing
the database now. Let me clear my terminal so we are done with wrapping
up the test database now. We need to create
a Microsoft offices in node.js. So this video basically talks
about how we can use Microsoft versus with Docker and what exactly are
Microsoft versus I won't go into too much detail
of node.js application and I'm talking about so let me just highlight
the areas and takeaways so Just go to a particular directory
called user service and let me just clear my terminal so
over here you can see that we have multiple folders
and files present here. So starting from
package dot Json. So this is basically used for dependencies and metadata
then index dot JS is nothing but a main entry point
of the application. So we have API as well. So this API file
includes our apis and the API test then we have
a config directory as well. This is basically
the Enthusiasts configurations of our application then we
have the repository directory which provides the abstraction over our database and then we
have server directory as well that will contain
the server setup code. This is how we have created
the node.js application. I mean just clear
my terminal again. Now if you want the code
for this application again, you can find it through the link
that is present in the chat box. And if you're watching
this video on YouTube, you can mention
your name and email ID in the comment section will
reply you ASAP with the code. So this application that I've built here is
basically a allows us to get all the users or to even
search a user using the email. So in the set of the SQL file, we have seen that we have given
all the data the email address in the phone number. So this is what
my application is all about. It's pretty basic but it's
very good example to understand why we should use Docker
with Microsoft versus right? So now let me just
hit few commands. So now to start that I'll just use a startup
that sh script that I've written and here we go. So it is waiting
for the database to start up. So it is done. Now. We have started
our test database. All right. So in order to stop it, we can just use a stop script
that is dot slash stop door. Sh and that's all we have to do. All right. So let me just open
one mode tab here so over here, I'll just run
my node.js application. So let me first go
to that particular directory. So all I have to do
is here npm install. All right, so this will set
up everything for me. So it is up to date in
four point eight to six seconds and the next command is
to start my application. So all I'm going to type
in here is npm start. So service started successfully
at Port 8 1 2 3 now, let me just open my browser
and I show you how the application looks like. This is my browser guys. I'll just go to Local Host Port
8 1 2 3 / users. So here we can find all
the users with the email ID and phone number. So this is how Our obligation
looks like guys. So now I'm going to tell you how to dock your eyes
are Microsoft offices. So here we have a micro service which we can run on
a development box as long as it has a compatible version
of node.js installed. What we would like to do
is set up our service so that we can create
a Docker image from it. Allowing us to deploy
our services anywhere with suppose Docker and one way to do is
to create a Docker file. So as I told you earlier is well
during the use case that we write complex
requirements for a project or a Microsoft ways and an easy
to write Docker file. So this Docker file is what
I'm talking about right now. So a Docker file is recipe
that tells Docker engine how to build your image
will create a simple dockerfile in US user service directory
and start to explore how we can adapt
it to our needs. So I've already done that. Let me just quickly show you
where it is present, so So just quickly go
to that particular directory where I've already
written that yeah. Let me just hit an LS command
and you can find that we have test database and user service here
as well apart from that. We have a composed or camel file
and integration tests, which I'm going
to tell you about data. You don't have to worry
about it right now. Let's talk about Docker file. So we'll go
to this user service. All right, so let
me just go there are my terminal and you can see that we have a dockerfile
present here as you can see that we have a Docker
file present here. So let me just Quickly show
you the contents of this Docker file. So what we have done here,
first of all, we are telling the occur
to use note for as base image CMD
command tells Docker that this image should run
the node executable when the executable terminals
the container shuts down. Then what we have done
we have made use of add command to copy everything. Alright, so you can see that we have an add command
here to copy everything and then current directory to a folder
in the container called app. We then use run to run
a command in this image and the image which
installs are modules. And finally, we expose
the server Port 8 1 2 3 telling Docker we intend
to support inbound connections on 8 1 2 3 then
run us over code. So this is how our
dockerfile looks like now. Let me just go ahead
and close it. Similarly. I have written the dockerfile
for my test database as well. So let me just quickly go
to that particular directory. So here in the test database
we can currently see when we hit analyst command that we have two files one is
dockerfile set up dot SQL file, but I have actually told
you to create start dot sh. Top Dog sh is well along
with Theta dot sequel. There was no talk of 5. So now that we are not familiar with Docker we can improve
on this looking onto my SQL image documentation
on the docker Hub. There's a note
which tells us the dots equal or dot SSH file added to the
images folder will be executed when setting up the DB. So what I have done basically
I have replaced my start dot sh and stopped or SS scripts
with Docker file. All right, so let me
just quickly show you how the dockerfile here. Looks like it's pretty easy. Although I let me
just open it through GL. It so when use my SQL 5 as
my base image after that. I have given the password
for my database then the name then the surveys and then the MySQL password password
is 1 2 3 add setup dots equal to Docker entry point. I need DB dot d so over here. I've just written
that to use MySQL 5 as my base image then provided the root password
database name user service. Then we have provided
the bicycle password and then we have used
the add command. Let me just quickly save
it and Close it. So that was pretty basic guys
writing a Docker file. Now. Once we have written
these Docker files, what we can do is we
can make use of a command called Docker Bill -
T Test database so Docker Bell - T Test database. So this command Docker Bill - t-test - database will actually
build a new image from the dockerfile
that you can see over here. Right? So it will build a new image from that particular
dockerfile similarly if I type in here
instead of build If I type in here Run - I T Test database. So this will run a container
with this image. All right little basically
ran container with this image the previous Commander. I've showed you will build
an image from the dockerfile and this will run a container
from that particular image. This is why we use
a Docker files. Let me just quickly go ahead
and clear my terminal and now I'm going to talk
about composing so building and running each container
is still somewhat, you know time-consuming we can take things a step
further with dog. Compose tool which have discussed
during the slides as well. So Doc is composed
lets you create a file which defines each container
in your system the relationship between them and build
or run them all now, what we need to do
is create a new file in the root of s
project called Docker - compose dot Yaman. So it's a yam elf. I'll let me just go back and hit an LS command
here and you can see that we have dr. Ivan composed dot
HTML file present. So let me just quickly take you
through that particular file. I'll use G edit
in order to you know, open that file you can use. Whatever editor or you can even
use the cat command to open that on the terminal and means
increase the size of it. Yeah, so I have written
all the doctor files that I first want to build
and create an image and linking the different Docker images
or the docker container. So you can see that I have Services
here user service and build will basically I
need to specify build value for each of us always
tells Docker way to go and find that
particular dockerfile. So the first one is
dot slash user's - service the name of the container
is user underscore. Service and the port
that is present here. It should be linked
to my database right depends on the database environment is database underscore host
is equal to D. Be similarly. My database image can be built
using the dockerfile which is President test
underscore database. So it is pretty basic. Let me just quickly save
it and close it. Let me just clear
my terminal again. So I need to sign in as
a root user for that. I'm just going to type
in here the password. So now what I'm going to do, I'm just going to type in
here Docker - compose build. So this will build
the docker images for me set is successfully build now. Let me just clear my terminal and now I'm going
to run this application. So for that I'm going to type
in here doc it - compose up. That's all I have
to do and here we go. It's always started successfully
running on Port 8 1 2 3. So let me open
my browser and check whether it's working or not. Local Host 8 1 2 3 / user. So as you can
see that application is working here here. I have all the email IDs
and phone numbers which are there
in my setup dot SQL file. This session is about the difference
between the applications which are implementing SOA which is service
oriented architecture and software applications, which are implementing
the micro Services architecture. So without wasting any time,
let me get started. Now before we go
into details about SOA and microservices. Let's see what is
a monolithic application and how that function. First of all you can think
of a monolithic application as a container, which is basically
I think the number of software components right? There can be a number
of software components as part of your software application. And if they are all hosted
together and delivered together, then that's called
a monolithic application. Now there are various challenges
with any software application which is implementing
the monolithic architecture. First of all,
they are not flexible. Okay, monolithic applications. They cannot be built
using different Technologies. That's the problem. The Second Challenge is
that they are unreliable even if one feature of the system does not work
then the entire system. Mm will not work. The third challenge is that these monolithic
applications are not scalable. They cannot be easily scaled. And even if the application
needs to be updated then the complete system
has to be rebuilt. The next problem is that with
these monolithic applications. They block continuous
development all the features cannot be built and deployed
at the same time. They will have to
be done separately. The next challenge
with monolithic applications is that the development
is very slow. They take a lot of time
to be built since each and every time It has
to be built one after the other and most of all the monolithic
applications are not fit for complex architecture because of course you cannot use
different Technologies. You are very limited
and very constraint, right? So that is the challenge
with monolithic applications. So now let's go on to SOA, which is nothing
but service-oriented architecture now with SOA
these services or features. They are broken down, right? The entire software application
is not built as one but the different
features teachers and the different services
are broken down into smaller components, right? So that's why it's called
coarse grained architecture and over here. If we have let's say
one software application inside the which it provides and if it provides
like five features or four features, then all those are four features are delivered
by four different services. And that is what you
can see over here, right? There are four
different services. And each of these Services
would have multiple tasks inside them and these smaller
tasks are together. Tell or ask one particular
feature and the whole software application comprises
of a number of these features, but with microservices,
it's a little more different. Now these features or services are further broken
down into tasks level services. So here it was
feature level Services. Whereas the services here. They are task level each and every task
in a particular feature that was broken down and that's
why you have multiple tasks and multiple services
in a micro service architecture. Chop and that is
why this is called fine grained architecture. So that is what
the differences are between these three
on a high level. Now before I go further and confuse you people let
me just go into more details about the differences
between SOA and microservices. You can think of the difference
between SOA and microservices with the help of these images. So SOA is like an orchestra similar to you having
multiple performers, you will have multiple services. But each of these performers will be controlled by
one potato director and similarly in Rip even though you have a multiple
Services these services will be interacting with one another and then they will be delivered as one
particular software application. But whereas in case of a micro
service there are multiple or let's say there are
independent performers, but these independent performers are not controlled
by any director. So they work separately
and they work in silos. So that is a different. So I hope you can understand the difference between the two
from these images right even though they work together. Are they are controlled
by one particular director and that's why this
is called a centrally governed architecture and whereas microservices you do not have a centrally
governed architecture and that's why
it's called a decentralized governing architecture. So let me go forward and talk about the difference
between these two which is nothing but Micro
service and SOA with respect to certain parameters. Let's look at the difference
between them with respect to architecture and coordination. So first of all in SOA,
there are four different. Types of services versus Business Service
the Nexus Enterprise service, then we have application service and then we have
infrastructure service. So these four service types
together form your SOA and they together delivered
your software application. Now, what are
these different services? And what do they do? Let's see that first
is business service. Right? So your business
service is the one that's going to be performing
your core business operations and it It can be either
a represented by XML or by web service definition language. And then we have
Enterprise service. The Enterprise service is
that service which implements the functionality defined
by all business service and the Enterprise service
does it with the help of the application service and the infrastructure service now moving on we
have application servers. The application service is
the actual core application or the core functionality of that feature
and these applications? Offices can be either invoked
directory or they can be invoked through a user interface. And now we have
infrastructure service the infrastructure service
refers to those non-business or those not technical
operations such as editing scaling or security
and all these things. Those are the different
Services enough SOA. But in case of micro
Services architecture, you do not have these many
types of services. You just have a functional
service and you have an infrastructure service. The functional service is
basically So the combination of a business service
and Enterprise service and an application service now a functional service is
a fine-grained service. So basically if your
Robb business logic or your business operations
requires a particular feature to work then the task that is related to exactly
that particular feature that is performed by the functional service and
besides a functional service. We have an
infrastructure service and the infrastructure service
over here is very similar to the infrastructure service that is there. An SOA the it does
all the non business or the non technical operations. Such as your security
auditing and logging. Okay, so that is the difference
with respect to architecture and coordination. So now moving on
to the next slide, we have a true
genius interoperability. Now what this means is
any software application and need not be developed on
the same programming language. Now when your main software
application you might have a smaller applications, right? And each of those
smaller applications could be written on Java or it could be written on C dot dot net
or it could be written on. On C sharp or python
or anything now when it's written in
different programming languages, it's tough for them
to interact with one another and if you want the different
services to communicate with one another then you would have
to bring a particular platform. Right? So that's where you have
this messaging middle web. So in case of SOA, there is something called
as a messaging middleware which acts as
a communication point or the interaction point between
the different applications which are in
a different language. So you can see that this application is
on either C sharp for.net and This is on plastic
javabeans, right? So now here it's C plus
plus and here is Java so and all of these
communications they go through this one quadrature
messaging middleware, but in case of micro Services, we do not have any broker
here the communication happens directly between
application to application. Even if they are in
different programming languages, even if they are
structurally different and even if they are built
on different grounds, so look at this if you have a C sharp
or a.net application, which is communicating
with a Java application, but then how does it happen? It happens with the help
of a rest API. There is a direct communication between these two
services and similarly. If you have
another Java application which wants to communicate
with another Java application. The communication would take
place with the help of rest API and similarly Java to C sharp or dotnet would again take place
with the help of a rest API. So there is no broker
here or middleman, which is a messaging Middle
where the communication is directly to
the other application. Then comes service granularity. If you can remember
I earlier told that in microservices you do not have the software
delivered as a whole right? It is broken down
into smaller features. And if you're basically performing an operation which
involves multiple applications or multiple Services, then those services are called
by one another when it's needed so as an end user as a consumer, you might be
performing one operation. Okay, so that one operation
would not be calling all the different
Services it would call. One service and this service when it needs to interact
with the second service. This would make the call
to service to and similarly your service to when needed it would call service number 3 and
similarly the ones the service requested
made the server's response is also given to the one that's invoking the request now the catcher is each and
every service requests and service response
takes hundred milliseconds. Okay. So let's assume it takes
this much time the API calls and this is in case
of micro services. So in the micro
service architecture when each call takes a hundred
milliseconds Is in total for this service to get successfully returned
it would take 600 milliseconds. Now, that's an awful lot of time for an API call to complete
successfully write for an API called be made successfully
and to be returned and this is where it is different
from an SOA. So when case of an SOA the service consumer
would again be calling would we would be performing
one particular operation? And what happens here is
this operation would be calling the different Services
all at the same time. So the and over here would
be calling the service number one service number
2 and service number three, it should be
encompassed all together. So one particular call
be made to the servers and all three would be serviced at the same time and by this
you would be saving time because all the three requests and responses would
be made simultaneously so you would be saving a good
400 milliseconds over here. So that is a difference
in service granularity between SOA and microservices. So the next difference
we are going to see is with respect to component. Eric this is very similar
to the previous slide again, right because then it would be
the same order service which will be interacting with your different
smaller applications each for customer management and for warehouse management and
for order fulfillment and the data again would be
stored in different databases But there again is
a difference in microservices because in the micro
Services architecture for each and every application so
for customer management, we have a separate order service and that order service would
be accessing its On database for Barros management, you have a separate order
service which would be accessing a different database
and then for order fulfillment, which is again
a different application. This would be using
a different order service and this order service would
be using a different database from where it would be
accessing data, right? So that's how there's
a difference in even component sharing between
these two architectures and then we have the next
difference between them. And that is the middle wire
versus API layer this we also spoke
about earlier write your essay. You just made your bed
for communication and your microservices uses
an API layer for communication. So that is about the differences
between SOA and microservices. Now, let's go ahead and look at the differences
between the two by understanding with an example
of a shopping cart. So every e-commerce portal
will have a shopping cart right where you can add
your products to the cart and then you can check
out later so for adding an item for removing
an item for checking, what is the tax
for checking the total? Bill amount for all
those things you have a shopping cart application. And then finally we
have another application which is the main application which gives details
about the product. So it will give us details
about the product name. What is the product ID? What is the product rate
how many quantities are present and all different
other options, right? What color the product is
and all these things now, these are three
different applications and when they work together you get the complete software
application right now each of These applications would have a smaller tasks
a shopping Card application. Like I told you before it would have an add
or remove functionality where you can add
a product your card. You can remove a product
from your cart. You can check what is
a bill in your cart. You can check out. What is the tax that is there
and all these things similarly. If you talk about
a product catalog you have other tasks, right? So all these tasks together form one particular
application service in case of RSA shopping application, but in case of micro services
Has shopping application each of the different tasks that these Services provide those tasks are broken down into
smaller fine-grained services. So here we have
feature level Services Where Shopping Cart is one feature
product catalog is one feature and user account application
is one more feature, but in case of micro Services, we have a separate
billing service for shipping. We have a
shipping options service. We have tax
calculation service, right? So the different tasks
in this particular feature. It's broken down
similarly for product. Catalog application. We have different
tasks level breakdown such as display product service. We have an
update display service. We have user default service and many more similar
for user account application. Right? We have a send email service and many more now
that you've understood that microservices is all about
breaking a particular feature or a feature level service
into task level services. So, let's see how microservices shopping
application is different. So first, let's take the case. Sofware micro-service shopping
application is better. So here we'll have certain
features which are common to multiple applications. Right? So we have was something
like display image server. So it's a smaller task
level servers over here. But the image of the product
of being displayed might be common across all
the three applications. It might be present
in the shopping cart also and the image of the product
might be present in the user account application also with us showing
which were the products. Which the particular use of pot and then you might have the
product you might have the image of the product the product
catalog application also. So in this case if there's a change in the image Dimensions or in
the license of the image or anything with respect
to the products image, then the code of course
would be similar in all the three applications
write the code may be some law but the code has
to be changed everywhere. Right? And when you change the code
when you re work, then it causes a lot
of problems again now when you changed The code
here you're changing the functionality and that might cause
this particular application to behave abnormally
it might have bugs or the application might cause
failure and similarly. If you change
the code over here, then even this might throw
errors and you might have bugs similarly to this
particular application also, so if you want to avoid all those things you have to test
each of these applications to separately after
changing the code and after updating
the required details and after testing it you
will have to deploy each of these applications and you have to
deploy them separately. All these things is
time-consuming, right? So it is the same thing
that you are doing across all the different parts
of your application. But even though you're
doing it everywhere, even though you're doing
something similar you will have to test
and deploy each of them. And sometimes you
might have errors in only one particular application
and not everywhere. So these are all
time consuming tasks. But if it's in case of a microservices
shopping application, you would not have this problem because all the different
tasks over here. They are provided as a service
if you want to change the way the products image looks then
you will have to change. And only this particular
application, right? So by only changing this service
your job will be done. You do not have to worry
about the other services and you do not have to change
anything over there. So the main change you will have
to be doing will be restricted to only this particular service. So you save time
and you save effort over here in case of micro
Services shopping application. Now this was a use case where the microservices
shopping application was better, but then there are also times when an SOA shopping application
is better for you, but this was a Sick use case of where a micro service shopping
application is a best fit. But let's see a use case where an SOA type
of a shopping application and the SOA architecture comes
out better and that example is when your product is
not actually that big. So in this case,
yeah, you have a lot of functionalities you have
a lot of features and tasks. So just consider
the example of a very simple software application which show needs three primary
functionalities one much as our shopping cart, which in to where you can add
your you can add your items and then you have
another user account application where you'll have
the user profile and then you'll have a
product information application. Right so over here all
these different applications will not have too
many sub level features or sublevel applications
the a very straightforward. They're very simple
in this case. If you're having if you're implementing
microservices architecture, then you will have to go
through a lot of trouble which is simply be avoided because your application is
in itself very simple. We also just you know, create one one website where you can have one website
in which you have a cart where in you can
add your products which you want a bike. Then when you're checking
out you can have the user information displayed
and then you have details about the product which is separate application. So in this case, it could just be
these three different services. So that is the difference
between an SOA. So I think by now you understand that neither of them is better
than the other right. So there are times when microservices is preferred
and there are times when SOS prefer and you
can not hardcore it by saying that one is better
than the other. In today's Industries where software applications
are built on a day-to-day basis developers always
have to keep in mind regarding the architecture and the implementation
of the code and also the UI through which
the user will interact with the application. Now the only way to make sure that all these parameters are met is by using
micro services and API in the session guys will focus on the differences
between the two and I also talked about how and where microservices
and API I come together in the architecture, right? So on that note, let's get started
with today's session. So the topics
for today's session are as you can see on my screen
will start this session by understanding what our apis once I tell you what
our API is we'll talk about where our apis
used in microservices. And finally, I'll tell
you the differences between the two right. So on that note, let's get started
with today's session. But before that I would like to
request all of you to subscribe to our a direct our YouTube
channel to get daily notified on the Going to acknowledge. He's now if you consider
an e-commerce application, what do you think are
the main three functionalities of it example,
let's say you using Amazon. What all do you
see your customer? Right? You see all the products on Amazon and then you put
your products into the cart and finally you order
those products, right? That is basically
the simple workflow. If you have to understand now, if you have to build this
application using microservices, what you can do is
you can have mainly three functionalities that is
the customer information. The products available
in the cart and all the products
available on the website right now all these three
functionalities can be put into different
different Services what I mean by that is you can have service a having
customer information service be having the products
available in the cart and service Lee having all the products available
in the application right now when the customer goes forward
and orders a particular product. You can have
a composite microservice which will basically take data
from all these free services and generate the output
for the client. Right. So I hope you've got an idea of what I'm talking
about right now. As I was telling you
that you know before microservices came
into the picture. There was
monolithic architecture. How do you think
all these functionalities of the application was stored
in this kind of architecture? Well, it's really simple what would happen would be
all these three services that is the customer service
the product service and the card service would
be residing in a single area and then they would be
a data access layer through which you
can access the data, right? So as you can see on my screen
you have a client browser. Zur through which
the client requests for the information so as
soon as the client would request for the information
on the application that request would be passed
to this particular area where all the functionalities
are present and the data would be retrieved
from the data access layer and the database so if I have to just Define
monolithic architecture for you, then it's really simple guys
monolithic architecture is an architectural style
in which all the functionalities or the required components would
be inside one single block, right? So, I hope that particular
part is clear on that note. Let's get into the second topic
for today's session. That is what our apis. What do you think apis are
obviously everybody has heard of this term API, right? So you can basically understand
apis as a point of contact through which all
the services communicate with each other to process
the client request and send the response. Right? So, for example, let's say, you know,
you've sent a client request. Let's say on Amazon you've
requested for a phone, right? So if you just type phone
what will happen is that you want
this particular request will be sent through apis. To the respective functionality or a feature right and
that particular functionality or a feature will retrieve
the requested data and then we'll send back
the response to the client. Right? So if you see your client, then this particular
functionality or a feature present in the application and then in between both
of you there's a pi/2 which we can communicate right. So I hope that point was
clear now while building and using these applications. What developers do is
that, you know, we basically use
the crude operations when I say crude operations what I mean by that is we
basically In the sauce read and Source updated resource
and delete a resource. So apis are generally developed
by using the rest quick style. And these methods are nothing
but the HTTP methods now, I'm sure you must have
got confused when I said create a resource read
the resource updated resource and delete a resource. Well guys, it's really
simple to understand. For example, let's say, you know, you're using book
my show and then you want to find out the details
of a specific movie. So what you do is you send
a client's request. So when you send a client
request you basically we asking for the information, right? So what will happen is
that you know, the information has to be read and then the response has
to be sent is applied. So that's basically reading
the resource coming to creating updating and deleting. This is from basically the
developer side where you know, they keep adding the information
to the application or maybe specific
movies details are updated or maybe the complete
movies deleted, right? So basically the information
of the movies deleted once it is out of
the market, right? So that's how basically it works now whenever
we send the request. As to what happens is that we're basically sending
an HTTP request, right? So for that we use
the HTTP methods, right? So next in the session, let's understand the
different HTTP methods. So the HTTP methods are
as you can see on my screen. We basically have the post
get put and delete methods. So whenever you want
to create a resource you basically use the post method
whenever you want to read a resource you use
the get method whenever you want to update a resource
you used for What method and whenever you want
to delete a resource, you use the
delete method, right? So basically guys apis use
these methods to basically communicate between the client and the respective functionality of the features
of the application right. Now. If you want to know more
about HTTP methods and apis you can refer to
my session on what is this API? So on that note, this is all that you
have to understand to understand the differences
between apis and microservices. Right? So now that I've told
you you know, what am I? Elvis's and what
our apis let's continue. Where are exactly apis used
in micro Services. Now when I was explaining
apis for you, I was always saying
that you know, they're basically a middle
person between the client and the respective feature
of the functionality now, obviously that particular
feature or the functionality can go into a
specific service, right? So let's say, you know, we have a functionality
of all the products present in the application, but that particular
feature can be present in a specific service, right? So now when a client request for all The products
available in the application the request can directly go
to that particular service and the response
can be generated back. So I hope that point is clear. So what you can do is
basically the application that we took the example that we took we had
a client browser and in the monolithic
architecture the customer information the product service and the card service all
these three services basically all these three functionalities
were residing in the same area and then there was
a common data access layer and then a common
database right now when you break
down this Application or maybe even you
refactor this application into microservices. What you can do is you can have
a specific microservice and then you can have
its own data access layer and database and for
each microservice. There's a separate API, right? So basically the customer micro
service will have a specific API its data access layer and database similarly goes
for the product micro service and the card micro service now, it's not necessary that you know this single
database for each and every microservice. It may also happen. And that you know two
or three microservices share a common database to which
the data is retrieved, right? So basically guys
if you have to understand where apis are used
in microservices, it's really simple. Each service will basically
have its own API provides. The services will communicate
with the client. Right? So, for example,
let's say, you know, you're a client and then you're
asking for your own information your own customer details. What will happen is
as soon as you send the request basically
the API Gateway will decide to which service this particular
request has to be sent. Now since we want the customer
details this particular request will directly go
to the customer microservice. And what will happen is that you the required data
will be retrieved from the API. And then again the API will send
back the requested response to the client. Right? So basically that's all that you have to understand
guys that you know, each service will have
its own API and then through that particular API, you can communicate with that
particular service right now. It's not necessary
that you know, you need information from a single service right
even in that scenario. Is what will happen is
that you know, each micro service will generate
the requested data and all of them together will send
back the requested response to the client. Right? So, I hope that you understood where our API is used
in micro Services right now. Let's move forward with the final topic
for today's session. That is the differences
between micro services and API now in this tutorial
on Microsoft versus was a pi. I hope that you know,
you've understood what are basically microservices
and what our API is Guys. These are completely
two different things. Microservices is basically
an architectural style through which you
can build the applications in the form of small
and autonomous Services coming to apis apis are a set
of procedures and functions, which allow the consumer to use the underlying service
of an application. Right? So basically guys this
is the main difference between micro services and API that microservices basically an architecture to which you
can build the application and apis is basically
like a middle person between the client and the services through which
you can establish. Location between both
of them right? So I hope that point is clear
also from the example that I explained you. I'm hoping that you know, it's clear to you that you know apis are
a part of Microsoft versus and thus it helps
these Services communicating with each other. However, while communicating with the other services
each service can have its own crude operations
to store the relevant data in the database not only this but while performing
the crude operations API is generally accept in return the parameters based
on the request sent by the user. So for example If the customer
wants to know the order details, right, so maybe he
must have ordered few items. What will happen is
that you know, the product details
will be fetched from the product service
the billing address and the contact details
will be fetched from the customer service and the product
purchased will be fetched from the cart service. Right? So basically if you have to, you know generate
a specific data, or maybe if you want
a specific data, all these Services can communicate within
each other with the help of apis and generate
the requested response, right? So I hope it's clear
to you guys. So guys this was
the basic differences between microservices and Epi Microsoft
is is basically a simple architectural style and apis are a set
of procedures and functions, which allow the consumer
to use the underlying surface of the application. So if you're someone
who is aspiring to build an application
using microservice architecture, I would always see that, you know, make sure
that you know, your API is a working and then all the services
are working are collaborated with the apis in such
a way that you know, no request is high. And maybe all the clients
requests are satisfied with the requested response. Right? So I would just say go forward and build applications
using micro services in today's market microservices
have become the go-to solution to build
any kind of application. They're often known to solve
various kind of challenges, but this is not the end
to the story as skilled professionals often
face challenges while using this architecture itself. So in the session guys will discuss on the The various
design patterns that you can use while setting up an application
using micro services. So on that note, let's take a look at the topics
for today's session. So the topic for today's
session are as you can see on my screen will start
this session by understanding. Why do we need design patterns? And then we'll look into what
exactly design patterns are and then I'll talk
about the principles behind microservices. Once you understand the
principles behind microservices. I'll finally end the session
by talking about the Microsoft versus design patterns. Before I move forward
with the session, I would like to request all
of you to subscribe to our red. You make a YouTube channel to get daily notified on the top
trending Technologies, right? So on that note, let's get started
with today's session. So the first topic for today's session is why
do we need design patterns? So to understand this topic
just consider the scenario where you have
a team of developers. Let's say 30 developers
right now, you're given a project to basically build
similar kind of applications as a team lead. What will you do you'll just
do Vice these three applications to a group of 10 10
10 developers, right? So the group one will have project 1 group
2 will have project to group 3 will have
project free and all these three groups will have
each of ten developers, right? So now when this team of developers start
developing the application, they can follow different set
of processes, right? So when I say process
what I mean, that is the way they're
developing the application, right so they can follow
a particular part to develop an application. Right? So let's say the group
one is following process one group two is following. Dual and group three following
process tree right now. What can happen is that maybe process
one works completely fine what I mean by that is
that you know, there's no errors and then
whatever errors are coming. Also. There's no latency time. There's no disadvantage
in using that kind of process. Right? But if you consider
any other two processes, let's say process
to and process tree. It may happen that you know, they could be
few errors and maybe that's not the right way
to build the application, right? So what could happen is
that you know, I'm not saying that you know process one is the Only way
to build an application. Maybe they have a better way when compared to process
to and processed rewrite. So as the team lead
what you clearly understand is that you know your development
team cannot build the application using process
to and process tree, right? So to ensure that all the teams follow
the same process or maybe of same pattern you can use
this concept of design patterns when the teams working
on various projects use the same pattern to build
similar applications, right? So basically they will select
a particular pattern. And we'll build all
the applications based on that particular pattern itself
on that particular pattern. You'll make sure that you know, you have
the maximum Advantage is that you can get
for your application, right? So that is the need
of design patterns guys. Basically if you have
to understand the need in a single line, then you get us understand
the fact that you know, design patterns are used
to make sure that you know, your complete team is on the same plate and everybody
is following the same process or maybe the same pattern
to build the application, right? So I hope you've understood what is the need
of design pattern, right? Right. So now let's understand what
exactly design patterns are what my previous explanation you
might have clearly understood that you know design patterns
are basically a simple pattern based on which you
build an application. But yet if I have to Define
design patterns for you, then design patterns or software design patterns can
be defined as a soffit template or a description
to solve a problem that occurs in
multiple instances while designing a
software application or a software framework, right? So I hope you've understood what exactly design
patterns are there. Basically just a top fit
template or a pattern or maybe a description
to solve a particular problem. And that particular
problem is seen in multiple instances, right? So when you want
to solve a problem, which is in multiple instances, you can go forward and choose
the design patterns, right? So now that you know what our design patterns
so next in the session, let's look into the principles
behind microservices. So the principles
behind microservices are as you can see in my screen, it starts with independent and
autonomous Services basically because you know
eat Services be independent of the other service, right that is because each service
is either created for a domain or a business capability and each service has
its own functionality, right? So that is the first principle
coming to Second principle. That is scalability. So when you build microservices, what you can do a sickly
do is for example, let's say you have for services for a specific
business domain then what you can do is you
can scale a specific service individually without scaling
the others, right? So let's say in the example that I took that is
the e-commerce application we had free. Right customers
orders and product. So if you want to scale the
customer service individually, you can definitely
go forward and scale that particular service and you do not have
to scale the orders or the product service similarly
goes for the other services. Also coming to
the third principle that is decentralization. The decentralization is
basically when you know, you do not have
a centralized architecture right what I mean by that is
for a specific business domain when you build an application
using microservices, your complete control
is not there for a specific service, right? So all the controls
are basically divided into Individual Services
coming to resilient Services. I would say micro services are red seal and services
because you know, let's say even if one service is completely
down the complete application will not go down. So in the incomes application, let's say the product
service is down. That doesn't mean that you know, your application will stop working only that particular
service is not working and the team will be working on that particular service
do get back the service. Right? So the only point
that you have to understand is that you know, even
if a service caused. On the complete application
doesn't go down. Next we have is Real
Time load balancing. So obviously when
a client sends requests, it may happen that you know, you have to retrieve data from
multiple Services over there. The load balancer comes
into the picture and then it defines how much CPU or how much
GPU should be used for a particular service
to get the data and similarly how the clients request
should be passed. Right? So that's happening real time. And in this kind of architecture
the client doesn't have to wait for a really long time. Right? So you get the outputs within
seconds coming to Availability. I think the principle itself
defines its functionality. It's basically means that the services
are available 24/7 and all these Services
can be basically used as much as they want right coming
to the next principle that is continuous delivery
true devops integration. Well biker Services is one such technology
or maybe you know, once it's framework that you can understand
which you can collaborate with devops to get containers
delivery of the output. Right. So once you understand devops, you'll understand
how to deploy a service and how to get the outputs. After that, we come
to the next principle that is seamless API integration
and continuous monitoring all the microservices have
a specific API Gateway, which is basically
the entry point to the clients request, right? So whatever clients
request has been sent and it will be first sent to
the API Gateway through which the request will be forwarded
to the specific microservices. And obviously these micro
services are continuously monitored whether the response
is sent back or not, or maybe if the service
is down or not coming to the next principle
that is isolation from failures. So when I say
A isolation from failures what I mean by that is, you know all the services even
if they're down on maybe if they have any specific errors that particular service
will solve its own error and it won't disturb
the complete application. So let's say
in the e-commerce application that we considered. Let's see if the product service
is facing few errors. Then what will happen is only that particular service will
be basically taken into account and the errors will be solved and those errors will
not affect the application or maybe the other two Services
coming to Auto provisioning or to provisioning
is basically Ability to deploy the information
by itself, right? So basically the service
will generate the information for the clients
request automatically without anybody's help. Right? So Guys, these were the basic
principles behind microservices that is independent and autonomous Services
scalability decentralization Brazilian Services
real-time load balancing availability continuous delivery through devops integration
seamless API integration and continuous monitoring
isolation from failures and auto provisioning. Right? So guys, I hope
you've understood Understood the principles
behind microservices, right? So now once you start building microservices you
often face future challenges to because of which you have
to start using design patterns. So since this session is
basically based on microservices will be looking into the
microservices design patterns. So let's get started
with the first design pattern that is aggregator. So when you hear
the term aggregator what comes onto your mind in Computing World aggregator
refers to a website or a program that collects related items
of data and displays them. So even in microservices pattern aggregator is
basically a web page and invokes very services
to get the required information or achieve the required
functionality apart from this when you basically build
the microservices architecture, maybe a Microsoft is application by breaking down
the monolithic application or the monolithic architecture the source of output
gets divided right? So when I say
monolithic architecture, you can just consider it
to be a one big block right? So when you break
that one big block into All small Services
the source of output also gets divided right? So this pattern basically
proves to be beneficial when you need an output
by combining data from multiple services. So if you consider a client
sending a request and maybe if we need data
from two Services, then aggregator is
a design pattern that you should go
for right now. How do you think that happens? So what basically happens is
that you know, let's say we have two Services when a client sends a request
and maybe that you know, we want the data
from both these services. So what will happen
is that both? These services will be having
their own database. So with the help
of aggregator design pattern what will happen is
that you know, each transaction will have
a unique ID So based on that particular ID. The request will be sent and all
the data will be collected from The Individual Services and the required business logic would be finally
applied after that. What will happen is
that you know, whatever data is collected. It will be published
to the rest endpoint and later on what will happen is that the data will be consumed
by the respective Services which require that data right? So it could be a specific
consumer or maybe a user. Maybe a group of users
or so on right? So if you have to understand
aggregate the patent guys, it's really simple. So aggregate the pattern
is basically a web page which invokes Media Services
to get required information. So whenever a client requires
a specific information from two or three services, you can go forward with this aggregated
design pattern also before I move forward
to the next design pattern. I would like to mention
over here is that you know, aggregate the pattern
is basically based on the drive principle. So what happens is
that, you know, based on this principle
you can abstract the Just a business logic
into composite microservices and aggregate that particular
business logic into one service. Right? So let's say you have
a business logic, right? So that particular
business logic, what you can do is
maybe you can put that particular business logic into two to three
microservices later on. What you can do is
you can aggregate that business logic into
one specific service, right? So, for example, if you consider
two Services service a and service we then you
can individually scale the services simultaneously by providing the data to
the composite service, right? So that was about the aggregate
that design patterns guys. Let's move forward
with the next design pattern. That is API Gateway now microservices are built
in such a way that you know, each service has
its own functionality. But when an application
is broken down into small autonomous Services, they could be a few problems that a developer might face
now the problems could be how can I request information
from multiple microservices? How can different devices
require different data to respond for the same
back end database service or how to transform data? To a consumer requirement
from reusable microservices or how to handle
multiple protocols request. Right? So Guys, these are
basically few problems that all the developers face. Well, if you wish
to solve these problems, then I would say
the solution to these kind of problems could be
the API Gateway design pattern. So the API Gateway
design patterns at this is not only the concerns
that I mentioned right now, but also it solves
many other problems. This particular pattern
can be considered as a proxy service to router
requested are concerned. Service. So basically as I mentioned before API Gateway
is the entry point to the clients request
also being a variation of the aggregate service. It can send the request
to multiple services and similarly aggregate
the results back to the composite service
or the consumer service, right? So the API Gateway as I mentioned is basically at the entry point
for all the micro services and can create fine-grained apis for different types
of clients, right? So maybe you have a client
sending a specific request or maybe the client B
sends a different. Frank was right. So with the help
of this particular pattern, you can create fine-grained apis for all different
kinds of crimes. And for the request also since developers are always
concerned about, you know, how to handle multiple protocol
request API Gateway scan convert the protocol request
from one type to another type similarly. It can also offload the
authentication responsibility of a specific microservice. So once the client sends
the request these requests are basically passed
to the API Gateway which acts as an entry point to Add the clients request to
the appropriate microservices, then with the help of the load balancer the load
of the request is handle and the requests are sent
to the respective Services. Right? So micro service is also
used this service discovery, which basically acts
as a guide to find the route of communication
between each of them. So when I say each of them, I mean to microservices
so microservices can communicate with each other
via stateless server. That is either by HTTP request
or message bus, right? So with the help
of API gate Pattern guys a client's request
is basically forwarded to the correct microservice. And even if there
are different kinds of clients using different UI
so maybe different protocols and they want the data
from the same back end service. Then API Gateway design pattern
is your solution, right? So I hope
that you have understood. What is API Gateway
design pattern now, let's move forward
with the next design pattern that is Chained
or chain of responsibility. So the chain or chain
of responsibility design pattern basically produces
a single output, which is a combination
of the People change output. I hope that is clear
to you guys, right? So as the name suggests in
this particular design pattern what happens is that the client request
is passed to let's say service a and then the request
is passed to service p and then the request
is passed the service C. Similarly the responses
first collected from service see to service be and then some service
be to service a and finally it goes
to the client. Right? So as the name suggests
guys the chained or the chain of responsibility
design patterns produces a single output, which is a combination
of the Multiple chained outputs. So for example, if you have three services
lined up in a chain, then the request from the client
is first received by service a and then this
service communicates with the next service service be
and collect the required data. Finally the second
service communicates with the third service to
generate the considered output. And what happens is that all these Services
response is sent again from service E2 service
be service be to service a and finally to
the client, right? So all these services use
synchronous HTTP request or ponds for messaging also under the request passes
through all the services and the respective
responses are generated. The client does
not get any output. Right? So guys, this is kind
of a disadvantage in this particular design pattern
because you know, let's say, you know, you have
20 Services lined up and maybe the client request
is a very big request, right? So until all the data is collected from all
these particular services and then the response
back is generated. The client does not see
any output right? So it's always recommended
not to make any long chain as a Line has to wait
until the chain is completed. Right? But before I move forward
to the design pattern one more important aspect of which you
need to understand is basically that, you know, the request from service a to service be may look
completely different from how the request is from service
be to service e similarly is the case for response. Maybe the response from service see to service
be may be completely different from service be
to service a right. So that's what you have
to understand about the chain of responsibility or chain
design pattern guys. Now, let's move Forward
with the next design pattern that is asynchronous
messaging design pattern. So what do you
understand by this term asynchronous messaging? Obviously, the messaging pattern between microservices is
not synchronous, right? So in the
previous design pattern, we had discussed
synchronous messaging right? So that was because you
know service a communicates with service B and B to C, right but in asynchronous
messaging pattern, it's not necessary that you know, all
the services communicate like, you know Service A
to B or B to C, maybe service a can directly
communicate so bossy and maybe Always seek and communicate with service be or maybe service be
does not communicate at all. Right and service
speak communicates with service a right. So basically what you have
to understand is that you know, since the client wait
a long time without any output in synchronous messaging and maybe you do not want
the client to wait for a long time. This is where basically you use the asynchronous messaging
design pattern, right? So in this particular pattern
what happens is that all the services
communicate with each other, but maybe they do
not have to communicate with each other sequentially. So if you
consider three services as I just mentioned
before service a b and c the request from client can be directly
sent to serve a c and service be simultaneously when I say simultaneously
what happens is that you know, the single request from client is sent to
both the services together that a service e
and service be so then what will happen is
that you know, these requests will be
in a queue. So when I say Q
you can understand that it is basically
a line of requests. So when a client requests
simultaneously sent to two Services you basically
The Q and A Part from that but you also have
to understand is that you know, let's say the service is sends a request to server
see it's not necessary that you know service
see sends back a response to service a itself. Maybe it can follow
a different part and then finally response
can be sent right. So the path is not defined
and it is not done sequentially in asynchronous
messaging pattern. Right? So guys that was about asynchronous messaging
design pattern next. Let's move forward
with the next design pattern that is database design patent
or share data design pattern. Now for every application there's obviously a humongous
amount of data present, right? So when we break
down an application from its monolithic
architecture to microservices, it's very important to know
that you know, each micro service has
a sufficient amount of data to process the request right? So I hope that point is clear
to you when we break down the monolithic application
into small small Services. We need to make sure
that you know, each micro service has sufficient amount of data
to process the clients request. So either the system can have
the database Each service or it can have shared database
per service, right? So when I say database
for service what I mean that is, you know each microservice in the system will have a
specific database for themselves and share data base
for service is basically when two or three microservices together share
a specific database right now, you can use the database
for service or shade database for service
to solve various problems. So the problems could be basically
the duplication of data and inconsistency different
Services have different kinds of stories requirements. So the problems
could be basically the duplication of data and inconsistency different
Services have different kinds of storage requirements
few business transactions can query the data
with multiple services and denormalization of data
is not easy, right? So to solve these
kinds of problems. Basically you can use the database for service or
the shade database for service. Right? So if you have
to solve let's say, you know duplication
of data and inconsistency. I may be different Services
have different kinds of storage requirements or maybe a few business
transactions can query the data. Multiple Services, I think you should go
for database for service as it will then
be accessed by Microsoft versus API itself, right? So H microservice will have
its own database ID, which thereafter prevents
the other services in the system to use
that particular database, right? So only that particular
micro service are can access a specific database present for that particular
microservice itself, right? So apart from this to solve
the issue of denormalization, you can go forward
with the share data bases per service to align
more than one. Database for each microservice. So what will happen is that this will help
you gather data for the monolithic applications which are broken down
into microservices. But you have to keep
in mind that you know, you have to limit this databases to two or three
microservices else scaling. These services will
be a big problem. Right? So guys that was about
the database design patterns. Let's move forward
with the next design pattern that is the event
sourcing design pattern. So the event sourcing design
pattern basically creates events regarding the changes
in the application. Date so these events are stored as a sequence of events to help the developers track
with change was made when and by home, right? So with the help of this
you can always adjust the application state to cope up
with the past changes and also you can query
these events for any data change and simultaneously published
events from the event store. Right? So once the events are published
you can see the changes of the application State on
the presentation layer, right? So that was about event sourcing design pattern guys
event sourcing design patterns. Is basically used to create
events regarding the changes in the application state, right? You've done a specific change
and maybe you want to go back to the previous change
that you have done. You can always use
this particular kind of pattern to go back and see
what changes was made and when and by home, right? So that was about event
sourcing design pattern guys. Let's move forward
with the next design pattern that is Branch pattern. So what do you
understand by Branch? Pardon obviously as
the name suggests, it's all about branches, right? So for a specific service,
you can have different branches. Right. So the branch might
the service design pattern is basically a design pattern in which you can simultaneously
process the request and response from two or more
independent microservices. So unlike the chain design
pattern that are discussed before the request
is not passed in the sequence, but the request is passed two or more mutually exclusive
microservices chains, right? So this design pattern
basically extends the aggregated design pattern and provides the flexibility
to produce responses from multiple chains
or a single chain, right? Right. So for example, if you consider
an e-commerce application, then you may need to retrieve
the data from multiple sources and this data could be
a collaborated output from various Services, right? So you can use the branch
pattern to retrieve the data from multiple sources, right? So the branch pattern is really
simple to understand guys. It's basically where you
want to simultaneously process the request and the response from
multiple microservices, right? So these could be
either in a single chain, or maybe it could be
in multiple chains also, but yes, it's not necessary that you At the request
of the response is done in a sequential manner. So guys that was
about the branch battle. Now, let's move forward
with the next pattern that is command query responsibility
segregated design pattern. So command query responsibility
segregated design pattern or more commonly known
as cqrs is basically used when you want to query
for a specific data right now. What happens is that you know, when you have microservices
design in the form of database for service
or shade database with service, what happens is
that you know, you have limited Access
to database right? So basically you
cannot Implement a query as the data is limited
to only a single database. So in such scenario, we basically use
the cqrs pattern. So according to this pattern
what happens is that the application
will be divided into two parts that is command and query. So the command part
will basically handle all the requests related
to create update and delete while the query part will take care of
the materialized views, right? So the materialized views are updated through
a sequence of events, which are created. I think the eventsource pattern
that I just discussed before so in the cqrs pattern guys, you basically divide
the application into two parts. That is the command
and the query the command will take care of the request
energy to create update and delete and the query part would basically take care of
the materialized views, right? So with the help of this pattern you
can make sure that you know, you have good access
to your data bases and then the clients
request is satisfied. Also, you can make sure
that you know, your materialized views
are updated through a sequence of event which are again created
using the event sourcing design. Turn so guys that was
about the cqrs pattern. Now, let's move forward
with the next pattern that is circuit break pattern. So the circuit break pattern as the name suggests
is basically used to stop the process
of request and response if a service is not working. So for example, let's say a client is sending
requests to retrieve data from multiple services, but due to some issues
one of the services down. Now, there are
mainly two problems which will see first. The client will not have
any knowledge about the service being down, right? So he or she will be
continuously sending the request to that particular service. The second problem that we see is basically
the network resources will be exhausted
with low performance and bad user experience as the client without
knowing will be waiting for the response to come back. Right? So to avoid such problems, what you can do is you can go
forward and use the circuit break up design pattern. So with the help
of this design pattern the client will invoke
a remote service via proxy the proxy
will basically behave as a circuit barrier. So whenever the number
of failures Cross the threshold number
the circuit breaker trips for a particular time period and then all
the attempts to invoke the remote servers will fall
in this timeout period right? So once that timeout period
is finished the circuit breaker will allow a limited number of
tests to pass through and only if those requests are succeeded
the circuit breaker resumes back to the normal operation, right? So just in case if the test don't go through
then they will be a failure and the timeout period
will begin again, right? So in this particular pattern
everybody have to understand is that is basically that No, when the number of failures
cross a threshold number the circuit breaker will trip
for a particular time period and then all the attempts to invoke that particular
service will fall in that particular period right
once that time period is done what will happen is that you know
as the circuit breaker will allow a limited number of
tests to pass through and only if the test succeed
it will resume back to normal operation else. It will show failure again and again the timeout period
will begin again. So with the help
of circuit breaker pattern guys, you can make sure that you know, there's no exhaustion
of the network. Horses with low performance and always the user experience
is kept under good bloat, right? So that was about the circuit
breaker design pattern guys. Now, let's move forward
with the last design pattern for today's session that is
decomposition design pattern. So micro services are basically
developed with an ID on the developers mind
to create small services with each having
their own functionality, but breaking an application into small autonomous units has
to be done logically, right? So to decompose a smaller a big
application into small services. You can go forward and use
the decomposition patterns. So with the help
of this patterns, either you can decompose
an application based on the business capability
or based on subdomains. So for example, if you consider
an e-commerce application, then you can have separate
services for orders products and customers if you decomposed
by business capabilities, but in the same scenario, if you design the application
by decomposing by subdomains, then you can have services
for each and every class so here in the example that had considered
before that is the e-commerce. Even if you consider
a customer as a class, then this class will be used in customer management
customer support customer query and so on right so to decompose you can use
the domain-driven design through which the whole
domain model is broken down into sub domains. Then each of these subdomains will have their own
specific model or a scope that is basically
the bounded context. So now when a developer
designs microservices, he or she will Design those services around
that particular scope or bounded context, right either you can decompose
Says by business capabilities or buy domains right now. Obviously these patterns might be sounding
very feasible to you. But yes, these patterns are not feasible for
a big monolithic application. This is because of the fact
that you know, identifying subdomains or business capabilities
is not an easy task for big applications. Right? So the only way to decompose
big monolithic applications is by following the wind pattern
or the Strangler pattern. So the wind pattern or the Strangler pattern is
basically based on the analogy. To a wine which basically
strangles a tree that it is wrapped around right? So when this pattern is applied onto web application a call goes
back and forth to each you are I call and the service is broken
down into different domains. These domains are then hosted
by separate Services, right? So according to
the standard pattern two separate applications
will live side by side in the same URI space and one domain will be taken
into account at an instance of time So eventually
what happens is that you know the new
refracted application. Actually wraps around or you
can say strangles or replaces the original application until you can shut down
the monolithic application. Right? So guys that was about
to strangle pattern and I hope you have understood
what is the composition pattern. So in the session guys will
focus on the different tools that you can use
to manage your services. All right. So without wasting
any further time, let's take a look at the topics
for today's session. So we'll start today's session
by Understanding different tools used in micro Services based
on various parameters or you can understand as used for different stuff. Right? For example, I'll start with different
operating systems using which you can build
your services then I'll talk about the different
programming languages you can use to build microservices. Once I'm done with that. I'll talk about the tools
for API management and testing the tools
for messaging the different tool kits available
in the market after that. I'll talk about the different
architecture Frameworks the tool for orchestrations
to tools for monitoring and finally the server list. So on that note, let's get started
with today's session. But before we start
with today's session, I would like to request all
of you to subscribe to our idiotic
our YouTube channel to get daily notified on
the top printing Technologies. So on that note, let's get into the main topic
for today's session that is microservices tools. Now, if you ask me what are microservices
my answer would be really simple microservices tools
are basically a collection of various tools and Technologies having
different functionalities these tools are you Used
in various stages of building an application and help the developer to work
with he's all right, so they come with basically
predefined functions algorithms and a very
user-friendly gy to make sure that you know developers
can build their applications in an easy manner not only this but startups to multinational
companies have been using micro services in the day-to-day
business activities today and to make sure that you know, they can build the application
in an easy way many other companies
are building of new tools and Technologies, right? So while building it
Application using microservices. I will not see that, you know only
a single tool is enough. Maybe I would say a couple
of tools together will help you build the application
in a more easy way. So on that note, let's look into
the different tools that we can use
for different purposes. So starting with the first one
that is operating system. Now one of the most
important factors of building an application
is setting a proper Foundation of your application. So this is basically done
by the operating system now, Lennox is one such
operating system, which It is most commonly used
in today's market to build applications with the help
of Linux containers. It provides a self-contained
execution environment and lets you orchestrate small to big services like
security networking and storage. So if you ask me, what are the better choices
of Linux family, there are with a red hat
and Ubuntu are the go-to solutions for anybody
in today's market, but they come with a lot
of unnecessary functionality which are not needed
for microservices apart from these Linux providers
have also come up with tools such as Dominic red hat and Ubuntu including lxt, which is basically
a container oriented hypervisor. So I would say that, you know, you can go for
any operating system that your company chooses
to build an application or maybe you're comfortable
with but Linux is one such operating system, which is growing
in today's market and helps developers to build
the applications easily. Now, let's move forward
with the next one that is programming languages. Now the main
advantage of microservices that different languages and Technologies can be used
Used to build different Services of the same application. So what I mean
by that is you know, let's say you have five services
in the same application. Now the first service
can be built using python the second one can be built using Java the third one
can be built using go programming language and so on so it basically gives
the developers to freedom to choose the technology stack
and build the application. But the most popular programming
languages used in microservices our spring Boot and Alexia. So talk about spring boot
first springboard. Please simplifies the creation of recipes microservices
with the help of spring boot Frameworks
in just a few lines of code. Right? So if you ask me
the features of springboard, then it provides
auto-configuration to load a set of default configurations for quick start
of the applications. It comes with embedded
termcat servlet containers and Jetty to avoid the usage
of War files springboard also has an opinion to reduce
the developer effort and simplifies the main
configuration and finally it consists of a wide range of apis
for monitoring and managing. Applications in the
development side and also on the production side. So springboard is one such
programming language guys, which is very famous in the field of microservices
and you would always see that you know developers are
trying to build microservices using this particular framework. All right, so that was
about springboard next. Let's move forward with
the next programming language. That is Alexia. Now, Alexia is a general-purpose
programming language which runs on the alang virtual machine now Alexia
shares the same abstractions for building fault
tolerant and distributed. Applications so if you
want me to mention few features of Alexia that I would say developers
can easily write the code in short fast
and maintainable banner. This code basically
runs an isolated light with processes which can
be scaled individually. For example, let's say, you know,
you have five processes, right and you don't want
to scale the particular process, but you want to scale up
the are the processes. Well, you can definitely do
that apart from this Alexia. Also, make sure
that you know, the application never goes down
by providing the supervisors. So basically the supervisors
How different parts of the system can be restarted if something goes wrong and that is the main
objective of microservices. Right? So our main objective is
basically that you know, even if a particular
service is gone down that doesn't mean that you know, the application will go down instead the bug in
that particular service has to be resolved and then the service
has to be restarted and finally coming to the last
feature that you know, this programming language comes with its own build tools
to create projects manage tasks and run
the required tests. So Guys, these were
the two programming languages which are very popular. In the field of microservices
next in the session. Let's look into the different
tools used for API management and testing now while you start
building applications using micro Services. You also have to make sure
that you know, all the Individual
Services communicate with each other using apis. So each microservice can have
its own API to communicate with the other servers. So this is where basically
the API management and testing comes
into the picture where all the apis
are present in the system and must be properly managed and It to get
the desired results. So if you want to know more
about micro services and apis and how apis and microservices
collaborate with each other. You can refer to my session
on micro Services versus API. Now the top tools used
in API management and testing are
basically the postman and the API Fortress. So starting with
Postman supposed. Where is basically
an API development suit, which allows you to easily run
UI driven API test with the help of Postman the exploration of restful API the sources
Comes very easy. So what I mean by that is that you know with the help
of Postman you can basically pass HTTP request to test develop and get
the required results. Now few features of Postman are as you can see on my screen
Postman basically integrates with your software development
life cycle in he's it provides features to design apis and maintain multiple versions of API with support
this tool can work for small applications
to Big application and it also supports
collaboration of work by allowing you
to save related API. High end points
into a collection now, once that is done. What you can do is
you can go forward and share the entire collection
to the other developers. So Guys, these are the few
features of Postman next. Let's move forward
with the next tool. That is API Fortress Now
API Fortress Is both an API test and help tool which automates the process of
load testing Health monitoring and functional testing. The stool is basically
a code free and is built around modern APA architectural
patterns and practices. So if I have to mention few
features of API Artists for you, then this tool is highly
interoperable with any platform that you choose
in your tool chain and validates apis built
in API management platforms. It also simplifies
API test creation and execution by providing
a drag-and-drop gy the store also aims to simplify
the end-to-end testing by providing easy generation
of functional tests and also focuses
to simplify the collaboration by storing the tests and reports in a collaborative
environment to make sure that you know teams
can validate their own apis if it Sighs the business case. So Guys these with a few
features of API Fortress now once you know the tools
for a pain management and testing the next thing that comes into a micro
service system is basically how the services communicate
with each other while these Services communicate with each other using
the messaging system. So the different tools
available for messaging our Apache Kafka and rabbitmq. So talk about Apache Kafka
first this tool is a distributed publish/subscribe
beseeching system originally developed at LinkedIn and On became a part of the Apache project
Kafka is scalable and agile and is distributed by Design. So Apache Kafka is a distributed
stream processing platform, which can be used
for data processing or API calls. So few features of Apache Kafka
or as you can see on my screen Kafka has
high throughput for publishing and subscribing messages
to maintain stable performance. This tool guarantee
is zero downtime and zero data loss in a
pasture Kafka message is purses on the desk as fast as
possible and many applications. Can plug in and make
use of this tool as it offers
new right connectors. So Guys. These are the ways
features of Kafka. Let's move forward
with the next tool. That is rabbitmq. Now this tool utilizes
patterns to communicate between micro services and also scale application
simultaneously with the help of this tools. You can basically connect
microservices with each other to solve problems
of various distributed systems. Not only this but you
can also use this tool to exchange events between
individual microservices now the Just of rabbitmq are as you can see on my screen this
tool basically offers a variety of features such as reliability
delivery acknowledgements, including persistence
publisher confirms and higher availability by using
this tool messages are routed through exchanges before
arriving at the q's rabbitmq comes with the Federation model
and allows the service that need to be more Loosely
and unreliably connected and also supports messaging over
multiple messaging protocols. So Guys, these were
few features of rabbitmq now, Once you know you're done
with your API management and messaging the next
thing is basically that comes on to everybody's
mind is toolkits. What do you
understand by toolkits? What toolkits in layman terms
is a set of tools used for a specific purpose. So in microservice
architecture also, you can build various kinds of application using
different tool kits that are available
in the market. So the most popular tool kits available in the market
are fabricate and Seneca. So talk about fabricate first. So fabricate is a I saw was tool which helps with developers
provide configuration management system true get it is
an open source tool which handles Port mapping
and IP addresses complexity. So this tool basically holds
the responsibility to load balance services with high
availability and scalability. Now the features
of this tool are as you can see on my screen
it provides a set of wizards to create
application fasters and set up continuous delivery
pipeline fabricate also comes with on-premise Git repository
hosting this tool provides me with the positive. Manager promoted releases
along with the mirror of Central Maine
with repositories and provides the developer
console to create build manage microservices
with deep visualization into the projects applications and environments now talk
about Seneca first. Seneca is used for building message-based
microservices processes. And thus the toolkit for node.js so this toolkit
helps you to write clean and organize code
which systematic business logic of the application so
few features of cynical as you can see on my screen
says Uh provides plugins which look after the foundation
of the application. You do not have to worry about which database
has to be used and how to structure your components
with Seneca in Seneca. Everything is written as
a command and these commands get called whenever they match
a set of properties and the code that you call does not know
which command is calling it. So guys, this was all
about Seneca now since you have understood
about toolkits also, the next thing
that I would like to talk about is the different
architectural Frameworks. So architecture framework
is an important factor while building applications
using microservices and top to architecture Frameworks
used Argo and conch talk about go first. So basically go a is
an architectural framework which provides a way
to build rest apis and microservices using
go line with the help of this architecture framework. You can design apis along
with this required dependencies and this framework runs on top of the Google Cloud
platform few features of go are as you can see on my screen
this tool also lets you generate Structures validation
of code and handlers once the design of API set
it has a decoupled engine and provides plugins which can Implement custom dsls and also generate
arbitrary outputs. So that was about going
guys moving onto cam Congress used for ready to deploy plugins
for enhancing the development and deployment of microservices
with the help of this tool. You can leverage the container
and microservices design patterns to quickly
build API Centric applications. Now I've used this term microservices
design patterns, right? So if you have to
understand this term, it's basically a pattern
or you can say or software pattern
through which a company follows based on which
the application is built. So if you want to know
more about Microsoft's is design pattern, you can refer to my session
on microservices design pattern. But until then moving back
to this particular session, if you ask me the features
of Kang then congruence plugins to extend and connect Services across hybrid and
multi-cloud environments it analyzes real-time data and leverages ecosystems
to deploy Kong with kubernetes. Kang connects with automation
tools to improve efficiency and reduce errors and provides role-based
access control and encrypts end-to-end to comply
with the industry regulations. So guys that was
about the different architectural Frameworks present
in the world of microservices. Now, once you build
an application using Microsoft versus the next thing that comes into our mind is to how to scale the application
will to scale this application you have to use
an orchestration system as microservices work
with respect to containers and so container orchestration. Comes an important aspect
that has to be considered. So in today's market,
there are various tools regarding the container
orchestration for microservices, but the top tools available in today's market our
communities and sto so talking about communities first communities is an open
source container management or you can understand
as an orchestration tool this tool basically owns
the responsibilities of container deployment scaling and descaling of containers
and container load balancing. So if you ask me if your features of communities
and I would say Of these can help you to deploy
an update secrets and application configuration
without rebuilding your image and without exposing secrets
in your stack configuration. In addition to managing
Services communities can also manage your batch
and CI workloads. Thus replacing
containers that fail if desired not only this
but Cuban it is only needs one command to scale
up the containers or two scales in down
whenever you're using CLI as scaling can also be done by using the community
stash food, right? So if you want to know
about dashboard also, You can defer to my session
on Cuban piece dashboard and finally coming
to the last feature that is with kubernetes. You can mount the storage system of your choice what I mean
by that is that you know, you can either opt
for a local storage or choose a public
cloud provider like gcp or AWS or perhaps use
a shared network storage system like NFS or iSCSI. So that was
about Commodities guys. Let's move forward
with the next to that is STO now this tool support service
deployment on communities. So it basically
provides features. As for manageability security and reliability to microservices
communication now if you ask me, how is it done? Well, the answer
is quite simple. It is basically done by
the service mesh technology which allows you
to improve the relationships and interactions between
applications and microservices so few pages of sto as you can see
on my screen it performs automatic tracing monitoring and logging of the services
this tool automatically secure services to manage
authorization authentication and encryption of communication
between In Services, it also controls the flow
of traffic and API calls between Services conducts
a range of tests and upgrades with red
or black deployments and finally also applies
policies and ensures that their infos and resources are fairly
distributed among the consumers. So that was about is two guys
now once API management is done, you know messaging system
is done and then you have your tools for orchestration. Also, the next thing is
to monitor your application. So to monitor your application the top tools Can be used
as Prometheus and locks - so talk about Prometheus. First Prometheus is
a monitoring tool which basically allows
visualizing monitoring information and supports
time based tracking for anomalous patterns, which have to be detected. Also. This is an open source tool which basically gathers
monitoring information. So the features
for Prometheus are as you can see on my screen, it provides a flexible
query language, it comes with distributed storage
and single server nodes, which are autonomous it. Uber's targets wire
service Discovery or static configuration
and provides dashboarding and graphing support now talk
about the next monitoring tool. That is logstash. Logstash is also
an open source tool through which you can check
the logs this tool basically lets you stash centralized
and transform data. So the features of logstash are
as you can see on my screen, it supports a variety of inputs Which pull in
events from multitude of common sources all at the same time the stool
aims to transform and prepare data. Let's of its complexity. It also allows you
to choose your own stash and transport data. And finally it is
a pluggable framework consisting of over 200 plugins to create
and configure pipeline as you want. So that was about logstash guys
the finally moving on to the last part
of today's session that is Sir will is tools
now these tools are part of micro Services which optimize the methodology of breaking stuff
into small functions. So few surveillance tools that are very popular
Claudia dot Chase and AWS Lambda. Talking about Claudia first
Claudia is a surveillance tool used for deployments for a double s Lambda and
API Gateway this tool automate error-prone deployment and configuration tasks and also contains tools
such as Claudia bot Builder and Claudia a pi Builder. So features of Claudia are as you can see on my screen
it lets you deploy an update using a single command. It reduces the boilerplate code
with the help of this tool. You can also manage
multiple versions and you can use standard npm packages
and do not have to learn. Either the so that was about Claudia now
moving forward to the last tool that is a double is Lambda. Theta plus Lambda is basically
a tool which provides infrastructure less servers
for your microservices bills. And the user is charged
based on the paper usage rate. This tool can be
used in combination with the AWS API Gateway
to host a rest API service and with the help of this
you can serve any requests made by the users. So if you ask me few features
of a double s Lambda, then I would say this tool
enables you to run your code in response to the events and automatically managed
to dependent compute resources. It lets you run the code
without managing the server. So it pays
as you use the service and you only pay for the compute time consumed
this tools case an application automatically by running
a code for each trigger. And finally I would say this tool can be used
to build a server as back in for processing
mobile apin web request. So guys, this was all
about a double s Lambda. I hope you've understood
all the tools that are discussed here. Was just a short introduction
to all these tools in today's market Will Industries are using
various software architectures and applications. It's almost next to
impossible to feel that your data is
completely secure. So while building these
applications using Microsoft's has architecture security issues
become more significant as Individual Services
communicate with each other and the client. So in the session guys
will mainly discuss the various. Ways you can implement
the secure your services? So on that note, let's get started
with today's session. So the topic for
today's session are as you can see on my screen
will start this session by understanding the problems
faced in microservices. After that. I'll tell you the best practices
to secure microservices. Well guys the methods that I tell you are
not the only method well, I would say
in Microsoft's architecture. You have the complete freedom
to secure your services based on the application
or the architecture that you have right? So on that Note before I start with the session
I would like to request all of you to subscribe to our a Dirac
our YouTube channel to get daily notified on
the top trending Technologies. So let's get started
with the recession. Let's understand the problems
faced in microservices. Well, the problems faced
in microservices are as you can see
on my screen starting with the first problem
consider the scenario where a user needs to login
to access a resource now in micro service architecture, the user login details have
to be saved in such a manner that the user Not ask
for verification each and every time he or she tries to access that
particular resource right now. This creates a problem as user details
might not be secure and also could be access by
Third parties now obviously guys to anybody use a credentials are
the most important credentials which have to be secured
right now in a scenario where a client is looking to an application
to access a resource. The application gets
the complete credentials of the user. Now if the credentials are
not secured by those services, and that's definitely
a A problem because anybody can exploit it. So that is one problem
that I clearly see problem. Number two is
basically I would say when a client sends a request
then the client details need to be verified and also the permissions
given to the client needs to be checked. Right? So when you use Microsoft
versus it may happen that you know for each and every
service you have to authenticate and authorize the client. So authenticate is
basically to check what permissions are given to
you and authorize the client is basically to check
who are you right? So basically the
user credentials are checked now, too. Devon oppose might use the same code for each
and every service, right? So what I mean by that is when a client is trying
to access to data from different Services. It may happen that you know, the plan details have
to be checked to make sure if the data has to be
sent to that person or not right now to check that maybe a specific code
is used in all these services for a specific application like service ABCDE can all use the same code to check
the authenticity of the client, but don't you think relying on a specific code reduces
the You of microservices. Well, obviously,
that's a yes, right. So this is one
of the major problems. Also. I see in the micro
service architecture that the complete application
having various Services is based on a single code base and let's
say you build an application now with that particular code
in all the services to check the authenticity
of declined but let's say after 10 years that particular code
doesn't work. Now you have to change the code
for all these services and in the same time. You also have to make sure
that you know, nobody is exploiting
the data from the services because there will be
no security layer then right? So this is one major problem
that I see that you know that has to be catered. So the next problem that is very prominent in this particular architecture
is basically the security of each individual microservice. Now what I mean
by that is basically in this architecture all
the Microsoft is communicate with each other simultaneously in addition to the
third-party applications, right? So when a client logs in
from a third-party application, you have to make sure
that you know, the client does not get
the access to the data. Services in a way
that you know, he or she might exploit them right so it
obviously makes sense because he's logging
from a third-party application. Now maybe that particular
application is not that secure so maybe instead of the client
the third party application is basically trying
to access the data. So we have to make sure
that you know, the data is secure and not every
application is given access to the data in the services. Right? So Guys, these are few problems that I see very much prominent
in Microsoft's architecture. Well, there could be lot of
other problems based on secure. Aditi of microservices, so these are few problems that I thought would be
very prominent right now obviously seeing
so many problems. We have to figure out a way
to secure our services right now to secure our services. All we can do is we can put
up security layers firewalls and you know use
some methods to make sure our services are secure right? So on that note
next in the session, let's see the best practices
for microservices security what the best practices for
microservices security a lot. I would not say the ones that I mentioned are
the only ones there are a lot of ways to which you
can secure your services, but I would say
these are few methods, you know to which you can start
at least securing your services or maybe you can figure out
a way to at least make sure your data is secured. Right? So let's start with the first one that is
defense-in-depth mechanism. Now as microservices are known
to adopt any mechanism on a granular level, you can apply the defense in-depth mechanism to make sure
that you know, the services are
more secure now what I mean? By that is that
defense-in-depth mechanism is basically a technique through which you can apply
layers of security countermeasures to protect
the sensitive services. So as a developer, you just have to identify
the services with the most sensitive information and then apply a number of security layers
to protect them. So in this way, you can make sure
that you know, any potential attacker
cannot crack the security on a single goal and has
to go forward and try to crack the other layers
in the defense mechanism, right? So basically if you say No, so it was B is the most
sensitive service which has, you know, a lot of information
which has to be secured. Right? So what you can do is you
can basically have layers of security and maybe if some attacker
cracks the security of the first layer he or she has to still go
and crack the other layers, but by that time you'll definitely understand
that, you know, there's some problem
in security happening and then you'll again
secure Services right also since in the micro
service architecture, you can Implement different layers of security on
different services and attacker who is successful in exploiting In a particular service
might not be able to crack the defense mechanism
of the other services. For example, let's say
you have service a and service B and
let's say, you know, you have few layers of security and service a and few
different layers of security and service speed now, maybe an attacker
who has attacked service a and has cracked the security
might not be able to do the same with super speed. Right? So that was about the
defense-in-depth mechanism guys. Let's take a look
at the second best practice that is usage of tokens and API Gateway now often
when you open an application. You see a dialog box thing
accept the license agreement and permission for
cookies right now. What does this message signify? Well, once you accept it, your user credentials
will be stored and a session will be created. Now. The next time you go
on the same page, what will happen is
that you know, the complete page will
not be loaded from the server but will be loaded
from the cashier memory, right? So I hope that's clear. So for example, let's say, you know,
you open book my show.com. So now the first time that you open and then you
accept the license agreements on the cookie permissions
It would happen is that your user credentials
will be stored and a session will be created. Now the next time again, maybe sometime later you
open book my show again that particular page will be
retrieved from the cache memory rather than the service
itself right now before this concept came. It is picture sessions
with stored on a server side. Centrally. Now. This was one of the major
problems as you know, storing the session
centrally was being a barrier to horizontally
scaling the application. So to overcome that what people started
doing is basically everybody started using tokens. NEPA gateways to secure
the services right? So what would happen
with tokens statue? No tokens would be used
to record the user credentials. So basically you can understand that you have to conserve used
to store the user credentials. So these tokens are used
to easily identify the user and are stored
in the form of cookies. Now each time a client
requests a web page. The request is forwarded to the server and then
the server determines whether the user has access to
the requested resource or not. Right now the main problem
which is prominent in tokens is That the user information
is toward right? So the date of the tokens
needs to be encrypted to avoid any other exploitation
of from third-party resources and I would say JWT or most commonly known as Json
Web format is an open standard which defines the token format
to provide libraries for various languages and also
encrypt the user details, right? So guys just to avoid
storing sessions centrally what people started using is
tokens now tokens are used to store the user credentials
and since the user credentials. Stored into tokens tokens have
to be encrypted themselves. So you can go forward
and use JWT to encrypt the respective tokens right
coming to API gateways. API Gateway is adds
an extra element to secure the services
to token authentication. So the API Gateway
acts as an entry point to all the clients request and efficiently hides the micro
services from the client. So the client basically has
no direct access to the services and thus in that way
no client can exploit any of these microservices, right? So what happens is that you have You have a client
and then you have a pi Gateway Now API gate
we will communicate with all the apis present
in the microservices. Right? So basically a we are if you visualize the client has
no direct access to the services instead. It's just the API Gateway and it's completely
the responsibility of the API Gateway
to forward the request of the respective microservice. So guys that was
about tokens in API Gateway. Let's move forward
with the third best practice that is distributed processing and session management
the talking about Distributed raising all of you
might be observing that you know, while you use microservices, you have to monitor all these
Services continuously, right? But when you have
to monitor humongous amount of services simultaneously that definitely becomes
a problem, right? For example, if you just have to monitor
fire Services then maybe that's an easy task
but in a scenario, maybe if you have to monitor
fifty or hundred tasks simultaneously and 24/7, then that's a problem right
now to avoid such challenges. What you can do is you can use
the method of distribution. Debated tracing so
distributed facing is basically a method to pinpoint
the failures and identify the reason behind it. Not only this but you can also identify the place at which
the failure is happening. So basically with that
you can easily track down which micro service
is facing a security issue. Like for example,
let's say, you know, you have five services and then
there's some error happening at service be right so you
can directly go and pinpoint that it is because of service be there's some failure
and maybe then you can directly go and figure out
that you know, Some security issue
at service be rather than to check all the services
and the complete application, right? So that's what distributed
tracing helps you guys with makes you identify. Where is the failure happening? Why is the failure happening
and then bit servers? Is it affecting moving onto session management
session management is an important parameter
that you have to consider while securing microservices. Now what happens is that a session is basically
created whenever a user comes onto the application. So what you can do is you
can handle these sessions in many ways. I could figure out free ways. The first way is basically
you can store the session date of a single user
in a specific server what I mean by that
is the session date of user a is maybe we stored on the server a the session date of user B is basically
stored on server be and session date of user
see is basically stored on servers see right? So in that way you can make sure that if there's
some exploitation of services then you
can track down which user is doing it directly
without having to figure out what is happening in all you can allocate
track down that you know, maybe use a Is exploiting
or user be your user see right? But the only problem over here
that I see is that you know, if the system is completely
based on load balancing between the services and it meets only horizontal scaling rather
than the vertical scaling. So for small applications, which let's say, you know have three to four
Services maybe this kind of system can be used but if you want
to use this scenario for a large application that I think that will create
problem right coming to the second way. Well, what you can do is the complete session data can be
stored on A single instance then what can happen is
that you know, the data can be synchronized to the network and the requested
responses can be generated and you can also make sure that you know, the data doesn't
go anywhere, right? So what happens is
that you know, you have a single instance
and then through Network. The data is completely
circulated between services and the climb now the problem if you think over here is
basically the exhaustion of the network resources, right? For example, let's say you need
a data from 10 Services rate and all the data
is completely stored on the single in stairs now. These Services have
to communicate with that particular instance
get the requested response and then finally sent back
to client right now. This is a little bit problematic when you have
that Services again, but I would say
for small Services you can move forward right now. Finally coming to
the third method. What you can do is
you can make sure that the user data
can be obtained from the shared session storage. So as to ensure that all the services can read
the same session data, so what I mean by that is
if you have fire services and the fire Services
need the user data, then the the user data
is obtained from a shared session storage to which
the data can be retrieved. Right but since
the data is retrieved from a shared storage you need
to make sure that you know, you have some security mekansm
to access the data in a secure way. So basically you have
to make sure that you know, you add another security
layer Maybe by using the defense-in-depth mechanism
to make sure that you know, the data is encrypted
with the help of tokens, or maybe you know, you have a specific firewall
that you know, not all of them
can access the data and no third party applications
can access and only a few. Admins can access right so you can use it the way
that you want. So guys that was
about distributed raising and session management. Let's move forward
with the next practice that is first session
and mutual assistance. Now, the ideal first session
is really simple guys. What you can do is basically when the users log in
for the first time into the application, then they can access all
the services in the application. Right? So what you can do is
whenever the user logins for the first time you
can store his or her details in an encrypted format
in a secured way, so that it Don't have to keep
verifying their credentials each and every time there are trying
to access different servers. For example, if you have 10 services
and maybe the user needs to log into all the 10 Services. What you can do is you
can have an initial login and when the user logs in
for the first time maybe he or she gets access
to all these services, but the only problem
over here is that you know, you have to make sure
that you know, the user who is trying to login
is a client himself and maybe he or she is not an attacker
then is not trying to exploit the resources
right coming to Mutual SSL. Applications often face traffic from users third parties and
also microservices communicating with each other right but since these services are
accessed by the third parties, there's always a
risk of attacks. Now the solution
to such scenarios is by using Mutual SSL or Mutual authentication between microservices with this
the data transferred between the services
would be encrypted and the only problem
with this method is that you know, when the number of micro
Services increases then each and every service will have
its own TLS certificate. It will be very tough for the developers to update
the certificates else. If I would say the developers are ready
to update the certificate and maybe they're not scaling
the number of services then I think they can go forward
with this particular method. As you know, each particular service will
have its own TLS certificate and that particular
certificate will Define which Microsoft was
has what access and which data can be retrieved
from each of these Services. Right? So mutual SSL sounds
like a good option guys. I think you should go
forward or not. But the only thing is that when
you're scaling your service. You have to make sure
that you know, you have to update all these TLS
certificates on that note. Let's move forward
with the final practice. That is the third
party application axis. Now all of us access applications, which
are third-party applications. Right? So the third party applications
basically use an API token generated by the user in the application to access
the required resources. So the third-party
applications can access that particular users data and
not the other user credentials. Well, this was with respect
to a single user but If the applications
need to access data from multiple users, how do you think
such request is accommodated? Well, I think the solution
to this is by using Earth. So when you use all
the application prompts the user to authorize
a third-party applications to use the required information and generate a token for it. So generally what happens is that an authorization code
is used to request a token to make sure
that you know, the users callback URL
is not stolen right. So in this way the user
of the client communicates with the authorization server
one mentioning the access token and also the authorization
server authorizes the client to prevent others from forging
the clients identity. So when you use microservices
with odd guys, the services act as a client in
the odd architecture to simplify the security issues, right? So I would say guys all
these methods that you know that have explained you are one
of the best practices that I've observed
to secure your microservices, but if you ask
my personal opinion, I think I would always go
for allthe with a collaboration of JWT that is basically
generating client tokens. I know Bees follow
the defense-in-depth mechanism to make sure
that you know, there are a number of
security layers to my services so that the data stored in my
services is completely secure. Right? So if you're someone who is aspiring to build
an application based on microservices, the remember that the security of the services is
one important factor, which you need to be
cautious about today. We are going to take a look
at top microservices interview questions. And by the time we are done
with the session, I'm sure that you all would be
in a very good state to go ahead and crack
any microservices interview. So let's not waste any time
and quickly get started then so the first question is what are microservices now think
of it as an approach towards software development. What do I mean by this? What this approach does
is it aims at having small autonomous services that Focus towards
a common business goal. Now as you can see
in this image, what we have is we have a number
of business domains and surrounding that are
certain micro services. Not each of these micro
Services they focus at a particular business
functionality only that means if a particular business domain
has a twenty functionalities, each of microservices should
focus at one functionality only for 20 micro Services 20
corresponding functionalities. So that is how you
simplify an architecture and this approach is called
as microservices architecture as we move further. We would be understanding
a lot more points and Concepts about microservices. So your have A lot more clearer picture as to what
a micro service exactly is. Meanwhile, you just bear with me
so that we can move further and discuss the other
questions as well. So what are the advantages
of microservices architecture the quite a few advantages
to be honest. These are some
of the important ones which we have jotted down. The first one is
independent development. Now when you talk
about microservices, you have to relate
it to this point because we are
talking about having an individual micro service
for individual functionality. That means for
each functionality. And develop a separate service
and you can manage it and control it totally
apart from that. We also ensure
independent deployment. That means if you
have developed a single service, you can go ahead and deploy that service you
do not have to wait for the complete architecture or other services to be ready
and up for deployment. Even if there is
certain amount of change in a particular service. You have to make change
only to that service and then deploy it again you do
not have to deploy the complete. Architecture here
fault isolation. Now, if a particular
micro service goes down. It does not affect the
functioning of other services. Now, what do I mean by this? Say, for example, I have an architecture where I
have some 20 applications or 20 Services
working parallely, if one of the application
fails at times what happens is these
applications are interdependent as it is in the case of a monolithic
architecture basically, if one of the system fails
or one of the services Fields, it takes the whole
system down now, this is not true with Says
if one service Fields, it does not affect the
functioning of other services in any possible way
mixed technology stack. Now, what do I mean by this? Well, since you have
different micro services and you have an independent
approach towards development, you can go ahead
and pick the technology that suits the need
of that service and accordingly. You can have a mixed technology stack for a complete
architecture granular scaling on this is an important Point
scaling can be a huge problem because again, you have to take
into consideration the complete architecture but Since you're
having small Services, you can actually go ahead and
scale those independently again, these are some of the advantages
which I just mentioned. So let us move further and take a look
at the next question as well. What are the features
of microservices? Well, the first
feature is decoupling. That means your applications
can be easily decoupled or rather separated to have
individual functionality. And that means it assures
easy development maintenance and deployment componentization. Now this point is similar
to the first point. But it is little different what happens here is
every micro service is treated as an individual component and it is responsible or manages all the intricacies
as far as a particular Services concerned and it
focuses only on that. It is Loosely coupled
with other services. That is why each micro
service can be thought of as a single component or a container
business capabilities now business capabilities
can be focused much better because why since you
are setting up smaller goals as and you focus
on individual functionalities, it becomes easier to go ahead and develop applications
to meet these requirements. As far as the business
is concerned autonomy. What happens is
your developers are now free because you are talking
about small clusters of teams and they're free to go ahead
and develop the applications that means other
teams and developers. They aren't interdependent
on each other this, uh shows Speedy development of software basically
continuous delivery now since you have so many features
with Just discussed this ensures that you have constant
and frequent releases of software's and a system
can be continuously updated and basically modified
as per the needs of a particular company or a particular business domain
rather responsibility what happens in this approaches
every domain or every project is treated as a product that means a team
will take responsibility of that so-called product and they'll bring it
to life and it is their responsibility to build. It tested and carry on
with the whole life cycle. That means people are supposed
to take in responsibilities of the micro service
that is there. And this helps in a much better architecture
other decentralized governance. Now, what happens is since you have
individual applications, it is very important to have
an independent approach towards the life cycles
of each micro service since they are
working independently. They should be managed
independently as well. And this also brings
in another concept into picture which is
decentralized data management. As we move further we would be
discussing that as well agility. Now what happens is since you have a decentralized
architecture here, you can easily go ahead
and build applications and also discard them if they are not needed so it gives you a lot
of agility basically. So these are some
of the features of microservices let
us move further now, what are the characteristics
of microservices now first few questions
might sound a little repetitive because these concepts
are kind of interlinked so we would be discussing quite
a few Concepts again and Again, but as we move further, the breadth of questions
are the type of questions would definitely very and we would be having much
more new topics to discuss this question on the other hand
might sound a little repetitive. So just bear with me. Let's quickly walk
through it and let me just try to give him
some answer to this question in a little different
perspective other so firstly we have organized
on business capabilities. Now, what do I mean by this? Basically what happens is since you have
individual microservices here? What happens is you
have an application? That works on its own. You also have a database that corresponds to
individual microservice. That means if you have
10 Micro Services, you'll have 10 individual
databases that are corresponding or answering only
to that particular microservice. So this gives you a complete
decentralized structure and this also means better organization because every micro service is very clear as to
what it is supposed to do and it has all the resources in that single container as
to this is what is to be done. And this is what we are. Ston and that is
why this organization or better management comes into picture products
are not projects know. What do I mean by this? Well, basically what happens
is suppose you have against it then microservices and you'll be having
small clusters of team who would be responsible
for building up this application and also maintaining it now what Amazon things is you
should have a tupiza team. Basically, what do
they mean by this? Well, they mean is you
should have such small team that can survive on too. Users and they should also
be able to go ahead and maintain the software. So every responsibility
as far as a software and application is concerned. It is given to that size
of a team that is that can survive on to pieces
this ensures modularity. That is why when you
talk about microservices, basically you're talking
about products when you talk about a team, they're focused on
a particular functionality and that functionality is
not as a project for them. It is more of a product
for them smart endpoints and dumb pipes now, basically this means that you have
different Equations and the quite decentralized and there has to be a way
of communication basically, so you should have
smart and points and good ways to integrate your applications with each
other decentralized governance. We've already discussed
this Poncho, I would just skip this point for now these
centralized data management. We've also discussed this that means you're free
to have an individual approach where you have your own database
and your single database in a microservices treated
as an individual entity or a container rather
infrastructure automation. This is an important point now since you have so
many microservices. It is important
that there is proper automation. This ensures Speedy development and also maintenance
design for failure. Now, this is
another important point. Now your applications
are such built that they do not hamper the progress
of any other applications even when they feel but still you
need to have a mechanism that takes care
of failure as well. So you have real-time monitoring
and Analysis here which ensures that if an application goes down
the Possible action is taken. So that that application
also comes back to running and also it does not
hamper the working of any other applications
in any possible way. So what are some
of the best practices to design microservices
now it is pretty evident. You can just go ahead
and read these points and you'd understand what it means firstly you need
to have a separate data store for each micro service, which we have already
discussed this one because we have a database which corresponds to
particular micro service basically keep code
at a similar level of maturity. Now, what do I mean by this? It means yes. You have enough freedom to go
ahead and build application the way you want to but each of these applications are at a similar
level of understanding when you talk about a similar level
of understanding you're talking about a similar level from
the business domain perspective and what this means
is all the teams are on a similar page even though they're working
on different things. They all are
on a very same level when they're working separate
built for each microservice. Yes, we've discussed this
already these micro Services they get deployed in containers as we Move further
would be understanding what containers are
and what they do exactly and it treats servers as stateless this helps
in better communication. Basically, what is a DDD now? It stands for domain
driven design again. It is an approach an approach that actually helps
you collaborate all the teams together and it also
helps you simplify the creation of complex applications. Now what this does is
it focuses on codomain and core logic at times
you let go of what is right for you rather you focus
only on the business. Men, that means this is what the business domain
needs and this is what we would include
in this architecture. This kind of an approach is
called as domain driven approach or a domain driven design. Basically now, what they do is that try to bring again
every team on the very same page and you would be using something
called as a ubiquitous language which helps you achieve this
domain driven design approach. Now, what do you mean by a ubiquitous language to give
you an example suppose? I have a ticket reservation
system for flights now. here all the terminologies that are used would be related to maybe aeroplanes
flight attendants customers and all those things now, even if a manager refers
to this so-called architecture, you should be able
to understand the terminology that are used here
and also the developer that means we are bringing
every team on the very same page and a language that does that for you is called as
a ubiquitous language now again, a cubic lattice language
would be designed in such a way that it focuses
around a particular domain and Architects that is developed out of it is called as
a domain driven architecture. What is a ubiquitous language? We just discussed
that so why is there a need of a domain driven design? Yes, the quite a few reasons
actually firstly we need to understand that here. The focus is
on a particular domain. So if you take a look
at the last point on the left bottom side of the slide,
you would understand that. It is mapping to a domain that means we
are mapping our architecture to a particular domain that means you're focusing
on on that particular day. I mean now this helps
you reduce complexity why because your concern
is just that domain again testing the application
also becomes easier and maintaining it
also becomes easier because everybody is on the very
same page knowledge design. Yes. This applications are
very heavy on knowledge that is particular
or that is very much focused on a particular domain
it brings business and service together
and it is very context focused. Plus it uses
ubiquitous language. So, how does the architecture
of Microsoft's work and when you talk about micro
Services architecture now, there is no particular pattern
for this kind of an architecture because it can be
very complex at times. And if you have n number
of micro Services, all of those will have
different architectures, but you have to understand one
thing the base Remains the Same that means no matter
how complex or how big actually the architecture
will never become complex. But yes, it might become big because we might think
of having n number of micro Services maybe
thousands and even laxatives. Required if the application is
that big but let's say that you have an application
which is huge in size. No matter how huge it is it
would never get complicated because we are developing
small applications here. And each of these
small applications will have an architecture that is more or less like this or at least would be
on these pages. So what do we have here? Basically, we have a client
and identity provider. We have API Gateway
static content CDN, which is nothing
but content delivery networks we have Travis has a management
and a service Discovery portal or a model rather
and you have your servers and all those things
and basically what happens is if a client wants to use
a particular service the client would send in
a request now it is the job of an identity
provider to verify whether the user
is valid or not. Once the identity provider
authenticates a user the request is then forwarded to API Gateway because a client cannot directly
communicate to a service that has to be
an intermediary or something. Intermediate approach that lets us communicate
with the micro Services as well. Now in this case. What happens is
we have a pi Gateway. Now this API Gateway, it finds the right service
that a client is looking for and the request is forwarded to that service the service
does it basically communicate with other services and sees how a solution is generated
for this so-called client. And once the solution is generated it is sent back
to the client using Siri. And that is your content
delivery Network. Now the static column basically
what happens is whatever content that is generated
and Is in the form of static it is basically
held by a static content and the management and the service
Discovery Porter 's they have a particular
task as well. What they do is say for example,
I have a number of services now the Management console
or the portal places those services on respect
your notes service discovery on the other hand keeps a track of all these Services
makes note of services that have failed
and all those things and this record is communicated
back to the management portal and it is the job of this management portal
to go ahead and resolved if there is any Failure in
the corresponding architecture or any of the services. So these components all of them
they work in Tandem and this is how they bring the architecture together apart from that
there some other Concepts which are not there in this architecture
say for example, the messaging module basically, so we have an approach where messaging also
happens in case if the client is waiting
for a particular reply from a service in that case. We have a way of communication
and that we have communication is through
synchronous message passing and if the One be waiting for a response from
the service in that case. We have a synchronous
way of communication. So yes, there are
those little components which are not there
in this diagram, but they do exist and
as I've already mentioned based on every architecture it
might be a little different but this is how the general idea is when you talk about
a micro Services architecture. So let us move further and take a look
at the next question as well. So what are the pros and cons
of micro service architecture? Well, we've discussed most
of these points already, especially the pros we've
already discussed those. So I'm just going
to read them quickly and switch to the con spot and discuss those as
well freedom to use different Technologies discussed
each microservice focuses on a single business
capability discussed support individual Deployable units discussed allows frequent
software releases ensures security of each service and multiple services
are parallely developed and deployed. And what are the cons
it increases troubleshooting challenges and increases
delay due to remote calls? Yes. This can be a problem by
because you're talking about a number of micro
services and at times since they are so independently working that the whole system
as an architecture when you talk about troubleshooting
certain challenges, it can be a problem
because we are talking about a complete
decentralized governance, but that is something
that can be managed. And as I mentioned we
have different portals that take care
of all the services and and these searches are since monitored in real-time. This does not become
a huge issue increased effort for configuration
and other operations. Yes configuring these
applications can be a problem. But then we have something
called as rest apis that ensure complete integration
of these services. And again, this issue
can be taken care of difficult to maintain transaction safety security
can be an issue and that is a concern that affects almost every software and you cannot be
hundred percent secure. Any possible way but this approach gives room
for security as well tough to track data across
various service boundaries. Yes, again individuality
may not be always good. So this can be a drawback and difficult to move
code between services but that is not needed
in most of the cases. So that is not a
problem here again. So these were some
of the cons and the pros which we've already discussed. So let us move further and take a look
at the next question. What is the difference
between monolithic SOA and a Service architecture. Now when you go back in time, the first architecture
that we had was a monolithic architecture. That means you had
a single container that had the complete
architecture all your services all your databases
not all our databases. Basically you had
a single database that corresponded to all
these services and yes, all the interdependencies those
were inside one single container now all the advantages that we discussed
about microservices become a disadvantage here because since you had
a single container or a Architecture deploying was a huge issue
a single failure would mean that you would have to go ahead
and work on the application and then deploy
the complete architecture. There was no fault isolation because if something failed
everything depended on it and then you had to go ahead
and repair that part and the other services had
to wait for that thing to mend and then go back
to working again. So yeah monolithic architecture
had quite a few other problems scaling was a problem as I mentioned fault
isolation was a problem. Then there was
no individual development. It and deployment
was a huge issue. So this architecture to simple to build actually it wasn't even
simple to build to be honest because you're talking about a complete
application development. And since you do not have
individual applications that are being developed
the whole team had to work in together and bringing up such
huge teams can be a problem. Plus there is too
much dependency on each other. So this also affects the functioning or basically
development of a software so it wasn't even condition or easy for development
in any possible. By the way, so these are some
of the disadvantages when you talk about a monolithic
or a single unit architecture when you take a look
at the next approach that is SOA. It is similar to Microsoft
versus but here the differences. Your monolithic architecture
is basically divided into smaller units, but these smaller units
will also have some subunits and that means you do not have complete modularity you
do have modularity, but that is to a smaller extent
not to the best possible extent when you I want
complete modularity. You have to go ahead
and choose microservices where if you take a look at monolithic it is
a single architecture SOA. It will have say
four features in this case. And each of these features
will have individual modules that is not the case
with microservices will have individual models directly
or the complete modularity that we are looking
for when you talk about features features are just
for the reference shake and all of these modules
would be able to go ahead and refer these features. So that is the difference
between SOA and microservices. These two a little
close to each other so we can just go ahead
and discuss those but when you talk
about monolithic architecture, it is completely different
from these two architectures. And there you go. We have the same question that is what are the key
differences between SOA and microservices to be honest
the quite a few differences. That means the approach
is very different when you talk about SOA
the focus on sharing almost everything with other modules, but when you talk about microservices here the aim
is share a As less as possible. So the approach is completely
different apart from that as I've mentioned you have
modular applications in SOA. But there are still
a lot of interdependencies that is not the case
with microservices. Basically. The other thing is when you
talk about intercommunication between services in SOA, you need a middle way for
communication but microservices that completely independent
and you do not need a middleware the directly communicate
through rest apis if you take a look
at this architecture or Image what you see here
is it is nothing but a shopping application. Now, these are
the three common things that you need you have
a user account application a shopping cart application and
a product catalog application. Now what happens is inside these applications
should be having - Alice's. So what microservices
does is it just goes ahead and has three features not as a shopping cart
feature product catalog feature and a user account feature. Now this feature will have
nothing but those policies or are those functionalities that would be needed by
the individual models that your essay is hiding. So you have these three features and apart from that
you have the modules that are independent
of all these features and they can just go
ahead and use these features if required say, for example, you need something
like display product service or update your display service. Now, you have
various other things like check inventory service
product rating service now all these are terms related
to your chopping application. But as you can see that this architecture
is completely independent and it is Modular compared to what you have in an SOA kind
of an architecture. So these are some
of the key differences when you talk about SOA
and microservices. Let us move further and take a look
at the next question as well. What are the challenges
with micro service architecture. Now when you talk
about challenges first thing that should come to your mind
is automating the components. Yes, you can go ahead
and automate all the components but maintaining these components
is a used task and automation is working
smoothly something that needs. It's constant attention
configuration management and possibility perceptibility. Basically now when you
talk about positivity and configuration management, you need to understand that this is nothing
but an approach that deals with the complete
design that you're talking about and configuring
these mini micro services and having clear architecture for it can be a problem at times debugging now
debugging is another issue here because we have fault isolation
and if some application fails, it does not affect the working
of any other application, but that also means That you also have
to be continuously monitoring. These applications are individual monitoring is
something that has to be done. And that is why when you talk
about system failures dealing with such failures
can be a problem in the overall architecture, even if it does not
affect the functioning of other applications still that application has gone down
and it needs to go up. So monitoring becomes a problem
here plus troubleshooting so many errors for individual microservices
can be a problem at times. So the next question
that we have is cohesion. And now when you talk about
micro Services architecture, you need to understand
it is a designing pattern of when you talk about
a designing pattern two points that should come to a head
as cohesion and coupling because a good design
will always have high cohesion and low coupling to understand this we need to understand
these two terms as a know. What is cohesion and Waters coupling cohesion
is nothing but the bond between an application or an intra Bond within an application
to give you an example. We have a molecule. Inside a molecule will be having
atoms now these atoms how closely are they
bonded to each other? This bond is something
that is called as cohesion now cohesion
should be high when you talk about a micro service that means we
are referring to the fact that the interdependencies inside a container
the database and the service that is running how closely or how well gelled up
are these with each other if they are very closely bonded that is good for
the Crow service now when you take a look at it
from a bigger picture, you're talking about different
microservices the bond between these micro
Services should be low. I mean, if one fails it
should not affect the other one if one is being developed the others one should
still work smoothly that means inter bond between two applications
on microservices. It should be loose. That is why we are talking
about low coupling and this inter bond is nothing
but coupling in trabant inside. Container it is cohesion in Te bond between
two different applications or two different
containers is coupling. That is why when you want a good
design you need High cohesion and low coupling. The next question is
what is rest and restful and what are its uses now, these are nothing but apis that means application protocol
interfaces now rest stands for representational State transfer. These are more or less used for integrating with
the applications much better. Now, you're talking
about a decentralized. Picture and to bring up
such an architecture. You need to have
a medium through which you can communicate
with all these services in a much better way and your rest or restful apis
basically help you do that. What is an actuator
in a spring boot. Now? This is something that would
give you real-time analysis or rather it would give you or
let you monitor your application when it is in
its production State. Now what it does is it
just goes ahead and gives you all the information
about a particular application. That means you can go ahead. And monitor all of its metrics that is what in actuator
does it gives you information about an application
is running State. What is spring boot
now for that? You need to understand
what spring is now when you talk about
spring the first thing that should come to your mind
is it is nothing but an approach towards software development or not software
development basically web services development. It gives you all the ingredients that are needed as
far as a web application is concerned think
of it as a shop where you get all
the ingredients for. Or web development when you talk about spring boot
it is the customized version of your string to give
you an analogy think of this approach or related with something called
as cooking and eating food. Now when you have spring here, you'll have all the ingredients but you'll have to go ahead and
cook your own food and eat it when you talk about spring boot. It is a customized approach. We have Ready-to-Eat
food, right? So ready to eat food all ready
to cook food is something that is your spring boot. That means all your ingredients
spices would be Next all you have to do is
you have to put that foot inside the oven heat it and eat
it as simple as that so that is what spring boot is. What is a spring Cloud now when you talk about
a spring Cloud again, it is something that lets
you get real-time analysis and perform finite amount
of data processing. It is nothing but an API that is provided to you by
Spring and it helps you get rid of various complexities as far
as an architecture is concerned. So what are the problems that are solved by
a spring Cloud will firstly what it does is it It
reduces the complexity with distributed systems
or the complexity that is associated with distributed systems service
Discovery becomes very easy. And it also helps
in load balancing. It takes care of redundant code
and application development and does help
in improving performance. So what is the
difference between rest and microservices now, you need to understand
this point that micro Service as I've already
mentioned is an approach towards software development
rest on the other hand. It uses this approach and helps
you develop applications. Plus microservices when you talk about these
small individual applications, they work very well
or function very well. Plus it becomes very easy
to develop microservices when rest is used for developing
these micro services. So these two are
kind of interdependent, but you need to understand
this basic difference micro service is an approach rest is
a way of building microservices. What are the different types
of tests for micro services and the quite a few tests. I mean if you ever
heard or learned And testing to any extent, I believe since you all are
here for the session you might have heard
about basic testing that is manual testing
and automation testing and what those things are or at
least read about it a little if not do not worry. I would be talking
about these as well. But these are very
common terminologies and they're used in almost
any kind of testing. So let's go ahead and try to
understand them a little more. So when you talk about
micro Services architecture, it follows the pyramid law
as we move further, we will be discussing
this as well. So when you talk
about pyramid law Certain tests. They are actually performed
at almost every Stitch and those are at the highest
priority of the pyramids that forms the testing
parameters what I'm talking about so certain tests
as I mentioned, they have higher priority
or not higher priority rather. They are implemented lot
more times than the other tests. Those tests are
your unit tests basically and to some extent atoms
performance testing as well. But to just to some extent not completely then you have
at the second level. You'll be having
your Your exploratory tests where these tests
are also happening or happened frequently, but not as frequently
as your unit test and then you have
your acceptance test and performance tests. Now these tests are
for the stakeholders. That means when you're
presenting or giving your end product, so these are superficial
not superficial but they actually go ahead and just test the end working
off an application. So they happen very less
compared to the other two tests. So these are some
of the different tests that are used as far as
your This is a concern what is coupling? I believe we've already
discussed this point. So just let us move further. What is a
distributed transaction. Now, you're talking
about a number of applications or services. So all of these services
will commit changes. So when you commit changes
to a particular client request what happens is
you need to make sure that all the applications are
on a similar page. So we have something called as think of it as
a managing entity that ensures that there is a commitment
for a particular service. From all the applications
are all the services and when that commitment
arrives it is then that a transaction
is completed and this kind of a transaction is called
as distributed Transaction. What is an Indian potent? Slaw and where is it used? Exactly. Now when you talk
about an Indian potential you have to understand one thing
there are certain results where you would want uniformity. That means if there would be
a particular application that would execute 10 times, but that should not vary
my end result. That means No matter how many times the application
executes the end result should be same each time. So to ensure this we have
something called as an Indian potential law
or that is what it does. Basically it ensures
that uniformity. What is a bonded context now, when you talk about
bonded context you need to understand this point. We are talking
about micro services and modularity to
give you an example on the organizational level. We have different teams working
on different things like like your marketing team
focuses on marketing. Your product sales team has
the job of selling your product. You have a development team that develops your product
a maintenance team that maintains your product. So you'll be
having different teams. They would be having
different concerns and different interdependencies. So each of this team
should exist in a single module now same as with the application
development as well. Your each module should have
its own independence. Now this kind
of an approach is called. Does a bonded context
or a bounded context that means your application
is bounded Within These limits and these are the things
you use and this is how you go ahead and proceed with the application or towards
your functionality rather. What is a
two-factor authentication? Well, you're talking
about most of the transactions that we do these days. Yes, we use
two-factor authentication, but we do not realize that we are using
that to give you an example. I use a Motorola phone
and it has as a finger scanner, but at times when I use or restart my phone
or reboot my phone and I use the finger
scanner to unlock my phone. It says enter in the password. That means I've given
in a fingerprint as well, but it still needs a second level authentication
just to verify that. I'm the very same person. So next time I enter
in the four digit password, which I have set and it unlocks. This is in a
little reverse order. Normally what we do is we enter
in the credentials and then we All these Biometrics
but this is an example of two Factor authentication. Another example would be
your ATM transactions. When you give in
your credit card details, you're actually putting
in your credentials. That is a card number
your name and you see we but when you do enter
those details you are expected to also enter the OTP that means what your car
does is it re verifies that the details that you've given are correct
and you are the owner of this card and also the number which you've entered and it is this turd
with your service. So this is where the second step
of the authentication happens. So this kind of an authentication is called
as a two-factor authentication what a client certificates now think of it as
gateways or passes if you have to go for a movie
you would be buying passes or if you have to go ahead
and attend certain concert. Let me give you another example
a bit example say for example, you visit certain restaurant
or maybe some club now they're what you do is you pay
in your cover. I just right so you
are given a band or something, which says that for tonight. You can go ahead
and you can use the services. So once you have
that band on your wrist or whatever card or something, when you go in you
have certain freedom to go ahead and use
maybe the dance floor or consumed there whatever
it is cocktails of food and all those things. So this is what
a client certificate is. Like when you have
a particular application when you have
a client certificate, you have a digital certificate
that tells you that you can go ahead and use
a particular client system or your authenticated to go ahead and use
following Services. Basically, what are the types of credentials of
a two-factor authentication now, we just discussed it
with few examples. Let us just walk
through these points quickly. Now, what are the credentials
that would be needed something that you know or in
simple words it is nothing but your credentials your card
details or your CVV number and all those things
something you have here again a part of your credentials that you have and which you
Enter and finally you have your something you are this is where they're referring
to the fact that if you're using some Biometrics
in the example, which I gave you where I used my finger basically
for the scanning purpose not is what they mean, maybe our retina scan
or all those things. So something you know
is your credentials your password and all
those things something you have is your OTP or the value that is generated back to you
and something you are is nothing but your body scanning
son all those things which you use for unlocking. So these are the credentials
yells you might require when you talk about
a two Factor authentication. Okay. So the next question is
what is the use of packed in microservices architecture
now you can think of it as a testing approach. What it does is it lets
you test your contracts basically now not contracts since you have a provider
in micro services and a client that is using these Services
now both these teams are these people they come
on terms or an agreement. Now when you talk about
these agreements you're talking about communication
between these two. And these communications
are governed or rather tested by something
called as a pact now, it is nothing
but a testing approach and it is used for testing
these communications, which I just discussed. What is an oauth. I mean you talk about oauth you're talking about open
authorization protocol here. You can actually go ahead
and use the Provider Services and to do that. You will have to go ahead and
use some third-party tools which would let you
access those Services. What is Conway's law now, this is something
that helps you. Maintain the Integrity
of an organization. Now when you talk
about an organization, they would be
having applications or a particular structure
for the applications that are built now if a new system or a new application
is to be built. It has to be
on the similar lines or the guidelines that the organization has
defined to give you an example. Coca-Cola makes cold drink ends. Now when you talk
about these coding cans, they have fixed dimensions and those have been decided
by the He's organization. Now if they're launching
a particular product, they might not make
the exact same can but what they would do is they would
be having certain principles that need to be followed
that keeps the other product or the newer product also
on the similar lines. Now, this is what Conway's
law preserves each time. You have a new system. It has to be constrained
or it is constrained with the properties
the organization follows. So this is what Conway's law is
as you can see in this image. Image organization has
a particular definition as far as a software
development is concerned as you can see the organization
has a particular approach what Conway's law does is
it lets you have a system that follows a similar
approach and that is what is reflected in the system
that is being developed as well. So the next question is what is contract testing now
contact testing is nothing but a superficial testing superficial again
would be a wrong word, but it is a test
that does not go. But our test
the complete application and what do I mean by this? These are more or less
the behavioral tests and these are done
just to ensure that the system is working fine
or the expected output. As far as the system
is concerned is up to the mark to give
you another example, we all appear for examinations
suppose you need to prepare for a particular examination and you maybe prepare for it
for say three months duration and then comes in your exam time and you revise it for two. Days, and then you go for the exam and on
the day of exam. What you do is you
just Overlook or walk through the concepts quickly
of this kind of an approach when you bring it into testing. It is called
as contract testing. What is n 2 N
microservices testing now, this is completely opposite from what we just discussed to give
you an example think of it as your bike servicing. Basically when you give you a bike for servicing
there are certain issues that do not occur every time
you give your bike for servicing say for example
your break Failed completely and your brake wire
needed replacement. Now, this is something
that won't happen every month, but this was an issue this time
but there are certain things that happen every month. Like you're always
checking your bike washing tightening certain screws
and all those things. So this kind of an approach that happens every now and then
has to be done frequently or has to put an end to end. This kind of testing is called
as end-to-end testing. Now when you talk
about microservices, you would be having
quite a few loose ends because you're talking about n number of Services
bringing them together and fixing in the loopholes
can be a problem and end-to-end testing fixes
those loopholes and this is something that is little
out of context to explain. This'll have to go
into something else. So I would rather
skip this question and move to the next one. What is the use of a container in microservices now
this gives you modularity you have your code libraries in a single container
your micro services and also the database now, this means your application
it works independently. So this is what a container
Does it gives you that modularity what is dry
in microservices architecture since you're talking
about too many applications and too many microservices. There might be a possibility
of code redundancy. Now what happens when the code redundancy
Yorkers will basically what it does is there might be
a piece of code which everybody is writing instead. What you do is if you have
a particular set of code, once you write it you kind of patent It Baton
won't be a right word, but you would create
a library out of it. Once you have that Library, it can be used by
others as well. And that is what dry stands
for don't repeat yourself. This ensures code
reuse ability a code that has been created by someone
and if it can be used by others, let them use it
a consumer-driven contract. Now this kind of a context used
to keep people on similar pages. That means your provider
is allowed to set certain set of rules when he is deploying
a particular application and the consumer who wants to consume
that application when they have this contract. Basically try to be
on the similar page that means client has
a particular set of requests and when the client mentions
those requests to the developer or the provider, he should adhere
by those requests. So this kind of an contact is called
as consumer-driven contract where consumer is made a priority and accordingly
a software is deployed. Basically, what is the role of web restful apis
in microservices again, rest plays a very important role, I believe
we've already discussed. The point microservices you're talking about
independent development. And for that rest is a very
good approach of web services, which can be used and it also provides
you with various apis that help you in various
other things we discussed something like monitoring
or getting real-time analysis and all those things. We discussed spring cloud
and all those things, right? So what restful does is it gives you something on the similar
lines it gives you apis that suit the need
of your micro services. Accordingly you can go ahead
and have your micro Services up and running. What is semantic monitoring in
micro Services architecture know when you talk about semantics
monitoring you're referring to the fact that okay. Let me give you
an example again. You have your application which is up and running
but you still do not know whether it gives
you the best output or every module
that is there in application is working in the
best possible way. So what you do is you go
ahead and generate a pseudo transaction. Now this transaction it runs through every
module and generates. It's an output and when you assure our verify
this output and find that all the readings are as you expect it to be then
you actually go ahead and deploy that software. Now this sort of monitoring or testing is called
as semantic monitoring. How can we do cross
functional testing now when you talk about cross
functional testing you need to understand what it is first. Well, it is nothing
but an approach where let me give you
the scenario again. First of all, you have a client who gives
you certain requirements and then Enters in output and tries or expects an output
from an application that you build for him. But there are certain parameters
which the client might not think of or he might enter and you expect output
for those inputs as well. Now while building
an application, you might not consider every
possible faucet as in what kind of an input the user
is going to given so it is the responsibility
of the Builder or the provider rather to ask
for these requirements and then accordingly
A test is taken care of to test our application for
these kind of inputs as well. Now this kind
of a test is called as your cross functional test. How do you eradicate non determinism in
tests a basically, these are different approaches. First thing you need
to understand is what are non deterministic tests. Now when you talk
about non determinism, you're talking about a series
of inputs for which you may not know what
the exact output is. Now in this case what happens is when you're generating
a Particular output the output might vary each time you enter
in a particular input and there are
certain outputs only that a correct not all of those. So what do you do
in these situations? Because this is a very non
deterministic situation where you do not know
what is happening with you. So in that case, what you do is you take
in various approaches. One of those
approaches is current. I know what happens here
is suppose you have maybe say a hundred outputs or results
out of which there are 20, which are not not correct. So what you do you put
the 18 one cluster and 20 in the other cluster and then you test them differently
a synchronous approach. You might come across tests where a synchronous
messaging is used. Now in this case the output that is generated
may be different because a synchronous
messaging is something that is little different here. The user does not wait
for your reply and the output that is generated might be
a little different. So again, what you do is you use sudo applications
of Shooter in post-fire, so called a synchronous requests and those are dealt
with differently remote services and isolation again here to you. Use something called as stub
are those are predefined inputs are predefined models
that can be used as we move further. We will be discussing
that as well. So you would have
a clear understanding of these terms as well. So yep remote Services
an isolation again, they can be dealt with determinism or
non determinism rather. But how do you deal with that? You use something
called as your steps? So as we move further
that's discuss steps and you can relate
to these terms as well time. Now time can be a constraint because you're talking
about applications that run four different times. But yes a pseudo time
again is generated for certain applications. And the non
determinism is something that can be taken care of. So what is the difference
between mock or a stuff for microservices test as I've just mentioned we have
something called as a stub and what happens in a stub. Basically, you need to understand this thing a stub
is nothing but A dummy object now this is used
for testing purposes. It would have a preset or a predefined set
of behavior and that individual or particular
behavior is something that it would
Implement each time. It is used now in cases where you do not want to go away
from normal behavior. You have this predefined stuff that can be used
mock is similar to it. But it has a set
of predefined rules. This is where it is different. It has a set of predefined rules that are set initially
it goes ahead. Head and it
functions accordingly. Okay. So the next question is what is my co Hans
test pyramiden microservices. Now when you talk
about the pyramid there are three levels in this pyramid. So first I will have unit tests. Now. These are tests that happen
for individual units. You have service tests. Now these tests they
test the complete service that is there. And then you have
your end-to-end tests which are for
the complete development or architecture now as per the law the tests
in the first layer. This for unit tests. They are the maximum
service tests are lesser than what unit tests are but more than what
end-to-end tests are. And finally we have
the end-to-end test now here. These are the least
compared to the about to what is the purpose of a Docker
now Docker is nothing but a container basically that means it gives you
a containerized approach and it also ensures virtualization at the
operating system level and it has three components. You have your darker
client your day. One or your server basically and then you have
your Docker containers and these containers would contain your
complete micro service or your complete application
to have your database there to have your interdependencies and also the
complete functioning of that micro service. So when you need a containerization approach you
can use something like a Docker which has a very wonderful
and a popular technology to have what is Cannery releasing
now you're talking about an application which might be used by lakhs
of people are Maybe. Chef people in that case when there is a new version
you cannot just go ahead and launch the complete
version for everyone who is around what you
do is you launch it for a certain set of people and when it works perfectly
then it is launched to the entire segment and this kind of an approach
is called as Cannery releasing that means you release
a particular software update or version to a specific
set of people. That's it. What do you mean
by continuous integration? We read something about dry. That is new. Not repeat yourself. This is what continuous
integration is also about first the code
that is generated. It is saved
in the form of libraries so that others can use it and there is a continuous
integration of your system. That means even if there's an update it
is recorded and it is released so that others can refer it if there's an improvement it
is updated and it is released. That means throughout
the life cycle of your software. There is a continuous
integration and updation what is continuous monitoring. It is similar. Continuous integration, but this deals with monitoring when you talk
about continuous monitoring you're talking about monitoring in every aspect of your application almost
everything is monitored and taken care of. What is the role of an architect in a micro service architecture
all the activities which we actually discussed
are all the questions which we discussed. Now that is something
an architect has to plan it is similar
to building the house. Now there you have
an architecture or an architect who takes care
of the construction part here the architect needs
to take care of this. A software development part
is responsible for creating the blueprint or the design. He zones out all the components or plans where all
the components should reside and how they should work whether they are
mutually cohesive and how Loosely coupled are they is
also responsible for deciding or helping plan what tools to use fair plus
there's technical governance, which he needs to take care of. So, these are some of the roles
that an architect takes care of. Can we create micro Services
as state machines? Well, the answer is yes. Definitely, you can create
State machines or microservices as state machines. Why because you're talking
about individual applications. You have your
individual databases. And since you have a single architecture or
a uniquely defined architecture for each micro service
and it is smaller in size. You can go ahead
and have a state machine for each individual
micro Service as well. So this brings us
to the last question of today's session that is
what is reactive extensions. Now when you talk
about reactive extensions, these are inappropriately. Roach, which lets
you collaborate your results. So what they do is they bring in
or collect all the results by using multiple services and
then they combine these results are compiled these results together to give you
a combined effect. And there is
a short abbreviation that is used for it
which is called as our X. So as this is what a reactive extension is as
far as the session goes. I believe we are done
with 50 questions. And this is where we have
to rest our session. I hope you all had something
nice and And I hope to see you. All again. Thank you. Bye. I hope you have enjoyed
listening to this video. Please be kind enough to like it and you can comment any
of your doubts and queries and we will reply them at the earliest do look out
for more videos in our playlist And subscribe to Edureka channel to learn more. Happy learning.
