4 episodes

Architect Tips by Clear Measure
Created to help .NET development teams move fast, deliver quality, and run their systems with confidence. This series is led by Chief Architect Jeffrey Palermo as well as other Clear Measure team members, publishing short clips of helpful tips to empower you to achieve more! Visit www.clearmeasure.com to view other content and learn more.

Architect Tips Jeffrey Palermo

    • How To
    • 5.0 • 1 Rating

Architect Tips by Clear Measure
Created to help .NET development teams move fast, deliver quality, and run their systems with confidence. This series is led by Chief Architect Jeffrey Palermo as well as other Clear Measure team members, publishing short clips of helpful tips to empower you to achieve more! Visit www.clearmeasure.com to view other content and learn more.

    • video
    Architect Tip: Application Architecture Diagrams

    Architect Tip: Application Architecture Diagrams

    Welcome to architect tips. I am Jeffrey Palermo. And I am going to show you today how to use architecture diagrams in a really, really easy way. Now as we go through, there is a lot of resources, a lot of, interesting topics on the Azure DevOps podcast. You will want to make sure to check out that as a resource to you and on this show architect tips, I will answer your architect questions. All you have to do is tweet me @jeffreypalermo and I'll pick a question and, if I can put it into a short five-minute bite-sized chunk, I'm just going to make one of these out of it. Otherwise, I will just send you an email and I will answer it for you.
    So, go ahead and send me a question there. And so now let us get into architect, architecture, diagrams, and I want to, I want to make it easy and show you some, diagrams that I use. So, let us take a system you want to communicate. You want to communicate what you want to either be built or what you are going to build with your teammates then you need to draw something.
    If it cannot be drawn, it cannot be built. Every profession that creates something has some type of design diagram. And so, we need that here.  So, let us pretend that we are starting a work order application. We are going to build a work order application. And so, we need some diagrams that are going to communicate it, and bread and butter diagrams is going to be your diagram.
    You could also think of it as a class diagram also. We are going to make ample use of sequence diagrams. Okay. Then you might have some patterns. In the case of a work order, a work order has a status, and it has a workflow. And so, we need to make use of a state machine diagram. And a lot of times, an activity diagram will be interesting or an overall dependency diagram.
    So let's just take these and let's go through one at a time and see how quickly we can use these particular diagrams to describe a work order application in a fashion where you would actually understand what .NET code needs to flow from this. So, let us start with a dependency diagram, you know, I am a fan of onion architecture. If I am laying out a visual studio solution, and I say, you know what, it is going to be.net. It is going to be Blazor web assembly. We are going to use a C-sharp nine and we are going to use SQL server, we are going to pull it up, Azure. Well, one of the first things is what is my visual studio solution look like?
    So, I am just going to quickly spec it out. I am not going to explain why, but I am going to have it core library. That is a, you know, dot net standard two. I am not going to go on all the rest of it. Then we are going to have a UI project. We are going to have a data access project, and I do not, I am not going to worry about my handwriting.
    I am just going to do this. And then we're going to have, let's see what else, you know, I know that I need some unit tests, so we're going to have a unit test library and I'm going to have some integration tests. These are going to be projects. And so, you know to have him here and unit tests are going to be linked to core integration tests, going to be linked to data, access, and core most of the time.
    And, if I put in acceptance tests, over here, most of the time they are linked to data, access core, and UI. So that is our test coverage. Now I did not put any arrows here. We need to communicate that. Well, the core needs to have no other dependencies. Then just .NET standard and whatever, most stable libraries. You are only as stable as your most stable library.
    So, I am going to make sure that the UI references core, I am going to make sure that data access references, core unit just references core, ah, all incoming references. I like that. No outgoing references for core acceptance tests that let me just finish these. And I finished all of them. Alright. So that is our dependency diagram.

    • 20 min
    • video
    Architect Tip: Versionable Architect Diagrams

    Architect Tip: Versionable Architect Diagrams

    In this architect tip, we’re going to be talking about Versionable Architecture Diagrams! As always here at Clear Measure, we are a software architecture company, and our goal for you is to be able to move fast, deliver quality, and run your systems with confidence!
    Having architecture diagrams that work for you as part of that. Now we want to have beautiful diagrams just like this one, but doing them in Visio, it just is hard. So, let's get into it.
    The first thing that we need to do in order to get started with these types of diagrams in this method in a versionable fashion is to install a few chocolatey components. And it's really easy. You can download the files. If you've ever used chocolaty before, you just run these components, make sure you're in a power shell window that's running as an administrator. After that happens, you open up VS code and install the PlantUML extension.
    We already have it installed here, so it's ready to go. And immediately after that, you can start creating your own diagrams with PlantUML. Now you can use PlantUML, wrong or you can use some C4 extensions, which we'll talk about. Now, it starts with your development process. And if you've gotten into our onion DevOps patterns, then this will be very familiar with you. But this is essentially describing a DevOps pipeline for a particular application or for a particular team.
    We have our git repository; our integration build, that kicks off a series of environments that we have with our TV environments or multiple or UAT manual testing, environment production, pushing telemetry over to Azure, application insights, and then all of the deployments, getting the deployable packages from Azure artifacts. So we want to describe this, but we don't want to mess with Visio or any of the diagramming tools and so we can do it in text. And this is that diagram in text and we're using the helpers the Azure plant, UML extensions and you can get those on GitHub.
    We define an actor, which is a developer, and we just start using the symbols and their objects. And these are methods essentially. And so we're using the symbols were defining the structure and then we're defining the process. The actors, the developer makes a change and pushes to Azure DevOps. And you can see each of the different objects is related either forward or backward with the single hyphen or double hyphen. And we can describe what they're actually doing.
    The text that we use to describe them is the text that is painted on the arrow between the symbols. And so the text on the left is translated easy, super easy versionable it's all text.
    And so the next type of diagram is the system level diagram. Example is if you're developing a new system, you already have an ERP system that a supplier uploads a file to and you want a customer to receive a text message. So we're kind of sketching out this new application that might have to consume some messages from our ERP system. OK, that's the system boundary. And so the system level diagram for this new application is going to be really, really simple.
    We define two persons. And again, we're using the C4 extensions defined by Simon Brown. And there's several supporters of Riccardo's, one of those that has some extensions out there for pommel and you can call it plantUML, you can call it pommel. But we're defining our extensions or defining the relationship between extensions. And that's it. We just hit Alt D and run the diagram. Easy as pie. We can change the layout left to right and it just kind of realigns and does its best to guess the direction of the diagram.
    But that's it for the system level. OK, so now that we've done the system level, maybe we want to zoom in to how we're going to structure this new application. The next level is the container level in C4, the container diagram. So we have this new application. Let's zoom in and the

    • 7 min
    • video
    Architect Tip: Blazor Circuit Tracking

    Architect Tip: Blazor Circuit Tracking

    Welcome to another architect tip. I am Jeffrey Palermo, your host, and we are going to be talking a little bit about a tip specific to the new Blazor framework for .NET Core. We talked to Steve Sanderson, the original inventor of the first version of Blazor on the Azure DevOps podcast recently, so you might be interested in checking that out. What we are going to do here is talk about how to track your circuits and how to know how many people are using your application and your distribution. This one is going to be specific to a tip specific to the server side because your client running in JavaScript is the same and it is going to be running in a browser. Then the Razor components are going to stream over web sockets, the changes to your screen. As you look at your development tools in your browser, you are going to see a bunch of binary messages going across. Those are the actual changes to your screen and that is the communication.
    Now, if you're running in Azure and you are running with multiple instances and you have some custom auto scaling rules, which you're going to want to do, and you're going to want to custom auto scale. Then you are going to have the question, how many of the users are tied or how many of the connected circuits are tied to each of the web servers? Because you are going to be using sticky sessions. That is the ARR Affinity as Azure calls it. And, so once a user gets assigned by the load balancer to a particular web server instance in your app service plan, it is going to stay there for the life of the session, which is the circuit. So, you are going to want to know, okay, how many what is my distribution?
    Do I have one that is overloaded? If you have scaled up, that does not necessarily cause the user sessions to be more evenly distributed. Once a user is assigned to an instance it is there. You can scale up after the fact, but that is only going to affect new users that come in after you have scaled up.
    If the original instances are already overloaded, they are going to remain overloaded unless you do something to specifically force the closure of those circuits, and then you can have the auto retry logic. So, what you are going to want is to graph in your dashboard and application insights.
    That looks a little bit like this and, on the top right you can see average open circuits and then bottom left, you can see the average connected circuits, and, on the bottom, right is how many circuits have disconnected over time. Then it is often also good to track them memory of each of the instances of your application.
    We can see that on the top left in this example, and you do not get this out of the box. You are going to need to emit some custom metrics, to application insights. I'm going to show you how to do that with Blazor server side and as I go over to visual studio, just to show you that there is a class in Blazor called circuit handler, and you can find it in Microsoft.ASPNetCore.components.server.circuits.circuithandler. In .NET 5, that is going to be really easy to find a refactored with .NET 3.1.8 you are going to find that in the components.server.web assembly nuget package. You are going to have to grab the WebAssembly nuget package to get something specific to, Blazor server side, but that is where it is. You're going to inherit your own class from this, register it in your services collection, and you can do with it, whatever you want, because you're going to get events for circuit up and down.
    Look at what we've done here, we've created the names of the different events and we've created a dictionary for open circuits and then a timer so that we don't, we don't emit this metric every single time it fires. Then the events that you get are circuit opened and circuit closed.
    Look at that with circuit open, it is going to be called for us by the framework. In our dictionary, this cir

    • 5 min
    • video
    Architect Tip: Blazor

    Architect Tip: Blazor

    Welcome to Architect Tips with a tip so that you can get your team to move faster, deliver quality, and run your system with confidence!
    We will talk about the architecture of Blazor and some of the key differences if you are running a Blazor application. Before we do that, you might wanna check out Azure DevOps Podcast; for .NET developers who are shipping software with Microsoft platform technologies; go to www.azuredevops.show.
    Blazor is a different architecture; it is a new architecture. Blazor runs on top of .NET Core, and the server-side has been out for several months now. WebAssembly just came out in May, and people are still trying to figure that out. Many applications are being developed already with the Blazor server-side model. I want you to understand the key differences in that model from regular web applications so that you can be successful. What is important to understand is that Blazor runs on top of ASP.NET Core. So, startup, the middleware, all that stuff running it in Azure will be the same. It will run in process, but the Razor components are a different programming model in the UI and are different from your ASP.NET MVC controllers or web API controllers, and it is a stateful programming model. When a Razor component essentially paints a screen, that class will be in memory; it will be on the call stack in memory for the entire time that your user has that screen open in their browser. What happens is when you have that first request to your URL, your web server is going to return a JavaScript file. That JavaScript contains the Blazor client, and it is scanned, so you do not need to mess with that. The client will subscribe to a built-in SignalR connection run by your web application, automatically Blazor publishes a SignalR hub, and every bit of communication between the browser and the server is going to go across that SignalR hub. If you are hosting it in Azure, you will want to use the Azure SignalR service because it is scalable and will take that processing power off your web instance.
    However, it is important to understand what happens and that Razor component class is going to be on the call stack and is going to be alive in memory, that instance of the class, the entire time that screen is on the page, no matter how many times things are clicked, no matter how many times maybe a section of the page is swapped out, that is going to be on the call stack.
    Now, if you do a navigate URL to another top-level page, well, then it will go out of memory and be cleaned up. That is how Blazor server-side works. Every session, every user’s screen, and what a user is doing is resident in memory on your web server, and the changes to the screen are messaged through that SignalR hub with binary messages. So, what is important is the latency in the network connection. If you have really bad latency, then your users are going to see slowness. For instance, if you have 100-millisecond latency, you may need 10 round trips to the server, which is not unheard of, these messages are really small, but if it is 100 milliseconds of latency with each one, well, that is one second. So you have to keep that in mind, that is the architecture.
    Let's now go over some of the settings. When you are publishing to Azure, you will want to make sure that you choose 64 bit because you will be using up more memory. Every one of your agents, every one of your users, keeps that memory on the server and their session, everything they do, and all of the memory keep those objects on the webserver. You will be using more memory as a trade-off for that phenomenally fast development model.
    You can crank out applications so quickly it is so much more productive than JavaScript and the JavaScript ecosystem. Now, you will want to turn on web sockets. Off by default, you turn on web sockets. We do rely on SignalR in the custom built-in

    • 8 min

Customer Reviews

5.0 out of 5
1 Rating

1 Rating

Top Podcasts In How To