- [Instructor] As we will be implementing microservices
in this course, let's look at the topic
from a 20,000-feet perspective first.
If we look at little bit at the history
of software architecture, we see that until 20
to 30 years ago, architectures were strictly monolithic,
which means they consisted of one single application.
If you wanted to modify code,
you had to check out the whole application
from your version control system,
and when your change was ready to go into production,
it was deployed with the whole application as well.
These applications were also run on a single server
very often.
The program logic tended to be very tightly coupled.
This means, if you changed a method or function in one file,
there was a significant chance
that your action would also affect other parts
of your application.
This means that a developer had to have a model
of the whole application in mind when doing any change.
When a new developer started to work on something,
she or he needed to first understand
how everything was stitched together
before writing any single line of code.
Think of a shopping system.
The front end, the product management,
the customer management, the shipping,
it was all in one application.
Around 2000, there was a paradigm shift.
Computer networks were quite common by then,
and architects started to create distributed applications.
So, they sliced the applications into logical pieces,
called services, that exchanged the data over the network.
This was called service-oriented architecture, or SOA.
The communication between components was mostly done
via XML.
Still, those logical pieces were quite large,
and unfortunately, often incorrectly used
when some vendors developed proprietary ways
to transparently call methods over the network,
which basically introduced tight coupling again.
Coming back to our shopping system example,
in a SOA application, you would maybe decouple
the display logic from the data access,
providing methods to fetch all items or to place an order.
Such systems were still tightly coupled,
but distributed, which made things rather worse than better,
and soon, SOA lost its popularity.
Around 2010, the term microservices was coined.
While they have much in common with SOA,
the aim was simplicity.
There is no standard but a set of best practices.
The shopping system I talked about before
would now have an independent front end
that fetches data from various microservices.
One service might return a list of items,
while another one may provide access
to the shopping cart for a given user.
Note that I'm now talking about services
and not methods as I did before.
There are a few best practices
when developing microservice architectures.
One microservice should only do one task,
or at least be responsible for one concern,
like dealing with all customer data on an application.
It should be possible to develop
and deploy a microservice completely independent
from all other parts of an application.
And microservices should communicate
using standard HTTP methods.
Of course, there are a few benefits now
from using microservices because that's the reason
they are used in the first place.
First of all, new developers don't have
to understand the whole application now,
and services can be developed and deployed
by completely independent teams.
They just have to negotiate contracts
how microservices have to communicate with each other.
And services can develop with the language
that does a given task best.
So, you can use Go for some microservices
and Node for others, and maybe Java for a set
of other microservices.
And we will explore that, during this course,
if a service fails and if it's done correctly,
not the whole application has to fail.
Of course, when there are benefits,
there are always also drawbacks.
There are possible code redundancies.
This means that you might use some modules
or some data structure and you have to use it
throughout many microservices,
and there it might be tempting
to just copy/paste logic all other the place.
It's also harder to roll out new versions
because if those microservices are dependent on each other,
you have to first roll out a whole set of new microservices,
and they also have to follow new contracts
that maybe are rolled out with this new version.
And they're harder to test, especially harder
to test on its own as compound on its own
because if one microservice depends on its other
and you write the test, you have to basically
mock the other microservice to test the one microservice.
And one major thing is also, the complexity is now moved
to the network layer, so things that were before
tightly coupled in an application are now distributed
over the network, and if something goes wrong
on the network layer, this also affects the application.
And this also means that a microservice application
is basically harder to monitor end-to-end.
For our application, we will apply the best practices
and we will also take measures
that if one service is degraded,
the application will still be functioning.
We call this resilience.