Multi tenancy is a popular buzzword, often heard coupled along with cloud computing terminology. This is the issue and has created a dogma and some believe that multi tenancy can only be related with the cloud and cloud based SaaS services.
This is observed in Visual Studio Cloud Service Template (Environment VS 2015 Enterprise Update 3 and Azure SDK 2.9.6 with .NET 4.6). This could be observed in most of the other versions – probably in Azure SDK version 2.4 and above, but I stated my working environment as soon or later this issue will be resolved.
Quick read and the reason : The template has the Trace.TraceInformation as the logging code line, but the configuration is set to log Errors by default. So when you run the application, the service has nothing to log and it doesn’t create WADSLogsTable. By changing the code to Trace.Error or changing the configuration to log information/verbose would solve the issue.
Mostly beginners bounce into this issue, and fair reason to get panic because when the just create the fresh Azure Cloud Service out of the box from the available template, it doesn’t work as expected.
Go to the Worker Role properties and you can change the application log level settings to log Information level logs.
or, change the code to this
The application creates the table when and only the information need to be persisted, so the available template does not create the WADSLogsTable until you do either of the suggested changes.
Being part of a software services company, customers often ask the question how to restrict access to Azure resources. It is understandable that any organization wouldn’t prefer to give all the rights of the organizational Azure subscription to a person.
In the classic Azure model the only way to give access to Azure portal is, adding the user as a co-admin for the subscription. This gives all the permissions to that user within the subscription except managing the administrators.
But the new Role Based Access Control (RBAC) helps to solve this problem. Using RBAC we can control the permission scope to either subscriptions, resource groups or to individual resources.
Permissions in the top level scope are automatically inherited to the level below – meaning subscription level users have the same permissions to the resource groups and the resource group level users have the same permission to the individual resources within the resource group.
RBAC has several roles – read more about different roles
Here I’ve explained the flow of adding a new user to a Azure resource group and how his/her experience in accessing Azure via portal. Assume the user doesn’t have any permission in the Azure, and he’s just a developer with a Gmail account.
First, a subscription admin logs in to the portal and add this user in the Azure Active Directory of the specific subscription.
Note at this point, developer1 does not have a Microsoft account. She clicks on the link in the email she received. She will be directed to create a Microsoft account with the specified email address. (if there’s a Microsoft account already available this step will not be required)
After creating the Microsoft account (entering a new password and create the Microsoft account), she can login to the Azure portal using – https://portal.azure.com But within the portal this user cannot create any resources. In case if the user tries to create or try to perform any action she will get the below message. This is a very similar message to the old grey error box in classic portal, as the user exist in the Azure Active Directory but does not have a subscription, in this case does not have any resource.
Now let the admin assign a resource group for the user. Assume you have a resource group DevelopmentRG and in the resource group IAM settings add the user (developer1) as a contributor.
Contributor is a predefined role in Azure which has the create/edit/delete permissions of the resources within the specified scope. In this case developer1 has those permissions within the resource group – DevelopmentRG.
After setting developer1 as a contributor, you can notice that the access type of the user is set to Assigned, because this is a an assigned permission. Also note that the subscription admins have the permission to the resource group as Inherited permission.
Now the developer1 logins to the portal and she will see the assigned resource group. Developer1 can perform actions within this resource group.
Also note that since, developer1 has only the specified resource group, she cannot create a new resource group or any permission outside the scope of the specific resource group.
RBAC provides more granular permissions with various roles required for the businesses, this helps the organizations to carefully delegate the permissions to the people without exposing the entire Azure subscription.
The feature to limit/set the quota for a resource group is in the request from the community.
This is a template and quick start guide for Akka.NET with ASP.NET Core. You can grab the concepts of using Akka.NET with ASP.NET Core and how Akka.NET actor model can be used in a simple quiz or survey based scenario.
But at the same time, this post will not provide all the fundamentals of actor model programming or Akka.NET. It assumes that you already have the understanding of the actor model and reactive programming basics, along with the some practical experience with the concepts of Akka.NET.
Scenario : A quiz engine has many quizzes and users can attend the quizzes. Each user can attend many quizzes as possible at the same time. So each user session is associated with a quiz. One user can have many quiz sessions at the same time. A simplest session key is a combination of quiz Id and user Id. This combination is unique and referred as a session Id. Each session is an actor.
Also a template actor provides the quiz templates during the session creation. Each session actor gets the fresh copy of the quiz during session creation.
The below diagram shows the actor system used in this scenario.
Step by step explanation
In the ASP.NET Core Startup class the actor system (QuizActorSystem) is instantiated.
QuizMasterActor is created in the context of QuizActorSystem and the QuizActorSystem is added to the ASP.NET Core services collection, to be consumed by the controllers.
QuizMasterActor creates QuizSessionCoordinatorActor and QuizTemplateActor under its context.
For simplicity the QuizController of ASP.NET Core has two actions.
GetQuestion – This gets session Id and question Id. The controller asks for the session actor from QuizSessionCoordinatorActor. If the session actor is already available it will be returned else QuizSessionCoordinatorActor will create a new session actor under its context. QuizSessionActor loads the quiz from the QuizTemplateActor in the initial creation, gets the fresh copy of the quiz and returns the requested question. Consequent requests will be served directly by the QuizSessionActor.
GetAnswer – This action methods takes the session Id and the answer for the question and pass it to the right QuizSessionActor for the update.
The entire QuizSessionActor tree is created upon the request for a question under a specific session and this is quite safe and straight forward.
You can download the source code from this Github repo.
IMO, Microsoft Orleans is a framework and an implementation for developing highly distributed concurrent applications, which can also be considered as a wrapper or a developer friendliness (or the so called developer productivity) coated actor framework.
Microsoft Orleans said to be having the concept/notion of virtual actors and optimized for cloud. As in production Orleans is deployed in Azure cloud services and on premise deployment. IMO – The production implementation of the Orleans is quite challenging compared to Akka.NET implementations.
The idea behind the developer friendliness is quite confusing; the so called developer friendliness is achieved through abstracting and hiding plenty of underlying concepts of actors model and some areas Orleans has key breaches to the actor model as well. In that sense one can argue that Orleans is not an actor framework. So if you’re a person who is into details, you might find it bit less involved, but if you’re a developer who really want to create a quick solution for a burning business issue this is ok.
I highly recommend, you to read actor model and how it works and then get into Orleans as this would give clear picture of Orleans and how it is implemented.
If I’m to tell the fundamental difference between Orleans and Akka.NET based on the developer learning aspect, it is same as the exact difference between Java and C#. Java is pure (recent versions are quite different, if you have used Java 1.5/1.6 you’d understand) on object orient programming and a good tool to learn the real concepts of OOP. But C# has OOP features but not a strict follower of it, on top of the OOP concepts it goes beyond the OOP language constructs in order to achieve developer friendliness and productivity.
Orleans is a derived innovation on top of the actor model concept and Akka.NET is more over a real mapped implementation of actor model.
Are you handing more than one SQL database in Azure for your application ? Most of the times the answer would be YES. In dedicated database multi-tenant systems at least you have your customer information in the master database and dedicated application database for each customers. Some CRUD operations need to touch both the master and customer specific databases.
We need MSDTC (Microsoft Distributed Transaction Controller) for distributed transactions in on premise systems, but in Azure the SQL Databases has the elastic distributed transaction feature enabled and using .NET 4.6.1 we can use them via TransactionScope class from Systems.Transactions.
This link explains how this works, but I wanted to test this with EF and Azure App service as the Azure App service has the target platform option .NET 4.6 and not 4.6.1.
I created two logical Azure SQL servers in two different regions, and enabled the transaction communication link between them using PowerShell.
Then I created a small Web API project using .NET 4.6.2 (which is higher than the required version) and tested the app from the local machine and things worked well. I deployed the same stuff and things worked fine in Azure as well.
Even the though the target platform is .NET 4.6 in the Azure App Service, when we deploy the .NET 4.6.1 and .NET 4.6.2 projects, the required assemblies in the respected platform version are referenced.
But my swagger endpoint behaved strange and didn’t output the results, no idea why and need to launch another investigation for that.
You can reference the test project from my Github
Conclusion – We can use the Distributed transactions in Azure SQL Database using EF and deploy your projects written in .NET 4.6.1/ 4.6.2 in the Azure App Service platform targeting .NET 4.6
The C# language features async and await are very easy to use, straight forward and available right out of the box in the .NET framework. But it seems the idea behind async & await has some confusions in implementations, especially where you await in the code.
The asynchronous feature boasts about the responsiveness, but it can help boosting the performance of your application as well. Most developers seem to miss this point.
Since most projects start with the Web API, let me start the discussion from there. In a Web API action like below, the async in the action method helps the IIS threads not to be blocked till the end of the call and return immediately, thus increasing the throughput of the IIS.
When ever we have an async method developers use the await immediately right there. This makes sense when the rest of the code depends on the result of the call, otherwise this is not a wise option.
Assume we have an async operation like below.
Say that you want to invoke the method twice.
In the above code snippet, the method is asynchronous – the action method is marked as async, and IIS thread pool returns before the completion and continue from the point where it left when the response arrives.
But the method is not gaining much in the performance, this method would take 12+ seconds to complete. As it goes to the first DoWork() which takes 6 seconds and then the second DoWork() which takes another 6 seconds and finally returns.
Since the result of the first execution is not used or not needed in the rest of the execution we don’t need to perform individual awaits. We can execute this in parallel.
The above code executes the tasks in parallel and awaits at the end of the method. This model would take 6+ seconds.
Async and await are very powerful features of the .NET and they help not only being responsive but also in performance and parallel execution. By using the await carefully you gain more performance advantages.