>> There is so much to talk about when
it comes to how architecture is changing.
This time, Uli and Eric and I discuss Serverless, so join us.
[MUSIC].
>> Welcome to the Azure Enablement Show,
where we'll be discussing the challenges
you and our other tech-savvy customers have encountered.
Together, we'll be talking with experts to find
out how they think about these problems.
We've recommended tools and best practices and
tips they've learned from years of experience that you can use.
Today on the Azure Enablement Show,
we do 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 the discussion.
We're back with Uli and Eric.
I want to pick up a conversation we're just having.
We were talking a little bit about how architecture is changing
as new things knock on our door.
The next thing I'd like to talk about
is this really interesting shift,
which I have heard called Serverless,
but I've also heard Serverless by many things.
I know what I think when I think of Serverless.
Let's just define Serverless, get that out of the way.
Then I really like to understand,
what does that mean in the realm of architecture.
Either you want to give me your best definition of Serverless,
and maybe they'll mess with mine.
>> Let me start giving you three dimensions of Serverless,
which I think would help with
the confusion that you have in your head, David.
>> Cool.
>> The first one is environment where
an observable state is shared in event.
You have a piece of code, in this case,
a function or the Lambda architecture as AWS has propagated in.
That is Serverless because the event exists without
a server being called and simply is in environment,
and then there is an environment that just picks it up,
piece of code that says,
''I'm interested in this event.
Let me pick it up and do something with it.''
That's the functional programming model that
started the Serverless revolution.
But it's really just effectively saying,
''Hey, there's an event.
Something happened and I'm reacting to it.''
The next thing is an operational pattern.
When you think about Serverless in the functional space,
you effectively see hey,
I don't know how many machines host this function,
is it one, five, 20?
I don't know. I don't care
because there's an event and there's a function.
There's an operational pattern that's now
being used to generalize the concept of Serverless.
Which is now, for example,
if you issue a query to a SQL data warehouse,
that is called Serverless because you don't know
how many instances of data warehouses are running.
You simply say, here's an event,
a thing, a query,
and I'm passing it over to
a database and the database will take care of it.
That's the other half of that Serverless.
You will see this more and more in the Cloud where
effectively an operational pattern
is hiding all the details from you.
You just tell us how far or how high you want the Cloud to jump.
You could have the trigger,
which in this case is the query and event or something like that.
The last piece of Serverless is a business model.
Because when Lambda came to be,
it was the first time that it was
effectively charged by calling and running the function.
You didn't get charged by a virtual machine
by our minute or whatever the thing is,
or by hosting a database,
you were charged by invoking something and
that invocation effectively cost money.
You have these three things coming
together really forming what's called Serverless.
>> Yeah, it does help me.
The thing that gets really funky for me and maybe that
gets into the realm of how architecture is changing,
is I have a hard time conceiving of,
okay, I'm using Serverless,
let's say I'm using functions as a service,
but I have a whole bunch of functions that
are together collaboratively the application,
like these 10 functions are my application.
Maybe I changed the functions themselves
separately and then call it a new application.
Like is it the same application
if I've changed three of the functions in it?
Can we talk a little about
architecture and how to think about this,
and how to think about this really decomposed micro computing,
micro-level of things that are
just the code that
does something in a band, as you said, and code runs?
Now, how do I think about that from an architectural perspective?
>> Let's start first with the definition
because your application is the code,
the functions, and the events.
Without the events, nothing happens,
the application is dead in the water.
You have triggers, events,
that effectively are key definition part of the application.
The important piece is that you need to
think through how does the event happen?
Then who wants to pick it up?
What's the next step after you're doing this?
It's a different way of doing workflows.
That's why you had initially,
you at stateless functions that didn't remember anything,
they're just event, function, done.
But now you have durable functions because now you
want to step up on event 1 happened.
I did some things,
but now I'm waiting for event 2.
Then I want to pick up where I left off and work on event 2.
That's a different way of doing workflow.
That's why Azure, for example,
has durable functions and non-durable functions.
You have stateless programming and stateful programming,
and then logic apps, for example,
as the new implementation actually sits on top of
durable functions to make it very easy to
build very rich workflow applications.
For me, it's really the components are the events,
the code, and then the state that you are manipulating.
Depending on how you do it,
it's either becoming a stateful of functions
app or workflow depending on how you want to call it,
but that's really what's happening in functions today.
>> Well, I think in addition,
the only thing I want to add to that really is I think that there
are categories of Serverless.
I think largely,
the misconception or it's an adequate conception that
functions are basically
the primary or principal actor in Serverless architecture,
which could be true,
but there are also other elements of Serverless compute,
ranging from infrastructure like
Serverless Kubernetes to logic apps,
our version of Serverless workflows really,
you talked about, Serverless app services and API gateways.
These are all elements in which we're [inaudible]
away the infrastructure because largely,
we're going to manage that as a Cloud provider.
Then the application architecture
really is how do I consume these things?
It's not only through
the implementation of code that
runs inside of a function boundary,
it could be the integration of a function, a stateful function,
along with a Serverless workflow
and those two components become an application.
But earlier in your question, David,
I think there's something that I bet you,
that there's a more meaning hiding behind that question.
Which is, if I have all of
these different Serverless capabilities
which may accrue to microservice boundaries,
and those microservices are reused across multiple applications,
then what is an application?
What does it actually become?
Is an application just a collection of
microservices with an orchestrator out front?
Versus of managing overlapping dependencies
of microservices as they
participate in different application scopes.
>> It's a little tricky because microservice
is even a bigger level and I'm
thinking about a collection of functions here.
How do I conceive of it?
The thing that's a little tricky, of course,
here is what's the difference between
a bunch of functions and a pass from your perspective?
Like somebody else is running the code,
not my server, not my thing.
To me, the differential there is the unit of computation.
>> Fine grade to porch grade.
>> That I'm paying attention to.
But then I don't know how to
understand those units of computation in
the aggregate in such a way that I
can reason about it from an architectural perspective,
reason about it from a management perspective.
That's my question.
How do I know I'm going to do a new release?
What's a new release mean?
>> Yeah. But I think it comes back
to the three elements that I mentioned,
which is you have the triggers, input, and output.
Because a function ultimately processes,
gets activated bits on something.
It does something and then it hands off to the next stage.
You have the staging,
which is then defined by these events which are restate changes.
Depending on how you look at it,
the state could be centrally managed in a database or it could be
just something that the function passes on and that's ephemeral.
It doesn't really matter, but at the end of the day,
there are triggers, inputs, and outputs,
and the functionality is really what you want to manage as an app.
You can say that the input, output function,
that's an application in itself because you can
change the entire thing without changing any of the dependencies.
That's not quite true if you have stateful functions,
where you say actually what I'm doing
is the starting point for the next section,
but that's certainly something that you can walk
through with respect to have a definition of the dataflow.
If it's stateful and building on top of each other,
then you have to manage that as an app.
If it's not, which I think is ideal,
then you can just take the triggers and the function and
call that a capability that
can slip in and out and change and what you thought.
>> Like we did in our previous conversation about
containers in which I said, ''Okay,
this Rosie world,
now we have Serverless. Everything is fixed."
Which it's not true because it occurs to me that for example,
your durable functions example,
it's a little bit like database schema.
If I have something hanging something off to something else and I
change one part of this while reverting is hard.
It's really super hard if everything else is now
expecting Version 3,
like I'm now in Version 4 or depending on as before.
Am I correct that we have not broken the law of
physics here or the law of
architectural physics, whenever you want to call it?
The same problems we had before here,
they're just perhaps in a different form?
The same concerns and said that,
that would problems is not the way I really want to state it.
>> I've been around long enough to remember binary compatibility.
I think it's really just an evolution of that challenge.
If I make a call to a component and that component breaks
its contracts and it changes the signature in how I call it,
that is an issue that we have to deal with.
Especially now that application components
are becoming more autonomous,
more reused across different application boundaries,
and that's the way I think about apps these ways.
It's a box of domains around specific microservices.
Those components may actually belong to multiple app domains.
Now, the question becomes, well,
what if those microservices
either change the way in
which they're called or change of behavior?
The call is the same, but the behavior is different
and I'm not expecting it. What do I do?
This to me loops back to our discussion about resiliency.
If some sub-component of my application is not working,
how do I make it seem like it is until I can
actually diagnose and implement the fix?
>> Let me throw in a contrarian view a little bit.
Because I would say that the functions or
Lambda-based architecture has changed fundamentally some things.
If you keep it stateless or ephemeral.
If the function truly only acts on input,
does something with that input and creates an output,
but it doesn't store anything,
it doesn't put anything in
the database or into whatever durable system,
that is actually a fundamental change in terms of how we do this.
It's not a new thing.
We used to have a reactive.NET in way back when.
There's a lot of knowledge about this stuff,
but I would say that the functions based model,
if done stateless,
is really changing the way things work and
it's very flexible and easy to manage.
You still have to do management,
meaning versioning and those things.
Once you get into durable state and you manage,
for example, durable functions,
then it gets more complicated and your concerns, David,
like version mismatch and stuff like that,
continue to be important.
But if you can get to input-output manipulations, awesome.
>> That's for you is one of the fundamental from
an architectural perspective changes
for a way to think about things.
Well, so for the lack of whiplash,
I want to go into yet another,
we've talked about the context of containers,
we've talked about the context of collaboration environments,
and just now talking about the context of Serverless.
I know of a couple of other contexts that are also
seemed to me like well off
forbidden path that architects have to think about.
Would you be willing to talk about this in another video?
>> Yeah, worth it.
>> Cool. Let's do that.
Well, we're deep in the middle of this conversation.
I really hope you'll join us on
the next episode where we pick up right where we left off.
Join us again on the Azure Enablement Show.
[MUSIC]