>> Hey, we're back with our architects,
Uli and Eric to go a little abstract this time.
This time I'm going to answer the question,
is that configurable? Join us.
[MUSIC]
Welcome to the Azure Enablement show.
We will be discussing the challenges that
you and our other tech survey customers have encountered.
Together, we'll be talking with experts to find out
how they think about these problems,
recommended tools and best practices and
tips they've learned from years of experience that you can use.
Today I will show you something we've never done before.
We're going to take our script and we're going to simply rip it up
because we want to talk today about
architecture and architecture is discussion.
We're back with Uli and Eric for some more architecture talk.
This time I thought it might be cool to go a
abstract and to go deep
into one of the architectural questions
that I think that comes up all the time.
This comes up all the time, especially when architects
are dealing with development teams.
The question that I think we're going
to focus on here is the question of, is that configurable?
Let's start to just frame this out a little bit
in terms of what we mean by, is that configurable?
You're writing software or you're deploying a system or
something like that and there's a choice to be made here.
There's lots of choices,
I guess is what this is all about.
There's lots of choices about,
do you provide for the opportunity
to configure and to change the behavior of something?
When do you allow it to do that?
Do we hard code stuff?
Do we not hard code stuff?
Anyway, maybe one of you has
a good place to start us because I
find that there's so many different questions here.
We can go in many directions
and we'll try to take as many as makes sense.
>> Uli, I hope you don't mind if I go first because I'm
coming from a place of pain around this.
Because actually this topic came
from my brain and I wanted to throw it out there.
Is it configurable?
Is a question that I find myself asking
way too many developers across
way too many codebases all the time.
Whether it's us internally or if
it's us dealing with clients and customers.
But there is this predilection to go fast and break things,
but at the same time,
we actually have to realize that
we're accumulating technical debt.
Whether I'm doing a code review or I'm
sensing the fact that somebody's taking a shortcut,
asking this question is always key.
Then the question becomes, well,
what do we do if it's not configurable?
Do we take time now to fix it or do we
incur that technical debt and then
come up with a strategy to reduce it later?
But the questions that I often ask customers in this space is,
why do you hard code?
Maybe hard coding isn't always bad.
Maybe there's a speed versus manageability tradeoff that's made.
But that's like the background
of why I thought this would be great for us to talk about.
>> I look through another element into this,
so this is obviously important configuration and so forth.
The other one that we also all
know is that ultimately things need to change.
You can introduce change in the number of ways.
You can rewrite code or you can add new things and so forth.
But configuration is another way we can
change the behavior of an application if you thought about it.
The third dimension of configuration in the larger sense is,
what if there
situations that arise that you haven't thought about?
How can you deal with that?
What are strategies for you to embrace that kind of new thinking,
call it self-service in a lot of ways,
that allows you to effectively build
systems solutions that can embrace and
support those kind of flexibility choices
that clients increasingly want to have?
Because they have very smart people that work in finance,
in IT, in HR,
whatever, and they might say, "Yeah,
the workflow of that Eric,
as the developer even here is great,
but it doesn't quite meet what I want to do and so I don't want to
go back to Eric and ask him to change the workflow."
I think there are a couple of interesting dimensions of
configurability that we can talk about here.
>> Let's go into some of those dimensions.
I want also to get a little less abstract here,
but I also would like to play devil's advocate
here a little bit for a moment, Eric,
about the last thing you said,
so your question about hard coding.
Here's my argument for hard coding,
which I don't necessarily believe,
but I'm going to I'm going to submit it to you.
If I hard code something then I
know exactly what is running in production.
There's no guess. There's no guess as to what the parameters are,
there's no guess as to what
the new version of the retry timeout is.
There's no guess and that sort of stuff.
I just know what it is because it's right there in the code.
I can point you to the source code.
What do you say to that?
>> I think that that is alluring,
but I think it's a temptation that we
have to start to move away from.
Because there are systems that we
can put in place that allow us to
determine which branch of
the code is actually running in which environment.
That of course, focuses on everything
from live site management to application deployment
to source control systems and all of this stuff
around how we manage code and the pipelines to deploy that code.
A hard coded may be GUI that says,
oh, this is in production list, that might be harmless,
but coding ports and network addresses and
all these different things inside
the code that control functional behavior,
we have to resist that temptation.
Now, on the other hand though, David,
maybe playing devil's advocate to my own pet peeve,
is that I've seen customers and some of our clients go in
the opposite direction where everything is super configurable.
They've got database tables and schemas and XML files and
config files that the application
has to just interpret at runtime.
That may actually slow it down and increase the surface for
you to make configuration errors when you deploy.
It's a spectrum and I think you
want to be somewhere in here, like right in the middle.
>> I want to ask what Uli thinks,
but I just want to be clear.
I'm not just talking about what version
of the code do I have out there,
I'm talking about what I would call state.
Which state is that?
Collection of port numbers,
that collection of retry timeout amounts,
it is that collection of which database I'm using,
that configuration represents and application.
Configuration and application state aren't the same thing
because the applications diverge from its initial config.
But we're still talking state here and I'm saying
like if I give you the thing where
the state is written in it, then I know what it is.
Uli, what do you think about this?
Do you think it's middle like Eric is
saying or do you want to take even
yet another contrary position to the three of us now?
>> Well, the way I think about it,
I'm more on the extreme side.
Because ultimately when you think about a development process,
start with that scenario.
You go from your developer test,
user acceptance testing or whatever you'd like to do,
or if you go in Cloud-native,
you're going to do AB testing,
you're doing deployment in rings and those kind of things.
But at the end of the day,
things change and if you can't change with those things,
I've seen the most funny errors,
unfortunately, they are very time-consuming,
because somebody hard coded
a dependency and all of a
sudden you move from one environment to the other.
Go back to some of the sessions we
run earlier when you do resiliency.
Now all of a sudden the Cloud environment or
the hosting environment you're running in
decides that I need to eject you.
I need to move you from this environment to another one.
All of a sudden the namespace changes,
the IP addresses changes and whatnot and
all of a sudden you are dependent on what you learned,
what you originally ran,
and you can't do this anymore.
For me, dynamic behavior is implicit with
configurability and you'd be able to cope
with dynamic behavior is really important.
The way to deal with it though,
is when the application starts up,
you effectively read the configuration once and you cache it.
You don't go and check all the time.
You might say there is a timer inside my application that says,
if nothing happens, I will check every 24 hours or 48 hours,
whatever it is, if something has changed.
But I will not continuously go read new stuff and so forth.
For me, you're looking at a balance between yes,
it needs to be dynamic and configurable,
but on the other side, from
the runtime perspective you try to keep it as static as possible.
>> Also make sure that you can forcibly expire a cache,
so when you do have emergency changes,
you can actually implement those and the app is just not
ignoring you after you change values.
>> Well, so let's follow this path for one moment
because I suspect this is going to be a multi episode one as well.
When do you think it's okay to change configuration?
Let me be precise about that.
Is at A at deployment time,
is it B at deployment time plus
at runtime when perhaps you might
throw some feature flag or something that says,
now start doing something different ads and behavior.
Pick another thing up. Is it C all three of those?
Or is it D none of the above?
I realize I'm realize I'm doing A, B, C,
D on fingers, but you know what I mean.
>> We have a lot of number problem there.
But I think these all have to be
carefully couched
in live site management and standard operating procedures
and run books whenever you want to call them.
But deployment, sure, that should be an operational pipeline that
deploys an application in
a particular configuration and
in particular state deterministically.
When you're doing it live in production,
it's either in response to something dynamic, as Uli said,
that has changed whether or not it's
a Cloud migration and your host
that you were running on now runs on a different host
and hopefully you shouldn't be able to tell the difference,
but some instances you might and you
actually need to repair the state of that application.
That should be executed under
live site management operating procedures
in full view of everybody.
It should never be a developer logging in to
the VM redeploying something
to a container to change the state, willy-nilly.
I think it has to be carefully orchestrated,
which leads me to your third choice,
which was both of those,
but under those circumstances.
>> The only piece I would like to add to Eric's point
is configuration are software artifacts.
They need to be managed like software artifacts.
You need to look into whatever DevOps tool you use and
whatever method you use needs to include
configuration and other metadata about your application.
Again, I mentioned in one other session the concept of GitOps.
That is one emerging capability that allows you to
use Git to manage operational artifacts,
which configuration ultimately is in
a repository and version
it and understand which version is in production,
what the difference between A and B was,
so that you can really do
understanding what part of my configuration drifted from A to B?
Really treat those configuration items
as if they was software artifacts.
>> Yeah.
>> I think that's a really good place to stop.
I have more questions on this topic,
but I think this is a good place to stop because it's
like one of the most important things we can say which is
treat your config like code
in that way and I think that's a fine place to stop.
Why don't we stop here and then maybe we'll pick
up this conversation or another conversation later.
>> Anytime.
>> Absolutely.
>> That was a really cool set of conversations.
I hope you get a chance to watch those episodes.
We're going to move on to another topic here on
Armchair architects as part of the Azure enablement show.
[MUSIC]