I apologize right away if I misuse my right to ask questions here. Yet, being a tyro in web development and an ASP.NET beginner, I need some advice from the experts.
I have developed an ASP.NET WebForms application which I would like to deploy to a remote hosting server. The application constantly queries and updates the database due to its purpose of being a document registration system. It will be sold to different institutions so that I've imagined the following scenario: host the app on the same server for all the institutions and have the databases on a different server or on multiple different servers. I have considered this option because as the data amount expands the storage provided by hosting companies may be insufficient.
My question is: is it possible to accomplish this scenario and if yes what are the risks and how should I do it?
Thank you very much!
Yes, it is a normal way to do it. However, you need a fast network connection between the web server and database server. You would also need to consider the service level (ie percentage up-time) and how much redundancy is needed to achieve that.
There's an easy way and a harder way to achieve this.
The easy way is to host your application in Microsoft Azure. It is fast to implement and very flexible.
You can host the database in SQL Azure Database, which Microsoft recommend for new development. This can be scaled from very small (and low cost) to very powerful (more cost).
Similarly the web application can be scaled. You can scale it vertically, by making the machine more powerful, and horizontally by adding more machines.
For both the database and web application, the scaling can be changed up or down in a few minutes.
The harder way is to host the application on virtual machines. You would need a lot of knowledge to configure and maintain this. For instance, you might need to configure SQL Server AlwaysOn.
This screen picture shows how you can select the pricing tier for a web application hosted in Microsoft Azure. (Prices are in GBP.)
You should host the web app and the database in the same data centre to ensure there will be fast network connections between them. Also you can make them belong to the same "resource group", which tells Azure that they work together.
This shows how you can select the level for a SQL Azure database. (Prices in GBP.)
See Microsoft Azure > Azure pricing: https://azure.microsoft.com/en-gb/pricing/
You could do it, just consider the speed between the hosting server and database server.
Related
So I'm pretty green to the industry, please excuse what I'm assuming is huge swaths of ignorance. I'm looking to develop an ASP.NET webapp (with a SQL Server db) as a kind of in-house tool for our employees, accessible from anywhere. We're a company with virtually no IT infrastructure, so these employees (~100) will be accessing this application from all around the country on what are basically personal computers. I don't ever expect there to be any more than 10 users using the webapp concurrently. The web app is going to be the frame for a series of tools I've been making for the head office guys, but from a central point that's easy for me to maintain.
We have our own domain, so that's taken care of.
I'd like to find a cloud-based tool that would pretty much just involve me deploying my code to it, and that's about it. I've take a look at Azure and that seems like the way to go, but I know if I present a price too high the bosses won't exactly be thrilled.
I was hoping some of you guys had some experience in setting these kinds of things up. Here's a series of questions I'm having a hard time coming up with an answer for:
Looking at the Azure cloud-based webapp, What da heck specs do I get? Is Standard S2 too much power, or nowhere near enough?
Do I need to purchase an Azure SQL Server thingo seperate to the Web App hosting, or does it come bundled in?
How the heck do I deploy my dang code?
I've been getting off pretty easily as I used to have a team behind me, and now I'm alone at a new company, there's not many people whose brains I can pick. I've had a call or two with a Microsoft employee, and they were helpful, but not entirely helpful enough. They keep assuming I know what I'm doing - I don't. So any help from anyone would be greatly appreciated!
You need to learn two services of Azure:
1.Azure Web app service:
Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.
This document will teach you develop web app with Azure SQL and deploy your app to Azure.
2. Azure SQL database:
Azure SQL Database is a general-purpose relational database, provided as a managed service. With it, you can create a highly available and high-performance data storage layer for the applications and solutions in Azure. SQL Database can be the right choice for a variety of modern cloud applications because it enables you to process both relational data and non-relational structures, such as graphs, JSON, spatial, and XML.
Azure SQL database is a cloud database. If you have the develop experience with SQL server, you will be familiar to it.
Azure App Service and Azure SQL database are independent, in Azure, which service you want to use, just pay for it.
You need an Azure Web app service to host your app, and you also need a Azure SQL database. Then you can develop the app with Azure SQL database.
Each service has the different price tier to meet the performance requirements of the user. You need to choose the most suitable for your company to save the money.
Hope this helps.
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
I already have ASP.NET hosting, but I'm not sure how to run my application off Neo4j, since it requires a Java stack.
It seems my only options are:
Get separate Java/Linux hosting, and install Neo4J there, utilizing it as a database server.
Get Neo4J-as-a-service, (akin to what MongoHQ does for MongoDB users) but I haven't had any luck finding providers. Any advice here?
Move my whole application to Mono and then put it all on Java/Linux hosting and install Neo4j.
Any other ideas?
Yes there is such a thing very much indeed. We have just put Neo4j hosted in Windows Azure and as such it may naturally back an ASP.NET solution or any other front end solution that you might want to have!
Besides it is very easy to communicate with the Neo4j server from .NET since it speaks over HTTP using REST. It's as natural to speak to it as it is to speak with Windows Azure Storage.
http://neo4j.cloudapp.net/
I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application in azure.
What challenges could we possibly encounter when we try to port an existing asp.net application to azure? Are there any other alternatives to azure in cloud computing?
For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.
However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):
You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).
So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.
It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.
If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.
Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.
The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.
Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/
Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.
Also this question here What is the difference between an Azure Web Site and an Azure Web Role
Client has a bunch of Access databases and associated reports.
He wants to make the reports available (live, not snapshots) via a secure extranet.
He's willing to recreate the reports using a proprietary GUI if necessary, but ideally would like a solution that exports his reports "as is" to the web.
Had a look at Caspio Bridge. It's pretty slick but doesn't appear to offer grouping and summing (key requirement) without a nasty Javascript hack - seems like a rather glaring omission to me!
Any suggestions?
I'm an ASP.NET developer so if there's coding involved, an ASP.NET based solution would be preferred.
You can try Access Reporter.
http://www.ssw.com.au/ssw/AccessReporter/Default.aspx
You might like to consider Access 2010, point 3 of the linked document says:
Access your application, data, or
forms from virtually anywhere.
Extend your database to the Web so
that users without an Access client
can open Web forms and reports via a
browser and changes are automatically
synchronized.1 Or work on your Web
database offline, make your design and
data changes, and then sync them to
Microsoft SharePoint Server 2010 when
you’re reconnected. With Access 2010
and SharePoint Server 2010, your data
can be protected centrally to meet
data compliance, backup, and audit
requirements, providing you with
increased accessibility and
manageability.
-- http://www.microsoft.com/office/2010/en/access/default.aspx
SQL Server Express edition is free. It includes Reporting Services
http://www.microsoft.com/Sqlserver/2005/en/us/express.aspx
You can connect to the MS Access database (or any other database that you have OLEDB or ODBC connectivity for)
For your existing reports, here is a link on how to migrate just the reports to SQL Server (leave data in MS Access)
http://technet.microsoft.com/en-us/library/cc966391.aspx
Actually, the suggestion being given here is to move your back and data up to SQL server , but keep your front end application part as is in Access.
So the suggestion isn’t to move your application to SQL server. The suggestion here is to move only the data part of your application to SQL server but continue to use the desktop access application.
So, you link your tables to sql server, and continue to use the access application.
What this means that is you can use SQL server reporting services, or some other web based interface that pulls the data from SQL server. So your access application will be directly updating the data on that SQL server.
This setup works well since you not tying to shuttle data between two separate systems. I know a number of companies that successfully migrated their backend data to SQL server for this very purpose of allowing the Executives and the company Managers to view reports on a web based system.
However, they did not have to throw out or lose the investment and time they spent building the access application part.