Modern Architecture 101 for New Engineers & Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025

Hi everybody.

Hi. Thank you. Thank you. Yeah, I'm a real person. It's nice to say. Thank you

real person. It's nice to say. Thank you

very much. Appreciate it. Hi everybody.

>> Hi.

>> I mean, it's only four. It's not that late. We're all staying for the party.

late. We're all staying for the party.

So, I mean, let's just go with it. Um,

okay. So, I'm going to go ahead and begin even though we've got 30 seconds before I have to. So, you guys get bonus content. This will be excellent. Uh, I

content. This will be excellent. Uh, I

met a handful of people over here just out of curiosity. Quick show of hands.

I'm not going to ask you any follow-up questions. Uh, do you feel like you're

questions. Uh, do you feel like you're an architect or are you an architect?

Either one. Yes.

Oh, okay. That's a fascinating number of nos. All right, that's cool. Well, this

nos. All right, that's cool. Well, this

is for both of you. Obviously, this is an exciting title, you know, for all of you forgetful architects and all the new engineers out there. uh you know it the the number is that about 50% of all

developers at any given time have less than five years of experience. So the

reality is there's always new engineers coming on board and I think we can all agree that the barrier of entry into this field is a little bit higher than like a sweeper, right? I mean it's

there's a lot going on here and it can be overwhelming sometimes to think about all the different things you have to learn. What I I'm also a a computer

learn. What I I'm also a a computer science professor at university back at where I come from and uh students are incredibly intimidated like when you just just think just Google software and

just imagine all the things that come up from that and all the things they think they must know in order to get there and they don't have the advantage that a lot of you old guys do where they uh got to

see the HTTP spec start at one and work its way up, right? instead they're

starting now with all the complexities around CSS and all the other things as well. I mean, I just my heart goes out

well. I mean, I just my heart goes out to them because it's a it's a difficult place to go into for sure. And even with Chat GPT, I mean, honestly, I think we all know that chatbt makes our lives a

little bit better, right? I mean, we're not going to none of us who use it believe the hype around it's going to replace our jobs. That's for sure.

Unless you're a very crappy developer.

And that being said, it help it also helps new students, but it doesn't help new students, too, because they get to sidestep some of the things that you got to screw up and you'll never forget

screwing them up, right? I mean, that's the thing. And so, it's it's really

the thing. And so, it's it's really hard. So, welcome if you're a new

hard. So, welcome if you're a new engineer for sure. All right. Um, my

name is Jerry Nixon. J R Y Jerry. I live

in Colorado in the United States and I've lived there for a long, long time.

I work at Microsoft. I'm on the SQL server team and uh the primary product that I work on is SQL server because I'm on the SQL server team and uh but one of

the teams I work with that is serious is the data API builder team and we'll talk more about that in this but it is uh a big deal. Uh out of curiosity how many

big deal. Uh out of curiosity how many people use a database?

Great. All right. So I assume you all use SQL. All right. So I'm kidding. I

use SQL. All right. So I'm kidding. I

know you don't all use SQL but it's kind of fun. Um, all right. So, a little bit

of fun. Um, all right. So, a little bit about me that's worth saying and then I'll get on with it. Uh, this is me on the Enterprise. This is me on the

the Enterprise. This is me on the bridge. This is New York City. They had

bridge. This is New York City. They had

a fully re restored um portable bridge which was incredible. And, uh, I did get the picture with this lady in it, which is ridiculous because she's not in uniform. But, nonetheless, it was real

uniform. But, nonetheless, it was real and it was awesome. Does anybody know which enterprise this is? I'll give you a hint. It's NCC 1701 dash and then a

a hint. It's NCC 1701 dash and then a letter. It is D. They you I mean it's

letter. It is D. They you I mean it's always right when I go to Germany. They

get it right every time. And it's just uh it's it's just you would think with a room of nerds like this. If I asked you what color Darth Vader's lightsaber is, you would have no problem. But yeah,

can't do that. All right, let's move on.

Move on. So that's me. Uh by the way, I've I've worked at Microsoft for a long long time. And uh I was a I was a

long time. And uh I was a I was a developer evangelist for about a decade.

And so I used to talk about ZAML and all kinds of cool things that have kind of seen their day. And um it is then I was a field engineer for the longest time and this is where it really matters. I

was a field engineer working with what Microsoft calls it's F-15 right the top 15 customers. So just imagine the 15

15 customers. So just imagine the 15 largest customers in the world and so those are the ones super annoying to work with but really really big doing cool things sometimes but sometimes not.

And the reason I bring that up is it drives me crazy when I hear people say that's a best practice. Oh, well that's a best practice. Usually they just say that as some sort of like cover for something they're saying because they

can't think of a good argument for why they're right. And so they're well it's

they're right. And so they're well it's just a best practice. And it drives me nuts because there is no such thing as a best. I suppose it an example of a true

best. I suppose it an example of a true best practice would be not to use SQL injection. I suppose that would be a

injection. I suppose that would be a kind of best practice, but a true best practice usually comes from the cover of magazines and it just drives me crazy because the sorts of things that people

say are best practices really are just good for them or they happen to have seen it work or in a specific environment it happen to actually work.

But what they don't account for are the weird politics of my company or you don't understand the budget constraints or the fact that my entire development team is very junior or the uh the fact

that we were just merged into another company and the technology set is just not at my I I don't have the option to make a change, right? All of these things. And so you're like, "Oh, okay.

things. And so you're like, "Oh, okay.

So the opposite of a best practice is a worse practice. So everything else is

worse practice. So everything else is just a practice or a worse practice."

And it's not true. There are so many ways to do the same thing and to get it done. And let me give you this one

done. And let me give you this one little tidbit that you may not know any other way. When you look at companies

other way. When you look at companies like Twitter, for example, and you look at the things that they do and their architect goes on to some podcast and starts talking about a solution that

they did. I didn't mean to do that

they did. I didn't mean to do that architect. I'm sure whoever it is is a

architect. I'm sure whoever it is is a real architect. But just to remember

real architect. But just to remember that companies that size can afford incredible mistakes and they could just pay them pay their way out of it. It's

unbelievable. And so when they're like, "Oh yeah, we decided to do all this craziness over here and so far it's working and and that you're like that's a best practice, but it's not a best practice." It's because a company that

practice." It's because a company that size don't have to they don't have to think so strategically. They don't have to think at at this point of like I have about three weeks to get this built.

after that I will be busy with other projects and I have to get this so that it actually works and actually runs and can be maintained. They don't need to think in the same way and so they can just throw money at problems and

solutions in the way that you can't and that's where a true architect sort of comes into play here. For example, if you think about a best practice and how it's changed over time in the '9s we had

spaghetti code which back then was pretty good. Like you would, it's funny

pretty good. Like you would, it's funny because now in retrospect, we're kind of chuckling at it, but I mean, sure, we had go-tos and we know not to use them now, but it was actually functional. And

by the way, the economy still seemed to manage. It's funny, even with terrible

manage. It's funny, even with terrible spaghetti code, we still had applications that worked. And then we upgrade to multi-tier, right? Where we

have layers like a lasagna. And so in the 2000s, everybody had their three tier solution. And it was exciting,

tier solution. And it was exciting, right? multi-tier and you could go all

right? multi-tier and you could go all these layer and oh yeah it's so not spaghetti anymore and that's true and then about 10 well 15 years ago now in the in the tens I guess is that what you

call it the 2010s I guess um then we have microservices microservices which starts a brand new religion by the way and so now all of us are like oh microservices you're doing them wrong by the way I mean that's just

kind of that should be the subtext of every time you see microser and it was like little ravioli little bitty little compartmentalized things that you could deliver. They had their own database

deliver. They had their own database sometimes and all these other mechanisms. But what's funny all the way around is each of those works even still today. It turns out that if you have a

today. It turns out that if you have a three tier application and not multi and not microservices, it still runs today even still. In fact, many companies

even still. In fact, many companies still have their legacy applications that somehow still make them money and employ people and pay people's mortgages and all the other things as well. So,

it's just one of these things where you see these kind of eye roll moments where you're like, "Oh, I'm going to I'm going to write this in uh in VB." Yeah, sure.

Let's just say VB. I'm going to write this in VB. You're like, uh, I roll.

You're like, well, you do not know my situation. Like, I like I have to do it

situation. Like, I like I have to do it in VB because we got 18 other line of business applications, each one written in VB. And so, we've only hired VB

in VB. And so, we've only hired VB developers and we're only training VB developers. Well, you should be

developers. Well, you should be upgrading. You're like, ah, you do not

upgrading. You're like, ah, you do not pay the bills. Like it's just one of these crazy situations where I it it is it's almost like architecture shaming in a sense where you look at the results of

others and you're just like that you it's all wrong but yet it's because of the situation that they're in. Often

some of the hardest decisions we make are the compromises based on the realities around us. No doubt. All

right. So best practice. Let's put that aside. Let's think about the word

aside. Let's think about the word architecture. If you're an architect,

architecture. If you're an architect, what is your job? Like does anybody have an interesting definition of the word architect versus developer?

Anybody? It's fun.

Okay. So, none of us know what an architect is. So, this you're all at the

architect is. So, this you're all at the right session. We're going to talk about

right session. We're going to talk about architecture and architects are the ones who build architecture. No, architects

are the ones who are responsible for the most expensive choice. That's what it is. They are the ones who are who are

is. They are the ones who are who are responsible for the thing that is the most expensive to change later and it must be made in advance. Now every

moment that the project continues is the current moment and so we will have to make a decision now for the rest of the project and that will be the most expensive choice for the rest of the

project. And so you maintain this role

project. And so you maintain this role of architect all throughout the project.

Anybody who can whiteboard an entire solution soup to nuts at the beginning of a project, you're just building a notepad. Like in a real world project,

notepad. Like in a real world project, there's too many unknowns and too many mysteries that will come up. And it's

not about being agile. It's just about being realistic that there are things that must be added and must be removed.

Now I would add to this architecture discussion of saying an architect's primary role is to figure out what things in the solution must be left out

more than what needs to be brought in.

Like you might think what are all the boxes that need to go on the whiteboard but more importantly I think that you are a guardian of what keeps out of the solution because the more you add in the

more complex your solution will naturally get. There's nothing wrong

naturally get. There's nothing wrong with complexity although we prefer simplicity. We certainly don't mind

simplicity. We certainly don't mind sophistication which is a much nicer word than complexity but at the same time we want to minimize everything as all the way through because the less you have the less there is to break all

that's always going to be the case.

However in the real world we have to add all these components one way or another.

So let's think about what the components might be. What are the choices you as an

might be. What are the choices you as an architect get to make and are paid to make and are also often held accountable for? That's kind of the reality of it.

for? That's kind of the reality of it.

H maybe that's a better definition of the architect, the one who's blamed.

Okay, but here's an example. The uh the software control, the the uh source code management tool that you're going to use has to be decided. So let's go green field, pure green field, right? Which

CI/CD plan you'll go through, what type of management of your project you'll have, the IDE that you'll have, but that's not all. which clouds you'll use because there's plenty of options and you'll have to this is a long-term

dating commitment you're about to make.

Whether or not you'll use containers and how you'll host and orchestrate those, the serverless technology that you'll use behind the scenes, the languages that you'll use because not every language is available in every

situation. So, you'll have to decide

situation. So, you'll have to decide what that is. You'll also have to pick a language based on the longevity of the language, but also being able to hire developers who are willing to learn or code in that language. It's very

important. So sometimes you'll actually choose a language that seems crazy, but you know that it'll be easier to hire a developer later. Uh which front end you

developer later. Uh which front end you might use because there's so many choices and you have to think through which one has longevity and shelf life beyond just the next handful of years or

whether or not the uh the the uh maintainer of that repo will retire someday soon. Uh which backend that

someday soon. Uh which backend that you'll end up using because each one is different for a different reason. Some

are faster and slower than others, easier to maintain, harder to host. Then

you get to decide which whether or not you'll have AI and which model you're going to use, where the model will be hosted, how you'll pay for that model, who's going to train that model, what you train it on, what the pipeline's going to be, what the different communications of your team. That seems

stupid, doesn't it? But it's so true.

How you're going to interact with a database. There's so many options there

database. There's so many options there as well. Then, oh, it's not done. Yeah.

as well. Then, oh, it's not done. Yeah.

Then you have to think about the UI itself and the layout and how you're going to put all these things together.

And even if you think to yourself that these aren't the things that an architect really does. These are the things that an architect is looked for or looked to for, right? They you're

like, "What should we do? What should we do?" And you as a good architect, of

do?" And you as a good architect, of course, build a consensus with your team so that they feel like they're making the decision, but these are still on your plate, like it or not. You get to think about how you're going to deliver it, how you're going to package it, whether or not you're going to sell it,

how you're going to handle upgrades, what hot fixes even mean. Then you get to operational things like what I mean it it's crazy telemetry and the performance of it whether or not it's

accessible whether on on and on it goes right it's so difficult when you think about the just approaching say well we're not done yet right so when you think about approaching software it is

just an overwhelming tsunami of choices and options that you get to make whether or not it's going to run on every operating system or just one and if just one then which one and of the which one which version it's going to be as

whether or not it's going to be mobile and which framework you use once you choose it's mobile. If it's iOS or it's both, does that mean it's also on an iPad as well? It's brutal. It's brutal.

All right. Whether or not it's web, but who cares about web? That's but whether or not you have a database. Which

database you're going to use? Obviously,

we'll use SQL Server, but like what will be the one we make fun of during class and stuff. So, that's going to have to

and stuff. So, that's going to have to be decided as well. Whether or not you'll have a NoSQL database because JSON matters. Are you going to break it

JSON matters. Are you going to break it all apart and make it relational or are you going to leave it as a as a uh single document? Whether or not you have

single document? Whether or not you have a graph database or how you're going to handle search, whether or not time series matters and on and on it goes.

Like I hopefully this feels exhausting.

We're not going to cover any of these things. By the way, I just want you to

things. By the way, I just want you to know that these are all the realities, right? When we sit and think and we were

right? When we sit and think and we were brainstorming, we would come up with a list five times longer than this if you were helping me. It is crazy all the things we get to think. We haven't even gotten to security, right? because that

always comes last. But the the thing is there's so many things to think in our mind and uh it's brutal. But here's what we're going to be talking about today.

You need to understand every component in a in a um solution. Of course, that is true. Your job is going to be saying

is true. Your job is going to be saying no. That is you. You, the architect, get

no. That is you. You, the architect, get used to saying no. We're not doing that.

But what you really secretly mean is we might do it, but just a little bit later. Not now. Right? That's what

later. Not now. Right? That's what

you're really saying. Like what if we just got a couple of things working? Now

I realize some foundations must be built. Certain things have to be put in

built. Certain things have to be put in place earlier than you actually need them. But generally that's not true. And

them. But generally that's not true. And

if you can be the champion for simplicity, then you truly have the soul of an architect. That's all there is to it. If I don't have any tattoos like the

it. If I don't have any tattoos like the world does, but if I did, mine right here would say simplicity is the best architecture. That's what it would say.

architecture. That's what it would say.

My wife would love that. And it is just one of those things where that's what we care about. All right. This is the meat

care about. All right. This is the meat of today. So, we're going to go look at

of today. So, we're going to go look at this architecture. You're like, "Oh,

this architecture. You're like, "Oh, that's nice." All right. So, I'm going

that's nice." All right. So, I'm going to walk through this, but I'm going to walk through it in a way that I guarantee at the end of this talk, you'll have a comfort for every box up there, and you'll be able to make an

argument for every one of them to still be there. But I am not going to

be there. But I am not going to recommend that they all go there.

Instead, I'm going to recommend that you instead understand which one should not be there because you as an architect are the one who says no. You are the one who takes everybody's dream. Oh, I heard

about this new framework and it like no, we're not doing that. Right? It doesn't

mean no. It means right not right now.

We might do it. Let me dabble on the weekend and see for myself because I never heard of it till you mentioned it.

But we might come back to it. Right? But

it's okay to say no because in the end that's the role of of a really really truly good architect. All right. So

every project starts with the client.

That's where we're going to begin as well. Does this architecture look

well. Does this architecture look somewhat busy and overwhelming? I hope

your heart says yes because it it does.

I don't think it's going to in the end.

Okay. So, if you build an application, we'll call that the client. Every

client's going to need a database. If

you're not talking to a database, then it's not a datadriven application. All

applications are data driven except Notepad and I guess maybe like solitire and stuff, but very few applications don't have a back-end database of some kind. My goal is that you would separate

kind. My goal is that you would separate them and not have them inside the same executable, but that's okay if you do because I don't know your business situation. So, you have the database

situation. So, you have the database separated. Of course, we're using SQL

separated. Of course, we're using SQL Server. All right. Now, the next thing

Server. All right. Now, the next thing you say is talking directly to the database feels wrong. And you would be right. The reason that talking to the

right. The reason that talking to the database feels wrong is because you have to leak the schema back to your application. And now you have coupled

application. And now you have coupled the schema and the application together.

You've also made it so your app developers have to be good SQL developers and that doesn't always happen. It also means that you tend to

happen. It also means that you tend to see SQL mixed in with like JavaScript and it just feels wrong. Just feels

wrong. And so instead we introduce the API and the API applica uh uh application programming interface. Uh

yes there's so many acronyms in the next few minutes. Okay. So we have an API and

few minutes. Okay. So we have an API and the reason we have the API is to abstract everything away, separate the the concerns so that people who write the developers who write the API don't have to be the ones who write the app.

This is really a good decision to make, right? It doesn't have to be thick. It

right? It doesn't have to be thick. It

doesn't have to be like fancy. It just

has to be an API. However, you haven't solved a a key problem and that is to be able to talk to it any database you need a database driver. That's just the way that it works. Database drivers are

nothing but trouble. Database drivers

have to be installed. database drivers

go through versioning and often that versioning is because of security concerns and so you must make it so that your client which is coupled with your API which is coupled with your database

driver must be ready to be upgraded regularly if not if for no other reason it's for the database driver and you think to yourself the database driver we use today works why would I need to

upgrade it and it's just because there are many under the hood reasons to do it I'm on the SQL team my team is also the driver team I can tell you that people who do not upgrade their driver are not

doing themselves a favor. Not only do drivers get faster over time, they get incredibly more secure because of things that we never accounted for before that made it so that it was that it was

insecure. Now we fix those as well and

insecure. Now we fix those as well and they just keep on rolling, right? And so

not to do it is a brutal thing. However,

what if we move the API next to the database instead and took it out of the client? Now we've solved the problem of

client? Now we've solved the problem of database drivers. Database drivers are

database drivers. Database drivers are no longer in the client. It also makes it so that the API is completely removed from the app that you have you're building which makes it so that you can

not only use different types of developers to do it but you can also now deliver in different cadences as long as you maintain the same contract between them so that the surface area stays the same. That's the easy part. The hard

same. That's the easy part. The hard

part is actually developing and implementing it in a good way. Terrific.

Now we have an important under the hood piece here and that is to make sure that we have full telemetry. So this is usually the things added last. I mean I

jokingly said that security is added last but usually telemetry is added last. But we really need to think about

last. But we really need to think about it upfront because telemetry allows us, especially in a separated environment like this, to be able to have all of your logs and then to correlate them together so that you can see and debug

all the operations that are going on in your application. This is not going to

your application. This is not going to help you at all during development. It's

only going to help you after you've pushed this out and you're trying to debug a problem while your boss is breathing down your neck. That's just

the way that it goes. And yet, we still put it off. But it is a very important part if you don't use open telemetry which is what everybody uses today across all the technologies which certainly is the most beautiful way to do it. But there's so many other ways

do it. But there's so many other ways you could do it. What are the other ways? Ah there's just so many.

ways? Ah there's just so many.

Open telemetry is what everybody's using. I recommend you look into it. All

using. I recommend you look into it. All

right. So let's think about this. What

if the database was no longer tied to the API and the API was not tied to the client but instead we separate those so that we can also separate the API itself making it so the write operations and

the read operations are in different places. So they could be physically

places. So they could be physically different places or logically different places. But the whole idea is that the

places. But the whole idea is that the operations that are intended for write can be isolated and the operations intended for read can be isolated. This

doesn't have to be a change to your codebase. I could just install it twice

codebase. I could just install it twice and I could make it so that all my write operations point to the top and all my read operations point to the bottom.

This is like this EQRS pattern. It

allows you to separate all of this work because it turns out that your application is extremely heavy in writing. It must write constantly and it

writing. It must write constantly and it must write fast and it must be good. But

it doesn't read very often, right? So

just a little bit of read and a lot of write. Now all of a sudden it allows you

write. Now all of a sudden it allows you to scale your write operations in any way you want and allows you to unscale or like decrease the size of or maintain the size of your read operations in a

totally different container or server or however you've deployed it. Right? That

this is a beautiful and easy first step to make your application faster and a little bit better truly and without having to do very much uh on the technical side for sure. However, the

API is not the only thing we would do in this situation. We can also make it so

this situation. We can also make it so that the database itself gets split.

This is not a special feature of SQL server. This is a feature of every

server. This is a feature of every server out there. There are no databases that can't actually replicate to another database and give you a readonly replica. That readonly replica is on a

replica. That readonly replica is on a separate machine using separate compute using separate file IO which makes it so that when you're writing as fast as you can to your right database then it

automatically usually through its log so there's no performance impact comes down to its read replica. You can read and make it you can crunch the numbers whatever you want and never impact the speed of your writes. That's really

nice. You can also have multiple reads if you want to as well but we're not talking about that here. So now the client now talks to the right operation uh the right API. The right API talks to the right database. The right database

automatically synchronizes down to the read database. The read database then

read database. The read database then gets pulled from the read API into the client. Everything is isolated and

client. Everything is isolated and you've barely done anything. Right? you

honestly you have barely done anything.

This is a change in your connection string and deployed in two different places. That's all. This is nice. This

places. That's all. This is nice. This

is cheap architecture. This is low tech architecture. This is simpler

architecture. This is simpler architecture and we're just getting started. Okay, that being said, there is

started. Okay, that being said, there is a tier, I don't know if all of you know this, there is a tier in Azure that you can pay for. Only our top customers can get it where the speed of light can

actually be increased. I'm kidding.

There is no no way to increase the speed of light. So that the transfer of data

of light. So that the transfer of data from one place to another always is the same. No matter how clever of an

same. No matter how clever of an architect you are, it'll always be the same. Which means we get this term that

same. Which means we get this term that Google made up for us called eventual consistency. Eventual consistency says

consistency. Eventual consistency says that two things will eventually be in sync. The goal for us is to make it

sync. The goal for us is to make it milliseconds. So fast in fact that you

milliseconds. So fast in fact that you think it is actually always in sync. I

don't know if uh earlier it was the quantum computing uh talk and they were talking about how you can have two states connected and you change one you change the other and you want you feel like they're exact exact simultaneity

but that doesn't exist in the real world it does in the quantum world just not for us and so instead we have as fast as you possibly can that's about as good as it gets each database including SQL

server does this extremely well right their whole goal is to make it so that we can synchronize with the read replicas as fast as possible but we need to understand that the only so much data

can pass through so fast. Even with the most expensive thumb drive, when you put it in and you transfer that movie over, you still get to wait, right? It's just

the way that it works because there's just a technical reality that all of us are bound to. So even when you create something like this, it's good for us as the architect to understand the caveat we've introduced into our solution. It

is so much faster to read now and it doesn't impact the right and look how low tech all that was. Just know this, there is going to be a slight delay.

Which means if you do a simultaneous call to read and write, it will not return the same value, right? Your your

right value will not be there. You must

make it so that they go in series and then you have to measure what it means to be eventually consistent. But it's

worth it because it's such a cheap and easy way to make your application better. Also cheap and easy is to

better. Also cheap and easy is to introduce some other services and not make it so you have one enormous service. So if you have microservices or

service. So if you have microservices or you have macroservices or let's just call them services. If you have services then good for you. That's the way it should be because it feels to me like I want to be able to hand off not just in

my team but I want to be able to think in my mind in tiny little cordons so I can say I'm only doing this work and I'm only doing that work and I don't have to think about how everything ties together because I've separated them nicely into

separate projects or per perhaps separate solutions. And so here the

separate solutions. And so here the client now talks to three instead of well four if you count count the readwrite separately talks to three services instead of one. All right,

that's good. That's what you want, right? Breaking it apart a little bit

right? Breaking it apart a little bit like this. However, you've introduced a

like this. However, you've introduced a new problem that you're going to have to solve. That's because everything you

solve. That's because everything you introduce is something that you're going to have to solve. So in this case, you're going to need to figure out how all these backend systems are going to talk to each other. So in this case,

they're all your systems. So it makes it really easy. you you'll introduce the

really easy. you you'll introduce the concept of a service bus. Perhaps not

the tool called service bus. Azure has a tool called the Azure service bus. It

certainly does this, but there are many many solutions out there that are open source. You could just add it as a

source. You could just add it as a library and now you have that capability. So don't feel like that that

capability. So don't feel like that that it has to be a specific product. It's a

concept. The concept of a service bus is a little bit like a postman, right? He

takes a message and he gives it to the right person and he makes it available and he puts timers on it and all the other things that you might have return to sender and all the things like that.

The service bus allows all of these to feel as if they're connected even though they're separated and so you don't lose the ability to have this interconnected flow even though you've separated everything. So development is easier and

everything. So development is easier and when you think about upgrading your application or going to the next version of net or whatever you can be like only the top microser only the bottom microser and you can move in these small

little seams that make it so things are actually manageable and that's because you as the architect did a great job of keeping things simple right that's nice all right so with the service I'm sorry with the service bus you'll have this

idea of a dead letter so this is the not green field no not the green path I guess is a better way to say it right the happy path that goes this way is always going to be countered by the bad

path. And so the bad path is the dead

path. And so the bad path is the dead letter. So you send a message into the

letter. So you send a message into the service bus, you're actually trying to talk to that third service or whatever from the first and the message is lost.

It it falls into the dead letter box.

Here's the thing with the dead letter box. It works. It totally works. But

box. It works. It totally works. But

nobody will handle the dead letter box if it's not for you. Which means if I introduce the concept of a service bus, I must also introduce the concept of managing the dead letter box because what if it fails, right? What if it fails? Okay, let's not spend too much on

fails? Okay, let's not spend too much on that. Just know that it's there and it's

that. Just know that it's there and it's a thing in your mind. Assuming that your company is bigger than one application, the service bus is the lever that allows you to talk to all the other applications out there. So, because I

have my new application on the left, I also have uh system A, B, C, and D that have already existed in my company and I need to interact with them one way or another. Now, if all I'm doing is

another. Now, if all I'm doing is merging the data together for reports, I don't do this. But if I need to operationally engage with them, making it so that they do something as a result of something I just did, then I want to

make sure that they're connected to the same service bus I have, which means the service bus is not part of your solution. The service bus is part of a

solution. The service bus is part of a of its own solution that is shared by multiple services which means you have created yet another beautiful scene making it so that all of your upgrade

options and all all of your like levels of effort can be isolated to different parts of your application. Okay,

congratulations. By the way, this integration probably will take a year because it's hard because the the guy who owns system C is a real jerk and so he he's really difficult to interact with. But you have it nonetheless. Now

with. But you have it nonetheless. Now

let's go back to the client for a second which is no longer talking directly to the API we've introduced in between the API and your client the APIM the API manager the API man if you have any APIs

in your application and you don't have an API manager I'm going to be the one to say I think you're doing it wrong I think that you should have some sort of app gateway or API manager in between

you and the API that you're calling it's not it's a little bit like telemetry it is not going to help you at the beginning in fact It's only going to add to the work that you have to do at the

beginning to add an API man API manager or some sort of app gateway. That's

because when the day comes and you need to upgrade your API, you will go from version one to two and you will immediately love yourself for

introducing an APIM because it will handle the transition from one to two ver from version one to two and then version one to 2.1 and then 1 to2.1 and

rolling them out and AB testing and all the other things that you need to do. In

fact, an APIM can take the payload that you're sending to your API, transform it in the APIM as the next version for you, and then pretend to be calling the so

you think you're calling version one, you're actually calling version two. And

the APIM is making your payload compatible for the second version. It

also handles denial of service. It also

handles load balancing and all the other things that you should have to simplify the overall use of your API, including making it so that your three microservices feel as if they're a

single API surface that you're calling.

That's really nice. All of these things matter and it's not a product. This you

can you can go get a an open-source tool and add it to your library today and you can have an APIM experience, right? But

not having this spot, not having that, you need to just look yourself in the mirror and ask yourself why. Because it

is so valuable. And so I I told you I was a uh I'm a computer science teacher.

Um so I tell my students, I'm like, listen, you're not really writing code for the computer so much as you're writing code for the maintenance developer that comes after you, right?

It's the next developer that really matters. And if there's anything you

matters. And if there's anything you need to remember or think of, you should think that the next developer is a killer. He's a he's an axe murderer. And

killer. He's a he's an axe murderer. And

you don't want to make him mad. Instead,

you want to keep him happy, right? And

so he receives your code. He opens up the box and he's like, "What the crap?

Are you kidding me?" And you I mean, it's like knock in the middle of the night at your house. So you don't want that to happen. Instead, you have to think the maintenance developer. you

want for their sake I'm going to do everything really really well really really nice right and so one of the reasons we introduce beautiful tools like APIM is because when the day comes

and you're off of this project and the next guy now has to version your API he's like a we only had an APIM now I've got to right and you're like that's the

that's just how you get killed all right it's a dangerous job to be an architect that's for sure APIM API manager App Gateway. Is there another name? Usually

Gateway. Is there another name? Usually

there's one other name I can't think of.

Uh out of curiosity, is it? No, I don't want to do that because now that I've said if you're not using it, you're the dumbest person in the room. Raise your

hand if you're not. I'm just joking. All

right, let's uh let's move up now to what we can do to our microservices individually to add capability to make them better. Right? So, these are

them better. Right? So, these are concepts, not actual tools, but nonetheless, it works fine. The first is cache. There's two types of cache.

cache. There's two types of cache.

There's level one and level two cache.

level one cache. In fact, Jody gave a a a uh a session yesterday. Some of you may have gone to that that uh that session. Um he's the maintainer of

session. Um he's the maintainer of fusion cache, which is an incredible library, very easy to use. Level one

cache allows for um a request from an API to be put into memory so that the second request for the exact same data just gets pulled from memory. There is

nothing faster than memory. In fact,

there is nothing. I mean, the a database is incredibly fast, but it's also incredibly slow. Here's a tip. If you

incredibly slow. Here's a tip. If you

want to make your SQL server or any database faster, there is one thing that'll work for all databases of any brand. That's for sure. And that is

brand. That's for sure. And that is query it less. That's all there is to it. If you just query it less, it'll

it. If you just query it less, it'll behave better. And so, for example, when

behave better. And so, for example, when my wife gives me jobs, I do them. When

she gives me too many jobs, I cannot do them all. Right? That's just the way

them all. Right? That's just the way that it is. I am like a database. I

prefer just a couple of jobs here and there. So if you can query a database at

there. So if you can query a database at the level that it's actually intended to, you don't have to scale it up to a million dollars. No, no, you could just

million dollars. No, no, you could just use something like cache to make it so you call it less often. Especially think

about that drop down in your UI that's a list of all the countries or a list of all the states or whatever it is that you special to your com your company that you call from a database so it can

always be the same for every user. And

how why wouldn't we cach that? Why

wouldn't we put that into memory? Memory

is cheap. Memory is easy. If memory is lost because we recycle the container, then we'll just fill it up again. No big

deal. And it's so nice. You don't have to a thousand people log onto your application and a thousand people need to know the list of countries again.

Absolutely not. There's one other thing.

There is stampeding. So in the cache world, stampeding means all thousand of us ask for it at exactly the same time.

And now all of a sudden even the best de best database is like that's a little too much, right? And so that stampeding is also fixed by using some sort of caching solution like fusion cache. And

then the second is level two cache. So

level two cache introduces like a reddus server which is just a name name value server right key value. It's nothing.

It's just nice and fast and it doesn't have to do joins and all these special lookups. It's a single index. So it can

lookups. It's a single index. So it can be nice and quick. And so Reddus makes it so that I can pull it out of my database. The expense of the query has

database. The expense of the query has already been done. Now I can put it into a cheap storage like Reddus which will be nice and quick because it just has that hash key whatever it is that I've calculated. All right, that's one easy

calculated. All right, that's one easy way, very easy way to make it so your API is so much nicer. You do have to think about it like like what can be cached and what can't. To be honest, if you gave everything a single second of

cache, just one second, nothing else, you would transform the behavior of your API. There's no doubt about it. You your

API. There's no doubt about it. You your

capacity would go through the roof with a single second of cache. And you think to yourself, I can't afford a second of c. Are you kidding me? One whole second.

c. Are you kidding me? One whole second.

But I'm just telling you right now that a second of cash is transformative.

Absolutely amaz. If if that scare if a second scares you, I'll tell you your users, unless you're building like NASDAQ or something, unless you're building like the stock market, then your users won't even know it happened.

It's there just something about it. All

right, so you got to think about it.

You're the architect. I'm not you, but just telling you cash is a great idea.

The second is a retry policy. We live in the real world where sometimes the database is not down. It just didn't respond for some reason. Maybe it's the network, maybe it's the router, maybe it's who knows what, right? I mean, you don't know what happened, but that extra

millisecond that it cost was beyond the timeout threshold, and now it didn't respond in time, and you're getting back an exception. Why not just try again?

an exception. Why not just try again?

Just one more time. No big deal. How how

many times should you retry? You get to decide that. My I set it at five. There

decide that. My I set it at five. There

you go. You could be like me if you want to. I I mean we retry, retry, retry. I

to. I I mean we retry, retry, retry. I

use exponential uh bleed off so that it goes nice and slow. But whatever it is that you want to do makes plenty of sense, but not to have a retry policy, especially now that it's built in like a SQL driver, you just tell it how many

times to retry. You can use the you can use poly library or whatever library you want. You can just add the retry policy.

want. You can just add the retry policy.

This is not an exotic solution. This is

just what should be there. All right, so that's just retry policy. You you you should have that. Another thing we could do to make our API generally better and that we would naturally do is to add

some sort of Q. Q is unbelievable. Q Q

is like like now we're into steroids country. Like it is incredible what

country. Like it is incredible what we're about to do to our API. We're

making it so that we can receive let's say your database can process a hundred things at once. Your API, which is just an API, so it doesn't have to do all the work, right? Have this transactional log

work, right? Have this transactional log or anything like that on the back end.

The API just takes a request and hands it off to the database, right? And maybe

it does a little business magic in the in the middle, but that takes no time at all because you're an excellent developer as well as an architect. So

the work that you've introduced is not that big of a deal. That means your database, which is stuck at a limit of 100 operations per whatever. Your API is about a thousand, right? It can take about a thousand at a time. We know that

this is actually many many commas can be in this number. It's probably hundreds of thousands that it could take. That

being said, let's just keep it easy. a

thousand versus a 100, which means you could actually take in a thousand and immediately overwhelm your database. But

you have a retry policy. The retry

policy takes a thousand operations and asks your database to do them again. And

your retry policy again because the database always can never do a thousand operations because it can't even do 101.

However, with a Q, you can solve everything. A Q, which by the way is

everything. A Q, which by the way is persisted and not in memory. So it's in a file system or whatever it is that makes sense to you. But a Q allows you to take the request that you've gotten

from the API, attempt it to the database, and if that database it doesn't respond, you can cue it and try again in a minute. Not a minute, but in

try again when you want. Or you can make it so that you have a hundred operations constantly beating at your your database's door. And when you get the 10

database's door. And when you get the 10 and1 101th when you get one more that is above above 100 and you will put it in the queue so that when you've processed those and you have room for another you

take it out of the queue and do it. Why

does this matter? Because think of your client think of the user think of the user's experience right they are like hey I would like to like I would like to

log in right like register me as the green flag I'm here changed me from busy to available. Let's just say it's as

to available. Let's just say it's as simple as that. That goes into the that goes into my API. The API cannot talk to the database because it's so busy. And

now they get an exception back. The

service is not responding. Please try

again. Ah god, that that's what this is why people hate us. So instead, we want to say we received it. Good job. Here's

the green flag. The database hasn't even been in updated yet. That's because I know that the database will eventually be updated. Now, I can't do this with

be updated. Now, I can't do this with credit card transactions, but I can do this with most things. If you I mean, that's the way that's the way Office saves. It's the way everything saves.

saves. It's the way everything saves.

Everything is lying to you. Everything

is not really doing what it's saying it's doing. It's asynchronous on the

it's doing. It's asynchronous on the back end. It just flips a flag a little

back end. It just flips a flag a little bit like soft deletes where we're like, "Sure, I'll delete it." But it's not deleted. When I ask for the API to do an

deleted. When I ask for the API to do an operation and it can cue that operation, it's not really doing it. We know that, but it has put it somewhere where it will guarantee it will eventually do it.

Right now, you know the system. You know

what needs to happen. You know what parts of your application could never participate in a queue. But you also know that the other 99% can. And so you might as well make it so that the user

has an incredibly positive experience.

Now what happens when your database changes? Well, now we can have something

changes? Well, now we can have something like an event hub. So an event hub is different than a service bus. A service

bus takes messages and it hands them around. But an event hub responds to

around. But an event hub responds to messages. It is the thing that is

messages. It is the thing that is basically saying, "I don't know where."

It's a little bit like a postman that delivers to your house versus a postman that is stays in the post office, right?

And it's like the messages are now available and they send you a text, come get the box because it's here. That's a

little bit more like what an event hub is. And it's meant to ingest as much as

is. And it's meant to ingest as much as possible. And so as many changes as

possible. And so as many changes as happen, you can never overwhelm an event hub is the idea. Then those events get handled one way or another. in your

database like in SQL for example we have change event streaming which means every change to a table could be pointed to a event hub to be able to respond to it that means you don't have to pull your

database over and over and over again that's really important because every time you query a database it gets slower so if you're respon if the way that you handle data change is to request hey have you made a change oh hey have you

made a change hey every single one of those decreases the quality of your database so instead we have the database itself say I there was a change I'm going to send it up to the event hub.

The event hub then uses something to do its work. It it doesn't do any work by

its work. It it doesn't do any work by itself. So you would introduce a

itself. So you would introduce a serverless function here maybe some sort of application on the side that receives some sort of a invocation through HTTP or whatever it is you decide and it

makes it so the function then does the operation sends its own message to the service bus so that whatever system needs to respond it can. Right? That's

really really nice. Right? So think

about it from well let's use stocks even though we're not building a stock application. Every time the stock uh

application. Every time the stock uh every time the stock price changes the database sends a message to the event hub. The event hub looks to see whether

hub. The event hub looks to see whether or not the price is above or below the threshold that you have. That threshold

then is finally in you know met. It

sends it off to the function. The

function says oh that that's a that's a sell order. That's a buy order or

sell order. That's a buy order or whatever it is. It does whatever its option is and now we got to record this.

So it sends it to the service bus to do the job. or maybe the service bus does

the job. or maybe the service bus does all of the the work, but that's the idea, right? You want it to be able to

idea, right? You want it to be able to respond to whatever the thresholds are that you have. If you don't have the thresholds in the event hub, they can be in the function as well, right? It's

kind of up to you how you want to end up handling. Okay, that's the role of So,

handling. Okay, that's the role of So, we've got a lot there's a lot of little pieces here. If you just step back and

pieces here. If you just step back and look at the entire solution, hopefully every piece here makes sense, right?

You're not looking at it like, "Wow, there's a lot of freaking boxes and lines." Hopefully, instead, it feels

lines." Hopefully, instead, it feels like the sort of solution where you're like, "I think I could argue for every single piece." In fact, some of these I

single piece." In fact, some of these I think I could argue very vehemently. No

doubt. But we're not done. Okay.

If I'm up in the event hub, one of the things the event hub can do is not just talk to your backend systems, but it can also talk to your front-end systems. This makes it so that if when you're I mean, we've all used GitHub, I'm sure,

and you have you have your PR, right?

And so you submit your PR and you're looking at the typos that you put in the PR documentation because we all write in our PRs. And then things start happening

our PRs. And then things start happening on the screen behind the scenes and they update the screen without you having to hit F5. That's not always how we build

hit F5. That's not always how we build our applications. Instead, we have users

our applications. Instead, we have users submit something and and the status is, let's say, yellow and they wonder if it's going to be green. So, they hit F5 again and again and again and again and again and again and again, right? That's

just the natural way that we do it.

We've all done it, right? And so, the way we get around it is we have a little box that says, "Please do not leave this window or hit refresh or we will charge you twice." That terror tends to slow it

you twice." That terror tends to slow it down a little bit, but doesn't fix the real problem. The real problem is the

real problem. The real problem is the client has no idea that the back-end database is finished with whatever it's supposed to be doing. So now I have it.

So the database makes a change. It goes

to the event hub. The event hub identifies the change that this should be told to the user that is now a green flag. And the green flag is now sent to

flag. And the green flag is now sent to the client and they have this nice message and nobody ever has to hit refresh. Not only is this handy, but it

refresh. Not only is this handy, but it makes it so that every time they hit refresh, it doesn't go against your API, goes against your database, and slows everything down, right? This is nice

because this is super unsophisticated because all I need to do is look to see if the change matters and see who the user is and forward that to them. That's

nice. Okay, through websockets or you get to pick the technology that this is just a concept. All right, so that's the event hub. Let's go down. The client

event hub. Let's go down. The client

itself is going to be served in a handful of ways. I know that most of us are building web applications. I I I prefer the high fidelity of a desktop application, but it's not realistic in

most situations. I understand. So, if we

most situations. I understand. So, if we are delivering information, not all information is going to change.

Sometimes, and just think about images and things like that, they stay exactly the same. So, I'll have a static server

the same. So, I'll have a static server that is able to deliver this information because it makes no sense for me to invoke my application or invoke my server application every time I'm trying to read an image. that's always going to

be the same and we haven't changed it in three years, right? And so that's really valuable. One other thing about static

valuable. One other thing about static is in ASP.NET core you can and you can enable it with use static. I'm sure you guys have already done that. Um but you

have to think that because of that by itself, it means that this the middleware must still be invoked, right?

So I mean how can I make it even lower tech is the real question. Could I just drop this in a folder and point to it?

And the answer is yes, you absolutely can. So just think about that. If you

can. So just think about that. If you

want to make static even faster, you wouldn't even wrap it in ASP.NET or anything any other middleware at all.

However, maybe you work for a large company that's international and you want to introduce one other little thing. The easiest way to make the

thing. The easiest way to make the experience of the user who is without a doubt the most important and the most annoying part of every software we write

is the user, right? And to make their experience as positive as possible, we would put it in a CDN to make it so that if they do live in the United States and somebody else lives, say in Denmark,

they don't have to wait for light to travel or for electrons to pass under the under the ocean. That is for sure, right? Because remember there is no

right? Because remember there is no special tier of any product that can increase the speed of light. Putting in

a CDN makes it a little bit faster. A

little bit faster. Okay? And it's

amazingly straightforward thing to do.

Let's talk about what we can do to your database to make it so that it can be faster as well. Each one of these is just yet another component that you'll adopt on purpose. The first is a row store. You already do this. This is for

store. You already do this. This is for free. This is what you get in every

free. This is what you get in every database. It looks like this where it's

database. It looks like this where it's stored a little bit like Excel and it's just a normal way of storing data.

However, some tables actually don't belong in a row store. They belong in a column

row store. They belong in a column store. Column store is not an extra

store. Column store is not an extra thing that you install. It's not it's this this package that you go and get.

It's a checkbox on a table and suddenly it is a column store. Column store takes all the data that is usually stored horizontally and turns it to be vertically. This is extremely fast. I

vertically. This is extremely fast. I

can't even start to tell you how much faster a column store is. Well, I can actually tell you. Yes, we've done the benchmarks and it's around a 100 times faster when you're running aggregates against against your data. A hundred

times faster and it's a checkbox on your table. It is amazing. The other thing

table. It is amazing. The other thing that it can do is it can compress a table dramatically, making it so that this monstrous thing that's taking up all this disc space is suddenly nice and

tight only because you made it a column store. Now, I know what you're thinking.

store. Now, I know what you're thinking.

How do you write a SQL statement against a column store versus a row store? And

the answer is there is no difference.

You will not know that it is a column store from your experience. We just do it on the back end, right? And so you still interact with it like normal data joins and all the things and everything just is magically faster. Not every

table needs to be a column store. Don't

let this be how you learn about what column stores are and then go implement them. Let Google teach you a little bit

them. Let Google teach you a little bit more. Ask chat to explain it. However,

more. Ask chat to explain it. However,

column store is the magic sauce that nobody is using for some reason. And it

is an incredible way to speed up your database. Uh and it looks like this if

database. Uh and it looks like this if you didn't know what columns were. Okay.

Now beyond that there is also a table with no index. Let me explain just for a

no index. Let me explain just for a second that every table that you create with a primary key is automatically indexed like it or not. You don't know that it's happening but it's happening.

And here's why. A and it's it is called a clustered index. The reason a clustered index is awesome is it keeps things physically in order. That is not the worst. It is not the worst. However,

the worst. It is not the worst. However,

if your key is not automatically generated and it is not in series and it is not numeric, then it makes it so that it is possible for you to introduce a key that belongs in the middle. And when

you do that in a clustered index where it will always keep them physically in order, it will rearrange the rest of the table to make room for that column for the row that you just inserted. It's the

way that it works. It's the reason that everybody's like, you're using a gooid for your key. Yeah, that is part of the reason that it is scary to use a gooid for your key because a GOID is obviously not in series, especially if it's

generated by different machines and then when you merge them all together, the table constantly has to reshuffle in order to keep things physically put together. However, like a hasht coding,

together. However, like a hasht coding, no index table is a hash table in a database. It is the absolute fastest way

database. It is the absolute fastest way you could ever write to any database table in the universe. There is no technique that's any faster than this.

You insert into a no index table and it immediately writes. There is no delay.

immediately writes. There is no delay.

It does not have to update at the index.

It does not have to change the order of the table. It just takes the record

the table. It just takes the record however you gave it to it and drops it in. That's as fast as you can get it. It

in. That's as fast as you can get it. It

is also the most dangerous table you can possibly imagine because take all of the constraints and controls, take all the reasons people love relational data, throw that into the garbage and just

call that your database and it's not the same. Right? So there will be times when

same. Right? So there will be times when you need a date a table that is insanely fast and you'll be like that guy at NDC said something about just taking off the primary key and I was right. It is going

to be insanely fast. Just be careful, right? Just Google it first is all I'm

right? Just Google it first is all I'm saying. All right. Next,

saying. All right. Next,

almost every database like SQL does uh includes in-memory tables, right? So,

you can take a you can take a table and you can remove it or you can extract it from the uh the file itself, put it into RAM, which is insanely fast, just like level one cache was, and you could treat

your database table as if it's level one cache. It is it faster than Reddus? It

cache. It is it faster than Reddus? It

is. It is insane. It is an incredible way to because everything is just sitting there in memory and it is beautiful and you can read and write have the same transactional experience

and all the things and you have no no knowledge that it's in memory other than this table is crazy fast and you could even write to it fast too. Take the

index off it'll be even faster. However,

what's the downside is if you recycle your SQL server then everything in memory is lost. That's true. There are

two ways to create an in-memory table.

The first way is to make it so that everything is in memory and that if you recycle your database, it's lost. The

second way is to make it so that everything is in memory, but when you write to it, it also writes to the file system. Is that slower? Yes, of course,

system. Is that slower? Yes, of course, because you have to write to the file system. Is reading from that table still

system. Is reading from that table still fast? Insanely fast. There's nothing

fast? Insanely fast. There's nothing

faster. It's just as fast as lightning can be. Okay, so you can have an

can be. Okay, so you can have an in-memory table. I recommend looking

in-memory table. I recommend looking into it. Google it first. Don't just do

into it. Google it first. Don't just do it. Uh the next is moving things into

it. Uh the next is moving things into relational graphs. So in SQL for

relational graphs. So in SQL for example, we support uh graph databases, you know, where you can do like matches across relationships. That could be

across relationships. That could be extremely useful especially in scenarios where you're working with like like let's say shipping or something along that like where you have a you have a a

warehouse and then you have a shipping lane and then you have well let's say it's a it's a it's a factory that makes it shipping lane warehouse another shipping lane and then you have the final distribution center. So those

three stops and then trucks across or whatever it is. Each one has its own cost and time and you want to say what's the fastest way for me to get to the from the factory all the way to this distribution center. I don't care which

distribution center. I don't care which which warehouse I go to. Just show me the fastest in time. How about the cheapest? And maybe you have multiple

cheapest? And maybe you have multiple warehouses, multiple trucking lanes, and you can figure all of these things out because of a graph database, right? So

it's very valuable. And the nice thing of having it inside your your your relational database is that you don't have to worry about moving any of the data out, right? It's already there. You

already have it secured. You don't have to worry about it. You can just use the graph capabilities. The last thing, and

graph capabilities. The last thing, and I'll just be honest, NoSQL is probably going to be coming up more and more for you just because it's easier to just accept a payload from somebody and hold

it. You might extract different pieces

it. You might extract different pieces from it and be able to use those, but you don't want to throw the rest away because you're like, information is still information. Fine. So in I'll talk

still information. Fine. So in I'll talk specifically about SQL server u in this case SQL server puts all NoSQL into a binary format making it so it's as fast as regular data so you can manipulate

individual properties without having to load the whole thing also has a 2 gigabyte limit if you can imagine something crazy like that and just imagine doing a select star from a table with two gigabytes okay so also no SQL

let me just move on okay so here's where we are now we're not done but I just want you to see how things can build up and it's not a bunch of insanity, right? We're just thinking about how we can make it a better

experience for the user, better experience for you when you need to upgrade and things like that as well.

All right, let's talk just for a moment about the API. I told you I'm on the data API builder team. So, let me just give you 30 seconds on that. Data API

builder is open source and free.

Supports Postgress, SQL Server, Cosmos, and MySQL. It is honestly it can replace

and MySQL. It is honestly it can replace 90% of all the data APIs out there. If

you have a separate project where you said you know start new or you know file new project and you say web API and you're creating your minimal API so that you can use entity framework to talk to

your backend database you could probably erase the entire project with data API builder. It's the reason we built it.

builder. It's the reason we built it.

It's because it's just the same repetitive code over and over again. We

call it copy and paste inheritance. when

you get bugs from one project to another because it's the sort of thing you do once and you copy it to the next project and just change your po objects or change your DTO objects or whatever they are. So, uh, data API builder is

are. So, uh, data API builder is AKMS/DAB. Again, it's open source. This

AKMS/DAB. Again, it's open source. This

you could just add this, right? It's

really nice. It's not language dependent. It's it's it works on every

dependent. It's it's it works on every platform. It's delivered as a container.

platform. It's delivered as a container.

It's really nice. You also get GraphQL endpoints if you want. We're that's not what we're talking about now. So, you

add to your client extra capability because AI is all the rage. We add open AI to it so we can chat with it and it can start interacting with us in different ways and it actually can be pretty nice. This is where you would put

pretty nice. This is where you would put it. It's not it's not part of your

it. It's not it's not part of your backend. It you're not going to host

backend. It you're not going to host likely open API. You're going to let somebody else host it like maybe Azure might Microsoft could do it in Azure Open API and uh or wherever it is, right? So you have your model sitting

right? So you have your model sitting right here. But in order for that model

right here. But in order for that model then to talk to the rest of your data, you're going to introduce a remote MCP server, right? So the remote MCP server

server, right? So the remote MCP server allows for your a for your model to talk to allows for your model to talk to the MCP server. Your MCP server then is

MCP server. Your MCP server then is talking to your API. Of course, it's not talking to your database. That's

ridiculous. You would not let anything talk directly to your database. And over

your dead body would you allow a model to write SQL and execute it against your database. Like you would nobody would do

database. Like you would nobody would do that. So we don't even have to talk

that. So we don't even have to talk about that because you would not believe how many customers are like, "Oh, I just wanted it to write the SQL for me." and

you just can't believe that they're still employed. So, now back to the

still employed. So, now back to the client. The client itself can be easily

client. The client itself can be easily improved, made so that you can give it a beautiful offline experience, making it so that if the user is working from home and there's a there's a lightning storm

and they lose their internet service for five minutes, nothing is even everything works the same. It's a little bit like the Outlook experience, right? You don't

know if you're connected or not. You

just kind of hope you are because it's awfully nice. But you that's because I

awfully nice. But you that's because I can go in and out of a tunnel and Outlook does not make me mad, right? M

it makes me mad for other reasons, but it doesn't make me mad for that because it does fine offline because I've introduced the ability to cache my requests and then to queue up sorry to cache Yeah, cache my requests and to cue

my responses. Am I saying that

my responses. Am I saying that backwards? To cache my requests. To cue

backwards? To cache my requests. To cue

my requests and cache my responses.

That's what I meant to say. Right. where

everything kind of sits there in a in an inbox sort of experience simply because you've added a cache and Q which is such a simple little package to add to your client so that you can give this

capability to your user and they think of you in good ways right because they're like oh every time you're the architect these apps just freaking work and I'm like I'll tell you why we added the thing that makes it nice okay let's

go over to the other side now these systems including yours all are going to be moved into some sort of lake where you can take your data and you can use it together. This is super important

it together. This is super important because if you just leave it siloed in one, then there's no value. And so

instead, you have some sort of ETL or EL process that moves it into a data lake.

And the role of the data lake is to run all of your reports. This is everything is in one place. And it's very difficult to get your app, sorry, it's very difficult to get your data into a a place where you can query it and love

it. But nonetheless, if you're going to

it. But nonetheless, if you're going to do it, it's going to be in a lake. What

is a lake other than an enormous database or just a big file system full of your data? That's all that a lake is, right? I mean, you can always pay

right? I mean, you can always pay somebody to have a lake, but that's all there really is. Okay. Now, the reason that we have a lake, though, is because we have an ML operation. And the ML operation is looking for all of the

things, right? So, maybe for you, it's

things, right? So, maybe for you, it's looking it's going to recommend to your customer a series of products that they uh uh are that's related to what they've already looked at or whatever it is, right? And so, you have a mechanism to

right? And so, you have a mechanism to do this. And the easiest place to do it

do this. And the easiest place to do it is against your lake where you have all of your inventory, you have all of your operations, everything in one place.

Beautiful. However, it can't stop there.

You must make it so that your ML data gets pushed back into the systems. Otherwise, it's never useful at all. If

it only shows up in your reports, but doesn't show up in your applications, you're not really taking advantage of the magic. Like, the reason you can do

the magic. Like, the reason you can do all these things is not just to make it so your dashboards are better, but to make it so that your customers have a different experience because of the magic you've added in the ML layer.

Okay, there's a little bit more.

We we really don't have time to talk about security.

Uh but let me just say this really quickly. All right. So uh Azure Active

quickly. All right. So uh Azure Active Directory was renamed to Microsoft intra ID. Why? Because we all know what it is.

ID. Why? Because we all know what it is.

All right. So uh intra id might be what you do whatever it is that you use to create a principle. It is how you will also generate a jot a jav a

json web token. Right? And so this takes all the things about you, groups it together in a nice little JSON block, and then signs it cryptographically, and then sends it on. Then the receiver can

then unsign it or verify the signature that you have against the authority or intra ID or whatever it is that you use.

Then read on the inside once it's validated to say, "Oh, you can do this, this, this, and this." Okay, no problem.

Oh, and that's your first name. I can

call you by that. It's really nice. Like

jotss are handy.

What you might want to do, and I think you at least want to consider it, is to be able to take a jot and recreate it in your application. And here's what the

your application. And here's what the reason I want to say it. You might feel like the seven tabs inside your application belong inside your active directory tenant or inside your entra

tenant as do all app developers. They

all feel as if the fine grain details of their application should be controlled inside their tenant. And if you do that, it's not wrong, but it's a real pain in the neck. Instead, you want to have the

the neck. Instead, you want to have the highlevel C categories in your tenant push down to your application and then your application to do the fine grain access control and rewrite the jot for

you. That jot then which is already

you. That jot then which is already validated, everything's cool. You're

handing it to all to all the systems that you have in this solution and it can see both the original jot that is in in ID so that you can validate it if you

need to for important resources but you can also see the fine grain access control that you have just for your application. If none of that makes sense

application. If none of that makes sense then it's totally fine. But I'm just telling you a system that has its own jot server is a system where you know there's somebody thoughtful there. It's

one of the most dangerous things you can also add to an application if you do it wrong. So Google it before you do it.

wrong. So Google it before you do it.

All right. Uh All right. So let's look again. It's not outrageous. When we

again. It's not outrageous. When we

started it, hopefully this felt overwhelming and this is going to be exhausting to talk about, but it's not.

Each one of these hopefully feels like you could argue it out of your solution.

That is my number one goal is for you to be like, okay, I'll tell you one thing why we don't want caching in our API.

Great. That's the that's what I want to hear. Once you understand it enough to

hear. Once you understand it enough to be able to understand why you don't want it, then you finally have enough why you would actually want it, right? Because

you have to realize the caveats because you as the architect are going to be the one that ends up getting your neck rung for it. Okay, remember simple is the

for it. Okay, remember simple is the best architecture. And uh I I I don't

best architecture. And uh I I I don't actually have a a tattoo about that, but if there's one little takeaway, it would just be this. The there are other things too. I like this was slide was at the

too. I like this was slide was at the beginning and I'm like there's so much we have to cover. I I had to take it out. There's so much more that you get

out. There's so much more that you get to think about. All right, this is the final takeaway is to defer decisions. It

feels like as an architect, I have a responsibility at the beginning of a project to make all the decisions now.

And if I don't, then that one jerk on my team's going to make the decision. So, I

need to make it ahead of them, right?

That's usually the way that it goes. But

the truth is, the longer we can put things off, the cheaper they will be in the end. Not cheaper necessarily to

the end. Not cheaper necessarily to implement, but cheaper to change your mind when you realize you made a mistake. It's just one of those things

mistake. It's just one of those things that the less you put in, the better it is all the way around. All of us are architects and if you think about it, even a junior developer has to architect the solution around the class they're

responsible for. So, we all have this

responsible for. So, we all have this sort of nature to it and less is always going to be more. All right. So, oh,

beautiful. That's it. All right. Thank

you everybody for listening. There you

go. I'll be up here for questions if you have any.

Actually, if you want to if you want to shout out a question here, I'll throw it back up there for a sec. If you want to shout out a question, I will uh let's let me let me back up to the the money

shot. There you go. Um anybody?

shot. There you go. Um anybody?

>> Yeah, sorry I couldn't see you. Yeah, go

ahead. You

>> uh good point. He's saying that frameworks like Aspire sometimes hide the hide the complexity behind the scenes. What's the downside?

scenes. What's the downside?

>> Oh, because it makes it so simple on the developer experience. It can make the

developer experience. It can make the production experience very complex.

That's a great point. Yes, sir.

>> You should bing it. Yeah, you should bing it. Bing's the only one that pays

bing it. Bing's the only one that pays you back, right? Uh, pennies.

Thank you. That's great. Anybody else?

>> Yeah, co-pilots, not chat. GPT. I've

said all the wrong words. And I did say SQL Server. I mean, I felt like a shill

SQL Server. I mean, I felt like a shill up here saying it so many times. Uh,

anybody else? All right. Thanks

everybody. Byebye.

[Applause]