﻿[applause]
Tomasz Tarczynski: Hello, managing a dynamic
distributed system is a tough task.
It became even harder for me when we moved to micro-services
architecture because the number of moving parts grew a lot.
I thought that if we work with containers and have
the application already split into micro-services,
the next step would be to utter an orchestrator
to dynamically and autonomously manage them.
I went to the Cloud Native Conference to
learn about acknowledges in this area.
I saw the Cloud Native landscape with tons of useful technologies
but I didn't learn what this Cloud Native is really about.
Then I started to dig into how different
people explain and describe it.
I found several different definitions and different points
of view and that these definitions are still evolving.
For me, the first question to answer was
why should I actually care, what benefits
can we get from this approach and, if it's
any good, how can I sell it to my boss?
The case study is available from the companies
that adopted Cloud Native approach already.
Among them are the Financial Times and Zeelander,
and unicorns like Netflix have used similar methods for years.
They can increase reliability by managing
the applications and infrastructure with
an autonomous system that reacts to failures of
components without human intervention required.
At the same time, they increase the velocity of
delivering features to customers so having
a self-service platform managed by software enables
them to deploy changes faster by orders of magnitude.
This is how Netflix is the relation between those two.
So increasing the rate of change, results in lower availability
and to improve both, you need
the changes in technology and architecture.
They also put less work into the mundane
management of drawing infrastructure.
Now, all routine decisions are made by their platform and also
the infrastructure costs can go down with better utilization.
The next question for me was how can I implement this Cloud
Native approach to building and running applications.
Among the different methods I find, there
are three that are most often advised.
First of them is to build your applications into containers.
It gives you the great benefit of
standardization, it lets you standardize on
a single package format, one way to deploy
and one way to control the application.
Second is to manage those applications with
an autonomous orchestrator so a human in its own need to
describe the desired state of the whole cluster
and then the up lifecycle is taken care of by software.
The third one is to break down the application
into micro-services that are small, single-purpose
and decoupled, and you benefit from them being
easier to develop and update and cheaper to operate.
This Cloud Native seems to be a technological
paradigm that prescribes these three patterns.
Container package applications, dynamically
managed, and micro-services architecture.
And when I've tried to find how people define
Cloud Native, I most liked what Justin Garrison
and Chris Nova said in their book Cloud Native
Infrastructure, which I really recommend.
It’s about infrastructure that is hidden
behind useful obstructions so you no
longer deal with individual machines but
have an API to control the whole cluster.
Also, this infrastructure is managed by
software so there is this autonomous
orchestrator that constantly makes sure
that the cluster is in the desired state.
Also, applications are designed to be managed by
software, not by humans so we no longer produce
operational documentation but we rather make
sure that we have standardized app interfaces.
I am Tomasz Tarczynski, I work with Gigaset
and thank you very much for listening.
[applause]