Cloud as a Story - Vunvulea Radu

Usually I don’t write posts about this kind of things, but last week I saw an update that makes our life better, especially if we are working with Service Bus or Event Hub. If you had the opportunity to work with one of this messaging/event system and when to production with them, I’m pretty sure (99.99%) that you had at least one exception from the messaging system that was very vague. A large system is not using only one Topic or Queue from Service Bus. But in the logs you can end up easily with a super duper generic exception, where you might not have all information about namespace, resource and so on. Because of this you start to write in the logs information from the ‘connection’ class to be able to log all the information that are needed. Once you get an exception from Service Bus, you usually check the status of the service, look inside the code and try to find our what is the root problem. Sometimes you find the problem and you are able to fix it. I’m happy in the moment w...

In April 23, I was been invited by ADSEC to speak about IoT at their annual event - ITDevConnect . I decided that I should talk about what we need to take into account when we develop an IoT framework from scratch - and why it is so important to keep in mind that there are out of the box framework for this (like Azure IoT Hub ) that can be used with success.  You can find below my slides. Feel free to contact me if you have any kind of questions. The Real Life Story of an Iot framework,ITDevConnect 2016, Bucharest, Radu Vunvulea from Radu Vunvulea

In this post we will talk about a performance problem that occurred in an application that is using Service Bus On-premises. But the problem and solution is applicable also for any other system that is using not only Service Bus On-premises but also Azure Service Bus. Context We have an application that process a specific type of messages that are coming through Service Bus. Our application has a dedicated Topic that is used only by them. A Subscription from another Topic forward automatically the messages to our application topic. The current requirement requires that we need to write in logs all the messages that we are reading from our Application Subscription, even the one that we don’t need to process. The system that push messages to our Topic, is pushing a lot of messages to our topic, even messages that we don’t need to process, but because we need to log all messages that we receive we add a filter to our Subscription to receive and consume only the messages that we c...

This days I saw an interesting question on internet. The response is interesting and should be well known by everyone that is using Event Hub or other services from Service Bus over AMQP protocol. Question: Why the connection is not closing when I call eventHubClient.Close() method? var factory = MessagingFactory .CreateFromConnectionString("@#$%"); var client = factory.CreateEventHubClient("rveh"); ... client.Close(); // or client.CloseAsync() By default, the communication protocol that is used by Event Hub is AMQP. AMQP protocol is using a connection over TCP. Opening and closing a AMQP connection is expensive, but the good part of AMQP is that we have a session that can be persisted and reused between different requests. When we are calling "Close" method, we are only notifying the MessageFactory that we don't need anymore the connection. It will not trigger a close/delete connection between our machine/system and EventHub. MessageFactory...

A few days ago the public preview of Azure Service Bus Premium was announced. The first two things that people usually check at a new service like this is price and the added value. In this post we will talk about them. Added Value The biggest things between the standard offer and Premium is the dedicated VMs that are reserved only for the end customer. Each VM that is used by Azure Service Bus Premium is isolated from the rest of the customers and will be used only by him. This means that the performance of the Azure Service Bus will be predictable. This is a very important quality attribute, especially when you need to know exactly how long it takes for a message to arrive at final destination, when latency and throughput needs to be predicted. When you decide to use the Premium offer, the storage engine that will used behind the scene will not be the standard one, used by Service Bus, but the new one, used by Azure Event Hub - so called Jet Stream. In this way, we can have ded...

In this post we will discuss about Azure Service Bus Topics and Queues, with a special focus on Peek and Lock feature. Introduction Azure Service Bus is a messaging system that allows us to send messages between different systems in a reliable and easy way. A lot of concepts from ESB are implemented by Service Bus, allowing us to do do magic stuff with messages. There are two ways to consume messages from Service Bus Peek and Lock - locks a message for a specific time internal and notify Service Bus when we want to mark the message as processed (removed from Service Bus) Receive and Delete  - once a message is received from Service Bus, it is also deleted automatically from the messaging system Peek and Lock When using Peek and Lock, by default we lock the message for 60 seconds. This means that in this time interval the message is not available/visible for other consumers. Once we process the message we can mark it as processed. If we don't mark the message as processe...

In this topic we will talk about different protocols and ports that can be used to communicate between our machines and Azure Service Bus Topics. The communication between Azure Service Bus Topic and our machines we can use: AMQP (new and hot) TCP/IP HTTP For TCP/IP connection is pretty clear what ports are used (9351 and 9552). It seems that 9351 is used for inbound traffic and 9552 is used for outbound traffic (this ports may change) The interesting discussion is when we are taking about HTTP. The communication over HTTP protocol is done over two ports - 443 and 80. Each port is used for specific use case: 80 :   is used for outbound traffic 443 : is used for inbound traffic This means that when we are listening to a subscription we will use port 80 to check if a message is available. The same port will be used to receive the message from subscription.  The port 443 is used when we need to send messages to topic. Each time when we send a message to a ...

In one of my latest post I talk about Azure Service Bus and Active/Passive mechanism that works great when you need  fail-over mechanism. Using this mechanism the system can use a secondary channel to send messages in case of the connectivity or reliability problems with the first resources (in our case with our Active namespace). The Passive resource it is recommended to be placed in another region (data-center). In this way there is better protection in a case of a fail-over. The downside of Active/Passive Mechanism is the risk of losing messages that were send with success on the channel. There is a risk of loosing messages when the Active resource goes down. If the system that sends messages over the wire is not capable to send again the lost messages than you could have an issues. This use case it is important only for use cases when it is not acceptable to lose messages. For example in the above example (from the Active/Passive post, when backed send messages to the ca...

A messaging system like Azure Service Bus is great for scenarios when you need to have a reliable communication channel between different components. There are cases when even the SLA offered by a cloud provider it is not enough. For example in the case of Azure Service Bus is 99.9% uptime. In this scenarios we need a failover mechanism that will offer us better reliability. Imagine a system where Service Bus Queue is used to transmit commands from backend to cars. The backend can order to the car to open/close doors or to start the engine. In this scenarios you cannot be out of order for 1h or 2h because the client will not be very happy. You don't want to stay in the front of the car for 2h until the doors will open. What should we do in this cases? A solution to this problem is to look at a failover mechanism like Active-Active or Active-Passive. In this post we will talk about Active-Passive and tomorrow we will talk about the Active-Active. An Active-Passive solution...

One of the beauty of cloud is scalability. You can scale as much you want, without having problem. Of course this is in theory. A cloud provider offer this feature to you, but a developer/architect needs to know how to use it in a way to design a high scalable system. Each cloud provider offer different points for scalability. We need to know very well what this points are and how we can use them in our benefit. As a messaging system, Windows Azure offer us Windows Azure Service Bus. This a powerful service when an application needs a messaging system. But of course, Service Bus, as well as other services has its own limitations. In this moment, the maximum number of subscription for a specific topic is 2.000. If we would have one client for each subscription that the maximum number of clients per topic is 2.000. What should we do if we would have 10.000 clients? It is clear that we cannot have 10.000 subscriptions per topic. We could send an email to Microsoft to ask them why they...

From same version ago, Windows Azure Service Bus supports 'event notification'. This means that we can register to an event that will be triggered each time when a new message is available for us. QueueClient client = QueueClient.Create("queue1"); client.OnMessage( OnMsgReceived, new OnMessageOptions()); ... void OnMsgReceived(BrokeredMessage message) { ... } This is a great feature, that usually make our life easier. By default, when we are consuming messages in this way, we will make a roundtrip to the Service Bus for each message. When we have applications that handle hundreds of messages, the roundtrip to the server for each message can cost us time and resources. Windows Azure Service Bus offer us the possibility to specify the number of messages that we want to prefetch. This means that we will be able to fetch 5, 10, 100, .. messages from the server using a single request. We could say that is similar to the batch mechanism, but can be used wit...

In today post we will talk about different redundancy mechanism when using Windows Azure Service Bus. Because we are using Windows Azure Service Bus as a service, we need to be prepared when something goes wrong. This is a very stable service, but when you design a solution that needs to handle millions of messages every day you need to be prepared for word case scenarios. By default, Service Bus is not geo-replicated in different data centers, because of this if something is happening on the data center where your namespace is hosted, than you are in big troubles. The most important thing that you need to cover is the case when the Service Bus node is down and clients cannot send messages anymore. We will see later on how we can handle this problem. First of all, let’s see why a service like Service Bus can go down. Well, like other services, this has dependencies to databases, storages, other services and resources. There are cases when we can detect pretty easily the cause of th...

Windows Azure Service Bus is a great mechanism to distribute messages across components of your own system or to different clients. When you want to use this service for enterprise projects you will meet the IT guys. For them it is very important to control the ports that are used by applications. Because of one of the first’s question that they will ask you is: What are the ports that are used by Service Bus? When this question is asked you should be prepare to have the answer prepared. Looking over the documentation from MSDN, the following ports are used by Windows Azure Service Bus: 80 – HTTP connection mode 443 – HTTPS connection mode 5671 – Advanced Message Queuing Protocol (AMQP) 5672 – AMQP 9350 – WCF with connection mode Auto or TCP using .NET SDK 9351 – WCF with connection mode Auto or TCP using .NET SDK 9352 – WCF with connection mode Auto or TCP using .NET SDK 9353 – WCF with connection mode Auto or TCP using .NET SDK 9354 – WCF with connection mode Auto or TCP...

Service Bus from Windows Azure is a great services to distribute messages to multiple subscribers. A topic can have one or more subscriptions. A message added to the topic will be send to all subscriptions that are register in that moment. To be able to control what kind of messages are send to each subscription we can define filters. A filter is added on each subscription and specify what messages will be accepted by subscription. The types of filters that can used are: Correlation Filter This is used when you want to accept messages that has a specific correlation value. This value can be set directly to the BrokenMessage and is great if you have messages with different priority or rank. CorrelationFilter filter = new CorrelationFilter(“low”); namespaceManager.CreateSubscription(topicPath, subscriptionName, filter); BrokenMessage message = new BrokenMessage(); message.CorrelationId = “low”; … SqlFilter This filter give us the ability to specify what kind of messages will ...

Until few months ago, Shared Access Signature (SAS) could be used only wilt Azure Storage (Blobs, Tables and Queues). From now one we can use SAS with Service Bus. We can define SAS to use in combination with topics, queues or notification hub This security feature is pretty great, especially when you have an application that use 3rd party. You don’t need any more to share with 3rd parties the account name and key. From now one you can give them a unique token that give them access to some part of your namespace services and also limit what kind of operation they are allow to do. In this moment you are allow to define only 12 rules in a namespace, but in the near future I expect to be able to define more than 12 rules. The access rights that can be controlled in this moment are: Listen – to be able to receive message Send – to be able to send messages Manage – to be able to manage the resource From Service Bus perspective, this access rights are enough and in combination with...

If you are using Service Bus, you should know that you have the ability to be notified when a message is available in the queue or in a subscription. Using this feature you don’t need to call the "Receive" method and catch the timeout exception when there are no new messages are available. OnMessageOptions messageOptions = new OnMessageOptions() { AutoComplete = true, ExceptionReceived += LogErrorsOnMessageReceived }; queueClient.OnMessage((message) => { ... }, messageOptions); As you can see, you register to an event that will be called when a new message is available. If there are more than 1 messages available the event will be triggered more than one. Each notification will run on a different thread. To be able to control the number of concurrent messages that can be received by a client you should change the value of "MaxConcurrentCalls". OnMessageOptions messageOptions = new OnMessageOptions() { AutoComplete = true,...

Let’s talk about Windows Azure Service Bus and the numbers of subscriptions that a topic can have. I started to prepare a POC for a possible client and it is possible to end up with hundreds of subscriptions on each topic. Looking over the documentation from MSDN, each topic supports 2000 subscriptions. I wanted to see what is happening with the latency of each subscription if we have over 1000 of them per topic. To find an answer to my question, I started to write a worker role that: Creates a new subscription Sends a message to the topic Receives a message using the first subscription I measured how long it takes to send a message to a topic that has 1, 2, … , 2000 subscriptions. The same think I’ve done for the first subscription of the topic. I measured how long it takes to read a message from it when we have 1,2, … , 200 subscriptions. The code is extremely simple but the results are very interesting. The first diagram shows how long the send and receive commands took. Th...

Some time ago I wrote about how I manage to process millions of messages over Windows Azure Service Bus. I discover that processing millions of messages every hour will increase the latency and response time of our topic. I wanted to find out what I happening with the topics from the same account and data center when the load of one of them increase drastically.  To be able to make this tests and discover the answer to my questions I made the following setup: Create 3 topics on the same data center. Two on the same account and another one on a different account. Create a worker role that will read messages from topics (via subscription) and monitor the delay time. The results will be written to Windows Azure Tables. Create 8 worker roles that will push hundreds of thousands of messages in a very short period of time on the same topic (multi-threading rules). Create 4 worker roles that will consume messages from our topic (via subscription). In the end we end up wi...

These days I participated at ITCamp 2013 . This year I had the opportunity to participate at a premium event with almost 400 attendees. For Romania, this is big number, it is hard to gather 400 people at a premium conference. What we found this year? COOL stuff. We discover what is the future of tablets, what is happening on the cloud and the voodoo magic that is happening inside the team management... and so on. I really enjoyed the conference, the sessions and especially the location – you could see all the city from above. Each year one of the most important thing at ITCamp is socialization – meeting people from different parts of the world, discover what they are doing and what are the trends of the IT industry. This year I had the opportunity to be invited as a speaker at ITCamp. Last year I talked about background task on Windows 8, but this year I decided to go on the cloud and talk about messaging pattern and how we can implement those patterns using Windows Azure Service...

Part 1 – What is the maximum number of messages that can be processed in 30 minutes? Part 2 – What is the optimum size of worker roles that process messages from Service Bus? Part 3 – What is the maximum number of worker role that can process messages from Service Bus? Part 4 – What are cost of Service Bus when we need to process millions of messages every hour? Part 5 – What are the scalabilities points of Service Bus? Part 6 - Topic isolation