Cloud as a Story - Vunvulea Radu

Auto scaling of App Services and Web Application it is a feature that is available for some time inside Microsoft Azure. Beside standard metrics like CPU, Memory and Data In/Out there is a specific web metric that can be used for scaling – HTTP Queue Length. Counter definition It is important to know from beginning what does this metric represents. The name of the metric can create confusion especially if you used in the past IIS or similar services. The counter that can be accessed from Azure Portal represents the total number of active requests inside W3WP. The technical path of the counter would be “W3SVC_W3WP – Active_Requests_ - _Total”. Naming confusion This metric created confusion in the past, so it was renamed from HTTP Queue Length to Requests and shows the total number of requests in a specific moment in time. This change was done only in the Metric Monitor part of the Azure Portal. Inside auto scale section of „Scale out” you will find this metrics called „HttpQueueL

In one of my previous post, I talked about different flavors of SQL inside Azure. I saw that many people were interested about Managed Instances. In this post, I will present Managed Instances services, that are still in preview, but it might be a game changer for companies that needs to do a migration from on-premises to Azure and they have compatibility problems with Azure SQL Databases. For this kind of scenario, the only options used to be Azure VMs, that is in the end IaaS and require extra effort to manage the VM and SQL Server cluster that is running on top of it. In one word you cannot put your database on auto-pilot and focusing on your business and not on the infrastructure. The current flavors that are available on the market when you put SQL and Azure together are: Azure SQL Databases Elastic Pool Azure VMs … Managed Instance Overview Managed Instance is a new service inside Azure that is allowing us a one-to-one migration from on-premises to Azure, without w

Just realized a few days ago that there are so many flavors of SQL inside Microsoft Azure that you need to be careful when you decide which one to use. In this post, I want to present the most important flavors of SQL that you can have inside Azure and to define a demarcation line between them. 1.0 SQL Server inside Azure VMs (IaaS) The classical IaaS approach where customer needs to manage the VMs and the SQL Server instance that is running on top of Azure. The list of tasks that you need to do when you run your SQL instances on top of Azure VMs are the same as you would have the SQL Server instances inside your own data-centers. From license, to backup and restoration procedures, all of this needs to be managed by yourself. 2.0 SQL Database (PaaS) The current offer of Azure related to SQL on the PaaS environment is more complex than you would expect. In this moment there are 3 options available, that cover most of the uses cases that you might have. SQL Database (Singleton)

In the last post I added the extra functionality that would allow me to know when was the last time when the device was online and last time when a command was received by the device. Additional to this I added also a state of each device, even if I was not collecting the device state. Now, it is the moment to add the state functionality to the garage doors (open/close) Context The current system is simple, allowing us to trigger the garage door action, without being able to know if we close or open the door. This might create confusion especially when you control the doors from remote controls too. By adding state functionality to the system, we would be able to know if the doors are open or close. On top of this we could also add actions like open/close the doors and the system could decide if the door is open or not and to close it. Limitations The Beninca system that I have on the garage doors is not able to provide to us the doors state. It is just a simple door mechanism