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.
Related
I have an Azure application consisting of various resources like Logic Apps, Service Bus & Event Grid. As Azure monitor now supports monitoring only the resources involved, are there any solutions that provides application-level monitoring?
Monitoring serverless resources in Azure has now become way easy as there are several third-party tools to achieve what you're looking for. As this question is just about suggestion, I'll suggest a tool that best matches your context, as I am a part of the development team. You should explore Serverless360. It is widely used all over the globe to solve the main problem that most of the organisations face: Business-level application management and monitoring.
Serverless360 has a dedicated module for this where you can pile up all your Azure resources that constitute your LoB application. Not only monitoring, but also there are several other options that Azure portal doesn't provide, for which you will have to go for different tools like Service Bus Explorer, Storage account explorer, App insights, New Relic to achieve things. Serverless360 is an all-in-one solution where you no longer have to look for a second tool for your management of Azure resources.
Also, you can take a look at the top Azure monitoring tools that best suits your needs.
I am new to the Azure platform and hosting in general and I am currently moving some web apps to Azure Paas and have configured a single App Service Plan which contains 3 applications.
I have read all the documentation I can find and I know the plan guarantees 99.95% up time but I cant find any info in regard to hardware failures. i.e. if there is a hardware failure on a rack where my app is hosted am I automatically covered by the plan? Does my app exist in multiple fault domains?
Hope someone can help
Thanks
You can see the details here. I'd say hardware failures are considered as downtime:
https://azure.microsoft.com/en-us/support/legal/sla/app-service/v1_4/
Microsoft guarantee that Apps running in a customer subscription will be available 99.95% of the time.
Note: No SLA is provided for Apps under either the Free or Shared tiers.
For more information, refer SLA for App Service.
This SLA works based on the fault domain and update domains, understand how fault domains and update domains works in Azure.
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've recently been asked to redevelop an .Net 2.0 WinForms application with a back end SQL Server Express DB.
One of the requirements is to allow remote users access to the application, so I've been considering hosted options to avoid VPN setup. The data is not sensitive and does not fall under data protection act, so a basic security approach for the web will cover me.
I like the idea of using Azure for a few reasons, but I'm not sure if a good fit for a users base of 5 or 6 with no real scope to grow. I've never used Azure and I plan to develop using MVC and a SQL backend as this is my main skillset.
A few points in favour of Azure in my mind are:
Tight integration with the TFS preview that I'm using for this project
Easy to setup a sandpit and a live version
Easy maintenance as I expect other hosted options will require more knowledge of underlying OS
Sticking to a full Microsoft stack should hopefully make things simpler
From what I find on the Azure site the message is all about scalability, which is great if you need it.
My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?
What you're asking here is the perfect case for Windows Azure Web Sites:
You get 10 web sites for free (no custom DNS, but this is perfect for your 'sandpit'/test version). The shared mode supports custom DNS and is very cheap.
Tight integration with TFS preview and GitHub
You don't need to worry about the underlying OS, you simply publish from Visual Studio or with TFS Preview.
Sticking to the Microsoft stack is the easiest solution, but other technologies work great aswell. Since you're talking about MVC I'm assuming you are considering ASP.NET MVC, which is a perfect match with Windows Azure. Take a look at the training kit for some good examples.
The day you'll need a solution which more scalable (meaning you'll have more users and more income) you can easily upgrade to a reserved instance or to a Cloud Service (Web/Worker Role).
About your question: "My question is simply, do you need a large user base, or plans to grow quickly, to use azure or is it how we should be hosting apps now?"
Windows Azure is a cloud service platform (includes PaaS as Cloud Services, IaaS as Windows Azure Virtual Machines and also Websites suggest by Sandrino above), and with cloud services you have ability to start very small and grow as much and as quickly as your user requirement is, so you can use Azure with both cases. On the other hand there are some advantages using certain offering depend on your which service you are going to use to run your application.
I think article (Section: "What Should I Use? Making a Choice") will explain the strategy about how you make a selection among various services.
This SO discussion does talks about the difference between cloud Services and Azure WebSites as well.
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.