Между микросървисите и монолита: Какво ни е необходимо за стабилна основа на нашите приложения?

In this talk, Stamo Petkov explores the complexities of software architecture, specifically focusing on monolithic and microservices architectures. He discusses the strengths and weaknesses of both approaches, including ease of use, scalability, testing challenges, and deployment difficulties. Petkov emphasizes the importance of understanding the optimal use cases for each architecture and suggests starting with a monolith before transitioning to microservices if necessary. The talk highlights trends in technology, such as AI and quantum computing, and the implications they have for future software engineering practices. Ultimately, it stresses the need for careful design and finessing of applications, given the rapid evolution of technology and the challenges posed by distributed systems.

[music] Hello everyone. As it became clear, My name is Stamo Petkov from information. service AD. And I had decided not to say how much I'm old, but apparently my colleagues decided to me issue. And so on the slide that I was prepared, I have only shown what is common I really love it. And this presentation will be shared with you after the conference. Accordingly, there are contacts

on it. If on Is anyone interested, maybe? ah to contact me if he wants to asked something. If what we are talked today he became interested and he is interested in something additionally, also on GitHub my profile will be uploaded, it will be done public demo, which should be held today I'll show you. So don't worry, if you get lost somewhere during writing code, aa can always

do it look. It is in GitHub. Okay. And today we will talk. for architectures. This was one of those the most frequently mentioned wishes in the opposite connection. And I will have a few words about monoliths. microservices. Let's still say what it is one and what is the other, what are they the advantages and what are the disadvantages and maybe when to choose one and when to

let's choose the other. But then we'll talk. rather about the things that are necessary, so that our applications, without importance and what we have chosen as approach, to be sufficiently stable and to work safely enough and without problems. Literally two words colleagues Before me, they mentioned the opposite. connection. The feedback you you give after these conferences, is extremely valuable. Today's lecture is actually based entirely on your

feedback. What I am prepared, I prepared it precisely after I got to know the things that people want. to see. The problem is that there are quite a few contradictory and so requests. even in the frames to a person who is very important to me favorite this this part of the reverse relationship, we mention it because actually I I have tried to construct this lecture precisely on

this thing that was wrote that he wanted a very thorough lecture on computer architectures, which even beginners can understand people in the hall. Okay, the challenge is accepted. I have tried. to give things that are interesting to all those who are deep enough in in the field of computer architectures and in At the same time I hope to have them made it understandable enough so that to

be clear about everyone. And one more thing about feedback. Be very careful what you write inside, because you might happened and don't take it as a threat, but you will really see what you have done to yourself in the second part of my lecture. So, for now, we continue. with the first one. Oh, yes, and something else very interesting. I really brought this up because it was

fun and it's a transition to the next thing, which I mean, but that's taken out from your feedback. More topics about AI other than AI. Despite all the things that I spoke, please, after the end of the lecture give feedback and say What do you think about our performance and of course what you want to see. A after the next one time when we talk about computer

architectures, we need to run away a little from so the buzzwords that exist. They are very cool. Many things are many interesting. We as computer architects We should always be in the best of times, but despite everything we must always have and one thing in mind, that in a large degree these things are more like, let's say, marketing than technological opportunities. They are technological opportunities, but to

a certain extent. You all know, there's a little girl, right? Sell ​​me this pen. Oh, I've got four copies of it out. years and you see that 2014 the pen was in the cloud. It is the 21st. happened with blockchain, the 24th is now with AI, and and this year it's a quantum pen. Why am I showing this thing? Ah, You see a very interesting trend here.

If any of these are super popular terms have been appearing, we see 2014 year everything is about the cloud, 2021 everything is about blockchain. We have if I can estimate seven years between them. Three years later, everything is AI. Next is a year in which we begin to we are talking mainly about quantum computers. And things happen a lot. quickly, and in fact we have to be

very careful we treat this thing with care let's go in the direction. We need to follow these trends, but let's not fool ourselves on each of them. And why did I say we were talking about quantum computers? This year has been announced as International Year of Quantum Science and technology and indeed more and more often I I have personally attended three already. events, I think this year,

which are dedicated to primarily security and quantum cryptography, rather post-quantum cryptography. But yes, we're definitely starting to talk a lot and on this topic. Okay, that was more or less like introduction. Now we are starting to be we are really talking about computers architectures. I know very quickly that I guess there's no one in the room, who has no idea what a monolith is and what is

a architecture, but let's quickly show the picture to understand about What are we actually talking about? When we talk about monolithic architecture, we're basically talking about an application, which is there are different options now the monoliths. It could be really strictly, monolithic, single, can and be divided into some modules and layers, but usually we have an application in which a are connected user interface, business logic and

aa access layer to the data. However, another thing is exceptional important in this case. And I really want to emphasize rather the ways in which store data in these two types because that's probably the main one the main difference and the main problem with and monolithic architectures. Exactly the data. In monolithic architectures for a relatively uniform database. You you may have several different aa stores for data,

but the main one is one in which Keeps the information from the application. This there are many pluses, there are also many minuses, which we will talk about in a moment. At microservice architecture things are separated. A moment ago, the colleague from Draft Kings mentioned, but that their applications are based on a little over 25,000 the microservice. Imagine what it means support 25,000 separate applications real with

25,000 databases for example. And this is truly exceptional. impressive, but also extremely complicated work. But it's important when we talk for microservice architectures, really to know that there is absolutely separation everything. And we must be very precise. define boundaries and how to divide these services, so that on the one hand they be independent, on the other hand, when requires them to work with each other, that is

happens easily and without us creating Okay, a few words just about the monolith. as pros and cons. It's very easy. developing, right? We've all done it, we know. This is the simplest option, when we teach students, too we start with a monolith, since it is a simple enough in concept and very we can easily show things, which must be done. Accordingly can very easily show patterns, which

we want to be respected, and all boundaries that we want to be imposed. It is very easy to find mistakes. We've all debugged, we know, we run the debugger, everything goes sequentially, everything is simple. We have no problem. with this thing. It is easy to test. Easy to test because you have everything in front of you you are. And you can do it very easily a test

to cover your code. Easy to unfolds. Now you only see the pros right now and in a moment we will see how they are in the sense of my schizophrenia how it develops. But how easy it is to unfold, what about you? you have to upload an application. You don't have Who knows what kind of problem, right? You catch the monolith, move it somewhere, it works. I

mean, we don't have any problem with that. something. Simplicity of evolution. Yes, simple, but ineffective. We can put it this way. It's simple, because again and you have to take care for a single thing and very easy you can make some changes to him. The result is usually a big ball of wisdom. It evolves so easily that in one moment you get a ball of mud and

nothing more or spaghetti, who what prefers. So yes, it's much simpler in compared to microservices, but not so effectively. See this with adding the new member to the team is great. And as I said, even with students start initially with monolith work. That is, they are aware enough of how things happen in the monoliths and very quickly they can logged in in aa part with the things

you do. Low price, but at the beginning of the life of really very often and we are looking for the most efficient way to to get out of the market as quickly as possible and to reach to our users and then to the monolith is a very good solution because we just go to market quickly, then This might be coming out of our noses, right? but we

succeeded in the beginning. Let's see what the cons are, shall we? I said, it's really cool how this unfolds. something. Yes. But when you decide to release your application somewhere, you you have to upload absolutely everything. You you have to test absolutely everything. You have to build absolutely everything. So simple and accordingly it should be you can upload absolutely everything. strongly coupled code. I already said it,

right? that the most common result of the monolith is namely Big B of M. And now this is something, that which is controllable can be controlled and we'll talk in a moment for this, as we get deeper into the lecture. We have unclear ownership of the code. That is, given that the application is monolith, one application and all are working on it. Yes, of course. You in

the team you can understand each other you do this, you do that, but everyone touches everywhere and This really leads to quite a few big problems. It's no coincidence that people say that our applications are largely reflection of the organizational structure of the company. That is, if you are just a small group, everyone touches everywhere. If you are separated in any way, you may You might also

be separated at work. This applies for the monolith almost with security. Here is mine. schizophrenia, right? Simplicity of testing, difficult testing. Why did I give it as minus? Because and when you want to test a monolith and you are made some change inside, relatively small change, no meaning, you touched something in it, and this can absolutely affect everywhere. Accordingly, you must absolutely do regression tests on everything,

right? You touched something. very little, but you test everything again. That's why you have a problem with testing the monolith. Problems with productivity. Most often these problems are due to the accumulation of of large amounts of data. Then The big problems of the monolith begin. although there are other things, which also matter. Price of the infrastructure. And we know that in order to we're scaling a monolith,

right? the only option is to duplicate it xix times. Of course, we might we want to enlarge a very small one part of the functionality. That is, we we need to scale very little pieces of this monolith, but for unfortunately we can't do it and we need to release two more, three, 5, 18 copies of the monolith in question, which leads to, of course, to price increase.

Because everything inside is interconnected, it is very difficult for us to let's start replacing some technologies. It's piling up, isn't it? We are created the application, time passes, It's good to update things. continuously, but when it happens too big, there is too big inertia and it is very difficult for us to start and we change things. And yes, as above it says simplicity of deployment, so here

too We are having problems with deployment. Deployment problems come from exactly that it is very big and needs to constantly raise copies of it and to make sense, which complicates things quite a bit things. Let's see how they sit then. microservices in this background, right, after like the monolith has so much problems. Ah, the big plus of microservices modularity, weak connectivity. We know, they are absolutely separate.

Scalability. It's not here anymore. need to when you want to release a new functionality, that is, to increase the capacity of a certain functionality, you can only increase the capacity of this functionality. There's no need to. you lift everything. Isolation in case of collapse. This is something very carefully done, with which must be handled. Yes, ours applications can remain completely functional when certain ones are dropped microservices.

Yes, there are microservices, from which everything depends, so when they dropped, there is no way the application can continued to work. It's as good as it gets. maybe more of these microservices can be isolated, respectively if it happens any problem, he should stay in the corresponding microservice, the rest from the application to continue working. Diversification of technology, something extremely important. We have often discussed the topic with

and other such events and with colleagues, that a sometimes, how can I say, the hammer is very a good thing, but it is not a tool with which you can do everything. And that's why for every task there is technology that is suitable. You and I We are at the DNET conference. Net super technology that is suitable practically everything, but not quite. You always know we need

some things that are different and that they use different technologies. Microservices give us this opportunity. Ah independent deployment, any microservice can be absolutely with individual CICD a pipe. Productivity of the developers. This is very controversial. Let's be honest for a moment whether it's true. The idea here, however, is that everyone developer can be responsible or any a group of developers, it depends how it is structured company,

can responsible for a specific microservice or certain microservices. Accordingly, he gets to know each other very quickly and very easily can make changes to them. He knows how specific microservices work and if this thing is coordinated well in the team, it turns out quite well okay. The worst thing about microservices is the high complexity. A The complexes they bring in are very is often unjustified and that

is the biggest problem with them. You face challenges of the distributed system. I only I mean, even with the monolith, a lot you often encounter this thing, so like our apps can't be isolated, they are in some kind of global environment and accordingly aa in any case you will have to we solve similar problems like these challenges of distributed system. Complex management of the data. Oh yes,

it's at the monolith. extremely simple. Everything is in one base. We know, we can maintain data consistency, making various constraints. We can to aggregate data at the database level data. We can do a variety of things. operations inside. There is enough applications that the entire business logic is exported to the database. And so we have a lot of tools there with which we can work. However, when

your data is scattered over in 10, 15, 20, 1000, 5000 or 25,000 databases, the things they are becoming quite a lot more complex. In this case we have possible consistency. Not always our data is consistent. Not always the result of our services is consistent. You up to a certain point you may not know what the result is from the implementation of task. And this brings additional complexity.

And of course communication between services is not that simple something. Complicated deployment. Okay. It was supposed to be simple, right? because each one can be deployed separately. Now suddenly it happened complicated. it became complicated because when we we turn to this type of architecture, we usually take advantage of a hell of a lot additional infrastructure services, which are provided to us and this is the big plus

of this type of system. Okay, but maintaining one like that infrastructure is a difficult operational task and no coincidence the colleague from Draft Kings, right, very thank you, it was a very good presentation, showed that underneath there were operations, who is responsible for absolutely everything, for the whole stream for all applications, so as this is one of the most difficult tasks, when we talk about a microservices

and testing. It is very simple to the microservice to test the specific microservice. However, when it is necessary to you test the application thoroughly, things they become much more complicated. They are more complex. the experimental productions are more complex the tests that are written and accordingly need QA who can handle with them. This graphic is from Martin's blog Fowler. Martinfor, I will talk a lot about him

today. He is one of the taka gurus of computer architectures and it is very indicative. And about what I said before right now, right? The monolith in the beginning you you see if it worked and Okay, I'm sorry. That's right. And you see that on this axis we have productivity, on this axis we have complexes, that is, complexity of the system. While the system is relatively simple,

until it's not, and we don't know who how heavy a system, the productivity for the monolith is much higher, because microservices still initially bring complexes, which we need somehow to overcome and much easier The work begins as a monolith. In one moment, however, when the systems become complicated when we implement many new functionalities, production drops sharply the productivity of the monolith and although that microservices performance also

falls, it is not so sharp. Ah The reason is that we have dedicated teams that work with certain microservices, they know them very well. The reason is that it is much faster and easier we can respond to changes and respectively, when the system is complicates, the monolith loses much faster your productivity. And keep in mind However, it is no coincidence that it is written below that extremely

important when taking solution what aa knowledge, what competencies, what skills the team has. The architect must always takes into account the team he works with. I think there's no point in telling you about these principles. We all know them. You are I need it. That means you won't need from this. Keep it stupid simple or keep it as simple as possible. And don't repeat yourself. We are

used to we look at these principles such as programming principles, but in fact they absolutely apply to the construction of architectures. And the main one of these principles is in the middle and keep it stupid simple. As much as you can simply keep one thing, so much the better. Don't go with complicated things if you don't need to them. Martin Fowler has one aa one article, there

is a link to it in the presentation. You can read it. Whether to start with the monolith first. And these two statements are his, not mine from his observation, but that almost all microservices success stories started with a monolith that became too large and that almost all cases, in who has heard of a system that started as microservices, this thing is failed. There's a reason for that.

However, when you start doing one application, at the beginning there are a few things, which you must comply with. First, Do you know the domain well enough? Every architect works, of course, in various domains, but in order to be able to correctly build the structure of the application, it must very accurately assess the boundaries, right? One of the main terms in a domain design is bounded context

and that is the thing that is how to say end the cornerstone of microservices, of If you manage to find it correctly boundaries, correctly divide a functionalities in a way that they can be performed separately and as overall to do the job, respectively, sure you can do very good microservices. For this purpose, however, you you need to know the domain very well, in which you work. you

must have a exceptional knowledge of the processes that you want to achieve. Whether at the beginning of creating a product even if Does the architect have such knowledge? Whether the company that starts doing it is sufficiently aware of all the processes, which he wants to cover. Rather The answer is no to this question. Besides, do you know at the beginning whether users will accept your application, will

it become popular, Will it really be used? Rather no. Do you have any research? you've tried something, but you have no any idea if this will work. Indeed, any processing of functionalities between services is in times more complicated than when this is and we will be able to adjust much more easily the concept we have chosen if let's start with the monolith. Now here is a piece

of advice Martin Fowler, who is very difficult to complies, right? Design carefully monolith, separate your modules as at both the API and storage levels of the data. Yes, we keep them in one base, but we keep them in different schemes. We are trying to they don't have connections that aren't needed and so onwards. Start with a monolith and peel services at the edges. This is also advice.

by Martin Folger. However, I would rather adopted the last thing he says: "Don't be afraid to build the monolith" and sarifl architect, that is, architecture, which you will sacrifice later. Go with the monolith, lift it up, do. Let people like yours application, let's start using it. Start working on version D, which is already with the accumulated knowledge in the home, with the clarity where you went wrong

and where you didn't, you can do much better. There was a joke. at the time, did they ask the Germans What do Bulgarians like about themselves and the answer? was: "I love the second mind of the Bulgarian." And yes, actually not only here however, this is true. Very common version One of the products is a total failure. So you can always start gain some knowledge and then

already to go, if of course this thing worked with and now the development of the system as Stefan Tilkov disagrees however, who answers in the same block with article of what Martin wrote Faller and he says that it was the beginning of building the system is the moment when which you should think about everything. I don't know. The question is can you think about everything at the

beginning when Are you starting? Do you have enough knowledge, if really problems. Wait until you see the demo. Okay then. I think we have a microphone. already. And according to Stefan Tilkov, if you you can build the super structured monolith, what the hell are you for microservices? Work with the monolith and Don't do stupid things. However, if you start with a monolith, the parts will be very

strongly connected and accordingly very difficult then it can do some changes. Now which one of you would you listened? I don't know, right? And the truth is that as Martin Fowler says, microservices and the monolith is just something you worth mentioning because they have interesting features. Nobody a self-proclaimed architect does not consider them to be some exhaustion of the architectural space, right? Our architectures they shouldn't go

to one or the other the other extreme. We must we try to make it possible the most suitable for our application. And of course, Stefan is absolutely right Tilkov. No matter how unpleasant it is, in everyone in every situation, you you will have to make your decision what to use and how to use it. And No one can tell you exactly what do. It had slipped my

mind. Kevin, the last name, I can't remember right now. a great speech in which he said after all, the answer to every meaningful question should start with itdi depends. It depends. And the answer to each An architectural question begins with depends. and none of us can tell you a what should you do. Very fast I want to show you so you can see. the complexity of one

such relatively microservice architecture, because it's not accurate. And with a demo that is purely on a presentation, it's about the national health information a system that we are developing ah and we support. And this is a simple one process. The doctor just has to tell you. write a recipe. Nothing more. So that it can to write you a prescription for a doctorate, he previously made a request

to us, to get a ticket, to a we know who he is after all. After which The recipe writing begins. His system sends a message to our App Gway. Our App Gway sends this message to the archive service. The archive service sends this message to time stamp service that is qualified time, to the time in which this message received. Since we are took the certified time, the

archived service writes it to the archive database and gives it an archive number. The archive number returns to the app, which from its country is turning to authentication I came here to ask, I have one here. be token, and is it valid? Authentication service checks bear tona in distributed cache in ready distributed session store in this case. have you seen this one and if it exists the

token in question, returns information about user to API Gateway. This user information immediately checked in hicks registers, because if he is a doctor, he will be checked in the register of the medical union, if he is a dentist at the dentist's, if he is vet of vets and so And accordingly, since these registers do not are very reliable, to be quite honest honest, you see the orange

dotted line. We we have built copies of these registers, which we maintain in us at Medical Registry service in its database, as asynchronously, of course, they are a synchronize with the registers that are on given professional organizations. After is checked there, and the message itself, the signature is checked to see if and the message has not been altered along the way and the certificate with which it

was signed is sends to certificate validation the service that should check it. Please note that certification validation server knows all certificates issued by European Union, all certificates corresponding to regulation 910. That is, it is maintained here communication with all publishers qualified electronic signatures from the whole of Europe union. Only then do we get to the very definition. service that needs to be found the patient. Look for

the patient if he/she needs it. found, everything is correct. If he doesn't find it however, depending on the type of the patient, can look for it in the grail, if he is a Bulgarian citizen or if he is a permanent resident foreigner in the Ministry of Interior, in Bulgarian identity documents. After by finding the patient, we create it, if he didn't have it in a the base,

respectively we turn to service nomenclature. Nomenclature the service must check if all nomenclatures that are used in the given recipe, are real, whether The doctor didn't do anything wrong. After which we throw to Okum Validation server, something that checks units of measurement. This is a universal measurement system. units, for measurement validation units. Are they mistaken somewhere? units of measurement. After which he himself prescription service is turning

business around rules through your RU engine to check whether there are no business rules violated. Then he turns to the service for number generation. He hands him the archive. number and to this archive number is generates a document number. We keep link number of each document to the message with which it was generated, to can in the event of any and all and it would be a

problem to check where it came from the problem came. Only then is it created the electronic record for recipe and now with asynchronous communication through one rait MQ queue, that is, several Rabit MQ queues, respectively sent to the notification service, which will send a push notification to the app It is good that the user has an issued recipe. Accordingly, if the recipe is health insurance, will be

sent for validation with the health insurance fund and will be a second archive entry was made that it was already issued in question document. Only then does the doctor receive response that he has successfully created a recipe. You see, such a simple thing, as much as prescribing two medications to a white piece of paper, what process do they trigger in a microservices architecture. So that one must

be very careful think about it. I'm out of time, which is terrible. To be honest, I have more that much. Okay, I'm sorry about that. Actually the idea oh, even if we use a monolith. Enzys, that you saw a moment ago, I can return this picture. And some of the services like for example, the Number generator and the archiver service, they are really microservices. They they do

a very simple thing and only one thing. But a service like The epition service does thousands of things. So it's not quite a microservice, it's a macroservice, so to speak. Yes, separate it's a service, but there are a lot of operations that can make on one recipe. A there are parts that are not affected here. Inside Enzis' infrastructure there is also two or three monolithic applications. That

is, you you never have clean architecture, never you don't have pure microservices, pure monoliths. You should always take solutions depending on the task, which is placed before you and to choose this, which best solves the task. That's why I prefer to I'm not talking about microservices or monoliths, and for distributed applications. And actually, this is the important thing, which which we should pay attention to. How we

have to deal with distributed applications? What does distributed mean? applications? This means applications that rely on to work as a whole rely on many services, which were microservices, macroservices or monoliths that are included in the entire situation. And when you have to manage such a complex Menagerie, you need a lot of things. One of which is communication between these services. And I have presented two options. of

synchronous communication. Very fast I'm going through REST and GRPC, right? I don't know how many of you are familiar with this, but we compare the two technologies. A REST Everyone knows it, we use it all the time. GRPC or Google Remote Pre is a way to synchronous and asynchronous communication. By the way, it can be in aa and which They are used as a remote prig call,

right? That is, we call remote methods. That's right. A the difference between the two in the protocols GRPC does not use HTP1.1. It a newer protocol is needed. If you you need to use HTP11.1, I hope you don't. There's no way. you are using GRPC. And with the rest, that is because of HTP11 TLS wish. So there is no such thing. wish. Mandatory TLS mandatory nothing that

can do it skip. And with GRPC, TLS is mandatory 12 with a question mark because there is a way to stop it, and which one will we use a little later. Communication during the rest is most often with Jon or XML messages, while GRPC uses buffers that are binary format. Protobuffers give a much larger data transmission speed, so as they are smaller, but accordingly they are not

readable by humans. You also have the opportunity to both for code generation, whether through Open AI or Sloger or via Pro 3 the standard. I'm out of time. Okay. Well, I really want you to be finish some of things, so the option is as follows. Going let's do it like this. we will let go the holiday, right, since it is planned. Then I have another hour, in

which I will quickly transfer these lectures and I'll continue with the demo, these slides. I hope you agree with such a decision. [applause] So, I realized that in general, we are the hall They took it until the next day, so I can I'll continue for another two or three. days. And apparently my time management is lame. Okay. And now what I wanted to do finished in the

first part of The presentation is here, they're stressing me out a lot. zeros on the display. And I know that at least they should come with minus signs Conversely, at least I know how old I am overdue. Okay. And the things about which I want to mention that right now they are actually about what we need to decide, when we build some of these distributed applications, because

without importance of the architectural style that will choose, your applications will not be isolated. They will be and will work in some environment, in which they will have to communicate with various other services and applications. Accordingly, I started with the synchronous communication, and with a comparison between REST and GRPC. What I mean is that REST is the relatively more familiar option and for most people it is

more comfortable. And we we have decided to use interface when we communicate with external services that are not ours are not part of our infrastructure and with GRPC when we are inside, as GRPC allows quite a lot higher data exchange speed, thanks to the smaller amount of data, who flies, thanks to the optimized protocol used and besides, I don't know if it made you impression above in

my haste from deve, but at the strait and IPC or a interpress communication, that is, a GRPC can be not only through a TCP or respectively the HTP protocol, but it can also goes by interpress communication, when the applications are on the same machine. Okay. Accordingly, it allows any streaming, whatever you can think of. This, of course, comes from the HTP2 and HTP3 protocols respectively, which in

R basically by design does not have stream, as you can also use a protocol that almost supports it. And balancing however, when we talk about rest systems, and we can safely we balance on Layer 4 and Layer 7 from the standard model. Now this maybe I had to skip it. I won't explain. what is Layer 4 and Layer 7. But the idea is such. When using R,

you can you balance purely at the network level. That is, your balancer can judge which way machine to send the corresponding request. A when using GRPC however, a problem, because then your balancer must also understand the application shell. That is, balancing becomes more difficult and not all devices can do it. So you have to be careful here, when you choose something like this, your Will the infrastructure

be able to handle it? no. Okay. in asynchronous communication actually the big problem of asynchronous communication even consistency. That is, you don't know in a certain point whether things are okay or not until they happen. You don't know if your data is consistent. are or not until a point where this It happens. You don't have that control. continuously, which you have at synchronous communication. Of course, always

use durable MQs, that is always use tails when possible a question of significant data, right, there is data that is not significant. With them it can don't do it, but Dable your tails ensure you won't lose data even in the event of an infrastructure breakdown. Accordingly, asynchronous communication is now the applications you see here as a joke, like Rabit MQ, like Zero MQ, you provide enormous opportunities

from various communication options as clean and protocols. You see, you can be you are talking about TCP, UDP, as I mentioned by DV Interprocess Communication, Transparent Interpress Communication, Multi-threaded, UE sockets. That is, you already have many options to communicate between the services, options that allow you to use the fastest and most optimal for you a way of communication and accordingly you have a lot of options as

pure communication patterns. There is a fanout in which you send one message, it is distributed to a variety of sources, that is processors. You have a crush when someone publishes, another is subscribed, accordingly read this message. Push you sew and when someone remembers, it can Pull over and check things out. That is, you have different options that you can you use aa in this communication and this

gives you the opportunity as architects to choose the most appropriate one for the specific task. And obviously, as It became clear this morning, my choice is not very correct. we had a certain problem. And the other thing something when you have distributed applications, you have to manage them somehow. That is, there must be someone to say you are this, you are that that, you do this, you

do that. We need a conductor or so-called orchestrator. Now I have given here DNETire, Docker Comps and Micro Cubernetis as options you can play locally with you while you develop and more or less the same when you are in production. As you can see, on production is missing DNET aspire and is replaced with Docker Sworm. There are others. options. This is just a sample, but you definitely

need something that manages this entire infrastructure, because when we talk about a multitude microservices, there's no way this thing can be happened by hand. When you have a monolith, You can do many things. Can manage your certificates manually, you can hand out addresses, you can do your redirects on hand. You have two machines, 3, 5, 18. Everything is possible. When the colleague mentioned about 25,000 microservices, just

try to hand-issue the certificates for 25,000 microservices, right? You certainly I need something that will do this. work. Another extremely important thing that and we need to know when you have monolith, it's very easy to track and logs. You know, right, my logo is Here, these are the problems. Not you need trace because it goes through the monolith. And metrics are good to have they also collect

from the monoliths, but let's say that it's much simpler to collect the metric from the monolith. You can get it from the logs of the relevant web server or something like that. However, when we talk about distributed systems, things happen quite complicated. Then the logs should gather somewhere. You don't think that if something goes wrong, you've deployed 15 instances of one microservice, occurs problem. In which of

the 15 copies is the problem occurred so that it could Are you researching? In whose log you should look at this thing? That is, the logs they need to come together somewhere place. When there is a problem in some of the processes, you need to find out very quickly who A microservice has just given a problem. I call microservices may currently be everything. What part of the

distributed application the problem occurred, right? The client calls you and says, "Well, I don't I can get a prescription." Well, great. Extremely cool. But you saw the prescription was issued in the 20s the microservice. And where is the problem? Okay, Get well. That's your problem. You you need to find out exactly where it is the problem occurred. When they are 20 microservices, you can go through them.

When there are 20,000 microservices, obviously you can't check them one by one. That is, you must know each one Where exactly did the process go and what happened? happened. and of course the metrics that are very useful to be collected because they allow you to monitor system parameters, give you the opportunity to correct quickly, by tracking metrics, you can you're taking preventive action, right? if, for example,

you see that periodically increases, there's some kind of peak, right, here the colleague mentioned the superbowl, he knows perfectly well that at Superall it will be something obvious. Before Superall they lift resources. where do they provide additional services and so on. After the Super Bowl, however What's the point of keeping these things? right? But so that you know that such things happen happen, the Super Bowl is

clear, right? But when you have less than clear moments, in which something might happen, the metrics give you a huge advantage and you should must be monitored. Here I'm jumping around too quickly. I will only I say, so you can see the menagerie with which you have to deal with it when you speak for distributed systems. And the logs they must be kept somewhere. I have to

you have centralized storage of the logs. Will you use Elastic? Search, will you use Honeycomio or anything else, it doesn't matter. You can send your logs wherever you choose, right? But it's good for everyone a decision you make as architects, to look for standard solutions. Don't. to invent the hot water yourself. Maybe you are good enough. As an architect, I will Come up with a really cool

solution. Whether however, it will be implemented according to the ideal way? Will all people comply with absolutely all good practices. so if you can use ready made a solution that gives you the opportunity, use it. Here we have Elastic Search and Honeycomb IO for example. The same applies to the metrics. Yes, you can collect metrics from everywhere without a problem, but a there are special applications where

this their job, such as Graphite and Prometheus. And they can bring you together application metrics. They can they make dashboards for you to monitor every single aspect of the application. So a you should definitely use these options. Now all these things, for which I am speaking at the moment, I am I tried to choose either open source projects, right, no I'm not advertising some company, and accordingly

such, which use the Open Telem standard. Because Open Telemetry gives you the huge opportunity, but flexibility rather to you use a variety of products. It's no coincidence that I've shown at least two, right? They will both work. Who are you? choose, it doesn't matter, since they use Open telemetry, you accordingly you can send to them. Traces. Traces are an extremely important thing. Trace is exactly what it

tells you, shows the path they are taking your lives at your service, your lives to your request when one comes request, what services it goes through to can, when there is a problem, you quickly find out where he might be arose. In addition, the traces usually they also give the time in which the request has passed inside the specific service. You can understand if you have any

delays, specifically where they happen, which is also exceptional important. And when we talk about metrics, traces and logs, keep in mind that you should collect these things not only from the applications you write, and from the infrastructure as a whole. Every every one participant in this infrastructure, any device, hardware device, any software that is deployed, must submit metrics and logs so you can navigate, when a problem

arises. the data. What I wanted to do paid the most attention, and when it's about microservices and monoliths, most often the conversation is not actually about a applications as much as for the storage of the data. And monoliths in general they store the data in a huge database data and that's not bad, right? This has its advantages. We have a consistency of the data. They are clear.

We have constraints. We cannot record wrong data and to ask because we have constraints that will stop us. We have very easy access to data. They are on one place, we immediately turn to them. Very easy deployment, of course. We are raising a database cluster and falls asleep. Nothing more we touch. Yes. However, with the accumulation of we have data loss productivity. It's getting slower. the work

of our base. And when we we rely on a huge base, we we lose flexibility. We might want to we use some kind of documentary storytelling, some kind of value pay storage. Can we want to use a variety of options. No, not every part of our application needs a relational database data, but we are tied to it, because we decided so. And accordingly we have vertical scaling.

That is, when things start to slow down, when resources are running out, the only option is to lift resources, to increase processors, to we increase RAM, increase disks. This is for a while. You can't do it. endlessly. Weak data isolation, respectively, when they are in one place, of course, anyone who has access to the database in question has access to them. They are not isolated. When we

talk about multiple bases, we have high productivity, as they are very smaller and much faster it happens everything. We can choose a different type repository for each task, which is extremely important. We can scale horizontally when we have a lot different bases, we can raise them to different servers, different clusters and and so on. That is, we have almost infinite scaling possibilities. It's all about money, right?

We have possibility of data separation, as as this data is stored on ah, access to them can be separate. You saw a while ago demonstration from Tenzis, where there was a thing called master person master patient index. Master patient index is the only place where Enzis preserves a connection to the real person. all documents, all bases everywhere, he has a fictitious identifier that does not can be

traced except through the masterpn index in question. Accordingly What we must protect is precisely he, right, and which guarantees that even to leak any data, they cannot be associated with a specific person, simply because there is no data on the person in question. And so you can isolate part of the data and accordingly in this way you also increase security. You don't have a guarantee of consistency

and that's it It's written here, the other here, the third there. Do they have any connection, one Lord knows. Much more complicated data access and a much more complex deployment. Not anymore you don't have one database cluster. Can you would raise 20, 30, 25,000. There is no no matter how much you have to When we talk about consistency of data, the only way to keep it safe

consistency when we have distributed application, is that so called saga. We don't have the opportunity. for transaction. The possibility of transaction that we have at a monolith in the unified database is missing here. Distributed transactions are not option. Forget them. They only do problems. And how many times have we tried to make a transaction on three or four bases, this thing was always full fiasco. In order

to guarantee consistency, it is guaranteed by the application itself. The application must to do it. How does this thing happen? When you are performing a business transaction, that is, a request has come in, you start to move it from a microservice to microservice. This is a series of local transactions, right? Every microservice works with a local transaction. He is writes things down and moves on. Every local

transaction now triggers the next one. That is, when one microservice has done its job, it is Okay, he passed it on to the other one. If the local transaction failed because it violates some business rule or something otherwise, there are some errors and so on further, then already and itself application must undertake a series from offsetting transactions. That is, it should start giving back the condition as

it was before the performance. This is extremely heavy. task and is one of the main problems in front of the microservice architecture. Aa for data access however, each service is owned by your data, which is great, right? Each service has access to its own data, but the services are not isolated. The services work together another. When another service needs access to the data in question, it must

pass via the owner service API mandatory. Do you have direct communication with a foreign database, this breaks all the patterns and accordingly you you don't have a microservice architecture, you don't have proper architecture, let's put it this way, because it doesn't matter microservice or not. And when you access data from a specific service, the speed of response is huge, because the data is relatively small, right? However,

when you need to cover hicks services, data from many places, then things start to get a little... more critical because you have to refer to the API of each service and here you depend a lot on speed of the relationship between them. you practically have no chance to aggregate data at the base level, as well as we do very often. It suits us. some ITL process is

needed to guarantees us that when we need certain aggregated data, they will be collected from all bases, will be aggregated and will be prepared in some kind of data warehouse or data lake, as you decide, wherever they may be the inquiries were made. You have several deployment strategies, as you can You are on the premises, if you want. You can be and on premis you can do

it deploy on ameal, that is, directly on the machine, your bases, right, which you have decided to do. You can use and virtual machines, you can use data for service from some of the big providers or to be cloud neutral. What does cloud neutral mean? This means that your your architecture, your applications are made so that not to care about where they will go your database is

deployed, your databases, right? This can be some private cloud, it could be some kind of hybrid cloud, it could be public cloud with one or more the supplier, that is, to have scattered data all over the world in different clouds. If you are cloud neutral, then you you don't care about this thing, you can deploy everywhere. Actually, here, right? The elephant in the room is visible in

my opinion, who quite deliberately connects with background, because what would give you now we work with postgre and I mainly I like the postgre, but what would you gave cloud neutrality when you work with databases is Cloud Native PG. Cloud Native PG is a Kubernetes operator that is really very, very good. It was developed by EDB, but was donated then to the Cloud Native Foundation and in

currently being developed by Cloud Native Foundation. It is completely open source. declarative. You say, I want four clusters of bases, each with one is with on, right, every single cluster I have primary database, two replications plus point in time recovery. You press enter and the provider starts to lift your clusters. And as it already communicates with kubernetes, lifts the floors, installs everything in them, Right, he's picking

up his containers. do it yourself the clusters, by setting absolutely everything, logical replications, a point in time recovery, everything that can help you is necessary. So, and more the best thing is, kubernetes is following them in the event of a failure in some of the clusters, a failure in some of the nodes. Kubernetes instantly restores the work, first transfer the master to one of the the replicas

if we have a master crash. the master is transferred to one of the the replicas, respectively raises a new replica. This way you don't even really have a downtime. when falling on a base, right? Dautai is absolutely minimal, even if it happens something with your base, this is being monitored automatically by the provider, by the operator and accordingly a decision is automatically made what to do. And

really quite a lot quite a readable thing. What is interesting, I stole this graphic from Gabriele Bartolini. And, because it is often said, what about this one? big problem. How will I raise a base in container? This doesn't work. This is slow, This sucks, this doesn't work at all. Gabriele Bartolini had one of these a graph that shows what science is We are at the moment, right?

And how in the beginning everyone explained that it was not necessary to postgrease It must be on iron. This virtual machine cannot run. It will be terribly slow. It's not lame. It must be on bare metal. In one moment these opinions slightly faded and opinions began to be raised. Oh, that actually the virtual machine was very cool thing, right? Okay, let me do it. we use it

and they prevail. Now these opinions prevail, but now people they leave and to aa postgray in kubernetes, which for For me personally, it's a very good option. And last but not least, What I mean is about security. And this is extremely important for your applications. You as architects would you should have initially bet the rules so that your applications can be sure. And this is divided into

several things that are extremely important. The first thing is infrastructure. We, because most of us have a background in developers, most of us think about applications, but not so much for the rest of the things. The infrastructure is extremely important. mandatory segment your networks. No need. different applications can access one to another. You have no reason to do it. It's clear that they don't interfere, they are

they work. But a breakthrough in one application can directly lead to breakthrough in the next one if your network does not segmented. Always have only one single entry point protected by some kind of firewall, with a web application firewall, if of course you use it web applications. And so you must guard only one place. The rest are relatively protected, so many it would be easier for you

protected. No need to have internet in your application infrastructure or if there is a need to use something, some part outside, then it must be controlled. We have access to accessible timestamp. The timestamp for us is external service for the application. And you should I need it. No way. I don't have internet, but I have a hole drilled to the specific service, to the specific port. That's

all I can see outside. If I need anything else, we're making a breakthrough. And the users your work with applications, this is what I'm facing lately. I don't know why people are so stupid. Honestly, the users of your applications don't need to have administrator rights. Why is it said? Stamo, on which you will now see a in The demo for the user for the database is with

administrator rights. Oh, no need. the application user to be administrator of your databases. Why? Because a breakthrough in your application will led to a tale about the one who is attacked, he will have your entire base and will can do whatever he wants inside and he creates whatever he wants and does whatever he wants whatever you want, right? There is no need to you give such administrative

privileges. Even when one of your team accesses the infrastructure, this would it should have been controlled. Control access. Use only secure protocols. high levels of encryption algorithms and fonts. You shouldn't to underestimate these things. And right now we are talking about TLS 13. 1 2 should already be be gradually removed, and still there are sites that are sitting or without protection, or on TLS11. And the other

thing that is exceptional important, this also applies to your applications, and for infrastructure. Always patch everything. Always up to the latest version. Mandatory. And all the security guards. Okay, okay. Not up to the latest version mandatory because there may be problems in the latest version, but security updates and patches are a must put it on. And as for the applications, any application object potential object of Attack,

so you say: "Well, I am You made a catalog of dumps here. at home and no one cares. Maybe no one cares, but it scans for absolutely everything and They try to penetrate absolutely everywhere. So don't stand on that knee. Any an application is a potential object. No invent the hot water. Use the ready-made things you have in the framer for authorization, for authentication. Don't. to count

on you to write it better than the people who have it work and that's all they do. Use standard algorithms. I will be Sam 2, Open ID Connect, OAL 2. There is a bunch, right, Jtttttt and so on. That is, a variety of algorithms and opportunities that you can use. Don't you discover the hot water and to do what you are decided. Always bet on at least

two the authentication factor. Unfortunately single-factor authentication is no longer works and avoid passwords. Passwords will disappear soon. I am convinced of this, but for Unfortunately, we are still dragging them along. Microsoft have requested that they stop using of passwords at all and they will block everywhere the use of passwords. But as we have seen very soon, and then, that is the alternative to passwords, which in currently

being pushed, and was also pierced recently, albeit in a rather controversial way way. So passwords are, how should I say, I think that statistics 85% of the breaches in enterprise applications are due to expired passwords. And yes, don't save your passwords. and other sensitive data in the repositories. GitHub is roaring about it something, but in other places you can you do. Okay. And the last slide. Mother,

because I said I shouldn't we use such bu, right, some modern words, so I can join in anyway There's no way with cryptographers. Have, Keep one thing in mind. So, when you do you work as architects or not even mandatory when developing applications, you should always keep an eye on what's going on around you and always you must be ready to react correctly to what can do.

What we're going to say is QD is near. What does Qay mean? What is the day when quantum computers will become powerful enough to break RS the algorithm. This is the day when everyone banks will stop working due to the simple reason that all encryptions broken. There will be an opportunity for breaking them. And according to all the analyses in currently this is expected to happen by

Forty-five years. Four or five years we have to prepare for one like this truly an apocalypse that would occur, if we are not ready. All asymmetric algorithms, I I mentioned Ersey, but it's not just him. And they rely on big numbers, on big prime numbers. Our algorithm, which is algorithm for quantum computers, and if there is a sufficiently powerful quantum computer, who would execute this algorithm would

broke. Now here for a while we speculate, but the expectations are for if in currently breaking RS 2048, I think, that it takes several tens of thousands of years on a computer, on the Shor algorithm on a sufficiently powerful quantum computer would it should have taken him about eight hours. And you understand what that means, right? All cryptography goes by the devils. The symmetric algorithms we spit

on constantly, however, it turns out that they are protected from this thing and they are quite safer than from the point of view of cryptography. The point, however, is that even there we have a Grover algorithm which is a search algorithm that allows us to to perform a brute force attack on quantum computer, on a symmetric cipher, so that they can actually be broken too extremely easy.

We already have four, four. There are three here. Okay. Three certified algorithms, one ke exchange mechanism and two the algorithm for encryption that are ready for use, they are also certified they use an algorithm that is not aa subject to quantum computers. That is, algorithms that cannot be broken by a quantum computer. So now we can react. It's currently fourth. in the process of certification. We can

now react and start replacing things. Google's preversions now Chrome supports the Key Exchange algorithm MLC and Google Chrome can work with TLS3 and with quantum algorithms, with algorithms that are protected by a quantum computers. So have considering that even today we can Let's start doing this thing. Microsoft, because we are on DNET conference with S Channel and SIMCT already they put these algorithms inside. SIMCrypt is the

library that Microsoft uses for encryption in Windows and Linux. And she too has already implemented these algorithms. Shannel is what is used for TCPIP communication. There at the moment they are implementing the algorithms and very soon Shannel will also support them. We can we use, of course, Bounce and CL today already with ready implementation of these algorithms. Accordingly, and I said already switch to HTPS TLS 13,

TLS level 13, because that's what it is TLS, which supports MLC and accordingly with it we will be able to use now such secure algorithms. Otherwise, you are you present, you enter the site of your banking and a padlock lights up How secure is this site? But someone has managed to break the encryption, yes steal the certificate in question, to put on your site and actually do

a copy of your banking application and you to transfer money not where it belongs must. Ah so extremely important in It's time to move in this direction, even though we are five years old. For these five years we should react somehow. And one extremely important thing cryptoliths. At the moment when you crypto libraries, use them smart. Export all cryptography to a unique place. Make yourself aa your

librarians who do all the crypto operations instead of, right, which are for the application. Why? Because it's very easy in you will simply replace it there the algorithms in question. And the last thing is an attack that is happening all the time more popular at the moment. Harvest Now the Crypt later even your encrypted data is currently uncertain because if anyone breaks in, make a copy of

these data, waited four or five years when will now be able to break the one in question algorithm and it will be able to decrypt and get your data. So if your data is alive more than three or four years, that is, if the data you are currently accumulating will be relevant in three or four years, we need start thinking about this now question. Sorry, I spent

a little more, than I expected, but I hope that the things you heard were interesting to What I wanted to show and what obviously it won't work in 25 minutes, a is the creation of a place of one distributed application. Just yes you see how all this complexity, for which we talked about today, and you can relatively to simplify, so quickly to start developing a distributed applications.

As I said, right, the biggest problem is complexity. If you want to you make these kinds of applications, they're complicated, and because of the infrastructure that is necessary, because of a bunch of tasks, communication between server services, distributed sessions, and accordingly you have synchronous asynchronous communications, you have but secrets that must somehow to share, you have many of them problems that you need to solve and no

It's not easy to start you are developing such an application because the simple reason that it needs to be local to your machine you can lift a super complex infrastructure or respectively someone from Operations to take you somewhere some super complicated infrastructure. Ah so this creates certain problems. What I wanted to show today and I will show it. The point is that a little It is faster

to use, implements four or five main characteristics of distributed systems. One is a service call. What does service invocation mean? You You have to discover this service, right? You know perfectly well when you should contact a service, you know and the address, URL - write it down and it will answers. Yes, that's very nice. However, when we talk about microservices, you have no idea where they were

raised these microservices. The orchestrator them crucified in different places. He moves them. continuously. They can be in one or in second deta. You don't know. addresses, you know nothing. how do you find them, how do you call these in a standardized way services, so it's very easy and fast to you can work with them. How you ensure communication between the services? Because we are talking about secure

communication. I have so far I was explaining how everything should be secure, everything should be TLS. Yes, well, but... now think about developing in right now, you need to generate respectively a certificate for each one such a service and somehow to do it you manage all of this something. How do you deal with the unstable communication medium, that is, some kind of resilience in some way, right?

What do you use to achieve this? And accordingly, of course, the metrics and tracking. This is only in part service invocation. We have a few more. things. How do you manage the session? Because It's very easy when we have one application and its session is with us, right? And when we need distributed session when it needs to to be distributed to different places, where different applications need

to have access to it, how do you asynchronous communication, right? How much Is it easy to implement this thing? Where do you keep your configurations? All we know, DNET is great. App settings. Jon is the perfect file. All configurations go inside. Problem however, when it needs to be distributed in many places, it becomes a problem when your your service is multiplied and suddenly you want to change

something in Sorrow. Password management and sensitive data. Where do you keep your passwords, how you work with them, how you reach them. And all these things can to be solved very easily infrastructurally, when you have the specific infrastructure. You know, that you keep your sessions in readys, you know, that as asynchronous communication you use Rabbit MQ. You know your passwords are sitting in Hash Volt. You know

that configurations you keep in the database. Great. Then you can do it very easily. Only that we just talked about Cloud Native. We just now we were talking Cloud Neutral, I apologize, we talked about these things having to be to be able to move to different places and work in the same way. How to be cloud neutral, as we are we connect with the specific infrastructure and

Is it everywhere we want this? infrastructure is available. That's a lot. solution and as the saying goes, dapper. Dapper is interesting framework that I recommend in meaning, and now, if you're a big company that is developing now, for example, on Draft Kings, I wouldn't recommend them to, because they already have all of them implemented these things, right? But when you have to start developing one application that

is similar architecture and you need to quickly quickly do it, reduce the complexity as much as possible with developers, so that they can immediately start they work. Yes, it's a good option. Duper or distributed application run time means this thing. Dapper is a cloud native graduated product, that is, it is was part of Cloud Native Foundation, after which it is now separate. DAPR is completely open source.

there is nothing, which you have to pay for it. The big advantage, what you see up there, you see the technology, right, dapper is technological aa actually works with a variety of technologies. Just touch one of them. You can safely use it, because I I mentioned at the beginning that your applications can hardly be on a single technology. From a virgin I was showing the service that

validates various units of measurement. He is javascript for the simple reason that was a in the sense developed in JavaScript he had it ready. I am one of those people who they try not to discover the hot water and accordingly I inserted JavaScript. Other things are on Dnet. There are things that Python you have to write. There are things that Go are perfect. And we communicated here

with colleagues, right? who were asking me about PKI, which works in Enzyme. It's written there in height. In the sense many different technologies you can insert into your applications. Accordingly DAPR gives you the opportunity of all these technologies you work on one and the same way, to work consistently and to know what he is doing and what is happening always. And DR provides a platform interface only

and nothing more, like it allows you to use different components. Below is part of the components you see, whose logos you may recognize, such as postgre Avita MQ, Kavka, we looked to a while ago, and the S3 bucket and various others. He also works with all Cloud Native tools that a you see like Kubernetes, Open Shift, Open Telem, Argo CD and so on. And the best can

be lifted practically in all clouds, as all the clouds keep dapper, and including can be picked up locally on your machine, can be lifted and m virtual machines and in your data centers. So Dap is a very good option. They have one calculator. here. I thought that I'm so abusive to people and I'm constantly making stupid jokes with them, but definitely Dappers surpassed me, because you see

this calculator that they they also developed my favorite part of it is actually under for division, right? And the divider, which is developed on JavaScript. The only language that has difficulty dealing with fractional numbers. from here and the attendees, but you see that you can develop anything on a different technology and they will work together. They will work together, as DPR adds, that is, injects into your

application so-called DPR site Card, who you talk to and he rules everything else. Ha, that was it. the last slide. Oh, okay. And now, because I'm 15 minutes, I can hardly write the whole thing application, right, but what I can I will do it. ah let me show you, let's go through the code, because I expected that you wouldn't give me The time has come and yesterday

I sat down and I wrote. In fact, I sat down and I wrote it yesterday in literally an hour or so, for example. That is, relatively simple you can pick one up sufficiently complex infrastructure. You saw what I said. I need it. some kind of discovery service. I need them. configurations that are distributed, I need acreage, I need it. respectively, ah, some kind of a nip. Okay,

What I have prepared is actually the next thing. Now I apologize, and The truth is that what I wanted to develop here, there would be a lot fewer projects, right, because of the simple reason why you left, whatever it is more real. But then I decided that there was no sense, but purely for the demo it is not necessary. And what we have is one APIs Gateway,

here is Gateway, which will accepts our requests. App gateway is with restfjs. Accordingly, this is a web API application. And we have a home manager. The entire cinema app. You create cinema and accordingly you can buy tickets and so on. Not for the cinema you need to do distributed system, to be honest, but like aa The demo is okay. Accordingly, this ho manager is responsible for the

creation of cinema, the addition inside of its halls, in which projector. And the third thing that will we use is one log. AIT Logit Log is an extremely important part of the whole and of every single application. That is, you always you need to know what and how it's happening in your application and you can make a report on who did what and When did he do

it in yours? application. So, something that is not here I know how many fellow architects there are in the hall, but they'll probably spit on me right away, right, they will be absolutely right, maybe. Oh, I have. one class library, which is shared among all. In principle, applications, code sharing is bad, right? And it is avoided completely. But you totally avoid sharing any business logic. There is

no business logic here. What it is used for the application in question is a yes first there most new get packages are installed, that is, new get with newt packages is available spreads, so they are installed there, as well as the packages for entitytifreywor well. And accordingly the other thing that's here, we talked about I agree with you that we have many databases. In there are two

cases, since we have ho the manager andlog. We have many databases, but we we don't have to repeat code, right? We have agreed that it is not good to just also something to write in many places. Therefore this shared and a project actually contains one thing, which is our a repositories, that is, this, which helps us work with the database data. That's it. And there are exactly

a few methods on how to read from the database data and how to record something. And why is that? done this? Besides him we have an abstract class that actually implements these methods. The abstract class repository uses entityfreework to perform the actions. You see, nothing much. There's nothing scary about this. When we want to add something, we use DBS adsing of Entity Framework. When we want to

add some range of products, at range assing and so on when we just want to read without them we change things up, we take up snow trekking, which is extremely important. Between the other, the advantage of this approach, when you are an architect, you give developer access to specific methods, you don't give them access to the entire AP and EntityFjork, you only give them access to what

you have decided. That is, they do not can use for example aa such R SQL queries. What should they be able to do? R SQL queries to become injections, right? And so on. That is, you have control, making it this thing. This is done once. After which, in order to works with the different databases, this, which is the only thing you need to do, and now pay

attention, each microservice has its own data folder, has its own database, has its own and migrations, own repositories, then sees only his base data. For this purpose you need and respectively again one interface, but everything that You have to say, "Oh, that's him, right?" he simply inherits it. You must you have the opportunity to access this database somehow. You must have separate repositories, like the only one,

what it does is implement the one in question interface, inherits your abstract class and all the work is done solely and just so you can enter the correct DB context, that is, to insert the correct base with which you will work. When working with DAP, please note that DAP uses its own configuration a. Accordingly, the configuration you have made for connection the strings, it will not be

visible to EntityFyrk tooling. Therefore, it is a pattern that Microsoft they advertise hard, but you have to be do it and he has it, he can do it see the Microsoft documentation, the so-called design factory. DB contex factory, the thing that can created your DB context, even if you don't knows the connection string. How? Well like found it somewhere else. Where from? He may find it elsewhere,

now we'll see. A I told you that the configuration a of Dapper is very good to use because and when you pass through it, you then later in any cloud upload your application, you can choose this configuration where to lives. The advantage of Dapper is that when you have implemented it inside in your application, then it is already work of operation. It's none of your business. work

of operation to say, and DAP the component that will be used for configuration storage is the base data. The DAPR component, which will be HCorp Volt is for you, for example, right? Oh yes the component that will be used for aa distributed session is Redis. This thing happens in some Yama files that are extremely simple and accordingly, when your CICD and Pipeline deploys your application, he can

replace these Yama files and accordingly get aa access to the right infrastructure. That is, to be explained, currently my secrets are stored in a single file called Secrets Jon, right this file, I don't know Did you pay attention, maybe you should to show. He is ignored. He can't to yes and can't stone, so that they won't go into my repo secrets, but they are in this kind

of secret jon file. Okay, why? Because I have a gift component, who is called and Secret Store. And right now you see that this DR component below is told, that the name is secret file and respectively value is secrets jon. That is, Here he is told where to look. the secrets in question. When my application went into production, the CICD will replace this file and it won't

be sitting here Secrets Jon, and will sit a HCOR Volt, right, the thing that we personally use for storing secrets. Accordingly yes, the settings there are like that, because there must be a lot of things to you access HCOR V, but it's not yours work. This is this Yama file that will be replaced by CICD. and the pipeline and your application will automatically start to work with

Corpol. Just like before the moment is forehead, so from that moment on it begins to reads from H Corp Volt. And this applies to every single thing. My config store is currently redis. local installation of Redis is my config store, but an operation can take solution and direct config store wherever he wants. As for the PPSU, for example, here is another YAM file. You see how simple

a file that says, well yeah, for PPS sub right now I I use redis, right? but when we deploy the application, for example, it is deployed in some kubernetes environment, it would be quite logical to hang up and use a pun or because I really love Rabit MQ, to I also use Rabit MQ. Everything, what needs to be done is to the metadata in this thing be

described. yes be told, come now, if you like, use this component and accordingly your application is hooked to the component in question. For the whole thing to work this thing, what do you need? In fact, in this same infrastructure I am did two extensions. The one action is, and by the way, if any of you use DNET aspire, and DNET aspire generates literally the same code, right?

I am here. made very, very slight changes to him. This essay adds to your Open Telemetry applications. I mentioned from that Open Telemetry is the standard, which you should use when you want to send your logs. respectively, metrics and traces to some of because practically all such tools understand Open Telemetry. And in this case you see mine logs are sent to Open Telemetry, and the metrics to

Open Telemetry, as I am put, hey, ASP netore instrumentation and HTP client instrumentation, they are needed to can extract these metrics. You too you say what your applications are, what does your apps have so they can to derive the right metrics, respectively the correct traces. From below I have added an exporter which is zipkin exporter, as currently I use zipkin for traces. And here you can to

put other exporters. Garagarra used to have his own, but now works with sporter. That is, if you want to use, you just have to say add from OPORTER and period, right? And now you use. This is the one for Open Telemetry. Why did I add it? Because DPR itself brings Open into your applications, but he aa sends the logs, traces and metrics from the DAR site. And

if there is anything, what's happening in your application, in addition to the logs, it also collects logs from your application, but if there is anything, some trace you want to track additional inside itself application, but the first one will not have it You'll see, right? You'll wonder why it's missing. So if you add Openem to your applications, you will be able to catch this too something. And

the last thing that's like is, that is, how do we add DP to our application. DP is a new get package. Actually You can see several new get packages. I said they're all installed here. here. Here is Dapper ASP Netcore, Dapper Client and Dper Extensions configuration. That's all I need for so I can bring the gift. I am refereeing. this project from all the others. Accordingly, these

packages are visible in everyone. No need to install them in the rest. Okay. And accordingly here they are also installed on the EntityФWork packages, which I need so that I can I access the database. What I have done right now and I can show, you saw. the secrets, right, but these are just username and password in ready. Now there's a small problem here, that you should be

able to load and damage, right? But I have used Just to a little, since the ready is raised in a console in a container, and loading the the key is done this way with docker docker exec. It doesn't matter. You see her. command, it is relatively simple and So this is my connection. the string. I have saved the string in the connection. space for username and password.

The username and that's it. loaded into the radish. Username and the password is in The secret, right? Accordingly, this what does it do is to lift the client and to put him in inversion of control the Microsoft container by adding it Singleton. It is very important that it is singleton, And accordingly, if I have submitted any configuration, right, to add Secret Store and configuration store, this configuration

will be applied. Here these two apply the configuration. This is all I need to configure my gift and for them to work things. Accordingly, you can see that in here is the home manager, in his program the extensions in question. Here is the action. config that is given the name of the configuration, the parameter that is a in ready, that is, the key from ready and respectively

what keys are there in the given configuration in ready. Accordingly filed It's also about who is Secret Stъ. That's all. which I am writing to add to my Secret Store and Configuration app Store. That's it. I'm not doing anything else, for to be added. And configure Opera, the other one I showed. The other thing, what I need to do is add context. How do I add the

DB context? I am using Microsoft Inversion of Control the container. Injectable the context inside, like I say that I use MPGSQL. And now turn around attention with the standard configuration Microsoft app, that is, I use Microsoft configuration, submitting the keys that are set in my Doors, I'm building a connection the string. So I'm not doing anything here. different. DAP takes care of where to get and how

in the configuration api of Microsoft to load these things. This is extremely valuable. Tolkos. Nothing There is nothing else here in this file. The same can you can also see in the audit Iit file, right, because this is the thing that absolutely the same way configuring DAER, Open telemetry configuration, DB context, and are accordingly different the keys. Now I want to say, and I know, that I

don't have time anymore. I will release now. the application to see it and I will continue to speak, until it is possible go. And I will continue to speak until You see it and I will show. It is very important, when using distributed for example store, distributed session page keep in mind that he is as distributed, it's not that much. It's a lot, right? fun. However, by

default it works on in the following way. He is tied to the specific application that calls it. That is, a as a prefix to the keys uses the application name. So if you have submitted to the sestor from one service and you try to pull it in another, it won't happen. In order to be able to this thing happened, they gave it to me several options. one

of which is, if it I only find second state store to choose your cipher prefix. You add the ki prefix in this case the value name means it will be used name of the store. That is, the prefix will now be named store and accordingly, everyone will have access to it apps that have the same name on the floor. You can order here. all sorts of prefixes,

but yes. Okay, like that. Time is running out, that's why I'm letting go Was that supposed to happen? Understands are. Or I missed the mark gate. But no, that's it. Okay. Nothing can ever be done. live demo, right? right? This is what they look like things. Okay, okay. Trust me. works. Oh, run away from here, okay? Let's see. did it thunder? or This is by the way

the consolidated lock on The dapper and fun is the audit. started, ho manager has started, but No, okay. 5062. Did I make a mistake? gate? Yes. Okay f. Local host 62 is good. The important thing is that it works. Okay. What I want you to see right now is for example I will try to A the first request, you know, this is donnet. At first request lifts

the containers and it's a pain scary. Look what's happening now. How long does it take for the first request? Is it okay? is? The important thing is that I passed and really gave back. result. The question is, if I execute it second time, it doesn't matter anymore, right? I will I'll submit another ID here, I'll request the sixth one. cinema and executive. You see for how long

It's gone, right? Just the first one works. the applications, returned us a result. However, the interesting thing is to see in ZIPkin here is this result that is finished for 200 and a little less milliseconds. You see what happened. happened and where and how they came from the requests. That is, you can follow in each part of the request what is happened. And let's just say that

just like that I'm looking at the requests in at the moment, but they don't make me happy especially, but that's my problem. Okay, so you can do traces. Here we are, running the trace. Logos He is currently being released to the DPR. But maybe I should have let DPR go. the console client to see it. Now you see that you see nothing here, right? But this is

the consolidated log from all applications. Of all applications go logos in one place, like yes, you can move it, wherever you decide. Accordingly, you see this too. Now that he has managed to access the base data, so he managed to get hooked on it too radish and accordingly pull it aa the radish configuration. except that he succeeded to pull the configuration from ready, managed to get the

secrets from Secret Old. So all these things work. And the most interesting thing about the whole thing is that He was able to find the services too, right? The first one is you and me. We rushed to the gate that I was supposed to find. This is because she is left behind. outside and the outside world communicates with her. From then on, however, you must start discovering

your own services and that something happens by name. And I'm very sorry. I really tried a little too hard and I don't have enough time, but I'll just show Now, very quickly, how does DAP turn around? Here is ours. controller controller. At the moment, in who came with a request to create a movie, for example, what you need to all you have to do is shout yes

the client. Here it is to the client. Because my services communicate via GRPC, you need to say GRPC method as and it expects you to tell him which application to go to turn around. Pay attention, it's me. got on a constant, because we are very Are you serious? is? Okay, I've got it down to a constant, but pay attention, you are communicate anywhere with your services only

and solely by name. Nowhere you put addresses, you don't turn anywhere nothing like that. And accordingly, Dapper knows where to direct your request and where to she went. And the other thing, which is interesting, and in the GRPC itself It's a favor, come on, now like I'm in a hurry, the GRPC service itself, unfortunately, this is something that is a little crooked because DnetEnet works a little

differently, but a you just get the name of it, what you want to address. That is, D will send you the name of the method, who should be involved. Accordingly, the problem is that you have to be make a suitcase, right, in who you can forward your request there, where needed. From then on, things are fine. You are unpacking. the data, because it is packaged, it are

binary to be smaller. You unpack your data, you work with it, like you would always do, right? generate the result you need and you bring it back to a dapper who will pass it on to the other one accordingly service. That is, you always go through DPR, because he knows where to get it, where to send it and where to return it. Now I will give you

access to the matter in question. application. I think it's in the right place. for now, but I will release it publicly. I'm sorry I couldn't show more, and unfortunately my time turned out to be a little, as always. And for me, three days Give it to me, I'll be there for a little while longer. So that you will be able to view it now in the guitar

is ready. Thank you very much and thank you very much. I apologize for the many things. time. yes