NServiceBus on the Windows Azure Platform

🔗Transcription

00:00 Yves Goeleven

Alright. Looks like we're on. Just give people a little bit more time to talk. Well, everyone we're going to start. People at the back, can you hear me? It's fine? Or should I speak up? For people at the back? No response? All right. Okay. See time going up. All right. This time we want to talk about NServiceBus on the Windows Azure platform. I was very surprised when I saw the hands up from Woody in earlier talk, when he asked about how many people were using it, and especially how many people are looking at Windows Azure as a hosting environment. This time, I'm going to cover what that includes. What is support today and what you need to think of when building for that platform, especially that. But first, a little introduction. My name is Yves Goeleven. I'm Belgian. Woody always calls me the Cloudy Belgian. I'm not sure if that's a reference to the weather we get or the fact that I'm working on the Clouds, or the fact that Belgians are considered to be drunk all the time. I have no clue which one it is.

01:28 Yves Goeleven

Furthermore, I have a little bit of a split personality when it comes to NServiceBus. On the one hand, I'm a customer. So I run my own online project called messagehandler.net. But on the other hand, I'm also one of the developers on the team doing the Azure support basically foreign services. So I'm on two sides of the fence at the same time. I have a long history in Azure. I have been using it since it was released in 2008, as a better and I've been on the program ever since. I've also been a Windows Azure MVP for the past four years, getting insights from Microsoft on what they're doing with the platform. So I'm pretty experienced in the Azure. Now, what we're going to cover today is mostly focused on Windows Azure. I assume that most people that are in the room actually know what NServiceBus is and what it does at least from a high level, otherwise, you would not have been here, I guess. But that might not be the same for the Windows Azure platform. So I want to give you an introduction into what Azure platform is. What it means to the applications that you're creating for it or running on it.

02:38 Yves Goeleven

And as well, what is support today from an end service points, this point of view on Azure. And what you need to think of when developing for it. At the end, I just have my deck a little bit. The initial plan was to do tips and tricks session for about 10 minutes. But given the huge number of hands that I saw, when people that are looking for using Azure, I think it might be better spent with the Q&A session where you can ask questions to me. Now, if you don't have any questions, I'll just fall back to the tips and tricks section. All right. So a little tour around Windows Azure. Now, let's start why people are interested in Azure. Why people are looking at it. And there are various reasons because Azure is very attractive to be used as a platform for developing applications. One thing is that it's fully automated. I heard Charlie said earlier, that deployment automation is a troublesome fact in this environment. Now, this has been completely solved by Windows Azure platform. Everything is automated. Deployment of your applications.

03:45 Yves Goeleven

But also deployment of the network infrastructure of the VM's of your firewalls, your DNS infrastructure, everything is automated. You just have to specify what the platform needs to do. And it will perform all the necessary operations for you in a matter of minutes. It's also very scalable. It's actually huge. It's one of the biggest networks on the planet. And you can get any amount of capacity inside of that network that you like, or at least that you can afford. That's your only limit. What is also very interesting is it is elastic. You can release resources again. When you have a normal on premises data center, you have to provision capacity based on your peak consumption. But if your peak consumption is only at the end of the month or only during a certain season, well, you're wasting a lot of capacity during the other months or the other parts. And Azure is that very interesting because you can just simply release the resources again which has a cost reflection. When you can do the scale in operation or when you can release resources, you're effectively saving money because you don't have to pay for them. It's a base pre-use model. And that's also very interesting. Finally, which often makes Azure no brainer is for global deployments.

05:06 Yves Goeleven

If you're a European company and you need to deploy something in Asia, it's very hard to do that with on-premises or your own data center. You would have to build it there. You would have to maintain it. You would have to set it up. Now with Azure, it's just simply a click and you have an operating website in Asia. So those are the main reasons why people are looking at Azure. If there are others, you can ping me afterwards, I'll add them to the list. Now all of this goodness, is coming at a cost. When people make the migration from an on-premises environment to an Azure environment, they have a lot of surprises for you. It's not simply picking up your application and port it to another environment. You have to learn completely new development paradigms. You have to think differently in this environment. And also, you have to be aware about the infrastructure. Something yet, you typically don't have to or not at least have to think about too much when you're in your own data center. Because this infrastructure is quite different from what you'd normally run. NServiceBus is helping you a lot with this learning curve. But there are still some things that you need to keep in mind. And that's what I'm going to be focusing on for the majority of the time.

06:25 Yves Goeleven

Now, let's first get an idea what this means, this huge platform. I said, this is one of the biggest networks that I know of. Currently there are 13 different data centers across the planet that are all encompassing Azure. So if we talk Azure, we're actually talking about 13 main data centers. And I believe 26 or 30 something additional data centers that are used for content distribution. So it's 13 for compute, and 32 additional data centers for storing files and bringing them closer to customers. These are spread across the planet in different regions that are optimal for Microsoft. You might notice a lack of data center in Africa, but that's because they're not doing that much business over there. But the rest of the world is basically over it including upcoming data centers in South America and in Australia, as well as, Japan. Though I think those are not officially open yet, but they should open in the next few months. But early adopters can already get access to the data centers out there. If you can get into the early adopter program, you can host that over there. There's also one in mainland China, that's a special one. We cannot just deploy there because of government regulations in China.

07:42 Yves Goeleven

So if you want to have access to the China data center, you have to pass through Microsoft and apply and have all kinds of legal checks before you can use that one. But it might be interesting for some businesses to actually have a presence in China. That's a bit different. Every one of these individual data centers is really, really, really big. This one is 50% of the Dublin Data Center. What you see here is a multi-storey building while they were constructing it. This is a top level you see the containers, that's the air conditioning system. So underneath every of those containers there are other containers containing the compute resources. So it's a building, or it's not a building, it might even be just simply containers deployed in a field somewhere. That might also be the case. But there are specific containers put into the building. I actually have a picture of typical container. Every container has about 2500 physical machines in there. This is commodity hardware. That's a nice word for saying crap water.

08:47 Yves Goeleven

It's less than your typical laptop is actually RAM. But there are many, many, many of those that is very little redundancy in the inside the containers. So the idea is we give you a lot. And it's normal that machines fail. Software should handle the fact that the machines fail all the time. And if machines die, we won't repair them. We just let them there. That we will just move yourself to somewhere else, give you another machine. If a large part of the container is dead, we will pull out a container and put in another one. Because it's commodity hardware. They're not going to do any kind of manual intervention or at least not even any kind of intervention on the hardware part. Its just use the box, let the box work. If the box is dead, we pull it out, plug it in your box. That's the concept. And there are many of these boxes inside the data center. So you have to think about every data center as being hundreds of 1000s of physical servers just sitting there for you to grab.

09:50 Yves Goeleven

But at least you don't grab the physical service, you put Virtual Machines on top. That makes it a little bit easier. So just to illustrate how big it is. There are 13 data centers right now. 13 of these regions, actually one region can compose multiple data centers, like Dublin has four data centers, not just one. So there might be multiple data centers. And there are 321 IP ranges that are publicly available. So there is a list of these, you can download them, changes every day. About 250,000 customers today with over two million Virtual Machines running in there. And 25 trillion objects stored in storage facilities. So huge. You as an Azure customer are somewhere in. You're not unique, you're just part of the club. That's very important. On top of that infrastructure, there are additional services that are operated by Microsoft, and there are 200 of those for all kinds of things. And NServiceBus uses a few of them being the storage facilities. Being the Azure NServiceBus facilities and a few more things. But beside what NServiceBus was using, you also have access to a lot of different services. Now, it's important that you know that these services are Microsoft's and not yours.

11:11 Yves Goeleven

You do not control it. If you take a SQL database from the services part, you cannot find unit. You do not have a lot of knobs and twist to actually control the environment. That's important. You're not in control, Microsoft is. So what are the implications when designing a system on top of this environment? The first set of emblem applications are related to the fact that it's so big, it's huge. One thing is latency is Given. If one server of yours is on the left of the data center, and the other guy is on the right of the data set, even if you only have two VM's running, it might take a while for them to communicate to each other. It might even physically be in different buildings at the northern side of the city. But you don't know. Just you're hosting two VM's and you have no clue where they're. So latency is something that you should expect. Another thing that you should expect is machine failure. Machines fail all the time. Especially the physical hardware is failing all the time. But you don't necessarily notice that because you're running Virtual Machines. And the Azure fabric is moving you around to better hardware or at least operational hardware.

12:34 Yves Goeleven

But you might notice it when you run. For example, a VM, it might have to reboot in order to get to another physical machine. So you might notice it in your application that your machines might be unavailable for a while. That's also reason why Microsoft explicitly says there is no SLA for single machine deploys. So if you have a single machine expected to die all the time, like all the time. Few times a month, you can expect it to go away. And then it comes back up somewhere else. If you run two machines, they actually have some business logic in place that will make sure that not both of the two machines will reboot or recycle or be moved at the same time. So always run at least two machines. Even for people that are using Virtual Machines Infrastructure. Anybody in the room who's running Azure Virtual Machines? Yes? You know there is no SLA for single VM? You always have to run two. Whatever you do always two. Network partitioning is also normal. So machines are in a very big network far away from each other. The routers that are in place are no hardware routers. They are software running on these regular machines. So they fail all the time as well.

13:54 Yves Goeleven

But it's important for you to know the network infrastructure itself is just software on VM's and it will be taken down every once in a while. So network partitioning happens a lot. And this implies that distributed transactions are actually not usable inside this kind of network. And it's not limited to Azure. We have the same issue in another huge network like Amazon, you'll have the same problem. DTC, just the fact that it needs to communicate with so many nodes across the network and it assumes that the nodes are there, will imply that you will a lot of in-doubt transactions or rolling back transactions. Just because of that is never partitioning inside in it. So DTC is very flaky, even when you can use DTC on Azure VM. Just take it from me, don't use it. Think no distributed transactions.

14:53 Yves Goeleven

The second set of implications is related to the fact that you're running many things on Azure service basis. That means that you are not in control, Microsoft is in control. And worse, Microsoft does not trust you. You might not like Microsoft, but they don't like you either. That's a Given. Now, this has a lot of implications on how the consumption of those resources is perceived. And first thing is that the individual capacity of any given resource is rather limited. If you use an Azure Storage queue, you should not expect the same performance as you get from an Amazon queue that is yours. So you should not expect the throughput of 5000 messages a second for one queue, you should expect a throughput of a few 100 max. The documentation of Azure Storage queue says that you cannot do about 2000 operations per second for any individual queue.

15:54 Yves Goeleven

But for any Given message, you need at least three operations to put it on there, get it off there and delete it again. So you will be looking at 500, 600 messages a second max for one Given resource. How do you solve that? Well, just by getting more resources. Design your system in many small services that actually all using their own queues, and you will run into these issues a lot less. But even at other levels inside of the infrastructure, you have these kinds of capacity limits. For example, at the storage account level, which is the group of queues that you have, you also have limits, you can only do 20,000 operations a seconds. So basically, around five 6000 messages a second, for a single storage. But you can get as many storage accounts as you want. So you can always get around that issue. These limits are artificial. So even though the infrastructure of Azure can handle a lot more, they just want to be sure that everybody gets its piece of the pie. And they will artificially topple you whenever you need.

17:00 Yves Goeleven

That's the throttling infrastructure. This applies to any resource in Azure that you use. This applies to queues. This applies to NServiceBus. But this also applies to your database, your SQL database. So your SQL database, you can only expect a few 100 queries a second from a single instance. You cannot expect the same performance as you get from a SQL server that is yours. But on the contrary, you can get as many SQL databases as you want. So if you want to scale your application, you need to be sure that you can actually partition your application correctly and use multiple resources. Now, furthermore, your resources are being moved around all the time. So especially in storage is pretty dramatic. Your stuff gets moved around every 15 seconds.

17:48 Yves Goeleven

So you have data and storage. And the storage infrastructure has been built that way that it moves all the data around based on usage patterns, every 15 seconds. That also implies that you might be toppled every 15 seconds, if they decide to move data around, that's yours. You want to perform queries or operations on it, they might push back a little bit like come back in a few seconds, and we're done moving your stuff. This can again be applied to any resource that you're using inside of Azure. The performance is pretty unpredictable. I've heard it a few times that people are using Azure Storage cubes, for example, or Azure NServiceBus queues, and they see these peak moments where they can get good throughput, and they see few minutes that they can maybe get one or 10 messages a second. That's sadly enough, also normal. That is because Microsoft is moving resources around based on usage patterns. It's not just your usage patterns, because it's a multi tenant shared environment. So you might be moved because one of your neighbors on the same machine is being aggressively usage. That might be the case. That's very important. Is a very different mindset especially when you're moving an on-premises application to the Clouds. There are these Givens that you thought were absolutely normal in the past that certainly are not normally, you have to think about it.

19:13 Yves Goeleven

Furthermore, when you're being moved or when you're being toppled, you will actually just get exceptions from your infrastructure. We call these transient exceptions. The main guidance is that just retry. Because by the time you can send another request to the infrastructure, they might have already moved you. So if you get an exception, just try it for a few times. Another big implemented implication on this as a service model, is that Microsoft absolutely does not like you to lock their resources. They don't want you to lock because that way, you could basically create a DDoS attack on them. Just lock everything and the entire service would go down if many people will do that. So Locks typically in many services you cannot take Locks or the Locks are very short in duration. Do not expect to take a record Lock of a day in SQL database, you can't do it. While you can do that on premises if you really would like to do it.

20:15 Yves Goeleven

Further implication because many services do not allow you to take Locks. That also means that many services do not support local transactions either. So for example, Azure Storage, you cannot take Locks on records there. So you can also not get any local transactions that span multiple items. That's important. One single operation is atomic by nature. And they will guarantee that one single operation in the backend is atomic and will succeed as a whole or fail as a whole. But when you cross multiple records in another table, you cannot get any locks on. So you cannot guarantee that you do not have local transactions. It's very, very important in your design. SQL is a little bit different. Because SQL has transactions built into the DDoS protocol itself. So there you can get local transactions. So if you're using SQL Azure you can get a local transaction. If you decide to go for Azure Storage tables, you can get local transactions. You have to think about that when you design. It's not really a problem. But for many people that come from the on-premises world, they are so used to having this local transaction. And they're so used that this transaction scope is magically applied across multiple records. That does not work in Azure.

21:32 Yves Goeleven

So how do you work around this? How do you change the code to be able to deal with this? Well, and NServiceBus already does a lot for you. We abstract, quite a few of the things that are troublesome in nature. So far, we haven't solved everything. We're still building things like the node etc, that Woody talked about that can help. But you still have to be aware of the fact that this is a different environment than what you might be used to on-premises. And it's better that you know it and code against it if needed. One thing that you have to do is retry, retry, retry, retry, retry. Whatever happens in Azure if you're being throttled, if you get the transient exception, or if you get some kind of pushback from the system, just try again. But don't start hammering it. Don't start bashing it, because there was just pushed back a lot harder. You take some back off, you retry. If the call does not exceed at that point, you back off a little bit longer, you retry again. And NServiceBus does it for you.

22:39 Yves Goeleven

Based on the native transports that are in there, it's best that you choose one of those transports that actually have retry capability instead of relying on local transactions. I will come back to the specifics of those transports, which are as a NServiceBus and I just started skews later in the deck. But I do not advise you, no matter where you are in Azure to use Amazon queue. And that's the bottom line here. Use another one that does not rely on transactions, but that uses retries to emulate that. We also have features called First Level Retry and Second Level Retry. These are great measure. Just keep retry, and back off. That's what Second Level Retry does, it backs off a little bit and now retries later. Use these features simply to get that retry mechanism going. Now, retry has a nasty side effect. And that is the fact that you can get one message more than once.

23:35 Yves Goeleven

In Azure, you have to take into account that you need to take care of idempotency. So we have the upcoming no DTC support, which will in certain scenarios, we'll be able to make sure you don't have to think about it. But in many scenarios, like for example, when you're using Azure Storage, when you do not have local transactions at all, we cannot use the no DTC support that won't work. Again at that moment you have to think about it. So to be safe, just think about being idempotent? Then how can you be idempotent? Well, the easiest way is to make sure every messagehandler implementation only does one operation. Make it atomic. One operation is always guaranteed to be transactional, so that it either succeeds as a whole or fails as a whole. If you can limit your application logic to only perform one operation on for example, Storage, then you're always good to go. Now, if you need to implement sagas, you also need to think about that. Saga state updating alone is already one transaction. So it's one operation. If you do other stuff, if you would implement table insert or something inside the saga handler, then you're already in two separate transactions. So don't do that. Just update your state, send the message and go. This is general good advice given by Woody in his talks anyway. But I know a lot of people sitting across that row in replications.

25:08 Yves Goeleven

So that's why I'm telling you. Saga is also great mechanism if you have to coordinate multiple local transactions. So they can keep an eye on what the state of the local transaction says. And if there is anything going wrong, they can perform compensation logic on the data in order to make things right again. So they can help you actually operating across multiple local transactions, or atomic operations depending on service that you use. You can also check for retry, so maybe check for side effects to figure out did I get this message before or not? I think there is a talk on event sourcing tomorrow. It's a great technique to actually handle this kind of scenario. There are more options. I have some links in the slide deck, Shimmy, get it on the end of the conference. And there are all kinds of links in there, which I'm now referring to with more options for handling with idempotency.

26:12 Yves Goeleven

Last one is never ever, ever trust your disk. Do not put anything on your C drive, D drive, E drive, whatever drive that you want to keep. The fact is machines die, they die all the time. And if you put something on a disk, what typically Azure does, is that just leave the machine there that are alive, they don't care, but they just don't use it anymore. They give you a new machine. Anything that was on the disk of the original machine is not on the new machine. So it looks like you've been formatted basically. All the data that's on your local disk might be gone. You might not notice this tomorrow, this might happen in six months. But anything on the disk might disappear at any given time. That's very important. Instead, you should put stuff in storage as much as you can. For the people using Virtual Machines in Azure I already said that there is no SLA on single VM. But there is on the disk, because the disk itself will be persisted remotely as well.

27:19 Yves Goeleven

So if you can reconstruct your machine from the original disk, then you're good to go with VM's. If you can't do that, but it's pretty hard to Windows to actually recover a VM just from the original disk. But technically, you can. Now storage itself as a 99.99 SLA on availability. I heard recently that they have 100% as a lay on data retention. So they actually promised to never lose the data. This did not used to be the case in the past, but they have some additional measures that they can always reconstruct your data. So you're safe when you use Storage as a data source. You have Local Redundancy, that means that you have additional copies in the same data center of your data. You can also have Geo Redundancy. That means that if you for example, hosted in Dublin, there is a copy of your data in Amsterdam as well. So you can fill over there.

28:17 Yves Goeleven

That's an entire topic on its own. If you want to know more about how that works, just come see me after the conference or after the talk. And I'll drive you through it. So now you know the bad parts. Okay, so now we're going to look at the different options that we have. And how we can use a NServiceBus on these different options and how we should apply it to our code base. So basically, there are three hosting options. One is called Cloud Services. That is the model of all hosting options. Anything else that I will discuss later is all built on top of Cloud Services. So Cloud Services is the most important part of Azure to understand. The second one is Virtual Machines. So this one is very familiar for most people, it just looks like Hyper-V, and you just make a new machine, you boot it up and you start using it.

29:09 Yves Goeleven

And then you have Azure websites. And Azure websites is basically continuous deployment environment for web sites only. So let's talk about Cloud Services first. And Cloud Services basically is a big set of VM's. And all of these VM's are stateless. So the disk in the VM is not even persistence, they don't even bother. They don't put it in Storage. It's just ephemeral. You can lose at any given time. But on the disk itself has been created based from a template. And the template is called a role. You can actually compose those roles yourself so you can define what the template should look like. I will show that in a few seconds, how you can. Finally on top of that template, they also deploy additional services inside the machine. So those are specific to Cloud Services, for collecting diagnostics information, for sending health information towards you. Those kinds of things to integrate with the Azure platform itself. So that Azure can monitor your environment and automate everything. So if a machine is not reachable or it dies, or it has issues, they actually can identify that, take the machine down and give you a new one.

30:26 Yves Goeleven

Now, let's switch to Visual Studio for a moment. Just to give you an impression of what you have to do. Okay, this one. So you can see that? I'll try to duplicate. Can I duplicate? I might need to kill PowerPoint here. So can you see this a little bit? Maybe a little bit small? But on the left hand side here you have the definition of what a role looks like. So this is a Cloud Services project. And inside of the Cloud service project, I have defined two different roles. One being e-commerce and one being the host. This is actually the wrong one, I'm sorry. I need this guy, they're five rows. So all of these five entries, they are actually role template definitions, they say what the machine should look like. And inside of these templates, there is a definition file. That is an XML file, it's quite old. That defines what the network infrastructure for that environment should look like. The first role is a web role. That means that IaaS is installed. And on that we have a site and on that site, we have an open port at port 80 to accept HTTP requests.

31:47 Yves Goeleven

And every role has additional configurations so you can put a lot more in there that say, what kind of ports one need to have open on the firewall. Do I need to put in a load balancer? All that kind of stuff is defined in this template, is based on this template that the Azure infrastructure will actually create your data center part. They will create it whenever you make new deployment or such a Cloud service. I'm not going to dive deeper into that. But it's important that you know that you do not start from creating Virtual Machines yourself. You just gave them an XML file with the definition of the network of the machines and what code should be deployed on the machines and you give that visual. This is what it looks like. So you create this package in Visual Studio, or manually, you can do it manually if you want to. And you just upload it to the Cloud. The fabric control, which is a part of the Windows Azure platform, it inspects the XML definition and it will start building your infrastructure. So it will look inside of the data center and find free VM. So free space to put your VM's.

33:01 Yves Goeleven

It will actually select the machines that you will be hosting on and it will be deploying the infrastructure, everything on top of that. That basically means that it does a full windows install from scratch every time and then run your scripts on top of that. So it takes quite a while. A typical deployment of a new Cloud service is about 10 to 15 minutes, you might typically expect. So this is not something instant. But that's logical, because you're actually configuring the entire data center that it's not just your application. So we have this machines provisioned. And then only at the last step, will they be putting your machines into the load balancer and start accepting requests front. But this is important. They first built your machines, and when the machine is healthy, they will put it into the network by reconfiguring the DNS infrastructure to allow traffic to be sent to your machines. But what happens if a machine dies. If a machine dies, Azure doesn't really know if the machine is just unreachable or if it's really that, or if software is the problem is hardware is the problem.

34:21 Yves Goeleven

They don't really know but they don't really care. They will just ignore your machine. Running or that whatever, it will just be ignored. And they will give you a new one. Sorry, I was too fast. They will just give you a new one and reconfigure the network load balancer to send traffic elsewhere. That's important. That's also the step where you lose the data on your disk. To make use of this environment, we have specific packets foreign NServiceBus that's an additional downloadable package on nougat. Which is called the service hosting is Azure. This is only for Cloud service. You don't have to use this for when you use websites or when you use VM's. This is specific for Cloud Services at only targets at integrating with these additional agents that are deployed on the machine. It's called a toll environment for the people that know the Azure SDK. And it just simply integrates with that. In the past, we also had some diagnostics integration. But that was mainly because of Visual Studio not setting it up for you. Today, Visual Studio sets it up for you when you create a new Azure project.

35:31 Yves Goeleven

So we don't have to do it anymore. So we removed. But the integration with the runtime and the configuration of vitamins is still there. How do you use it? Well, basically, you need to integrate a little bit DNS servers row entry points with the SDK's row entry point. So you have this default class work at all, which inherits from role entry points. And in there you called and service role entry points equal start and stop on the same operations. Why did we do it this way? Well, in the past, we had our own role entry point, and you didn't have to go this little piece of infrastructure. But that also tied and NServiceBus to the Azure environment. The Azure SDK that's available on nougat is not really a problem. But there are two assemblies that Microsoft is shipping not as part of the nougat package, but they are being shipped as part of Visual Studio, especially the tool version in Visual Studio would make a difference. And a lot of people got tripped up by that, because they had a different tool version. And then suddenly, and NServiceBus assumed that was another one.

36:39 Yves Goeleven

And you had all kinds of assembly binding issues, and the people tipped into. So we decoupled completely from the SDK. And that's why you need to integrate it this way. If you want to use an endpoint in Azure, have different profiles called Azure worker. Basically is the same as a publisher profile that you know from the regular host. But it has all the default. So it defaults to Azure Storage for most of its operations. So if needs to store subscriptions, it will assume that it's going to store it in Azure Storage instead of the default RavenDB. That's the difference. The configuration settings because you don't have to specify any configuration settings by default, but the configuration settings are all pointing you to your local emulator to your local development. This is a historical choice. I regretted a little bit because the local emulator is crap. That's what it is. So if you really start thinking about doing a real project on Azure, stop using the emulator and configure it manually the settings. What you have to anyway, because all of the resources are yours.

37:53 Yves Goeleven

The storage accounts, you need to specify them one by one depending on what you're going to use for this post. Another side effect of this Cloud Services environment it assumes that you will build a huge application for every role that you define. So basically every Visual Studio project that are shown, they will assume you have at least two machines. So for this video store sample, which was five rolls, that will automatically translate to 10 machines. And if you design systems like we are used to with a lot of small components, it's not hard to get to 70 AD, whatever machines, and that's a costly affair. That's not what you want, at least not in the beginning of a project. It's fine when we need to scale out or when we grow. But it's not fine when we have to start out especially not have your startup. So there is this as a host profile that allows you to combine hosting of multiple endpoints on a single machine. We're already late on time. So I'm not going to give you a demo on this. It's a little bit advanced, but there are samples that you can use. VM's are also Virtual Machines very similar to Hyper-V. But they are running on top of the Azure Cloud Services environment.

39:18 Yves Goeleven

Well, they actually have to apply to the same rules as anything that you do in Cloud Services. Even if you think about it conceptually as a regular VM. The only difference is that the disk are persistence. The disk got in storage, so you're probably not going to lose them. But it has some side effects on how they respond. That is no, by default no local write caching, So latency methods. People complain about IOPS performance and Azure VM's all the time. But it's normal because they have to cross the network to actually persist every right operation, let's know. So instead of complaining about one machine performing badly, just grab more machines or get up more disk, that's always the same ID. Attach more disks. Grab more machines. Every single individual resource is limited. And you can only get around that by having more resources. You can use the regular and NServiceBus host for that, that's the same thing as what you're used to on-premises. Only thing is that you should not rely on a DTC.

40:19 Yves Goeleven

So you should swap out the default transport for either as a store excuse, or as a service. And also don't put anything on local disk. Think about that, you have to be scaled out by default. Websites, it's basically IaaS as a service, you only control the code, you do not control anything on the machine, nothing, not even the IaaS configuration. But you can hack it in but by default. Use this the same way as you would use a self hosting environment. But you can only use transport and storage, that are publicly available at remote because you cannot control any of the configuration settings on the machine itself. So you cannot purchase machine. You can't install even to be on Azure website machine. And publicly available because Azure websites is a different type of service, and you cannot put it in the same network as another Cloud service. So you have to use a public service. You cannot put something on a VM and start using it.

41:25 Yves Goeleven

Alright, transports, I already mentioned these, the guys that were typically advising to be used on Azure services on Azure Storage queues. You can also use any of the other transports if configured correctly. That means that they are configured for failover in clusters. You do not rely on the local disk, et cetera. So it's quite some setup work. But you can use additional services on a VM if managed properly. I just started skills, main advantage, highly reliable, extremely cheap, extremely big, you can get up to 500 terabytes for the queue if you want to. It's HTTP-based, so it has a lot of latency, and use a queue peek Lock as a retry mechanism instead of transactions. And important to know, it's only seven days for the message can stay in the queue. You can configure it on your endpoints. You see it's just using transport as a storage skills as a specification on your endpoint config. You provide the connection string and you have a bunch of additional configuration settings that are optional and are found in documentation. NServiceBus, it's reliable transport.

42:49 Yves Goeleven

It supports queues construct as well as topics and subscriptions, for we use that internally for the subscription mechanism and services. Capacity is less, only five gigabytes per queue. But there is no TTL on the messages. So you can leave them there forever if needed. It's TCP based, so it has a lots lower latency. It also uses queue peek Lock 40 tries, but it makes you think it's using transactions. Do not be fooled, it's not a transaction. It's a cubic Lock mechanism. And it has a lot of additional features that you can make use of. But it's relatively expensive. It's about $1 for every million messages, but you have to pay this. While storage is extremely cheap, I think it's 100 of that cost. Why not million, but I believe. Same way to configure it using transport as a NServiceBus, just a different connection string. You have to get that connection string from the management portal over here. As a NServiceBus has a lot of additional features. Some are applicable in NServiceBus and some are not. The applicable ones are duplicate detection. So you can get d dupe from Azure NServiceBus if you want to. It has an impact on your throughput, so it will lower throughput but you get duplicate detection. Partitioning is a very important one because it will actually bundle 16 cubes into one logical cubes.

44:16 Yves Goeleven

So you do not have the capacity limit on one cube but you have the capacity limit of 16 cubes. So it's basically a bigger pipe instead of having one, so that makes sense. Message ordering can be turned on so they will guarantee the order, if you need it. It's also affecting your throughput, obviously, because I need to buffer up messages to source them in the correct order. It also has that lettering mechanism that we fall back to when we cannot reach the answers was error queue. And it also support batch operations, I think that's a no brainer. It improves throughput quite a lot. But what is not applicable is session. Sessions basically means that messages for the same session ID will always be routed to the same node. But it's only usable for when you have to send larger messages than the max capacity of an Azure service message, you will split it up and send them all to the same node to be aggregated again. With insight and services, we have this other construct called the database that we're using for that, which is actually routing the larger message bots through Azure Blob Storage instead of through Azure services.

45:27 Yves Goeleven

So we're not using this feature, and it won't help you by turning it on. Persistence, default as a Storage. And Alternatively, if done well, you can put your own RavenDB on a VM or your own SQL Server. This is found in the NServiceBus Azure main package that you can use for configuring storage. What you need to turn it on if you want to use it inside of on-premises host. There are a bunch of extension methods for every part of NServiceBus that needs to be swapped out like subscription storage size, storage database et cetera. And every individual entry also has an entry in config where you can specify your connection strings. More details in the documentation. All right. Do we still have a few minutes left for Q&A? No, no? Okay. Then we will do the Q&A after the talk.

46:27 Yves Goeleven

You just come to me if you have specific questions. I did not intend to scare you away from Azure. But I do know that there is quite a lot of surprises when you're used to working on-premises and you go back to or you go to the Cloud, you suddenly find out that you can't use DTC, that you can't use your disk, that your machine always dies. All of these things if you're prepared for them, if you know about it and keep it in mind in your designs, it is no issue. I've been doing it for years now. It's no problem. But if you're not aware of it, it will be a problem. Okay. So we'll end up here and if you have questions come over to outside.