I am looking to create a small personal web site using Azure web sites free tier. As part of the project I would add minimal database support. This is a hobby project so I want to stay within the constraints of the free web sites.
Here are some of the options I am considering:
SqlLite
RavenDb (RavenDB Asp.Net Hosted or Embedded)
CouchDb (don't think this will work but I have not investigated enough)
.sdf file
Short of using XML files, is there a good database option for the free web site tier?
When you create an Azure website you get a 20 Megabyte SQL Server database for free. Granted, that is not much, but if you are considering SqlLite, perhaps that is enough.
The small print from their website.
Free and Shared (Preview) tiers include 60 minutes and 240 minutes
of CPU capacity per day, respectively.
These quotas are per
sub-region unless noted otherwise.
One 20MB Azure SQL Database and
one 20MB MySQL database are available at the subscription level for
the first twelve months of use; standard rates apply thereafter.
Related
I have a web site I developed for displaying the results of some data analysis work I did. It relied on ASP.NET for the front end and connected to a MySQL back end utilising Entity Framework and LINQ extensively.
I chose MySQL because I personally have used it in the past and like the database, but this resulted in some serious issues when I had to deploy it to a hosting provider (incompatible connectors, access rights, etc.)
I am now getting ready to redevelop and expand the site and I am looking for some advice to avoid the issues I had last time.
The new DB has to serve two roles. The first is to be a data provider for the charts that are the output of the analysis work. These tables are straightforward, almost flat files, with 10 tables. One table has roughly 200k rows of data the rest have aprox 1200 rows of data each. There are little references or queries between the DB tables, but there are a few. This data is updated periodically by a back end process and does not need to be added to or edited by the user.
The second role of the DB would be as a basic persistent store for a standard user management system. It would need to manage data for adding/ removing clients, user names, passwords, access rights. etc. No financial data or super secure data is involved.
What database approach would you recommend that would give me easy deployment and management at a web host and still allow me to use both Entity Framework and LINQ effectively.
Second, what tools/frameworks should I consider as I rewrite this system. It is very graphical and data focused. Presentation of charts and information is the key factor in this site. Are there any new technologies or frameworks that would add specific value to what I am doing?
A few notes. I am a one man shop and I maintain the entire system myself so I am less worried about enterprise level frameworks than other people. My focus is on the easy development and deployment of the site. Maintainability is also a key factor.
I am also an experienced C# developer, but new to ASP.NET and the web side of things. The first version of this site was a big learning experience. It was good, but I wasted an enormous amount of time on just understanding new technologies and approaches. I am very open to learning, but I can't afford the time to get my head around a complete paradigm shift.
I am looking forward to your thoughts, thanks.
Doug
The natural choice would be SQL Server. I'd guess by your description that you are way under the maximum space limit of the SQL Server Express edition. I of course supports Entity Framework and the drivers are part of the .NET Framework, so no problem with third party assemblies here.
This will also open up the possibility to host your app in the cloud (Azure) later on, because SQL Azure in fact is a Microsoft SQL Server, so there is no overhead in supporting that.
Regarding user management - ASP.NET has this all build in (Membership, Role and Profile provider) and also a SQL Provider for which default tables are available. So you don't have to design your tables by yourself and it runs very naturally on SQL Server.
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.
We are currently finishing a web-based time-tracking software built on ASP.NET and WCF (for different desktop-clients). Our customers can register an account and add an unlimited number of users to their account. Pricing is tied to the number of active users in the companys account.
To keep things simple and easily scalable we thought it would be a good architectural decision if we design each account to run as a single IIS-website with it's own application-pool, SQL-Server database and subdomain.
Unfortunately we rapidly run into memory-shortage, due to the fact that a single worker-process will consume at least 150mb, which means that for every single trial-account we need approx. 200mb more of memory...
Beside the heavy costs of such an architecture (trial-accounts!), we are not sure if it was a good decision for scaling, to design the architecture that way.
How would you design such
SAAS-applications?
Single app-pool for many sites?
Single website for many accounts with shared database?
Scaling vertically (more power) over scaling horizontically (more servers)?
Any good books or blogs on this topic?
Thank you!
What are the reasons for creating a new site and application pool for each account?
A single site with a shared database (number 3 in your list) is a much easier solution that can scale much better. You can then scale up the number of web or database servers when needed. This architecture is used in e.g. Sharepoint and most public web sites.
The current application is a kind of CRM application built upon MS Access. The application is for internal use. My job is to migrate it to ASP.NET web-based application. Now boss requires to keep Access as database and develop ASP.NET code against it.
My question is, is there any disadvantages of using Access as database in ASP.NET application? (e.g. optimistic concurrency issue?) Should I persuade boss to upgrade Access to MS-SQL?
Many thanks!
We've used Access as a backend for web sites with good success. It's cheap, can be used effectively by moderately skilled programmers, and you can store the MDB on a document server so it gets backed up.
Most IT people dislike Access, but from a business perspective, Access can be very valuable.
MS Access is notoriously unstable in multiuser environments. A WEB app is by definition heavily multi-user.
So IMHO leaving MS Access as underlying DB is a call for trouble. At least use SQL Express (it is free)
The problem you are going to face in upgrading from Access to MS-SQL is that there is a major cost investment for the application. If your company already has the infrastructure in place(licensing, hardware...) then you won't have such a hard fight to pursuade your boss.
As for a technical answer:
I'd say you need to let you boss know that access databases aren't ideal for concurrent usage which a web application suggests is the intended goal of the application. My view is that Access is for database information that a SMALL set of users will be simply using for small data entry and querying. NEVER use Access to build an enterprise-level solution.
If you are planning to upgrade a Microsoft Access database to SQL Server 2008, use the SQL Server Migration Assistant (SSMA) rather than the upsizing wizard built into MS
10+ tips for upsizing an Access database to SQL ServerAccess.
Your boss probably likes to do ad-hoc stuff with access / excel. If you move the DB to SQL Server Express you can use Access and it's linked table feature to let your boss keep doing his ad-hoc needs through Access while keeping the data in SQL Server Express. If you keep the linked tables named the same as the old physical ones all his reports and queries will should keep working.
I'm an Access promoter, but not for use on websites because Jet/ACE is not threadsafe (though Michael Kaplan once said that is is threadsafe if you access it via ADO/OLEDB; I don't quite understand how a database abstraction layer can wash away a characteristic of the underlying database engine it's calling, but if MichKa said, it's 99% likely to be true).
Now, the exceptions would be if you're using it for prototyping something that will use a different database, or if it's read-only, or is read-write but will only ever have a very small number of users.
Michael Kaplan's website, trigeminal.com, used to use a Jet database as the back end (it may still -- I don't know that MichKa ever changed it), and when that was his main website he reported getting 100K hits a day. But it's a read-only site, so fits my restrictions.
There are so many different alternatives and they are mostly easy to use that I just don't see the point of trying to use Jet/ACE as back end for a website. I'd never do it myself (all the websites I'm responsible for use MySQL).
Simply put, go with MSSQL. Express edition is free, and will give you everything you need to migrate away from Access. These articles are talking about Access applications specifically, but the same issues will plague you.
http://resources.zdnet.co.uk/articles/features/0,1000002000,39285074,00.htm
https://web.archive.org/web/1/http://techrepublic%2ecom%2ecom/5208-6230-0.html?forumID=102&threadID=205509&messageID=2136367
The application is planned to be built using ASP.NET, .NET Remoting & MS SQL Server.
High availability is required at presentation layer, application layer and database.
Does IIS 7.0 provide any advantages over IIS 6.0 in regard to the High availability aspect?
Among the many aspects you want to consider, make sure that you have numbers.
By numbers, I mean how many request per second do you want to deliver? How many users per day are you planning? Are they all going to come in 1 hour or through out the day? Are they simply buying stuff on a e-Commerce website or is it a social network website with lots of pictures and videos?
All those questions matters in how you will architecture your website. If you go with a simple e-Commerce website that should not crash, make sure to have 2 servers with load balancing with some health monitoring on the IIS process. For the database, 1 machine will do the trick especially if you have some RAID hard drives.
However, if you go toward a social network site... things get freaky fast. If users upload pictures, you will need lots of space and much more if they upload videos. You might want to use Cloud Service to host those pictures without too much fees. For videos, you might want to use embeded link like Youtube or Google video.
As for IIS 7.0 versus IIS 6.0, I don't think there will be any significant changes. Both are really reliable.
Take a look at the High Scalability Blog
Make sure your design scales in a horizontal manner.
That is, have your system hiding behind a load balance layer with the servers that are actually providing the service behind the load balance layer.
When you need to increase capacity, you build a new server or servers and plug it in alongside the existing servers. Then you configure the load balance layer to also consider the new server(s) when passing out the work.