I have thousand of SQL Server databases (one for each client). When we decide to push on production, we have most of the time changes in databases, the web API and the web application.
The problem is the time it takes to deploy everything, especially the databases. We are using Code First migration and MVC .NET and SQL Server, all with the latest version. It is a SaaS. And the code first migration process is able to update the database one-by-one.
The API and the web application are deployed very quickly within a few seconds. However, the databases are all updated within about 30 minutes. During that time some users got errors and cannot use the software because the API tries to target non-updated database. And worse, if during the databases update, something fails and stop, the non-updated users are stuck until we fix the issue and update the rest of the databases.
Any idea how to solve this problem and make clients happy?
PS: The web application doesn't access to the database, but only the API.
This question is somewhat opinion-based. The maintenance window approach is the easiest. If you want to do live-updating, another way would be:
Keep a version number in the database
Allow running multiple versions of the Web API side-by-side
Choose which version of the API to use by looking at the version in the database
Determine if the Web API's public interface is stable. If it is not, also find a way to allow running multiple web sites side-by-side and choose which one based on the version in the database
The most maintainable way to accomplish this would probably be to have at least 3 servers:
One backend server which hosts the old version
One backend server which hosts the new version
The frontend server which routes users to the proper backend server based on the current version.
The routing could take place only at login, or you could do something more fancy such as redirecting the logged-in user when an upgrade is detected. Obviously none of this deals with what happens to one particular client during the actual upgrade of that client's database. You'll still need to address that separately.
Related
I'm trying to use Entity Framework Core with SQL Server (not SQLite) in a Xamarin forms app but I just can't figure it out! All tutorials explain how to use EF Core with sqlite! Are there any clear documentation or tutorials?
About connect to a Remote DataBase in Xamarin.Forms, I find one article that you can take a look:
https://xamarinhelp.com/connecting-remote-database-xamarin-forms/
You may be wondering why you couldn’t just connect directly to a database from your mobile app? The main reasons are:
Security
You don’t want your mobile client apps to have a database connection string with a username and password in it. It opens your database up to anyone. You can create a user with read only permissions and only allow access to certain tables, but they could still see all data in these tables. On an API, you can implement additional security checks and have authentication based on OAuth or an existing user management system.
Performance
Database connections weren’t designed to go over high latency connections. It is likely your database connection would keep dropping, forcing you to reconnect every time.
Control
With an API you can control the flow of data to and from your database. You can implement rate limiting, and monitoring of all of your requests. If you need to change business logic, or even what database or resources are used via each API request, you can do this on the server, without having to redeploy a mobile app.
Resources
With an API, you reduce the need for server resources. While you may have to setup another server to handle an API, the REST API is designed to be stateless and efficient. Scaling to many users in the future is easier with an API.
I maintain a website written in ASP.NET MVC 5, and hosted in Azure. It's a legacy app that is a real nightmare to maintain, and so I've been asked to start migrating to a new codebase and the ASP.NET Core framework.
Our goals are:
Migrate one page at a time
Don't lose the "F5 debugging" experience in Visual Studio
My initial thought was to use a virtual application/directory, which is supported both in Azure and in IIS Express. The idea is to point, for example, the /Shop page to the new website by using a virtual path. Then when we're ready, move the /Team page and so on. I would add a virtual path for each migrated endpoint until the migration is complete.
To accomplish this I created a new ASP.NET Core project, and I've been trying to edit my applicationhost.config file and trying to start multiple projects from Visual Studio, without luck.
I tried configuring two sites with the same port binding, two apps within a <site> tag and also two virtual directories within an <application>, but I always end up with errors. Either I can't start debugging (Can't connect to IIS Express or The object invoked has disconnected from its clients messages) or I get a 502 error.
I don't even know if this is going to work in Azure, but I know we can't go down this path without proper development experience.
Am I missing some other, better solution? If this is a good solution, is there any way to make this work in Visual Studio?
I would consider creating multiple new websites in Azure, one for each section. Then, as I start working with Shop, for example, I'd leave an almost-empty controller in the original solution, redirecting to your new Sales web site. Using this approach, you can efficiently work with one smaller code base at a time and in the future scale the individual pieces of your site as needed. Please note, that you can host multiple sites within the same app service environment (thus not incurring a lot of extra cost by separating into multiple processes).
Best of luck :-)
I'm new to azure and cloud platform development - I have a web application and I create multiple companies using a
company table and
seperate the
company_products using a foreign key: companyid
Is it possible to run multiple instances in which each has it's own SQL database? I want to do this because every customer is unique and they may need tailored modules.
There are no restrictions on how you build your app. You many create as many databases as you wish, and have multiple web apps if you wish (whether in the same app service plan or across multiple app service plans). How you do this is strictly up to you, but no - there is nothing that forces you to use a single database for anything.
If I am understanding your question correctly, you would like each of your customers to have their own instance and separate databases?
Have a look at this article: https://msdn.microsoft.com/en-us/library/ff966499.aspx
I'd suggest using Azure App Service, and running each of your customers in their own app. You can save money as all the apps run under the same App Service Plan. Usage on one instance however, does not affect performance on another. There are quite a lot of benefits with App Service.
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
For starting out, I'd suggest using individual Azure SQL Databases for each customer. This is to save money, as you can spin up S0/S1 databases for relatively cheap. Then you can set the connection string through the Azure Portal for each app you have under your App Service Plan.
If you end up scaling quickly, have a look at Elastic Databases. You pay for a database server and get something like 200 databases per server. So its really only economical if you have quite a few customers and can justify the cost. However there are some useful Azure tools that make managing elastic database pools easier. Check out the Azure documentation for more details on this.
Once you have this architecture set up, you can either manage your instances/databases through the portal or setup another logic app to manage all your instances. It would be a lot less development work to just manage it through the portal for starting out, however if this is a SaaS product, and is going to scale quite quickly, you may want to invest ahead of time in automating some processes so that deploying new instances doesn't have to be done manually.
I prefer this approach as well, because you can then point different subdomains at your individual custom apps. (i.e. customer1.yourdomain.com, customer2.yourdomain.com). Each app already has it's own domain under azurewebsites.net, so if you don't mind using that domain, you can just stick with it. It's nice cause then you don't have to manage your own DNS or worry about SSL Certificates and what not, as it's already managed for you. If you do want your own custom domains, there's plenty of documentation on this. Azure also has a DNS service for automating creating CNAME records while automatically spinning up a new app and deploying a DB to your pool and initializing the DB, etc...
As David says, you can do this how you like. My suggestion would be to use connection strings in your application's web.config to control the database instance you want to communicate with, and you can then configure your azure web app deployment's "slot settings" in the azure portal (or your ARM template) to override the web config settings for that deployment.
So - you can create your ARM template which describes your infrastructure, and may deploy your app service plan, web app, web config, sql database to a specifically named resource group (ie. targeting one of your customers). This would have configuration that points to the database instance in that resource group, and possibly other config that turns customer specific functionality on/off. Try to keep the code and deployment as common as you can, otherwise you'll end up with a maintenance nightmare in the future.
See https://azure.microsoft.com/en-gb/documentation/articles/web-sites-configure/ for information on configuration settings in azure web apps.
I am building a very simple asp.net application that will have a SQL Server 2008 backend.
Some users will be entering data and storing in the database and some users will be viewing data.
The SQL Server 2008 is working with Windows authentication for every user; however, I am unable to get ASP.NET working with Windows authentication yet. Is there a simple way to allow windows authentication with ASP.NET? I found a very convoluted way, but I don't like it.
I will need to audit every action that the users perform.
Should I audit the users at the application level or at the SQL Server level?
Are there already built in methods to do this? If so, how?
On the contrary, I have always found Windows Authentication to be quite easy to set up and relatively painless. Here's some guides:
Setting up
More Setting up
I didn't realize that you could audit what users did at the ASP.NET level. My answer would be to use SQL Server for this one. You'd need to log:
timestamps and user name for every action
do you need to log workstation or location where the actions were performed?
can users go to mul
if multiple locations use this application, consider storing UTC time only
all actions, even deletes, which mean that delete's only get "hidden" from the user, but never erased from the database. Same for edits, the old record should never be changed or taken out of the database.
Your best bet here is to talk to your boss about this one. Auditors can have very specific needs, and you definitely don't want to forget anything. Every situation is different, so be sure to sit down and double check all your requirements and specifications.
Two things:
Here is example on Win auth on asp.net app:
http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx
I suggest you implement a log framework like log4net to log your application. It's simple and easy to use http://logging.apache.org/log4net/download.html
I would do this from the application if it is significant HOW people accessed the data as much as the WHO, but that's quite different from rlb.usa's answer. In my past jobs, it's often been as important to know which application the person changed data from as when/who. If it's primarily for application issues, log4net is a good option.
I am going to write up a webapp hosted on a windows 2003 server to allow me to connect to local and remote servers to do some basic things.
The webapp will be hosted on serverA. It will need to be able to copy files/folders from one folder to another on this server.
It will need to be able to connect to ServerB and copy files in the same way, e.g. copy \serverB\path\to\sourcefiles to \serverB\path\to\destinationfiles
ServerB hosts an installation of MSSQL 2008, I want to be able to create new database/login etc.
How do I go about this please? I've been reading a bit about Windows Authentication, Impersonation, Delegation but i don't know where to focus on.
thanks
S
To be honest there isn't really a one size fits all complete answer to your question, however there are a number of things that you need to take into consideration early in development to ensure that your platform is built on solid foundations.
From the description you have given the most critical consideration has to be security and everything you develop has to have this at its core. Judging by your post if the wrong person was to access your front end then they could wreak havoc.
As for the model to use, I would suggest Windows Authentication as this is built into the framework and gives you the ability to segregate into usergroups with differing levels of access. It will also open up some of the functionality you need, i.e. network copy of files etc
As for the database management aspect, this again can easily be done via Windows Authentication as you can grant (in SQL) windows users the ability to perform certain tasks, i.e. Create Database, Create Login, drop x, etc
All this said, it of course assumes that the two servers share user credentials, i.e. domain controller etc.
Another method, would be to use the web "interface" as a pass through onto a WCF service that operates under a specific user account that has the access you need. You would then seperately manage authentication/authorisation in a manner that you decide.
Like I said, no simple one size answer - but hopefully this will give you something to chew on.
If your goal is to create new databases or logins, why can't you use the create database and create login commands?