I am trying to undestand "What really SAAS is". It is Software as a Service, and hotmail outlook is one example of SAAS. But I am still in confusion.
Suppose, I built an web app "Hospital Management System" which keeps the record of all patient and all that, Is it a Software as a Service. What specific things are needed to be a Software as a Service, or just a web app is a SAAS????
A software is SAAS if it is deployed and managed to serve mutiple users (tenant is the term here) from the same deployment. That means the software is not deployed at the client side and it need not be one per tenant.
Your Hospital Management Systems would be a SAAS if you deployed it in your infrastructure and multiple hospitals used them as if you had created one for each of them.
Here are a few links that will help to understand better.
Databse architecture (single db vs client specific db) for Building Enterprise Web (RIA) application on cloud
Explanation of Tenant Load Balancer in SaaS maturity model level 4
Web applications (especially online and browser-based application services) require a significant amount of flexibility to accommodate ever-changing user demand.
SoftLayer’s infrastructure lets you customize highly scalable solutions ideal for meeting today’s needs without compromising cost efficiency or expansion speed. Linear stacks of Web, application and database servers can be added on the fly to precisely meet demand whenever more resources are needed.
Related
We have completed our ALZ design and are migrating our existing resources to the new subscriptions.
Also, we have deployed two small utilities AzGovViz and AzNamingTool in our new ALZ that the Cloud Operations team will access. I foresee additional 3rd party tools to be added and/or developed in-house.
Let's call them operational tools for the context of this question:
I have some questions about the recommended design for deploying these operational tools that are not LOB applications:
Does it make sense to reuse the same app registration or is it better to create one per tool? Every tool will have the same permissions and will be accessed by the same people. Currently, I have one App registration for bot utilities and it works. I am aware that app registrations do not have a cost but I am wondering what are the best practices or if there is a use case where an app registration is used by multiple apps.
About App service plan, we are using the free plan that has an app limit (no app plan limit) for up to 60 minutes. From the cost perspective, it seems it does not matter if each app has its own app service plan or if they share one. Would you create one shared app service plan to be used by all the operational tools?
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.
In Visual Studio 2013, I have a solution that holds several projects, including multiple class libraries, as well as an MVC5 project to serve HTML pages to clients.If I get the free tier, can I host my entire solution, including all the projects that it holds? Microsoft's own documentation on this matter is not clear, and I was hoping someone here has already used the Azure platform for hosting their website.
Does Microsoft's Azure Hosting allow the hosting of n-tier applications?
Sure, why not? You can host every tier of your application separatly in Azure (DBs, web sites, services, background jobs, etc.) in different services provided by Azure. In the free tier you have the limitation of sites you can create for free (Azure Web Sites), limitation of cores (don't know the exact limit) and the costs you produce. If your costs exceeds the limit all of your resources will be shut down.
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.