Please tell me what is the relation between Windows azure and multitenacy application?
How to make multi tenant application?
It possible to host multi tenant application in windows azure platform?
Windows Azure is a platform upon which you can build web applications and services. Windows Azure does not provide multi-tennancy support built-in (multiple separate clients using the same app instance but not sharing data between clients).
Your options are two write your application for single-tennancy and configure a new instance of that app for each client, or implement your app for multi-tennancy and handle user accounts and user separation internal to your app.
Windows Azure does support multi tenancy, but you have to architect for it.
The most typical model I've seen used is a multi tenant web and business layer with a single tenant data store. You can debate multi tenant data, but single tenancy seems the preference from a risk perspective. If one client is compromised or corrupted, you don't want to affect all your customers.
You can do that quite easily by
Ensuring that your web and business
components are stateless.
Use a common security layer
Switch data context per request
The data context switching is the most complex part, but it could be something as simple as having a per user/role Entity Connection string if you're using EF, or a Partition naming pattern if you're using Table storage.
Related
I am new to Azure and tasked with identifying the right approach to take our on-premise asp.net core web application to Azure so that it is a multi tenant offering to customers.
With my research so far, it appears that I have the following options
Make my web application a multi tenant SAAS application with data partitioning per tenant
Make my web application a Azure AD protected PAAS offering that can be deployed to customers subscriptions using Azure Managed application.
Containerize my solution (ACI/Dockers etc).
Q1: Is there anything called multi tenant PAAS application? All references I come across are multi tenant SAAS application.
Q2: I want to know if I am in the right direction and are there any books/references/documentation that can help me in this regards to solidfy my understanding.
Any help in this matter is highly appreciated.
Thanks,
Is there anything called multi tenant PAAS application?
For multi tenant PAAS(Platform-as-a-Service) application,you can understand it this way:
each application runs in its separate space, meanwhile still sharing the compute, storage and network resources, as well as providing a complete separation of the security domain and application related data and processes.
I want to know if I am in the right direction and are there any
books/references/documentation that can help me in this regards to
solidfy my understanding?
Azure hosting for ASP.NET Core web apps,microsoft officially provides the following solutions:
App Service Web Apps
Containers (several options)
Virtual Machines (VMs)
App Service Web Apps is the recommended approach for most scenarios, including simple container-based apps. For microservice architectures, consider a container-based approach. If you need more control over the machines running your application, consider Azure Virtual Machines.
For detailed information, please check:here
Hope to help you.
depends on many factors, some of most important ones being:
number of tenants
load spread over tenants (do you have roughly equal distribution of load over tenants or some tenants use app 10s,100s,... more intensively than others)
security and data isolation (is there a security reason to have tenants separated by each having their own environment (domain, db, application instances)
your most straightforward starting point would be to go with app service & cosmos db as it can scale practically indefinitely.
then, if/when you hit the wall because of your requrements (if you have some like in the list above) then you start from there.
It's a general answer, but it really depends on the nature of your application and the usage patterns/requirements.
I would like to develop a simple ToDo app using Xamarin. It should allow the user to sign in with an account and access their notes on multiple platforms.
Microsoft offer a number of sample applications using different APIs (https://developer.xamarin.com/samples/android/Web%20Services), but to a beginner, it seems unclear what the advantages and disadvantages are of the different methods. I'd be grateful if you could outline these for me for the differing technologies (e.g. CosmosDB, REST, ASMX, DocumentDB, Azure Mobile App, and OAuth).
CosmosDB:
Azure Cosmos DB is Microsoft's globally distributed, multi-model database service. With a click of a button, Cosmos DB enables you to elastically and independently scale throughput and storage across any number of Azure regions worldwide. For details You Could Check here
REST:
Representational State Transfer in short (REST), REST requires that a client make a request to the server in order to retrieve or modify data on the server. A request generally consists of:
an HTTP verb, which defines what kind of operation to perform
a header, which allows the client to pass along information about the
request
a path to a resource
an optional message body containing data
There are many good article you could found online. you can check here
ASMX:
.asmx is Active server methods. Webservices have this extension in dotnet. ASMX provides the ability to build web services that send messages using the Simple Object Access Protocol (SOAP). SOAP is a platform-independent and language-independent protocol for building and accessing web services. You can find more details here
DocumentDB:
CosmosDb is the evolved version of documentDb. It is also important to point out that DocumentDB’s SQL dialect has always been just one of the many APIs that the underlying Cosmos DB was capable of supporting.
Azure Mobile App:
Azure App Service is a fully managed platform as a service (PaaS) offering for professional developers. The service brings a rich set of capabilities to web, mobile, and integration scenarios. You can start good tutorial here
OAuth:
OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential. In authentication parlance, this is known as secure, third-party, user-agent, delegated authorization. You could check here
I have an existing Web API 2 project that I'm looking to move over to Azure Service Fabric. I'm planning on creating a single stateless service within Fabric as detailed here (mainly as I don't understand actors/services at the moment!) and move the API across.
My API uses Entity Framework for it's backend and the built in Individual Accounts using OWIN.
Is there anything I need to consider when moving the service over (I mainly thought the the DB and authentication might be an issue) or is it just a case of putting a Service Fabric layer on top?
Thanks
EDIT
I've had a bit more of a thought about this and have some more questions (based on #Mihail's comment)!
So I'm going to have many stateless services (so I'm splitting my Web API project up) which will be exposed via a Web API project (based on this)
So two questions really:
I need to authenticate users based on Individual Accounts. I think I should do this on the Web API frontend so only authenticated users get through to the Fabric services but that means that the API has access to the DB and it's not just a pass through anymore. Is this OK? Should the API call a microservice to authenticate and then call the service it requires or is this overkill?
Entity Framework. If I have many services (and API frontend) accessing the same DB do I have to worry about concurrent connections/locking or will Entity Framework handle this for me?
As Mihail said, the questions around Entity Framework and authentication shouldn't be a problem, or at least not a Service Fabric specific problem.
One thing to consider though is whether Service Fabric is appropriate here if the only thing you'll have is a simple API, or whether an Azure API app would be a better fit for you.
If you went with Service Fabric, you'd have to have at least 5 VMs so you'll need to consider whether your app requires 5 VMs or whether that would be an overkill. Also remember that you'll need to manage those VMs - you don't get the magic that a PaaS solution would give you. You'd also have to deal with certain things that you'd get out of the box from an API app like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Might be worth having a look at this SO question for a comparison between Service Fabric and the App Service.
I have developed an MVC5 web application which uses Code First Migrations to build out the database. Now I am attempting to develop a mobile app (using PhoneGap if that matters) that exists as a native option to access the data of the application. However, I am having trouble finding a way for the databases to work nicely together.
Ideally, I'd like to use the same database schema entirely, and just have the application and the mobile app point to it. The database is hosted on Windows Azure. The issue I'm having is that with Azure, the standard way of handling databases with mobile apps is to use an Azure Mobile Service. However, when that service creates a database, it creates its own schema named after the service, whereas the web application uses the dbo schema. So the Users table might exist in dbo.Users for the web app, but in myAppName.Users for the Mobile Service.
I've already explored this solution, which seems to mirror my problem. However, there is an additional issue. The .NET MVC5 Authentication services use dbo as the default schema and there seems to be no way to change that.
Bottom line, if I use the default schema, the mobile app cannot access the database, but if I move the tables to the Mobile Services schema, the Login/Authentication fails because the tables don't exist in the default schema anymore.
Am I missing something here? It seems like it should be a fairly common task to have a web app and mobile app accessing the same database, but I've been investigating this for days without finding a solution.
Thanks for any help you can provide.
The standard way of using a database for mobile apps in Azure is not Azure Mobile Services. I mean, I would not call it standard but just one of the options.
When Azure Mobile Services creates a database it does not create the database with its own schema. Azure Mobile Services does not have a predefined schema. You can define your own schema. The only predefined logic is the addition of the azure mobile services tenant name as a prefix to all table names. This is done to help you host multiple azure mobile service accounts in a single database. You can override this logic if you write the app in .NET. I'm not sure if that's possible if you roll a JavaScript based Azure Mobile Services account.
My suggestion to you would be to roll your own ASP.NET Web API project and host it in Azure. You can host in Azure Web Sites or Cloud Services according to your requirements. Once you have your own APIs running in Azure you should have no problem accessing the APIs from a web site or mobile app.
Hope this helps.
We are planning to deploy one of our reporting application/product on Microsoft Azure platform for testing & research purpose.
Application is built on .NET framework 4.5 , and thankfully Azure does support 4.5 now.
Application is not Azure ready yet. I assume some config level changes are required to deploy it over Azure. Not much is required in Azure websites though.
Our Application has three major components , one is the MVC web layer built using n tier approach. Second component is an independent window service that pulls data periodically from an external system, and pushes that into the third component, a SQL Server database. MVC Web layer coupled with a business layer uses this SQL server to perform R/W operations.
Had it been a typical case of web application with a database, I'd have gone for Azure websites. Now that I have a window service/(Schedule based data puller) in picture as well, I am confused what accounts & services I should opt for , within the Azure platform ?.
Azure provides bouquet of services such as Websites, Service Bus, Cloud services, VM etc, but I am pretty confused what setup will fit in good for this application.
Some additional details about the application :
UserBase (for a single instance) : 10-30 users at a given time.
Data volume collected from external system/web service : approx 100 mb per
day.
Do I need to setup multiple services like Azure websites at one end with a database, and for scheduler/window service something else ?
Since you have a background windows service keep pulling data currently, I'd like recommend you using Windows Azure Cloud Service (WACS). You can migrate your MVC web portal as a web role and the background service logic into a worker role. Then your worker role can pull data from the external service and insert data into Windows Azure SQL Database (WASD). Then your web role can r/w data from WASD and display them in the portal.
The Windows Azure Web Site (WAWS) currently doesn't have the symmetrical feature as worker role. But since both WAWS and WACS can use WASD, you can move your web portal to WASD, and your background job into WACS worker role.
Hope this makes sense and helps