In the last part of this section on deployability, we will deal with the microservice architecture
and the other means of applying or instantiating the deployment pipeline.
We had this overview about solutions for continuous deployment where we will start with the Microsoft
service architecture and later come to rolling update, automated user acceptance test and
some words finish with some words on monitoring and rollback.
Let's start with the microservice architecture.
It's an architectural pattern and it has gained quite a good attraction from both goals from
deployability as well as from distributed development.
It enables an evolution, it enables scalability, that's one part, but the core idea is to
provide elements with low interaction with each other.
In our case, under the aspect of deployability, it helps because less communication, less
coordination between developers, between teams is required.
Because each service is micro in a way that it covers one thing, one aspect, one responsibility
as a whole and has only limited interaction, limited dependencies with the others.
This is the point where evolution is easier and the change impact is easier, lower and
the other part which we don't discuss here is about scalability, so it's easier to deploy
these microservices on different machines to achieve peak performance and provide more
resources if it's necessary to have more power.
We consider especially the aspect of limited interaction, so this is what we want to achieve
because the coordination between developers during deployment or for deployment is very
time consuming, especially if they have to do some revisions, if they have to revise
things because they didn't notice before that there are some dependencies.
This really takes time in this deployment pipeline and therefore we want to reduce the
coordination, thus we want to reduce the rework, making the whole process faster.
Microservice architecture is a pattern, here it's partly described as a pattern with goals,
decisions and consequences and on the next slide we will say something about the operation.
The solution is that we decompose a system into small services.
Service oriented architecture has already been there before, the microservice architecture
pattern arrived and was developed, however we want small services, each covering one
responsibility with low interaction to others, with good encapsulation and with a simple
coordination model.
The customer and client relation for this, there's another pattern coming on the next
slide, the API gateway pattern and between the services we can have synchronous or asynchronous
messaging, which reduces coupling, therefore the impact of a change is less than calling
the systems, the services directly.
Sometimes it might be an issue that data is necessary, data has to be used by several
services, so here partitioning data helps sometimes to decouple the systems to encapsulate
them by themselves.
For scalability, for communication coordination between the services, we need a load balancer
and we need a registry which works similar to a broker for providing the services to
the clients and what we need further, especially for deployment, is state management, because
if we want to exchange one service by a new one, then we have to make sure that he continues
its work where the other just was.
So shutting down is not always possible, so it should be possible to switch at one time
and this is possible if there's a stateless, for example, if they have stateless services
or we have a good state management.
And it should be possible in the system to provide new instances that's especially important
for scalability.
The consequence that we benefit from is reduced dependencies between the services, thus between
the teams as well.
Then some examples, we could have services for a catalog with serving a UI, with reviews,
serving a UI with recommendations, or with orders, this is an example from the shop system
where we have some services and these services are then accessible or provide information
for some parts of the user interface.
Here the services are cut into pieces according to their responsibilities, so something about
the catalog, something about reviews, virtual foundation and so far, plus it's distributed
between being the model where the operation is done and the user interface where the information
is provided and user actions can be started.
So however, there are more than these principles or these ways to this criteria to cut a system
into services.
First of all, of course, we have to mention the functional decomposition, so we have the
toll function, it's cut into pieces of different sub-functions and down to very small services
covering one responsibility, one service as a whole.
Another point could be for load balancing, that means if we have some order services
for peak hours, then we have these order services in parallel and we split the whole
order up into different ones, or we do it according to data partitioning, maybe for
example this catalog is using order data, check out data and catalog data itself, so
this order data as we check our data combined, so we need some entanglement, some interaction,
some coordination between them and data partitioning helps.
As you notice, I go over the things rather quickly, of course, unfortunately I have to
limit the time we have for this microservice pattern, I would encourage you to read more
about it, it's quite efficient today, everybody wants to do microservices or service-oriented
architectures, please feel free to read more about that, we could do a whole lecture on
microservice architectures, however we can just spend 50 minutes on them.
I just mentioned this API gateway pattern, that's another pattern where I spent only
one minute on, to show that it plays a role, because we want to have independent services
and the independence is achieved by providing all services through API gateway.
This API stands for application program interface is the one point or the one open entry to
the services, similar to a facade pattern on the lower level, API gateway is considered
as a pattern on architectural level.
Please read more about it, we just mentioned that it's there together with other services.
Let me call you, let me mention that there are other patterns and tactics, I will just
mention a few of them.
Stateful services or stateless services represent a kind of tactics or patterns for the state
management, for this evolution aspect for provisioning new instances is partial release.
Another tactic, I just want to mention that in the recommendation for further reading
there are some more links to papers about the microservice pattern.
Let's have a look on the slides, on the questions for this part.
The characteristics on the microservice architecture in the fourth question have been discussed
together with this pattern structure and the positive aspect of microservice architecture
on continuous deployment is this decoupling aspect, that people can work independently,
parts of the components of the services are independent from each other, so it's much
easier to switch them and especially we reduce the rework if something doesn't fit.
So criteria for service decomposition has been in this slide on microservices, so functional
decomposition can be mentioned there, load balancing could be a criteria for data positioning.
There are much more criteria but however these are the most important ones.
So far I want to stop here on the microservice architecture, I feel pity about that.
I want to come to further points for continuous deployment.
So far this was the first point and now I want to introduce rolling update to you.
Rolling update is an important strategy or even tactics for automated build integration
delivery installation and this rolling update comes with automation of these processes,
of these activities.
Rolling update helps us to get the machinery that works without human impact or without
human control, however just with working on high numbers of clients and with a strong
monitoring system.
What we want to achieve is consistency among the system.
That's an important point when we update the system during operation, that we achieve consistency
between the different versions that has to be defined or controlled before by decisions
on the design of the works, however even between different services and between services and
persistent data.
Here is a T, here missing.
Rolling update means we have one instance that's allocated, we allocate one instance
where we start, we provide a new version and then we release the version to the next one
and then we roll over the whole set of clients, the whole set of machines.
Therefore we decide which group has to receive the new version and then we provide them one
after the other so that we steadily increase the number of clients with the new system,
with the new version, allowing the hotline and the services and everything else to work,
to receive messages, for example problem messages, not all at one time but one after the other.
For example, if we want to perform a rolling update on the Amazon Cloud, an Amazon Elastic
Computing Cloud EC2, then it works this way, this feature is provided there, is available
there, we define a group that has to be updated and then all the instances are provided with
that.
The old instance is then shortly terminated and started by the cloud and then again registered
again with the new version.
So far, if everything works, it's fine, so it will roll out over all the instances and
that means after some time everything is working with the new version, that's one point, however
if something is broken, something wouldn't work or some error message, then we would
roll back the whole thing again over all clients of all instances.
That was one important point, just to achieve consistency among the clients and we can
use this for feature toggling, which is very important during user acceptance test, our
next topic.
User acceptance test was the one, the strategy or the tactics that helps us to reduce the
effort for human testing.
Acceptance test means the users confirm that the system is responding and doing what they
expect that they can work with the new system and this is usually time consuming because
you have to send it to the users, they have to be informed and they fill out a questionnaire
or they have some problems.
We want to automate this step and we do it through canary testing and strongly relate
to that is A-B testing.
Let me introduce this shortly.
The name canary testing comes from canaries in a coal mine.
The miners took this in the mine, there are some poison gases and not only explosions
could be the results of big blast killing people, however, the miners could just die
from the gases.
Therefore, they took small birds with them, the canaries and as long as the canary alive,
there is no danger for the miner and if the canary died, then the miner should go out
as quickly as possible.
So therefore, this canary is somehow a tester, it dissolves as a probe if everything is working
fine.
We use the same principle for checking if a new version is accepted by the customer.
We send and we pick some customers out for testing a new version and if everything works,
no complaints, then we roll it out over the other clients or the other customers by rolling
update.
Canary testing is a technology, is an approach, is a tactics for live testing of software
and it could be for logical problems, for performance problems, just for usability.
We start with a small number of clients of instances and a new version is placed on them
and we monitor how it works, how does it work.
For example, in a shop system, you send it, you have 10,000 of clients working there,
people are ordering and you place a new version to 10 of them.
You monitor them closely, what happens?
Do they break, do they discontinue their buying, is the client hanging up, do we get
error messages or do we get complaints from the customer?
All these things are monitored and in the end we decide, okay, it seems to be working
fine, then we roll it out to everybody or not, then we roll back.
The steps is we decide which intint instances are the canaries in our case which are used
for testing, then we activate one new feature or one new version, what we call feature toggle
and then we monitor them closely because messages are not just passed to log files, no, they
are passed to the monitor to find out which problems are there, how severe are they and
otherwise we roll back the whole thing.
There's a new term we had on this last slide as well, feature toggle.
What does feature toggle mean?
Feature toggle means we can easily switch on or off some feature.
This is possible, for example, this can be done by rolling, by submitting this new service
and by keeping persistent state, it was on the previous slide, where was it, now here.
The state management is an important means to just replace one version by the others
and it is told that Amazon Marketplace, they just play with colors, which type of green
or blue is accepted most by the customers and they just do it by feature toggling, they
switch off or on a new version and they monitor what are the customers doing.
So far canary testing, A-B testing is very similar to that.
We have two versions, version A and version B and we check what is the behavior of the
customers.
With canary testing, we focus the differences.
Canary testing is for a very small number of customers or instances and A-B testing
is for bigger numbers on both sides with both versions and we check which version works
better.
One more point we had here on the solution side was the monitoring frameworks.
I don't have more slides for that, I just want to tell you that monitoring is the means
to automate the things for unobserved installations.
We do the installation as a rolling update on the clients and we connect to these clients
with the messaging system to find out what is working good or bad and we receive the
information and this enables a quick reaction.
We can instantly roll back or roll out the whole system, the new version to all clients
if we want.
So far this was the point on deployability.
Let's go back to the questions.
We had no questions on canary testing or A-B testing here, however this is an important
point as well because for user acceptance tests what we had was the steps for this deployment
pipeline where we want to especially to automate the testing, to automate the build and to
use all the design decisions in a way to build independent units, independent components
called services, microservices.
So far thank you for this part.