>>What is a microservice?

In this video, we'll talk about what microservices are and what they do.
Okay, let's jump in.
A microservice is just a web service
that is a small, well-defined scope and is loosely coupled from any other web
service.
Usually, you don't build just one microservice,
but rather your organization adopts a microservices architecture
that consists of a collection of microservices,
each one self-contained and implementing a single business capability.
Each service has a separate codebase, which can be managed by a small development
team.
In fact, microservices don't even need to share the same technology stack,
libraries, or frameworks,
which allows each team to choose the right tool for the job.
This means that a single development team can build, test, and deploy a service.
The result is a continuous innovation and a faster release cadence.
Teams can now focus on one service, and with a smaller scope of each service,
the code base will be easier to understand,
making it easier for new team members to ramp up and to get started.
Going this route now allows each microservice to be deployed independently of every
other microservice in the organization.
A team can update an existing service without rebuilding and redeploying the entire
application.
Plus, they can also easily roll back or roll forward and update if something goes
wrong.
The best part, this makes bug fixes and feature releases more manageable and less
risky.
The deployment strategy also means that each microservice can be scaled
independently.
A benefit of this efficiency is that each microservice is responsible for
persisting its
own data or external state
and not rely on some common repository layer.
In fact, some microservice experts insist that each microservice should even have
its own separate database.
Again, the idea here is to make each microservice completely autonomous
with no cross-dependencies from a business domain perspective.
This kind of freedom provides a
a layer of fault isolation.
If a service goes down, it won't necessarily take out the entire application.
Okay, great, but you might be thinking, "Each microservice is an island unto
itself."
"Then what happens when you need to work with multiple microservices in a single
application?"
Good question. So here's the answer. Microservices can communicate
with each other by using well-defined APIs.
The internal implementation details of each service are encapsulated behind their
interface.
However, typically you'd want to reduce those interdependencies and try to
introduce an orchestration or management layer
in the higher level consuming application
that coordinates calls to various lower level microservices and combines results.
A microservices architecture solves some problems and is more appropriate when you
have a large application
that requires a high release velocity, you have complex applications that need to
be highly scalable,
you have applications with rich domains or many sub-domains, you have an
organization that consists of small development teams.
Microservices can benefit from the management
and hosting capabilities of several different Azure services.
We'll talk about those in other modules. But for now, just know that
microservices is a way to simplify an application architecture
by focusing on creating smaller, more manageable, autonomous and independently
deployed web services
that address a single business domain or capability.