i08.txt

R1: What are you doing so professionally in your job? So you're somehow
Tester, team manager, DevOps, microservice—

I8: I am a Cloud Foundation Architect. That is a group
of five teams. A few teams have their own services, so they do it
really DevOps in the purest sense more or less. Then there is one
a few teams that do such a thing, where there is still an ops department
hangs in between and then there is one of the teams or two of them
Teams that do - so this is really the old world, the old one
Monolith world, where there are developers who don't know how
Environment works and we do, so we are the interface
between Ops and the business developers. So in my five teams that
are really everything: pure DevOps to old school.

R1: And in which domain do you work? So we mean domain now
Web development, frontend, backend -

I8: backend. Everything backend development.

R1: And the role in software development was now project manager
or then architect then one -

I8: This is not project management. So we deliver, we are one
SaaS Company, that means there are two parts. First the projects that
really implement something for the customer, we are not,
rather we really manufacture the product that is available in the cloud
and then used by the customer to configure his stuff there,
So I'm still making the system available, so to speak
configured what he needs and interfaces and such. This is
actually our part more or less.

R1: Okay, so more as an architect. Yes, what part of the daily
Is work still software development and programming?

I8: That is becoming less now. Up to six months ago I was like this
60%, 70% of my time developed. And I've been an architect now
half a year, uh quarter of a year and you have to see more,
that the teams work together, communicate, concepts
work out something like that. So there is more of a need for communication then
higher. And then collect requirements. Technical requirements,
Configuration is a big topic, for example.

R1: How many years have you had in software development?

I8: 19 I am now.

R1: And since when here?

I8: For five years since the acquisition - ah no, three years ago
we bought up. The company was called before, I've been there for five years
and this company was split off and I had been there before,
so is the same code base. I've been working on the for 20 years now
same code base. In extremely different incarnations. So I know
still the difference between SaaS and Premise, so if you put that as a CD
sold. All the historical thought - life behind how to
Configuration made earlier, with properties and then you were done and
like this. So understanding has also changed.

R1: What frameworks and tools do you usually work with?

I8: Now in the area or in general?

R1: Already in the area, yes exactly.

I8: So there are several things in the area. One is that
classic git where you check in properties and then those
deployed somewhere and they are read there. Development environment
is then IntelliJ, so the common IDEs that the developers have around
what to edit. Then there are monitoring functionalities wherever
checks whether the configuration has arrived. Or if we if
Now Ops says okay, we don’t like that, we have to go
Performance reasons what change or the performance engineers that the
change certain configurations. Because this feedback loop is too long
would be there now - there are two ways to do that
do. Either they are self-sufficient and they just make decisions and do
we check in the software, so to speak, that this is a valid one
Configuration and then we have monitoring functionality
that is a Grafana means where we see which configurations
were appliet, but only for those who are interested in us more or
fewer. That means we write in addition to what you write
can configure that you can also monitor it. That one then
can see later how many of the 10,000 instances have this
configured how many have configured this and so on. Or
Feature flags: how many are on and how many are
switched off. There is such a board where you can see it so clearly
sees. But of course only for production instances. For
We don't have developer instances, so what every developer has
we don't really know. That is actually missing.

R1: Okay, so Grafana would be that -

I8: Grafana is the main monitoring tool. We also have our own tools
designed to collect such information.

R1: What do you mean by the term configuration?

I8: In my view, configuration is a very, very difficult one
Subject in the sense if you want to define that now. Because it works
starting from the default setting of the developers - so I know
that I take a library, you can apply configurations like
if you want to use them, you check them in and I know that
Everywhere exactly this one configuration is used and it will be
never change. And when a new version of maybe comes out
the library, then I change it, check in with the code and then
it goes outside. It is the most static of all. And the other one
Dimension is that the customer at runtime for a specific instance
certain behavior, because of me at the check-out flow, can configure
or no idea if he wants to configure how in the business manager
the editors, how long they can edit, for example, or how
Batch processes are configured, scheduling, such parameters, where that
is very very dynamic. So there can also be certain areas where
The following configuration and then one apply in a certain time frame
other. That is the other side of the configuration in my view.
And this very dynamic, one can hardly say, that is now
Configuration or are these just normal business features? The
so blurs a bit when you do all of that - you have one
Process that has different behaviors, i.e. branches where that
can go there and with the configuration you can change that and then it is
the life cycle of the configuration is very static, how dynamic
the? So that's why the spectrum is extremely wide. And then you can
still see from another dimension, from the stakeholders. Who leads
this configuration? So who says there is this branch,
do so, do so. These are either the developers or the
Ops people and and and and and. Up to those who then have the concrete
Values ​​ownen. For example, in the product we say the developers
say "I can use the VM size for my application server
configure. "We don't know which one will be applied. So
we know, we say, "Okay, we tested that with from - that is
the minimum that you can have is the maximum. What you
in between, maybe we give guidance where we can say
okay if there are so many products in the shop, then you have to
make it a bit higher if so and so many users come in, concurrent
session, then there is always a guideline on how to do that,
but ultimately that's what the Ops people do, who then say "I know that
is the specific customer, we measured that, that's ours
Performance metrics and now let's change the configuration "and the
Then we owe the values ​​and are responsible for them. If this
Leave the frame, that's another communication between us,
where they say we've set it up as correctly as you did
documented, but it doesn't work. Then we have to go back
look back and why is that, this is a special case, we have
what forgotten and so on. So that's the one - that have values
its own lifecycle, the configuration itself around the code, which then
on it that somehow has its own lifecycle and that
People who use that then. So the different ones
Business users. I'll say that I can endure the configuration
have to. One is responsible for switching and the other has to do it
live and then say "Hello Admin, can you go for my box
turn something on because I need a new feature "or
something like that, feature toggles for example, for business reasons that would be one
Possibility. These are very - and you have to do that for each configuration
think about who is what?

R1: I think you now mostly have a professional configuration
spoken, we often differentiate between technical and technical
Configuration and, okay, VMware features might also be technical
and where we look a little bit now is CI / CD, Docker and such
further, virtualization. Does that matter to you or what?
is the relationship between technical and technical?

I8: That is, so if you abstract it completely it depends on mine
View only from the stakeholders, from the stakeholder groups. So for
it is the developer, I think, if you introduce a configuration,
whatever that looks like if it's a business configuration now
for a business user who changes something at runtime or who
Build engineer who wants to configure his Docker image, ultimately
what you do is very, very similar. It's just another one
Stakeholder who has certain requirements, such as the lifecycle of the
Values ​​is and from the configuration. And that, so you have to
think that needs to be validated, checked, and so on.
Scopes and so on. And that's, these are special
Groups that also communicate with each other differently. So if
the build engineer tells you I need a configuration for mine
Docker image, because I want to better configure my VM, that's something
different than when a product manager talks to a customer who then
talks to the PO and then talks to the developer. There is the
A completely different flow of information to introduce such a configuration.
So, the second is, a build engineer can be trusted to be the one
Has a feel for technology. That means you don't validate so much.
Then it pops in the development environment, then it fails
Build step fails, then he calls "why is that?", Then we say "well
wait, the two numbers don't harmonize with each other, pass that
time ", while with business users we can not say now
try it out, let it pop and have a look because there is money on it
hangs. That is why there is so much attention - validation
very important that it can only apply valid configurations.
While the build engineer is probably ... So I'm working now
right now, i'm configuring the docker images and so on, that is
very fragile, you have to have a lot of technical knowledge and then
know what depends on each other and develop a feeling for it and
hope the documentation is at least good enough. It will
treated very neglected, because there is no sales or
anything.

R1: Yes, we also have interesting ones - maybe I can do that for you
have had insights so far. Some say exactly the same thing that
it is very complicated, fragile and there is a lot of connection, others say
that's absolutely easy to do Docker somehow. Maybe that depends
the complexity of the task or maybe that is not yet
certain tools or best practices or something where you can get them
can hang around?

I8: The problem with, so I can well imagine if I now
own project owne, own small service and the whole
Buildchain or something, it's totally easy. But if we have 120, 160
Developers who all work in different locations, too
different times and who do not agree on how you like her
Configure Docker and everyone their own - we have now
our build process, I'm trying seven, eight right now
various Docker images that are needed during the build
then deployed, which are used in test instances,
maybe even more, to harmonize. Then it goes to
Example of JDK exchange. Quite simple thing actually. And I'm sitting
for 14 days now and fight with it. One has it that way
done, the Java home is there, the other one is configured
each is configured differently, you don't have to be with each other
agree and if you have such a global, through all images
has to go through, has a global view at once, it will
extremely complicated because you have to know the dependencies that
User groups must know each other and every Docker image completely
have to understand so that you know how it works. That's why if it is
one thing, it's totally simple and if you know what the code is and
how it is structured. But if you have six or eight you don't
knows and first has to look into the source code how to do it, then
it gets complicated.

R1: Are you also involved in configuring monolothic systems?

I8: Yes, that's one team, we've been overall since 20
Years. Felt.

R1: Has anything improved since then (I8: Yes) or worsened?

I8: Yes, improved. So there it goes, that's the case with the monolith
The main problem is the interdependencies. So through the one
Creating services, I don't like the term microservices at all,
because it's like a marketing term. For me when someone says
build microservices, they are good, for me that's someone who
has no idea about technology. Because you can - there is no definition
what a microservice is. If you take services, you try that
Problem of disassembling what was solved in the monolith. If you have one now
building new architecture and building services, you get another one
different category of problems. An example is there are initials and
Disadvantage. I don't think monoliths are bad, I just think
not services are bad. Depending on the application, I always find
you should take one of the two. So if I now, for example
I'm a startup company and I have to go as fast as I can now
possible to bring something to the market and try something, I would
always start with a monolith because you are much faster.
While when I say I now have 10,000 instances and then come
now - customers are getting bigger, bigger, bigger and act
always worldwide wherever you can be in America, in China or
anything, then a monolith God knows is not the best solution that
you can choose there. You should try for scaling reasons
pull that out. You have to keep in mind when configuring services
that it's very, very complex. And now we come to that
Configuration. Why? The more a system is decoupled, the more or
all the better tests are needed in the runtime environment in
Production system. For example, if one team now says, "Oh,
I want to - I am going to reconfigure it now because I think
that's good for me. "Doesn't that mean that for the overall system
good is. You have the same in monoliths, only that there, the one
who reconfigures it and wants to test the monolith and its module,
sees that the other one doesn't work either because of the
probably used the same buildchain. But if that, if you
now has a hundred microservices and I can't do all of the hundred
Try microservices with my new configuration, then it will
difficult. That means code itself, configuration changes
rolling out can be very complicated. You need others
Strategies to do that. Because you have to test that at runtime
more or less. With the monolith this is easier in my opinion
because one, because I have everything: I have all the information in
inside my computer and there I get a large share of
Problems already when developing with. So that's actually that
Challenge we have.

R1: And what has improved now?

I8: Has improved in that there are extremely many new ones
Frameworks out there. Before there were only properties and that was all. And
how to load the properties, who changed them and who changed them
It was actually relatively free. So the first versions
I worked on there, they tried everything
configurable in the properties and then you have the customer
said, here are the properties, here are the descriptions,
have fun. If you were lucky, the developer thought about it,
to validate and discontinue any areas that the one who
that has managed and installed, understands what this is about. Now
is it - so it used to be, we have the software
produced, made it configurable, gave it to someone
and customers with a technician who has no idea what's inside
happened that was not in the development process and told that
now have fun, configurable. And there was an extremely big one
Loss of information. Most of the time that led to this, for example,
a concrete example, a project had been such a major customer and
then we had made a mistake, we had in the software
given an incorrect default value or unfavorable. Let's say for
Large customers were unfavorable, it didn't matter for small ones. And then we had them
said, watch out, you can change this configuration if you
that makes you quick as a rat and you need fewer resources.
And that was before Cybermonday and they said "No, no, no, that
don't make it now because of this risk and the side effects that are there
can happen, they are so high, nobody can estimate them. The
you may be able to say on your development environment now, but
it is a completely different story in our production.¨ and there it is
it is that they prefer to do things that they have always done.
So the classic is that they scale, they just put ten
App servers, twenty app servers to do this as a configuration
change and don't know what if I change that pops somewhere else. The
is this fear of it, these are typical Ops people. They make servers
every now and then, these are the common practices that happen there
while changing a configuration, a property that has never changed
is a high risk. So now in the DevOps environment it is
yes, because the developer knows and can watch how it is
System works, he can also learn from it. And this coupling, that
but has more to do with the business model, it has it extremely
improved. So that was my big change five years ago.
So far I've always delivered this CD and hoped and there
they sent me stack traces and I had to guess what
could happen and philosophize about it and try that in our
To recreate the environment. But that didn't always work. Up to
where I now, so where I switched over to the SaaS company,
I did a lot to get information from the system. The
I haven't done it before. And that actually gives me a lot
better feeling what's going on and a much better insight and can
give much better advice on how to configure or what
is to configure at all, which one maybe not at all
should configure.

R1: How far do you have to use tools, frameworks and infrastructure
be configured? Have heard almost everything, right?

I8: Yes, so we have pretty much all the environments there are. The
only simplification that we have that we no longer all OS
support. So historically it was seen that at least one or
three OS - twenty years ago it was like this: Windows, SunOS or HP-UX,
so a Unix system and a Linux. Then the old SunOS and
HP-UX are extinct, then there are only Linux and Windows and
In the end, Linux has now completely established itself.
That's why the kernel with Linux is now included in Windows and such
continue. It's actually only Linux. As a development environment
let's take a macOS here, which is now also a Unix, that's why
the step with Linux and macOS is not that big now. Most of it is
almost the same. So the environments have simplified
consolidated. What has become more complex are the runtime environments.
So it used to be bare metal, we always have
still in our old data centers, towards a virtualization like
VMware and OpenStack and so on, towards narrower virtualization
with Docker. Now the next step is Kubernetes and let's see what
comes next. I don't know what the hardware is then.
That you no longer have any contact with the hardware at all. So
that has changed completely. And now when you go from
Development processes the software, so I'm now writing code where the
must run everywhere, that goes from a development environment, where you can
conserves resources as possible in macOS and is easy to use
use and dynamically reloadable, to a test environment, wherever
Dockerization is there and, of course, where you test the function
a load test environment, where it is already close to production and towards
various, with customer data and scaled systems. So those are
- the one code runs in very, very different environments and
with very different purposes. I say, also with the customer himself.
The customer doesn't just have one environment, he has several environments where
he tests his own code or certain data variants of
Catalogs for example and so on. Promotions and stuff. That's why
the more configurable the code you write, the better
is. But of course you have to worry, lifecycle of
Configuration, who configures that, how much do I need to validate and
so on.

R1: Are there interactions between the whole configurations?

I8: Unfortunately God's not. So mostly it's always because
that different teams mostly do that you can't say
I am now introducing a property and now I want from everyone
Configurations, where my software lives, where, how, who, what
configured and why.

R1: Oh, I meant interaction when I was shooting something
once happens there is something else
switched on, then an error occurs. So somehow you have
Dependencies between different ones, as far as I'm concerned in the Docker file
is what and then what is in the properties file of Spring Boot -

I8: Dependencies between the properties.

R1: Yes, exactly.

I8: That is, I don't think it exists yet. So what we do
currently doing, as I said at the developer -

R1: So there are only, you don't know them, do you?

I8: No, I don't think there is a standard yet. So there is
Configuration server, you do it as follows, so there is
the problem in several ways. One is how
said you always have a test suite when I am now a developer
such a technical property builde, then it pops, then someone looks
purely in (? 25: 14), edit that, the feedback cycle pretty slowly. And
Dependencies, you have to understand the whole product and so on. Or
you start pouring that into software and these rules that
Dependency must be validated beforehand. Then when you validate that,
can you say when starting up I am not starting up now because there is missing
something else. So if there are either wrong values ​​in it or
Dependencies are not correct, this is the simplest variant, but that
is not cheap for a production system where the ops engineer then
doesn't know what to do there and the configuration somewhere else
stands. This is more for the business user, where we build a UI, where
who can configure something and the UI guides him into the correct one
Configuration. And there is also investing a great deal in that the UI
then encapsulates. Mostly. For business users. We can do that
of course not do it for everything, because it's just not worth it and
you don't always have this UI for every environment, then what - that is
a different system every time, a different reason why you do that
configured. It's very different.

R1: Can it happen that yours is like that
DevOps person then somehow misconfigured his CI server
or it runs in 99% of all cases, but in one percent of the cases
there is one, feature toggle for my part, and only then does that lubricate
from?

I8: Yes. 26:38 There is. That is the daily bread. So right now,
by being so many developers, we have, they have very,
very many, let's take feature toggles as an example, very, very
many different configurations and if you take it now,
you would have all combinations of these feature toggles
test. But if we have 120, we don’t need to talk about it,
that this is not testable. That's why we always try
that someone who introduces a feature toggle has both variants in
Cast unit tests for this one feature toggle. But we'll get
non-implicit dependencies if they do not harmonize with each other.
We hope that this is taken into account in the developers' code and then
maybe write that in the test, but we can't get it, so
so that he goes into a QA department with all the test clusters and then
combining everything that is possible that the developer has forgotten
maybe that's what the developer needs to know. And be responsible
more or less.

R1: How would you rate the importance or the importance
from configuration in software engineering or at
See software development?

I8: So from my point of view, it is becoming more and more important, because the
- You try to write less and less code and prefer to write through
Configuration, so to speak, to achieve its goal more or less. Just
if you now, if you have a market consolidation and different
Wants to map business models in one system. The more business models,
the more configuration. That is, when someone started to
Example, before 2004 not like \ [\] said, we said
focus on shops with fashion. And this has made a whole
Latte of simplifications result .. So back then they have the source
Taken code from \ [\] and then expanded everything they didn't
needed. 28:29 \ [\] had fanned out rather broadly because they were the
first were and have supported more and more business models and then
the product got bigger, bigger, bigger, the monolith is always
grown more. And that was only tangible for a few people, what
because actually happened at all. So then someone who, for example
just running a shop in a country, it was a huge knock there
to run a site in there was difficult to convey more
Or less. For major customers who operate worldwide, that is there
- Features were missing more or less. So that's very
very difficult to reconcile that. That's why it's there
really depends a lot on how much you can show with it. Easier ever
less and more special, but then it's only for one use case.
Or then more complex, then mostly it is always through configuration.

R1: And technical configuration as well?

I8: Technical configuration has now become easier, as I said,
through the operating systems and also through the standards that are changing now
push through. Let's come back, example over there, that's how it is, we
don't even know how the data center is structured. There it may be
that there at once between the app server and database
Firewall is and not for all other customers, as an example. Or the
we really had a very simple example, one
Customer who is based in Cologne. That was a simple telecom
Company, so not the real telecom, but such a
Subcontractor. There we have the database, now as an example and
not the app server, which is actually the same principle, we have it
the database tries to configure the same load on three
Balances hard drives, so to speak. And a week later I'm after
America flew to a customer who had three different data centers -
High availability, there was no downtime - they did
Monster Oracle license, invested a lot there, there were
maybe 50, 60 times more databases for a system.
And not just three hard drives. So that's the dimension, so what
an Oracle, for example, covers as software. It is still the one
connects a kernel to the database and storages and is highly configurable
makes. And that's why an Oracle makes it extremely difficult to configure
or difficult to understand for simple businesses. Then they already have
Simplifications built in, so smaller products, but that's a good one
Example from the databases. And with the app servers is actually
exactly the same principle.

R1: Are there differences in the different software life phases
regarding the importance or importance of configuration?

I8: Which phases of life?

R1: Requirements, design, implementation, testing ...

I8: Oh, okay. We are very, very happy to do that. And if we, me
give an example, we have - in the JDK it changes
Garbage collector. An important component that always clears away objects
and it has - in every JDK they improve it. With these
Memory management is a different and we improvements
don't really know what the impact is. So
every change is a different behavior and that has a change on it
Performance, what is cached and so on. What happened now
So what you do as a developer if you don’t know how it is
and how to get the right value, immediately as a configuration. Then do
you can configure it, says your testing engineer “You can do it
test different configurations? "because it's easier than
to say, "Look, I'm going to send you ten branches and you
try all ten branches. "That's one reason why
introduces this configuration. What then crystallizes out is that
es Konfigurationen gibt, wo man sagt, die sind dann irgendwann konstant.
Die bleiben meistens drinnen liegen, lassen wir so wie es ist,
vielleicht ändert es sich ja beim nächsten JDK und so weiter, da ist die
Änderungsrate relativ gering. Und dann gibt es aber welche, wo man sagt,
das geht gar nicht anders. Das hängt wirklich davon ab, von den Daten
der Kunden. Da kann es dann beim Kunden wieder konstant sein, dass sich
beim Kunden sich das auch nie wieder ändert und dann drinnen bleibt. And
dann gibt es Situationen, wie Flashsales, Cybermonday und so weiter, wo
man für eine bestimmte Period of time dann sagt, jetzt müssen wir da mal
was ändern. Größeren Speicher und dann wieder runtergehen, weil wir die
Ressourcen nicht brauchen. Das ist sehr, sehr unterschiedlich. Also vom
Lifecycle, wenn ich neue Software einführe, versucht man immer natürlich
das bequem zu machen, nicht dass ich jedes Mal neu deployen muss und
dann den — irgendeinen anderen Code oder das andere Verhalten zu
deployen und deswegen ist eigentlich fast alles, was wir machen, ich
denke mal 80, 90 % ist irgendwie konfigurierbar. Entweder durch
Properties, durch Feature-Toggles, durch was auch immer, Preferences,
Laufzeitverhalten und so weiter. Das hat sich übrigens auch geändert.
Dass das diese Konfigurationen da, also diese Möglichkeiten, die man da
hat.

33:23

R1: Und 80, 90 Prozent konfigurierbar, über was für Mengen Code reden
wir denn da?

I8: Das hängt ja von der Firma ab. Also hier die produzieren wie viele
Entwickler da drinne sind, aber aus Risikogründen ist es sehr selten,
dass wir sagen ich ändere irgendwas — Bugfixes ja —, aber wenn ich
ein neues Feature baue, ist meistens hinter einem Feature-Toggle. Wo ich
sage das Modul siehst du erst, wenn ich hier irgendwas anschalte und
dann für bestimmte Kunden rollen wir das aus. Und wenn die alle gesagt
haben, ist alles gut, dann nehmen wir es raus, dann ist es für alle
Kunden verfügbar.

R1: Wurdest du denn während deines Studiums oder deiner Ausbildung auf
so eine Konfigierbarkeitssachen—

I8: Null.

R1: —vorbereitet. Okay. Sollte sowas denn unterrichtet werden
eigentlich?

I8: Ich denke in der Softwareentwicklung — also ich stelle ja viele
Leute ein. Ich führe sehr viele Einstellungsgespräche momentan und das,
was meistens immer, oder als ich noch im Studium war, da war, da gab es
zwei Bereiche. Einer das entwickeln an sich und das andere war damals
gewesen, die Infrastruktur und die Technologien, die dahinter waren und
dann war es das eigentlich schon. Mit dem DevOps-Gedanke hat sich da
auch die Anforderungen geändert. Weil wenn ich jetzt — auch, ich kenne
jetzt auch ältere Entwickler, die sich erstmal dieses Umdenken, dass sie
auf einmal Laufzeitumgebung auf einmal ownen, dass sie nicht nur die
Technologie verstehen, was da passiert, sondern auch sagen, Empfehlung
geben für die Konfiguration oder selber die Konfiguration applien und so
weiter und das verantworten und Strategie. Das ist ein ganz anderes
Mindset und die durchzudiskutieren. Also ich finde, man sollte wirklich
dahingehend die Ausbildung verbessern. Und vor allen Dingen die
Prozesse, die wären da sinn— wie, nicht nur wie — also man hat ja
Objektorientierung eingeführt um zu sagen wie designe ich sowas, aber
auch in der Ausbildung, wie betreibe ich. Also was sind SLEs, gibt es ja
manche, das sind immer solche Spezialisierungen, (?35:25) die extra
waren, aber das ist ja eigentlich alles zusammen. Wenn ich eine SLE von
99, drei Neunen habe, dann muss ich wissen, was bedeutet denn das. Und
wenn ich da deploye, was wie muss ich dann deployen, was ist denn
Deployment dann, groß, Risiko, Fehlerraten und so weiter, was da alles
dran ist. Ich finde es aber auch nicht so schlimm, wenn man das im
Berufsleben macht, weil man die Prozesse, die jetzt sich etabliert haben
am Markt, die helfen einem schon, dass ein Junior-Softwareengineer
erstmal was eincheckt und zeitig auf die Nase fällt, weil da zu viele
Tests davor sind, dass der dann mit dem Entwickeln so lernt, was es denn
so alles gibt und was er bedenken soll. Das ist beides.

R1: Das wäre eigentlich dieses eine Anfangs— jetzt geht es um arbeiten
mit Konfiguration. Wir haben jetzt natürlich schon einiges schon so ein
bisschen abgearbeitet, aber erste Frage: Wie werden bei euch
Konfigurationen verwaltet und dokumentiert?

I8: Jetzt gibt es da zwei oder mehrere Welten. Es gibt eine ganze Latte
von Konfigurationen, die — aber das hängt davon ab, wer konfiguriert
das? Also was sind die Stakeholder. Wenn ich jetzt zum Beispiel — mein
Team halt der Stakeholder ist, dann führe ich das Property ein, mache
eine kurze Dokumentation drüber und möglichst findet man noch den Code
dazu, dass die da reingucken können und welche Values sind da gültig und
so weiter. Wenn ich noch gut bin, sage ich noch eine gute Exception mit
Error Trace, wenn er was falsches einträgt. Das ist so das minimalste.
Dann gibt es die andere Variante, wo man sagt, da wollen wir mitteilen
dem Support-Engineer, wenn wir Konfigurationsänderungen machen, dass der
was sieht. Dass die nicht nur für den Entwickler in dem Property-File,
sondern von anderen Stakeholdern zumindest gesehen wird und Änderungen
auch mitbekommen werden. Also zum Beispiel wenn wir, das haben wir mal
so eingebaut, wenn der Server hochfährt, eine andere Konfiguration
kriegt, dass man das im Log reinschreibt, das wurde geändert seit der
letzten Inkarnation. Dann ist jemand, der Fehleranalyse betreibt,
hilfreich, dass der versteht „ah, das ist eine Verhaltung(?). We have
es zwar nicht deployt, aber wir haben etwas umkonfiguriert, das hat
potentiell einen anderen Codepfad und deswegen verhält sich das System
anders."

R1: Wo wird das dokumentiert?

I8: In Logfiles meistens. Im einfachsten Fall. Der nächste wäre, wie
gesagt die Metriken, die wir eingebaut und dann die Tools, die dazu
waren, wo man sagt, wie ist denn die Einstellung? Oder wenn man
Vergleiche macht, zwei Systeme, wie ist da die Einstellung und wie ist
da die Einstellung? Es ist sehr, sehr unterschiedlich und hängt wirklich
stark von der Konfiguration ab. Bis hin zum Businessnutzer, wo wir
tracken wenn der irgendeine Änderung macht, wir wissen nicht warum, aber
wir zumindest wissen, okay seitdem ist irgendwas fehlgeschlagen, da ist
dann der Error grad hochgekommen und dann sehen wir, ah, da wurde doch
die Änderung gemacht, sodass man relativ schnell den Fehler findet.
Deswegen ist meistens, im Produktionssystem ist, wenn man Fehleranalyse
betreibt, guckt man immer, was hat denn sich geändert, das passiert ja
nicht spontan. Das kann einmal sein Deployment, Skalierung,
Infrastruktur, Lastverhalten, Konfigurationsänderung, Datenänderung,
sowas. Das sind immer so die, wo man immer guckt. Man versucht immer
inkrementell rauszukriegen, wenn es gestern lief und heute nicht, dann
muss irgendwas dazwischen passiert werden. Eine Sonneneruption wird es
nicht sein. Das ist ein gutes Beispiel. Deswegen sind so Sachen, die man
zum Beispiel — Hah, schönes Beispiel, ich kenne da einige — das
lustigste, was ich mal gehört habe, als schöne Story, da war ein
Oracle-Consultant unterwegs und der hat gesagt, ich habe einen Kunden
gehabt, der hat angerufen und gesagt, Donnerstag wenn es regnet ist die
Datenbank langsam. Und da musste er anfahren und gucken warum
Donnerstag, wenn es regnet die Datenbank langsam — er war da, da war
die Sonne scheinen, alles fein und dann hat er analysiert, analysiert,
analysiert und dann hat sich herausgestellt, dass es — die Datenbank
hat einen Optimizer drin, der dynamisch Konfiguration sich merkt. Also
früher war das so gewesen, da musste man statisch sagen der
Executionplan wird so ausgeführt und der Executionplan so, hat man
einmal gegossen. Dann musste man manuell ganz viel konfigurieren und
weil das aber kaum einer verstanden hat und einen Haufen Spezialwissen,
hat Oracle angefangen, wir bauen mal eine intelligente Komponente rein,
die das alleine rauskriegt. Das ist jetzt so die nächste Inkarnation, wo
man dynamisch rauskriegt wie sich das System verhält. Und da war es so
gewesen, abhängig von dem, der hat ja gelernt wie das funktioniert, wer
zuerst was macht hat er entweder die Konfiguration oder die
Konfiguration genommen. Das heißt immer Maintenance (?39:54 ), Datenbank
wurde hochgefahren und dann wenn es geregnet hat, ist ein Mitarbeiter
nicht mit dem Fahrrad gefahren, sondern mit dem Auto, war schneller auf
Arbeit, hat seine Queries gemacht, die waren gut für ihn, aber für alle
anderen schlecht. Das war der Hintergrund. Wo man merkt so, selbst wenn
man das dynamisch macht und hochintelligent und das in Software gießt,
es gibt Limitations. So und dann ist aber dieses *es regnet* selbst das
ein Anhaltspunkt für ein System um Fehleranalyse zu betreiben. Alleine
dieser Fakt, dass die sagen wenn es regnet ist der langsam, ist schon
ein riesen hilfreicher Sache als der, der hinkommt und sagt, moment, was
kann denn der Grund sein? Als lernen, also sind so Konfiguration und
ausrechnen der Konfiguration. Was man jetzt auch gesehen hat in der
Vergangenheit, dass diese Konfigurationsmöglichkeiten immer weniger,
dass man das zwar konfigurieren kann, aber Komponenten draufgibt, die
dynamisch errechnen, was die optimale ist, das dynamisch machen. Und die
haben natürlich auch Bugs.

R1: Was ist denn der größte Vorteil von eurer Verwaltung bezüglich
Konfiguration?

I8: Der Hauptgrund ist der Feedbackcycle eigentlich. Also diejenigen,
die die Values ownen sozusagen, also die Werte, die da angelegt werden
und der, der was ändert, dass der schnellstmöglich Feedback kriegt, ob
die erfolgreich ist oder nicht. Das kann auch (?41:21) wenn er was
ausprobiert, aber zumindest, dass der nicht sagt, „Ich stelle jetzt mal
was ein und ich hoffe, dass das besser ist." Der Feedback ist ganz, ganz
wichtig aus meiner Sicht. Und idealerweise ist es bevor er appliet wird
und sagt, ne, das ist total falsch, dass er gar nicht das applien kann
oder wenn er sagt, ich probiere mal mit einer größeren VM-Size aus und
gucke mal, wie sich das verhält, das wissen wir jetzt nicht konkret. And
dann muss er mappen, diese Konfiguration auf Metriken, die vielleicht
gar nichts mit der Konfiguration zu tun haben. Also
Request-Response-Zeiten zum Beispiel oder Speicherverbrauch,
Ressourcenverbrauch und so weiter.

R1: Okay, und der größte Nachteil? 41:52

I8: Der Nachteil ist momentan, dass das alles manuell gemacht wird. Also
da muss jeder Entwickler, es gibt da keine allgemeines Pattern oder
keine, ich würde jetzt mal, eindeutige Sprache oder Konzepte, wo man
sagt das macht man heutzutage nur so. Das ändert sich wirklich alle paar
Jahre. Also früher war ja Puppet und Chef der große Hype, jetzt ist es
Docker, dann kommt Kubernetes. Ich bin gespannt auf die nächste
Inkarnation, da wird wahrscheinlich ein KI-System dahinter sein, was
dann sagt ich lerne das alles.

R1: Gibt es spezielle Tools denn zur Verwaltung der Konfiguration?

I8: Genau, es gibt welche, aber die sind, das ist sehr, sehr
unterschiedlich. Also je nach Konfiguration ist das ist das sehr, sehr
unterschiedlich was man braucht. Es gibt einen Haufen Möglichkeiten da
was zu tun, aber was — also momentan setzt sich durch Docker mit
Umgebungsvariablen. Das war vor fünf Jahren schlimm Umgebungsvariablen
zu machen in der JVM. Bloß, weil sich die Umgebung geändert hat,
versuchen wir im Sinne wirklich Environments. Mit wem Rechner rede ich,
war früher immer in Propertys ausgelagert und jetzt ist es eher Tendenz
Umgebungsvariablen.

R1: Und wie verwaltet ihr wiederum die Dockerfiles? Also wie verwaltet
ihr praktisch die Configuration Files?

I8: Configuration as Code ist das große Schlagwort da in dem Punkt. Also
wenn wir versuchen zumindest, dass keiner mehr im Ziel— wie sagt man
immer? Die sind read-only die Instanzen, also unveränderbar, immutable
Deployments. Und wenn irgendwann eine Änderung machen muss, muss er
irgendwo was einchecken. Dann sieht man wer hat was und warum gemacht.
Dann wird das appliet die Konfiguration und dann kann man gucken und
dann hat man wieder mehr Informationen, dass was geändert wurde, den
Grund warum es sich geändert hat und man kann mit demjenigen reden, wer
hat das geändert und fragen warum hast du das denn jetzt gemacht? Gives
es da noch einen Hintergrund?43:44 Das sind ganz wichtige Informationen.

R1: Also wenn jetzt — also ihr geht immer über eine Art
CI/CD-Infrastruktur drüber?

I8: Das ist unser Ziel, sind wir noch nicht, aber in die neuen
Umgebungen alle, die jetzt in Public Cloud gehen, die machen das so. There
gibt es keine Möglichkeit—

R1: Also bei jedem Umkonfigurierungsschritt checkt ihr ein praktisch
dann? Okay. Ja, wie kommuniziert ihr denn Konfiguration in Team?

I8: Das hängt davon ab auch wieder, was man ändert und warum. Also wenn
man jetzt zum Beispiel, wenn ich weiß, dass, nehmen wir mal an, was
könnten wir denn machen? (?44:25) gutes Beispiel? Es gibt doch wieder
die Auswirkungen. Jedes Mal wenn ich jetzt eine Konfiguration ändere,
muss ich mir Gedanken machen, was hat das für eine Auswirkung? And then
kommen wieder die Stakeholders, die davon entweder profitieren oder
nicht profitieren oder was anderes machen müssen und zumindest die muss
ich darüber informieren. Das ist aber jedes Mal manuell, das kann man
nicht automatisch ausrechnen.

R1: Also per Email, Telefon..?

I8: Per Email, bei Slack in unserem internen Teamchannel, Release-Notes
zum Beispiel werden noch verwendet oder wir haben auch, wenn man sich
bei uns im Backoffice-Tool einloggt, dann Nachrichten, dass wir haben
jetzt eine neue Software ausgerollt, das sind die Änderungen, die wir
gemacht haben. Dass der so ein bisschen Gefühl kriegt, was sich geändert
hat und warum.

R1: Und was ist da der Vorteil von den Sachen, die ihr da macht?

I8: Na, es ist wichtig für die Leute, die das System betreiben. Dass die
wissen, wenn irgendwas nicht geht, das ist immer die Fehleranalyse. As
auch, das ist ein bisschen Marketing, wenn etwas besser geht, dass die
wissen warum. Lustigerweise haben wir das immer vernachlässigt. Also das
haben wir immer nicht für wichtig gehalten, ich habe euer System
verbessert, ist doch schön. Und dann hatte ich mal mit einem unserer
größten Kunden zu tun gehabt und der hat — waren wir im Gespräch
gewesen und dann gab es mal Probleme mit ihren Instanzen und dann habe
ich das alles aufgenommen und habe Internas verbessert. Weil ich das
aber nicht kommuniziert war, hat der Kunde gesagt, „Na ihr macht ja gar
nichts, wir sollen alles machen und wir haben eine Haufen Tasks und ihr
macht gar nichts. Das geht ja gar nicht." Und dann habe ich gesagt „Ne
ne ne, wir machen das schon." und dann habe ich denen mal eine Insight
gegeben, was das für ein Rattenschwanz dran war und dann hat sich
rausgestellt, dass wir viel, viel mehr gemacht haben als er, wir hatten
es bloß nicht kommuniziert gehabt. Und das war für den Kunden aber so so
wichtig, dass denen das, wie groß die Mannschaft ist, die dran arbeitet
und vor allen Dingen, das Resultat der Änderung. Hat das wirklich was
gebracht oder war das irgendein Seiteneffekt, die auch positiv waren zum
Example. Und das war wichtig für den Kunden zu verstehen, der damit
leben muss mehr oder weniger. Wenn ich zum Beispiel in der Werkstatt
bin, mein Auto abgebe und die da irgendwie neue Hardware da auswechseln,
will ich das ja auch wissen. Und wenn vielleicht einen neuen Turbolader
oder die Reifen ändern, dann (?46:30 ) das ist wichtig, dass man das
kommuniziert sowas. Und so eine automatische Anzeige für bestimmte
Sachen fände ich mittlerweile, wir haben es nicht überall drinnen,
meistens wird es manuell gemacht, aber in bestimmten Inkarnationen haben
wir das jetzt schon drinnen, dass man das nachvollziehen kann.

R1: Und der Nachteil?

I8: Der Nachteil ist, es gibt Situationen — Eigentlich gibt es mehr
Vorteile als Nachteile. Es gibt manchmal Situationen, politische Gründe
warum das eigentlich nicht machen möchte. Wo man — Security ist so ein
gutes Beispiel. Ganz, ganz kritisch. Also man muss aus Security-Gründen
etwas ausschalten, anschalten, irgendwas oder sich an Standards halten,
weil dann Probleme gibt und die Kunden interessiert meistens Security
nicht. Also das ist immer der — Im Web, also wenn ich mir überlege,
2000, wie naiv wir damals vor 20 Jahren im Web die Seiten entwickelt
haben und was sich seitdem an Security geändert hat, ist das schon, also
das, ich sage mal vor 10 Jahren würde ich locker, vor 5 Jahren
wahrscheinlich, ist das Netz komplett offen gewesen für jemanden, der
sich auskennt. Das ist glaube ich wirklich — was jetzt an
Sicherheitslücken rausgekommen ist, ist der Wahnsinn. Und manchmal ist
es besser, dass man Informationen erstmal geheim hält, damit das nicht
groß auffällig — wir werden jetzt nicht sagen „Okay, wir haben eine
Fehlkonfiguration gemacht. Wir haben aus Versehen vergessen dieses
Property zu setzen damit keiner invaliden Code hochlädt." Das
kommuniziert man natürlich nicht. Intern ist das ganz heikel, das wird
auch ganz restriktiv gemacht, dass das ja keiner weiß.

R1: Aber dann steht es ja schon im Repository drin, oder? Wenn jemand
die Konfiguration—

I8: Wenn jemand auf dem Repository guckt, da hoffen wir, dass wir
schneller deployen als dass jemand diese Sicherheitslücke ausnutzt. The
geht aber nicht anders. Das ist immer so ein Henne-Ei-Problem.
Repository muss natürlich jeder getrackt werden, der Änderungen gemacht
hat. Erst recht security-relevante. Man kann auch sagen da war noch gar
keine Lücke, aber ich baue ein Security-Feature ein. Muss natürlich da,
hier das dokumentiert, wer hat das warum eingebaut. Weil das kann ja
auch eine Lücke sein. Das ist sehr, sehr schwer. Also Securitybereich
ist ein ganz eigenes Thema, riesengroßes in dem Bereich.

R1: Werden bei Codereviews auch bei euch Configuration Files —

I8: Ja.

R1: ...reviewt und wie ist der Prozess dahinter?

I8: Das ist genauso wie der Code. Also das ist eigentlich — also was
auch passiert, dass beim Review festgestellt wird, warte mal, du machst
du die Änderung, ist dir das Risiko bewusst, was passieren kann? The
Reviewer guckt dann drauf und sagt ja warte mal, kann man das
zurückrollen, wenn man das Deploymentnetz, das hochfährt und das — in
den Umgebungen nicht geht. Oder wir machen Annahmen über Umgebungen, wo
wir nicht genau wissen. Das ist bei 99 % überall wo man guckt das
richtige, aber es kann sein, dass eine sehr, sehr alte Instanz, die seit
15 Jahren läuft, dass die das eben noch nicht konfiguriert hat. Da ist
ein Review sehr, sehr, wo man sagt, jetzt brauchen wir einen
Feature-Toggle ringsrum, dass man das ausschalten kann. Zumindest zur
Laufzeit. Damit wir schnell reagieren können. Was passiert. Aber es ist
auf jeden Fall, bei den Entwicklern ist das wie Code. Das ist dasselbe,
selbe Anforderungen.

R1: Habt ihr irgendwelche Kriterien und spezielle Zeitpunkte in denen
ihr Konfigurationsoptionen plant und dann implementiert?

I8: Ja, das hängt auch wieder mal von der Komponente ab. Da kann ich
wieder ein konkretes Beispiel nennen. Wir haben manche, in der
Vergangenheit wurden manche Probleme in der Infrastruktur gelöst, die
der Kunde hatte. Aus Security-Gründen haben die Put Blocks, sogenannte.
Also da ging es darum, dass jemand nicht Code uploaden kann im
Produktionssystem. Das haben die damals in Firewallkonfiguration gelöst.
Rausgestellt hat sich danach, dass die nicht nur den Code-Upload
ausgeschaltet haben, sondern alles andere auch. Also was man im
REST-APIs jetzt braucht. So und jetzt hat man da eine Konfiguration
appliet und die müsste jetzt so verallgemeinert werden. Das schafft aber
der Firewall nicht. Deswegen mussten wir das dann in einen anderen Layer
verschieben. Das Projekt hört sich ganz einfach an, dass man diese
Konfiguration, das File da nimmt, A macht, daraus ein B macht im anderen
und dann geht das. Also ein bisschen Code dazu schreibt. Der Aufwand
war, das Code schreiben war drei Tage, Monitoring zu machen, dass 10.000
Instanzen korrekt konfiguriert sind — also man muss so sagen, das ist
die alte Konfiguration. Die muss rüberkopiert werden in die neue
Konfiguration. Dann muss monitoren, dass das überall auch passiert ist,
weil meistens Ops-Engineers sind da, haben wir gemacht und dann sagen
wir Entwickler „Ne, auf der Instanz und auf der Instanz—". Wir haben
von 10.000 Instanzen drei gefunden, wo das nicht passiert ist. Oder da
wurden ganze Pods, Datencenter vergessen. Menschliches Versagen einfach
nur. Ist aber normal, wir sind alle Menschen, wir machen auch Fehler.
Deswegen versuchen wir das immer sowas zu validieren und dann wir eine
Overload-Strategie, wo wir dann sagen jetzt schalten wir es mal für
einen Pod aus und dann sukzessive für den nächsten, gucken dass das
alles geht und haben natürlich, validieren das, dass die neue Funktion
appliet wird und dass alles funktioniert. Das kann sehr, sehr komplex
will. Konfigurationsänderung. Also wenn man das wirklich systematisch
für zehntausende Instanzen macht. Das kann aber auch manchmal ganz
einfach sein, wenn wir sagen, ach, ob da jetzt drei oder vier steht, wir
tragen da irgendwas ein, rollen es aus und hoffen, dass da nichts
passiert. Also wo wir sehr confident sind, dass das alles total einfach
is.

R1: Wie viel Aufwand betreibt ihr denn zur Entwicklungszeit eines
Systems um Konfigurationsoptionen einzubauen?

I8: Gibt es auch wieder verschiedene, hängt von dem Use-Case ab. Also
wieder ein konkretes Beispiel, wo vielleicht drei oder vier Tage der
eigentliche Code, der neue Code da ist, der laufen soll und nur die
Konfigurationsänderung war mit Kommunikation ein riesen Projekt. Also
nicht der Code an sich, aber die Kommunikation mit dem Ops-Engineer, wer
was zu tun hat, war das Verhältnis ungefähr gefühlt, Diskussion und Code
war 90 zu 10. 90 % Diskussion wie, was, wer, wann, wie, warum, in
welcher Reihenfolge, mit welchen Pods, das durchdiskutieren und coden
war ganz wenig. Anderes Beispiel war auch gewesen, wo wir einfach nur
ein Directory von einem Punkt zum anderen verschoben haben, aber da
waren ganz viele Prozesse drauf und damit man Rollbackfähigkeit machen
und wir nicht wussten, ob wir Codeteile gefunden haben, die auf die neue
Location gehen, haben wir alles umgehangen, es kann aber immer noch
sein, dass irgendein Code, den wir vergessen haben — menschliches
Versagen — trotzdem auf den alten geht. Das man immer noch sagen kann,
symbolischer Link, umhängen, anderes Environment, das Zurückrollen, da
war auch ein Verhältnis locker von — dieses Feature-Toggle einbauen
und hin- und herswitchen waren 90 % das Featuretoggle, 10 % der
eigentliche neue Code noch. Das sind die Extremwerte wirklich.
Normalerweise ist, der normale Fall ist eigentlich also einen if-Block
ringsrums und neuen Code aufzurufen, das geht einher. Das ist wie
normales coden, das kann man eigentlich gar nicht klassifizieren. The
hängt immer vom Risiko ab. Das Risiko ist da ein ganz, ganz wichtiges
Thema. Was passiert, wenn man sich irrt. Und daraus ergibt sich ganz
viel wer, was, wie, wann, mit welchem Lifecycle konfigurieren wir.

R1: Und wenn wir jetzt bei der initialen Einrichtung einer Konfiguration
für ein Tool oder für so eine Deploymentchain und weiter, wie viel
Aufwand würdet ihr da mit rein?

I8: Das hängt natürlich immer wieder von den Installationen ab. That can
man sehr schön an Demandware sehen. Früher hatten die drei Kunden
gehabt, da haben nicht viel investiert in — haben dich angerufen, guck
mal in Logfiles, fertig erledigt. Bei 10.000 Instanzen ist dieser Anteil
der Formalien das hängt von der wie viele Systeme ich habe und wie viele
Leute daran arbeiten, die mitarbeiten. Wie viele Stakeholder davon
abhängen und dann leiden mehr oder weniger. Wenn es auch mal — wie
gesagt mit den drei Instanzen, das hört sich jetzt nicht viel an.
Letztendlich, auch wenn es, wenn man sagt das ist eine Quote von
99,999irgendwas und dann 7 % irgendwie, wo ich sage ist es erfolgreich
gewesen, ein erfolgreiches Projekt? No. Wir werden Sonntag nachts
raus, wenn das Deployment läuft und die drei Instanzen nicht gehen,
stehen wir auf der Matte. Und deswegen haben wir ein persönliches
Interesse daran, dass das läuft, also zu 100 % eigentlich. Wobei das
auch zwischen den Kulturen sehr unterschiedlich ist. Also jetzt mal so
ein kulturelles Problem. Wir Deutsche sind da extrem pessimistisch.
Deswegen sind wir gute Engineers für solche Systeme, weil wir da wenig
Noise verursachen im Sinne, dass irgendwas nicht geht. Während die
Amerikaner sind sehr mutiger. Auch mal so als kulturell hat das auch
was, wo die sagen ach, ist ja nicht so schlimm, dann (?55:11) mal
runter. Und firmenpolitisch. Ansehen ist extrem wichtig da in dem Fall.
Wenn jetzt, hat man bei Google gesehen glaube ich. Und bei Microsoft.
Die haben ja Public-Cloud-Implementierungen und bei Microsoft ist es vor
kurzem passiert, dass mal ihre Datenbank, ein großer Datenverlust war.
Das war auch eine Konfigurationsänderung. Die hatten selber jetzt auch
Konfigurationsfehler gehabt, wo man eben dynamisch die geändert hat bei
einer Datenbank und das hat ja securitymäßig riesen Auswirkungen gehabt
auf unsere Kunden und da mussten wir gut reagieren drauf. Also das ist,
wie gesagt das Risiko ist da ganz wichtig. Also wenn ich ein kleines
Unternehmen bin, was ein Startup ist, mit einer Software, die nicht so
wichtig ist, ist das fein. Groß agierende Unternehmen, die haben, das
geht sofort in die Zeitung und da war mal Microsoft für drei, sechs
Stunden weg. Oder Google war vor kurzem gewesen, mit dem Google Docs und
dem Mailclient, war mal für eine Stunde oder zwei Stunden weg. Das ging
durch weltweit, in alle Presse. Bei kleinen Unternehmen — ich habe
schon Kunden gesehen, damals drüben bei denen, da war der Shop 9 Stunden
down, die haben das nicht mal gemerkt. Also das war ein deutsches
Unternehmen und jetzt mal wirklich die Aussage von dem war „Ach, wir
haben Verträge mit den Kunden. Die können gar nicht weg, weil die
Kündigungsfrist ist drei Monate und dann müssen die eben später kommen."
Das ist wie *ich bin mal kurz Kaffee trinken, eine rauchen* am Store. So
sehen die das. Während die anderen, die den Umsatz messen und dann genau
sagen warte mal, zu der Zeit haben wir so und so einen Umsatz, das macht
so und so viele Millionen. Ihr seid dran Schuld, Kohle her.

R1: Wie viel Aufwand betreibt ihr denn, wenn so Versionsänderungen
kommen. Oder andere Konfigurationsabhängige Änderungen. Also jetzt war
ja Spring Boot von 1 auf 2 zum Beispiel.

I8: Genau. Also bei, die kleineren ist ganz relativ gering. We have
unsere Testsuite dazu laufen. Also so Security-Patches ist relativ
einfach. Dann gibt es eben Minor Updates, die gehen meistens. The
Kompatibilität ist nur marginal, ist noch relativ einfach, sind so
kleine Projekte. Also ich sage mal ein Sprint, zwei Sprints. Also in
einem Monat ist das durch. Wenn man jetzt sagt JDK 11 wird ein
Riesenprojekt, das wird über ein halbes Jahr dauern denke ich mal.
Tomcat-Upgrade zum Beispiel ist ein riesen, riesen Projekt, weil da
meistens auch das Verhalten sich ändert. Gerade Cookie-Handling und
sowas. JDK 11 sind die Librarys unterschiedlich. Müssen wir rauskriegen
die ganzen anhängigen Librarys, das ist, das sind richtig monströse
Projekte. Also jedes Team muss dann gucken, dass sein Code noch
funktioniert. Riesiger Kommunikationsaufwand. Reihenfolge betrachten.
Docker-Images upgraden. Die ganze Laufzeitumgebung. Dass überall
dasselbe deployt ist. Rückschaltfähigkeiten. Also das ist richtig,
richtig fett.

R1: Ja, was ist denn für euch der größte Faktor, der den
Konfigurationsaufwand bestimmt?

I8: Das kann man an der Konfiguration nicht festmachen denke ich. The
eine ist, wenn man einmal eine Infrastruktur hat um Konfiguration zu
validieren — also wir haben ja wie gesagt verschiedene Arten von
Konfiguration, wo ich sage eine Property alles fein, hin zu ein UI, wo
man schon vorher einen Haufen Logik reinmacht, dass nichts falsches
konfiguriert wird und wo man die Konfiguration vielleicht auch testen
can. Man wählt ja dann die jeweilige aus nach was denn das für eine
Auswirkungen hat, die Values. Also ist das Risiko groß die Änderung zu
machen, dann investiert man wesentlich mehr, ist die Änderung klein,
wenn da irgendwas ist, dann geringer. Oder von der Testabdeckung. The
ist auch ein ganz wichtiges Kriterium. Also wenn ich sehe, ich habe da
zwei Pfade und da sind bloß die beiden Code-Schnipsel und wir haben in
Unittests beide durchgetestet und nach außen ist umgebungsunabhängig,
dann brauche ich jetzt nicht groß noch irgendwas mit (?59:21
)-Strategien machen. Bisschen kommunizieren, fertig, erledigt. As soon as
man aber mal eine Environment-abhängigkeit hat oder Unbekannten, wie zum
Beispiel, jetzt kommen hier ein Haufen Requests für uns ran und die
Komponente, die die Requests entgegennimmt und die parst und validiert
und dass das alles korrekt ist, wir man die ändert, wie der Tomcat, dann
ist das sehr groß. Weil wir wissen ja was geht, wir wissen aber nicht,
was im implizit so geht. Also wenn jetzt im Header mehr schicken oder
Characters in Headers, gerade international mit Japan und China, wenn
auf einmal andere Unicodes reinkommen oder wenn sich Zeitzonen in Chile
ändern regelmäßig — das ist so ein Ding — das sind so
Herausforderungen, die man hat gerade wenn man weltweit unterwegs —
ich weiß doch nicht, was in Chile, wie da E-Commerce funktioniert. There
hoffe ich, dass wir genug implementiert haben das hinzukonfigurieren.
Als Beispiel. Das ist wirklich, also wirklich die Values ist mehr da
entscheidend als die Konfiguration an sich. Das ist nur ein Tool um das
Risiko zu minimieren aus meiner Sicht.

R1: Jetzt noch mal eine spannende Frage, da kannst du glaube ich noch
was zu erzählen, benutzt ihr denn Konfigurierbarkeit um
nicht-funktionale Eigenschaften wie Performance zu tunen?

I8: Ja, natürlich. Ganz viel. Also das ist, da besteht die
Herausforderung drin, erstens ist es extrem technisch, es gibt nur einen
ganz kleinen Kreis, der versteht überhaupt, welche Values kann ich da
eintragen und warum und wie sind die Abhängigkeiten zwischen den Sachen.
(?1:00:57) ist da hochkomplex. Also brauchen wir wirklich, das sind die
besten Leute eigentlich, die wir haben. Die darauf gucken, wissen, alle
Metriken kennen, alle Codeteile, die damit zu tun haben, wie das
zusammenspielt, die ganzen Technologien dahinter kenn und ein Modell
haben im Kopf wie das funktioniert. Also technische Konfiguration ist,
also aus Performancegründen ist sehr, sehr schwer, weil die auch noch
iterativ ist. Also man kann, also das ist immer der Irrglaube wie man
ein Businessfeature entwickelt mal so. Man hat einen Sprint, man
definiert was man haben will, dann sagt man, dann implementiert man los,
da ist die UI da, dann klickt man, dann ist es da. Bei Performance ist
es so, man kann jetzt nicht sagen heute ist mir so, wir haben
festgestellt je schneller der Shop ist, deswegen sehe ich mal zu, dass
wir jetzt die Antwortzeiten eine Millisekunde ist. Weil da gibt es ja
technische Grenzen und Gründe. Und dann fängt man an zu diskutieren und
dann das eine ist die festzulegen, die non-functional Requirements, dass
man da hinkommt und das andere ist, wie komme ich denn jetzt dahin? There
muss man erstmal so eine Baseline machen, dann fügt man Code hinzu, dann
muss man den mit dem alten vergleichen, das Verhalten und gucken, ob das
besser wird. Und wenn man nicht nur eine Schraube dreht, sondern fünf,
sechs, sieben, acht Schrauben, weil die alle miteinander zusammenhängen.
Kann man sich vorstellen, wie tune ich denn jetzt einen Formel-1-Wagen,
was die da machen. Das ist sehr, sehr schwer.

R1: Habt ihr da, ist das mehr manuell oder habt ihr da auch Machine
Learning dran und so weiter?

I8: Bei uns ist das sehr manuell momentan noch. Also ich denke darüber
nach, das zu tun, im Sinne von, dass wir sagen einmal kann man es
manuell einstellen und dann legt man noch eine andere Komponente drauf,
die einfach mal verschiedene Kombinationen durchtestet. Aber das wäre
eine ganz eigene Abteilung, die das macht und die Daten liefert,
analysiert, Learning-Algorithmen drauf. Weil diese KI, die dahinter
steht, die braucht viele Daten. Also KI funktioniert nur — man braucht
ein Mindestmaß an richtig vielen Daten und dann die Daten, die man hat,
müssen auch noch das richtige enthalten. Das ist ganz schwer.

R1: Da können wir uns vielleicht 1:02:58 nach dem Interview auch noch
mal unterhalten, weil genau das haben wir auch genau drauf
spezialisiert.

I8: Ja, sehr schön. Brauchen wir.

R1: Auf die Optimierung von Konfigurationen für Performance und so
weiter.

I8: Ja, das brauchen wir. Das brauchen wir. Das brauchen wir. Das macht
unser — das machen nicht wir beim [Projekt], aber das macht [das andere
Projekt] (?1:03:13). Die haben ein eigenes Team, die KI nehmen um zu
erkennen, ob neu skaliert werden muss. Die haben da schon so Grafiken,
wo die bestimmte Parameter machen. Weil das ist sehr speziell.

R1: Gut. Naja, kann man das noch mal—

I8: Also sehr, sehr gerne. Da bin ich sofort, leuchten da meine Augen.
Bin ich sofort dabei. Helfe ich gerne.

R1: Kommen wir vielleicht noch mal vorbei und dann können mal einen
Vortrag halten, was wir so gemacht haben.

I8: Also ja, wirklich.

R1: Super. Okay, jetzt sind wir bei den Konfigurationsfehlern. Stellt
die Konfiguration von Systemen, Tools, Infrastruktur, Frameworks und so
weiter euch vor Probleme bezüglich Fehlern?

I8: Ja. Also ich denke mal es ist auch historisch gewachsen, die, ich
sage jetzt mal die verfluchten Properties, es ist ja immer noch die
Basis, wo man irgendwo ein Textfile hat, wo man etwas reinschreibt und
dann kann man irgendwas reinschreiben. Tippfehler. Also ein gutes
Beispiel, wir haben ein Property gehabt, was bestimmte Cache-Sizes
konfiguriert hat beim Kunden und das haben wir optimiert und haben wir
die erste Optimierung gemacht, wurde besser, machen wir eine zweite,
sind wir uns sukzessive haben wir uns an die Konfiguration angenähert.
Also schön alles manuell, nicht Machine Learning und haben gesagt „Oh,
jetzt machen wir die letzte. Das wird die finale." und dann
konfigurieren die und knallt es auf einmal. Wir: „Was ist denn nun los?"
und haben analysiert und fertig und Hintergrund war gewesen, da war ein
Leerzeichen zu viel in der Konfiguration. Und sowas finden, das ist...
da verliert man den Glauben. Und wenn man da Metriken hat und
Feedbackschleifen, kann man, kriegt man, erfahrene Entwickler kriegen
das relativ schnell raus. Aber für jemanden, der dann das System kriegt,
das ist der Horror. Wenn so nicht sichtbare Zeichen Auswirkungen auf
irgendwas haben.

R1: Was sind denn deiner Meinung nach die schwerwiegendsten Probleme?
Die die meiste Zeit vielleicht in Anspruch nehmen oder die die meisten
Auswirkungen auf die Kunden haben oder so.

I8: Die schwerwiegendsten Probleme denke ich mal sind immer die, wo man
keine Konfiguration hat. Also wenn der Entwickler sagt ich weiß doch wie
es geht, bei mir geht es auf dem Laptop und dann knallt es beim Kunden,
dann steht man nämlich da. Weil das ist ein riesen Aufwand dann. Man
kann da nicht — man kann entweder zurückrollen, wenn Glück hat, wenn
es zeitig genug auftritt. Das haben wir ja noch so eingeführt, aber
dieser Rückrollprozess ist sehr aufwändig. Schlimmer wird es wenn
Datenverlust ist. Dann muss man Recovery fahren. Da sind ganz viele
Leute involviert, hohes Risiko, Frustration beim Kunden, ein bisschen
Gesichtsverlust noch beim Kunden und so weiter. Und das sind eigentlich
— Datenverlust ist das schlimme. Wenn eine Konfiguration Datenverlust
bringt.

R1: Habt ihr da so ein Beispiel?

I8: Ein böses Beispiel. Ist sogar mal mein Bereicht gewesen. Das war so,
wenn man in so einen 20 Jahre alten Mono — der ist ja schon 22 Jahre
alt — 22 Jahre alten Monolithen hat, dann ist natürlich nicht, dass 22
Jahre lang Leute daran arbeiten, wie ich, sondern da sind mal da mal
einer zwei Jahre, dann mal drei Jahre. Und dann entsteht viel Code, den
keiner versteht. Das sind so Codestyles und so weiter sind da ganz
wichtig. Und wenn man dann — irgendeiner erbt den ja. Und wenn man
keine ordentliche — dann denkt man so, die Klasse die macht schon
irgendwas. Ich weiß nicht, was sie macht. Wie die im Kundenfall, wie die
ausgerollt war, man weiß nichts darüber. Und dann fängt man an Annahmen
zu treffen, wo man sich selbst belügt, weil man den Code nicht anfasst.
Man fasst nicht gerne fremden Code an. Und dann hat man ein echtes
Problem. Weil das ist da passiert. Ich hatte so eine Klasse, die hat mir
nicht gehört, hab da immer vertraut, dass die läuft, weil die seit zehn
Jahren lief. Baue ich immer alles ringsrum und hatte aber den Effekt
gehabt, dass jemand dann die ausversehen aufgerufen hat, in einem ganz
anderen Kontext und das hat dazu geführt, dass der einfach anfing alle
Daten zu löschen. Das war die Löschlogik um einen Katalog zu löschen,
die wurde aber appliet auf ganz andere Sachen und dann waren ganz
wichtige Tabellen auf einmal weg.

R1: Und das war ein Konfiguratiosfehler, oder?

I8: Ja. War auch ein Konfigurationsfehler. Also es kann immer Code und
Code sein. Es ist — also Code, als jetzt in der Entwicklung. Ob das
jetzt im Property-File steht, der einen Pfad macht, letztendlich ist
immer ein if-Statement irgendwie dahinter. Im einfachsten Fall. Es kann
auch manchmal so ein paar andere Werte sein oder ein Switch, aber
meistens ist es ein if-Switch irgendwas und dann hat man einen anderen
Codepfad. Das ist — ob ich den Code deploye oder mit if freischalte
ist dann auch wurscht. Deswegen ist da Code und Konfiguration — das
hat sich auch geändert seit zwanzig Jahren — es wird gleich behandelt.
Früher hat man beim Support angerufen „Konfiguriert es doch um, ist doch
euer Bier. Ich hab dir den Value nicht eingestellt." Aber das ich hätte
es programmieren müssen, dass ich sage wenn der hochfährt ne das machst
du jetzt mal nicht oder ignoriere die invalide Konfiguration, das hat
man damals nicht so, als Junior-Softwareengineer, habe ich nicht so
gedacht.

R1: Was sind die Probleme und Ursachen für Schwierigkeiten bei der
Konfiguration?

I8: Also es ist zum einen, also das ist jetzt mein Gefühl, also das ist
jetzt wirklich sehr subjektiv, also würde ich jetzt nicht mehr allgemein
sprechen, aber ich denke mal, wenn man zum Beispiel ein Properties hat,
so man frei irgendwas eintragen kann und keine Validierung hat schon
beim Editieren, ist das immer mit Risiko. Das ist, man merkt halt, man
hat ja so eine Testsuite, die baut man durch, aber ich mache eine
Konfiguration, dann lasse ich es durchbauen, dann ist es rot und dann
„ach, da hab ich einen falschen Wert eingetragen oder ein Leerzeichen
oder falsche Annahmen gemacht, dass das nicht funktioniert" und so
weiter. Es gibt, ich denke mal viele Konfigurationen, wo man schon
vorher Validatoren einbauen kann. Aber das muss man erstmal machen. Also
Docker hat da nichts. Das sind alles Textfiles. Und dann mal ausversehen
drauf gedrückt beim Einchecken vorher, an Enter rangekommen, wo man sich
umgedreht hat, weil jemand was gefragt hat, macht dann, checkt ein und
dann knallt es und dann wieder von vorne. Das macht jetzt nichts kaputt,
aber es ist nervig. Und dauert, frisst Zeit einfach. Entwicklungszeit.
Das ist so, was wirklich nervig ist. Ansonsten Schwierigkeiten bei
Konfiguration? Was auch schwierig ist, Konfiguration ist das eine Thema,
aber zu validieren was kofiguriert denn sie. Das Mapping zu wenn du
diese Konfiguration änderst, gehst du ins Grafana und guckst dir
folgende Metriken an, ob das besser geworden ist. Das hat ja nichts mehr
mit der Konfiguration zu tun, sondern mit dem freigeschalteten Code.

R1: Ja, das Tracing praktisch.

I8: Genau. Also dass man — ist es denn wirklich besser? Also das geht
einher, gerade bei Performancesachen. Also ich habe — das sieht man
sehr, sehr viel, dass der Entwickler sagt „Ich habe im Java-Buch
gelesen, dass man das so macht und dass das viel schneller ist." und
dann haben wir Kurse gehabt hier, wo man dem erklärt, dass das beim
Kompilieren dieses, das was er geschrieben hat, der sowieso macht. But
ob man so schreibt, so schreibt, oder so schreibt ist egal, kommt immer
derselbe Bytecode raus. Nur mit dem Unterschied, er hat das dann so
geschrieben, dass das kaum einer lesen kann. Zum Beispiel solche Sachen.
Also diese Schleife zu *was bewirkt der Code* das ist wirklich schwer zu
verstehen. Und dann gibt es auch Frameworks, wie zum Beispiel
(?1:10:33), haben wir wieder ausgebaut, eingebaut, wieder ausgebaut, wo
man gar nicht mehr sieht im Code, dass da noch im Bytecode was geändert
wird unten drunter. Das ist der Horror, wenn man sowas baut.

R1: Kannst du denn ein schwierig zu konfigurierendes Tool oder Framework
nennen? Und warum genau das?

I8: Docker. Nein, das war nur Spaß. Schwierig zu konfigurierendes Tool?
Die Buildchain eines Monolithen. Also das ist zum Beispiel — ist ein
schönes Studentenprojekt wahrscheinlich — wir haben ungefähr, locker,
um den Monolithen zu bauen, Repositorys. Git-Repositorys. Die sind
erstmal, hat man (?1:11:20 ), da steht Code drin, der wird irgendwie
durch einen Buildprozess durchgebaut und dann kommt ein Artefakt raus.
Das ist von einem Jar, hin zum Dockerimage, hin zum tar, tar.gz, oder
irgendwas. Das sind ganz verschiedene binäre Sachen. Jetzt hat man
immer, das ist jetzt mein Problem gerade, im Sourcecode-Repository eine
ganze Liste, die von irgendeinem anderen Server ausgeführt, der ist ein
Jenkin jetzt, der irgendwas produziert, dann hat man irgendwas binäres.
Die Sourcecode hängt irgendwie miteinander zusammen. Die Jenkins müssen
in irgendeiner bestimmten Reihenfolge ausgeführt werden und die binären
Repositorys hängen miteinander irgendwie zusammen. Ich habe noch kein
Tool gesehen, dass mir das visualisiert.

R2: Was meinst du mit binären Repositorys?

I8: Also Nexus oder (?1:12:02) bei Docker. Das sind immer so Sachen, wo
da, irgendwas produziertes liegt dann da drinnen. Gezippt, fertig, binär
ausführbar und das muss dann irgendwo hin deployt werden und gemacht
will. Und das zu konfigurieren und zu sehen und einen Überblick zu
schaffen, gerade bei so einem riesigen Monolithen oder vielleicht noch
bei Services vielleicht noch verrückter, weil die ja noch loser
gekoppelt sind und Abhängigkeiten da vielleicht ganz anders
funktionieren. Das ist wirklich, also wenn man, je loser gekoppelt und
aber Abhängigkeiten, implizite Runtimeabhängigkeiten, umso schlimmer
wird es. Weil man kriegt ja erst das Feedback wenn alles deployt ist. If
das funktioniert. Man merkt das ja vorher nicht.

R1: Was sind für dich denn Konfigurationsfehler und wie unterscheiden
die sich von normalen Bugs?

I8: Also Konfigurationsfehler... für mich ist das dasselbe. Also —
aufpassen! Jetzt muss ich mal langsam überlegen. Jetzt muss ich über die
verschiedenen Arten von Konfiguration nachdenken. Ist die Konfiguration
mit dem Sourcecode eingecheckt, ist Bug und Konfiguration ist das
dasselbe für mich. Das macht keinen Unterschied, weil da der selbe
Prozess dahinter hängt um das zu fixen. Du musst auschecken, ändern,
einchecken, gucken ob wie es geht, fertig, erledigt. Dann gibt es die
Laufzeitkonfiguration, wo man sagt, wo der Bug eigentlich die
Validierung ist. Fehlerhafte Validierung. Also wir hatten auch schon
Sachen gehabt, wo man eigentlich mehr besser konfigurieren könnte und
die Validierung zu restriktiv war. Da musste ich erst die UI ändern,
damit noch eine Zahl dazu kommt, die man konfigurieren kann. And the
dritte ist, bei einer Konfiguration Abhängigkeiten, also diese
Seiteneffekte, ich glaube nicht, dass wir, dass es da allgemeine. Also
ganz schwer zu finden sind solche Sachen, wenn ich jetzt, im Monolithen
vor allen Dingen, da was zu schraube, dass es da vorne knallt. Das hat
man bei Services wahrscheinlich auch. Ich lösche eine Version von einer
API und dann knallt ein anderer Server. Bei mir ist alles grün, kommt ja
nichts mehr an, kein Request, sieht toll aus. Das ist übrigens auch ein
schönes Thema auch für den Services(?1:14:29). Wenn ich jetzt eine Firma
bin und jeder baut da Services und da sind mal 300, 400 Services und
dann gibt es einen, einen Entwickler, der sitzt da, baut einen Service
und der kriegt noch Requests, kann sagen hier, so kommt das an. Can I
mir gut vorstellen, dass es irgendwann mal Services gibt, die gar nicht
mehr gebraucht werden. Dass das so eine selbstlebende Beweihräucherung
is.

R1: Welche Auswirkungen von Konfigurationsfehlern sind denn häufig bei
euch. Also auch Performance möglich, aber auch keine Ahnung.

I8: Also Perfomance, das passiert schon öfters. Wir versuchen jetzt so
Profile anzulegen, wo man sagt es gibt, ich spinne jetzt mal rum, ich
weiß jetzt nicht genau die Zahlen, aber sagen wir mal 20, 30 Properties,
die irgendwie miteinander zusammenhängen. Und die müssen dimensioniert
werden, wie die Zahlen da drinnen stehen und dann sagt er wir machen
drei Templates. Es gibt einmal die, die und die. Bronze, Silber, Gold.
Und nur die wird appliet, weil wir die schon durchgetestet haben und
Erfahrung mit anderen Kunden haben. Wenn jetzt jeder da selber losgeht
und *ne, bei dem einen Kunden weiß ich, mache ich was anderes* da wird
das immer schierig das — also wie gesagt, Performance ist wirklich
schwer. Was heißt denn Performance? Antwortzeit vom Request? Von welchen
Requests? Ressourcenverbrauch zählt auch mit dazu. Das ist so,
Performance alleine ist ja schon ein kompliziertes Thema.

R1: Hast du selber schon Konfigurationsfehler erlebt und was sind dann
besondere, vielleicht nicht nur schwerwiegende, aber vielleicht so ein
besonderer Fehler mal.

I8: Ja gut, da hatte ich jetzt schon ein paar Beispiele. Also mit dem
Regen, das ist so ein typischer, das sind ja, da gibt es ja ganz viele
verschiedene Arten, also — was könnte denn besonders sein noch?

R1: Vielleicht einer, der sich gut versteckt hat oder —

I8: Ja, ein gutes Beispiel: Wir haben, ist jetzt auch vor kurzem
aufgetreten, nehmen wir eine Datenbank und die Application-Server, die
müssen ja auch konfiguriert sein, wie die miteinander reden. The
Datenbank sagt man du kannst 5000 Connections annehmen. Und je nachdem
wie viele App-Server ich davor stelle und die skaliere, müssen die die
Datenbank, die abhängige, auch natürlich das können. Jetzt gibt es noch
ein Pool im Applicationserver um die Connections zu reusen und da gibt
es so eine Konfiguration, was ist die minimale Anzahl und was ist die
größte Anzahl, was du kannst. Man sollte tunlichst das hinkriegen, dass
die die Summe aller maximalen Anzahl vom Appserver einhergeht mit der
Oracle-Datenbank. Jetzt liegen die zum Beispiel in verschiedenen
Systemen. Mir ist kein Validierungstool, dass das validieren kann
überhaupt. Also jetzt, es gibt Standards draußen, HP OpenView oder
solche Monitoringtools, die wo man das machen kann, wahrscheinlich auch
so Regeln einbauen, aber das muss man alles manuell programmieren und
das haben wir glaube ich gar nicht. Bei uns knallt es, dann gucken, dann
gibt es ein Ticket und so weiter. Eine spezielle Konfiguration, war die
?1:17:27, die fand ich gar nicht so wichtig. Ob da jetzt noch drei oder
fünf, ist ja egal, irgendeine fährt da hoch, hat eine Mindestanzahl, hat
sich aber da rausgestellt, das war Fehlkonfiguration, weil wenn jetzt
alle 50 App-Server drei haben, drei Mal fünf sind 150 und jetzt kommt
auf einmal Requests rein. Das ist so, der Taglast geht los oder ein
Flashsale, die sagen jetzt, okay jetzt verkaufen wir mal hier
Fernsehfreischaltung, irgendwelche (?1:17:52). Dann kommen auf einmal
ganz viele Leute zu selben Zeit. Das kann man im Fernsehen messen
übrigens. Deswegen sollten eigentlich, jetzt beim Kunden zum Beispiel,
dass die Leute, die so eine Werbung freischalten, sollten die auch sagen
„Passt mal auf hier, Ops-Leute, zu der und der Zeit läuft diese Werbung.
Wundert euch nicht. Das ist keine Attacke. Das ist keine DoS-Attacke".
Nicht, dass die denken oh, ist eine DoS-Attacke, wir cutten mal den
Traffic. Das ist auch passiert beim Kunden zum Beispiel. Also
Missverständis über ­— weil die dachten wir werden attackiert, oh mein
Gott, keiner was Bescheid gesagt, machen sie dicht und dann ist der
ganze Umsatz flöten gegangen, naja. Und da war es so gewesen, dass die
drei eingestellt waren und dann kamen die alle rein und dann kam die
Datenbank nicht hinterher so schnell wie möglich die Connections
anzulegen. Das kostet auch Zeit. Und dann sind ein Haufen Fehler
passiert. Das passiert aber nur *einmal* bei *einem* Kunden, nur
sonnabend früh. Und damit habe ich festgestellt, weil es bei ihm
fehlgeschlagen ist, dass — das war durch einen neuen Code, den wir
eingeführt haben. Der ist dann fehlgeschlagen. Dann haben wir den
analysiert und dann war es der Hintergrund, was ich raugekriegt habe,
dadurch haben wir rausgekriegt, dass wir eigentlich ein
Performance-Problem haben. Bei allen Kunden. Wir konnten es bloß nie
messen. Wir haben hier nicht die Visibility gehabt. Zum Beispiel, wir
haben da eine Konfiguration, aber keine dazugehörigen Metriken. Also das
ist—

R1: Ja klar, was man nicht messen kann, kann man auch nicht—

I8: Das sieht man nicht. Dann hofft man, dass das geht. Dann glaubt —
das ist so wie eine Religion halt.

R1: Gibt es denn einen Unterschied zwischen falscher und schlechter
Konfiguration?

I8: Ja. Falsche Konfiguration ist für mich *das geht gar nicht, das
funktional überhaupt nicht* und schlecht heißt naja, *verbraucht mehr
Ressourcen und ist ein bisschen langsamer*. Sowas zum Beispiel. Das ist
der Klassiker. Cache zu klein konfiguriert. Kann man besser machen.
Höher schrauben. Also funktioniert, ist alles da. Der Kunde wartet ein
My länger, aber, und bei uns rödeln die Leute rum, aber—

R1: Und das ist dann da mit dem Beispiel mit dem (?1:19:47) denn eine
schlechte oder eine falsche Konfiguration?

I8: Das ist eine schlechte Konfiguration aus meiner Sicht. Also keine
falsche, aber eine schlechte, weil meistens geht es ja. Und das hat sich
auch wieder eingefangen, also das ist ja, war bloß dann Error-Rate hoch
und das System hat darauf reagiert und das kann damit umgehen danach.

R1: Wie häufig treten denn bei euch Konfigurationsfehler denn auf bei
der Arbeit?

I8: Also ich wette, also das kann man nicht messen, weil dazu zählt ja
auch ich ändere meine lokale Entwicklungsumgebung und da zählt ja auch
zum Beispiel Git-Repositorys oder irgendwas, das ist ja jedes Mal ein
anderes Fehlerbild, was man da kriegt. Ich wette das passiert jedem
Entwickler zehn Mal am Tag irgendwie, wenn er irgendwas — kommt darauf
an, was man als Konfiguration sieht wieder, wahrscheinlich. Aber sehr,
sehr häufig. Bin ich mir ziemlich sicher. Das ist, was ich meine mit
wenn ich dann mal was anfassen will, dass ich schnellstmöglich Feedback
kriege und weil Entwickler meistens mit Properties-Files, reinen Text
und keine Validatoren, arbeitet, hat er täglich damit zu kämpfen denke
ich.

R1: Wann kriegt ihr denn so typischerweise Konfigurationsfehler? Am
Anfang, wenn ihr euch mit etwas beschäftigt oder erst wenn es deployt
ist oder?

I8: In allen Inkarnationen wieder. Also von lokal auf der
Entwicklungskiste, dann kompiliert er vielleicht nicht, weil falsches
Repository, bis hin zu wir hoffen, dass wir alle möglichen
Konfigurationsfehler in der Buildchain erwischen und dann gibt es aber
welche in dem Environment, wo man mit Metriken nachvollziehen, ob das so
eingehalten wird oder nicht.

R1: Gibt es Unterschiede bei Konfiguratiosnfehlern zwischen fachlicher
und technischer Konfiguration?

I8: Ja, weil die fachliche Konfiguration — das sind andere
Stakeholder, die dahinter sind. Die fachliche, die haben einen ganz
anderen, andere Ziele um das zu konfigurieren, lass es mich mal so
ausdrücken. Wenn es nach der fachlichen Konfiguration gehe, gäbe es
keine Caches. Die würden sagen Caches sind alles blöde, wir wollen immer
die aktuellsten Daten, wenn ich irgendwas ändere, ist es sofort sichtbar
für alle auf der Welt. Und dann kommen die Techniker und sagen „Ne,
machen wir nicht\". Und das ist ein riesen Unterschied. Und dann ist
wieder die Diskussion, wie lange kann der Cache leben, wie aktuell muss
das sein, was ist noch verkraftbar und so weiter. Und deswegen ist es
ein riesen Unterschied, weil die, die haben konträre Ziele. Also das ist
auch der Gedanke von Ops und Entwicklern. Der Entwickler will Feature
raus, raus, raus, raus, Op sagt, ey rührt das System nicht an, ich bin
froh, dass ich jetzt Wochenende habe. Das ist ja das Ziel, was man damit
machen kann, ist da ja das Problem.

R1: Wie gehst du denn typischerweise vor um Konfigurationsfehler zu
finden und zu beheben?

I8: Meistens, Reihenfolge ist — also eigentlich weiß man ja nicht,
dass es ein Konfigurationsfehler ist. Also es gibt, oder sagen wir mal
es gibt zwei Sachen, die man machen kann. Wenn man Feedback hat und der
sagt das ist falsch konfiguriert, rot, dann suche ich den Code dazu, der
das ausliest und dann versuche, gucken welche validen Values und so
weiter. Also meistens immer erstmal Konfiguration mit dem Code zu mappen
mehr oder weniger. Oder umgedreht, ich habe einen Fehler, gucke in den
Code rein, „Ah, das kann man konfigurieren.", dann gehe ich zu der
Konfiguration und ändere das. Da gibt es aber kein *die Konfiguration
ist rot*, die ist da, wo du sie konfigurierst vielleicht
miskonfiguriert, ist ein Fehler in der Konfiguration, aber dann über den
Codepfad und den Error—

R1: Das ist jetzt aber alles bei Optionen, die ihr selber eingebaut habt
im Code. Was ist denn, wenn es jetzt eine Spring-Boot-Konfiguration ist
oder so. Oder eine Oracle-Konfiguration.

I8: Na Oracle ist, das haben wir ja auch gehabt, wenn jetzt hier die
DBAs zum Beispiel. Die kennen ja nicht unsere Applikation, was wir damit
machen und die stellen irgendwas ein. Dann kriegen wir meistens
irgendwelche Fehler, dass irgendwas nicht funktioniert und dann fangen
wir an, analysieren und überlegen. Dann reden wir über die über die
technische Dokumentation mehr, dass es diese Konfigurationsmöglichkeiten
gibt. Wenn wir Glück haben, kommen wir selber drauf und können das
selber validieren. Also wir haben so bestimmte Rechte können wir jetzt
schon gucken, mit dem Leuten reden, dann kriegen wir schon viele
Informationen raus.

R1: Und StackOverflow oder sowas bei andersartigen?

I8: Ja, das ist ja der Klassiker. Also die—

R1: Wird schon immer nicht genannt, bei unseren Interviews.

I8: Ne, also StackOverflow ist wahrscheinlich — ist nicht nur
StackOverflow. Meistens macht man Google und Google ist auf
StackOverflow. So ist die Reihenfolge. Man sagt oh, es gibt eine
Konfiguration — das machen wir mit Tomcat-Konfigurationen, das ist
sehr, also mögliche Konfigurationen zu finden um Performance-Probleme zu
beheben geht ausschließlich darüber. Das ist immer, irgendeiner hat das
Problem schon gehabt und dann löst man das. So als Inputquelle für
gültige Values, ja. Sehr, sehr, also ist die Regel.

R2: Oder vielleicht mit Kollegen sprechen?

I8: Das auch. Ja also es gibt die erfahrenen Entwickler, die kommen dann
meistens „Was sind denn die Werte?" oder mit Performance-Engineering,
die schon mal irgendwas custom ange— aber der erste ist immer
wahrscheinlich „Was kann man konfigurieren?" und dann ist der zweite
Schritt wahrscheinlich „Ah, es gibt das Property. Was ist denn
eingestellt bei den Kunden, bei anderen?". Dann vergleicht man das oder
probiert es selber aus.

R2: Also erst Dokumentation, dann googeln?

I8: Erst Google. Google ist immer offen, wirklich bei jedem.
Dokumentation — also jetzt zu sagen, dass — diese Diskussion hatte
ich auch schon mit vielen Leuten gehabt. „Das kann man mit Dokumentation
erschlagen." Äh, ne. Kann man nicht. Also es sollte intuitiv sein, man
muss in dem Moment, wo man es appliet, sollte man — also jetzt bei,
für einen Businessentwickler — sollte sehen, dass es rot, gelb oder
irgendwas, Nachrichten, vielleicht die Dokumentation gleich daneben
haben, dass er nicht erstmal eine ganz andere Webseite, die UI kennen
muss und so weiter und dadrinnen suchen noch und zufällig das —
deswegen haben wir bei uns in der UI ist das gängige Pattern, dass man
da so ein Fragezeichen hat, wo man draufklicken kann und dann sich das
anschauen, was da valide ist. Das hilft dann. Wenn das nicht da ist, ist
schlecht. Haben wir aber auch. Historisch gesehen, war schon früher
immer so gewesen.

R1: Welche Strategien habt ihr denn um Konfigurationsfehlern
vorzubeugen?

I8: Das ist wie gesagt die Validierung davor. Also es kommt wieder von
je nachdem was man konfiguriert. Bei den Businessentwicklern sind es
wirklich die Validierungen im UI. Das ist das wichtigste. Und die
Dokumentation, die dann dran ist, dass der das versteht. Bei den
Entwicklern ist es eher die Buildchain, wo der Unittests drauf schreibt,
und derjenige, der die Komponente gebaut hat und die Konfiguration
eingeführt hat, dass der sagt, das sind meine validen und dann knallt
ein Unittest. Sowas machen wir meistens.

R1: Wie habt denn ihr bei der — die Validierung, habt da ihr selber
das per Hand geschrieben oder ist da so ein SAT-Solver dahinter?

I8: Das ist, bis jetzt kenne ich noch kein gutes Framework, was das
can. Also ich kenne einige, viele haben es mit XML probiert, aber das
ist irgendwie komischerweise nicht so gerne gesehen im Sinne von, weil
da hat man ja zumindest kann man Datentypen angeben, man kann sagen
welche Reihenfolge und so weiter. Aber das reicht nicht für
Konfiguration aus meiner Sicht. Weil man hat ja Abhängigkeiten zwischen
den Konfigurationen und wenn der Wert so ist und der andere so, dann
geht das nicht, aber wenn der ein bisschen höher — das ist immer nur
auf das eine Konfigurationsvalue, aber das ist ja, die hängen ja alle
miteinander zusammen. Da bräuchte man so eine andere Komponente, die das
da durchcheckt.

R2: Also ihr habt da auch kein eigenes Tool, sondern ihr schreibt das so
wie es gerade für die Konfiguration gerade passt?

I8: Nur für die Businessentwickler, aber nicht für die Entwickler. The
Entwickler machen meistens das über JUnit-Tests. Würde ich denken jetzt.
Oder ich irre mich und ich habe was vergessen, aber —

R1: Testcontainer oder so. Für das Framework.

I8: Ne. Also wenn Unittest. Also wir, es gibt doch die Annahme mit
SonarQube, dass man da auch bestimmte Regeln da kontrollieren kann, aber
SonarQube — der Ruf ist besser als es ist aus meiner Sicht. Weil man
muss ja diese Regeln pflegen, man könnte den Build jetzt fehlschlagen,
wenn man einen alten Monolithen, alten Code hat, dann muss man den
erstmal umbauen, damit man diese Regeln applien kann. Dann kann man das
für neuen Code machen, dann hat aber einer nur schnell mal Code
formatiert, dann knallt der wegen formatierter Code da, obwohl er hat da
gar nichts geändert und — also SonarQube kann man so als zusätzliche
Inputquelle sich zum inspirieren lassen für QA, aber im Buildprozess
würde ich das niemandem empfehlen, weil das wirklich bremst auch. If
man neue Projekte anfängt und gleich von vorneherein SonarQube macht,
dann ist das eine andere Option sowas zu validieren und neue Regeln zu
applien. Aber für Monolithen ist das Quark.

R1: Ja, dann sind wir jetzt schon beim Verbesserungsbedarf. Also viele
hatten halt vorher — also bei anderen Interviews — gesagt,
Dokumentation muss irgendwie verbessert werden.

I8: Ach, ja.

R1: Was erwartest du denn von einer guten Dokumentation, dass es
vielleicht benutzbar ist oder so? Oder ist das gar nicht wirklich —

I8: Also das gilt für alle eigentlich: Also wenn ich irgendwas
dokumentiere, sollte die Dokumentation immer aktuell sein. Das ist so
das größte, erste Problem. Wie halte ich die aktuell? Und der einzige
Grund die richtig aktuell zu halten ist, dass die mit dem Code
eingecheckt in dem Moment wo die Änderung da ist. Wenn die in
verschiedene Repositorys ist das schon veraltet, die Dokumentation.
Definitiv. So, jetzt man dann die Dokumentation geändert und dann muss
die Dokumentation so sein, dass da wo ich das konfiguriere (?1:29:04)
gelinkt, dass man da gleich draufkommt. Wenn die auf einem anderen
Server, in irgendeinem Dokument ist, benutzt die keiner. Definitiv. And
die Dokumentation, wenn die sagen das muss mehr dokumentiert werden,
also mehr im Sinne von, dass alles dokumentiert, vollständig im Sinne
die Properties, ja. Die muss aber so einfach geschrieben werden, nicht,
dass da ein riesen Text steht. Und da kommt aber auch die Grenze gleich
dazu. Wenn man komplexe Sachen einstellt, die kann man manchmal nicht da
so beschreiben. Da gehört einfach mal ein bisschen dazu. Also jetzt eine
Garbagecollector-Konfiguration, da kann man auch nichts dokumentieren.
Man kann eine Garbagecollector-Dokumentation, wie der funktioniert um
mögliche Values, Bereiche machen, aber was man dann messen und Metriken
und zu beschreiben, wenn du das und das einstellst, musst du davon die
Metriken um zu gucken um irgendwas. Da gibt es ganz teure Tools für, die
kosten 8000 Euro, die das nur anzeigen die Metriken. Geschweige denn
Empfehlungen darauf geben. Das ist — das hängt davon ab. Simple
Sachen möglichst einfach validieren vorher, Dokumentation wenn es nicht
(?1:30:13), aber ein Validierer würde schon viel helfen. So bei
Properties, wo du sagst das ist ein Int oder ein Boolean. Ich kann auch
Spaces.

R1: Welche Verbesserungen würdest du dir denn wünschen von, Hinsicht der
Konfiguration von Softwaresystemen? Also generell erstmal so.

I8: Meistens ist ja die Konfiguration ist ja sehr, sehr customisiert. It
gibt da beim Docker zum Beispiel da — was ist denn da die
Konfiguration beim Docker? Das macht jeder anders. Da gibt es so best
Practices, aber was wie wann konkret konfiguriert wird? Ich sage jetzt
mal, ein Dockercontainer mit CentOS, Maven, Java drinnen würde man
annehmen, dass es den als Standard gibt, aber wie viele gibt es denn da
draußen? Wir haben alleine schon drei in der Firma, wo ich mich frage
warum. Mal willst du Ressourcen sparen, mal brauchst du aber noch was
anderes, weil es als Basis für die nächste Generation von Software ist,
also es ist, ich glaube nicht, dass es da eine allgemeingültige Lösung
gibt, aber es gibt für bestimmte Use Cases, wie jetzt zum Beispiel wie
gesagt jetzt die Buildumgebung. Wo ich sage ich habe eine Git, also drei
Tools — Git, Jenkins, Quayund Nexus, oder vier Tools, die alle
miteinander zu tun haben, unterschiedliche Systeme, aber ein Tool, das
sicherstellt, dass die alle, die der Zusammenhang harmoniert, zum
Example. Sowas, so eine globalen, die gibt es wahrscheinlich bei
Tivoli, aber das muss man auch wieder alles manuell konfigurieren. Weil
diese — der eine nimmt Nexus, der andere nimmt Artifactory, dann Git
und Subversion. Weil jede dieser Komponenten kann dann ausgetauscht
will. Jenkins, Bamboo.

R1: Wäre es da vielleicht sinnvoll, dass man ein bisschen das vorgibt,
dass alle nur Git und alle kriegen eine vorkonfigurierte Jenkinsinstanz
und —

I8: Na bei uns ist das so. Wir haben Git, Jenkins und Nexus und Quay,
weil Quay ist nun bei Docker und Jenkins ist für die Jar-Files und
vielleicht irgendwelche anderen Artefakte. Aber dann, es gibt kein Tool
draußen, was genau diese Chain kann. Obwohl die jetzt nicht so weit
hergeholt ist. Also wahrscheinlich gibt es eins und aber ich kenne das
vielleicht nicht, aber habe mich jetzt auch noch nicht damit beschäftigt
groß. Aber das ist zum Beispiel für mich, jetzt wenn ich das, meine
jetzige Arbeit, wir haben es gerade nicht. Kann sein, dass es was
draußen gibt. Schön wäre es. Oder genauso beim Garbagecollector. Gut, da
gibt es das Tool, Garbagecollector-Konfiguration, kann man kaufen, muss
man wieder connecten, viel Geld ausgeben, dann hat man Grafiken. Then
braucht man das Lastverhalten, da muss man viel Wissen, welche Last man
wie was konfigurieren um sagen kann, dass diese Kurve besser als diese
Kurve ist.

R1: Und was würde dir helfen schneller Konfigurationsfehler zu finden?
Oder zu beheben?

I8: Also Validatoren ist das einfache, das hatten wir ja schon mehrfach
jetzt. Das wäre, hier falsches eingetragen. Da man jetzt diese
Möglichkeit nicht hat vorher, also weil ja ich nicht dieses Value
angebe, sondern irgendeiner draußen und der das gar nicht weiß und die
Möglichkeit und der dachte sich da was dabei. Ich sage mal, um das
rauszukriegen, welche Informationen sind denn wichtig? Es gibt da
meistens einen Grund warum die das tun. Da sind ja meistens auch
Ticketsysteme dran, wo man sagt warum wurde diese Konfiguration gemacht?
Wir haben zum Beispiel historische Konfigurationen, die irgendwann mal
vor drei oder vier Monaten mal gemacht wurde, irgendwelche
Feature-Toggles, die irgendwelche Emergency-Switches sind und alten Code
ausschalten. Und jetzt wollen wir diesen Feature-Toggle ausbauen, wir
wissen aber nicht warum der noch an ist. Meistens vergessen. Weil der
Lifecycle nicht richtig definiert wurde oder nicht rangeschrieben warum
oder da hat er mal schnell was ausprobiert oder — also der Grund ist
zum Beispiel eine wichtige Sache. Der Grund wer hat was warum geändert.
Das sind für komplexe Systeme, also wenn der Entwickler das nicht macht,
das ist sehr wichtig. Dafür gibt es Configuration as Code. Wer hat das
eingecheckt? Was, welches Konfigurationsproperty? Und wann ist es
appliet worden? Kriegt man auch noch raus, wenn die Deploymentcircle(?),
wann das appliet wurde. Dann hat kriegt man — deswegen ist
Configuration as Code mit Git nicht schlecht.

R1: Aber ihr habt dann bei dem Lifecycle, habt ihr jetzt nicht irgendwie
eine Möglichkeit zu sagen *nur bitte bis dann und dann* oder? Das ist
kein Automatismus, oder?

I8: Deswegen führen wir ja jetzt — Split.io ist so ein Tool, was wir
versuchen zu integrieren gerade. Also früher war das ja alles nur, alles
über Properties und dann hat man gemerkt, naja das eine Property ist
eine Performance-Optimierung und das andere ist ein Feature-Toggle, was
einen bestimmten Lifecycle hat. Beim Performance, das bleibt für immer,
das soll auch so bleiben. Und beim Feature-Toggle ist eine Seite, wo du
dynamisch mal systematisch aufräumen willst. Wo du noch eine
Probe-Workflow hast und mit Kunden sprichst. Möglichst jetzt nicht ein
Deployment drin hast und so weiter. Maintenance wenn du einen Zeitpunkt
mit dabei und so weiter. Oder mal eine Stunde freischalten, wieder
wegschalten. Das sind ganz andere Anforderungen.