My application contains 25 C# projects, these projects are divided into 5 solutions.
Now I want to migrate these projects to run under Windows Azure, I realized that I should create one solution that contains all my web roles and worker roles.
Is this the correct way to do so, or still I can divide my projects into several solution.
The Projects are as shown below:
One Web application.
5 Windows Services.
The others are all class libraries.
Great answers by others. Let me add a bit more about one vs. many hosted services: If the Web and Worker roles need to interact directly (e.g. via TCP connection from Web role instance to a specific worker role instance), then those roles really should be placed in the same hosted service. External to the deployment, your hosted service listeners (web, wcf, etc.) are accessed by IP+Port; you cannot access a specific instance unless you also enable Azure Connect (VPN).
If your Web and Worker roles interact via Azure Queues or Service Bus, then have the option of deploying them to separate hosted services and still have the ability to communicate between them.
The most important question is: How many of these 25 projects are actual WebSites/Web Applications or Windows Services, and how many of them are just Class Libraries.
For the Class Libraries, you do not have to convert anything.
Now for the Cloud project(s). You have to decide how many hosted services you will create. You can read my blog post to get familiar with terms like "Hosted Service", "Role", "Role Instance", if you need to.
Once you decided your cloud structure - the number of hosted services and roles per each service, you can create a new solution for each hosted service.
You can also decide that you can host multiple web sites into a single WebRole, which is totally supported and possible, since WebRoles run in full IIS environment since SDK 1.3. You read more about hosting multiple web sites in single web role here and here, and even use the Windows Azure Accelerator for Web Roles.
If you have multiple windows services, or a background worker processes, you can combine them into a single Worker Role, or define a worker role for each separate worker process should you desire separate elasticity for each process, or your worker require a lot of computing power and memory.
UPDATE with regards to question update:
So, the Web Application is clear - it goes to one Web Role. Now for the Windows Services. There are two main considerations that you have to answer in order to find whether to put them into a single or more worker roles:
Does any of your Windows Services require excessive resources (i.e. a lot of computing power, or
lot of RAM)?
Does any of your Windows Services require independent scale?
If the answer for any of the questions is "yes", then put this Windows Service in a single Worker Role. Put all the Windows Services that the answer for both questions is "no" in a single Worker Role. That means that you will scale all of them or none of them (by manipulating the number of instances).
As for Cloud Service (or the Hosted Service), it is up to you to decide whether to use a single cloud service to deploy all the roles (Web and Workers) or use one Hosted service to deploy the Web Role and another one to deploy the Worker Roles. There is absolutelly no difference from billing prospective. You will still have your Web Role and Worker Role(s), and you will be charged based on instances count and data traffic. And you can independently scale any role (change the number of instances for a particular role) regardless of its deployment (within the same hosted service, or another hosted service).
At the end I suggest that you have single solution per Hosted Service (Cloud Project). So if you decide to have the Web Role and Worker Roles into a single Hosted Service, than you will have a single solution. If you have two Hosted Services (Cloud Projects), you will have two solutions.
Hope this helps.
You are correct ! and all projects goes to under 1 hosted service if you create only one cloud project for all your webrole and worker role project
Still you can divide your projects into several solution and you have to create that much cloud project and hosted service on azure platform
You can do both.
You can keep your 5 separate solutions as they are. Then, create a new solution that contains all 25 projects.
Which solution you choose to contain your Cloud (ccproj) project(s) will depend on how you want to distribute your application.
Each CCPROJ corresponds to 1 hosted service. So you could put all of your webs and workers into a single hosted service. Or you could have each web role as a different hosted service, and all of your worker roles together on another hosted service. Or you could do a combination of these. A definitive answer would require more information about your application, but in VS, a project can belong to more than 1 solution.
Related
I'm using a Google Service Account to push MySQL backups from our webserver to Google Drive using a Google API PHP client script setup as a cron job.
I now want to run the same script across multiple webservers, I'm not sure how to correctly configure the service account for this, should I?
Use the same service account and service account key/credentials across all servers?
OR Use the same service account, but add a service account key/credentials for each server?
OR Setup a separate service account for each server?
Your requirements/needs/whatever may vary, but this generally it won't wont matter how you do it.
Single project
Create a project on Google developer console, and create a single service account key file and share it across the servers.
Is the same as.
Creating a project on google developer console and creating three separate service account credentials with different key files.
You will be bound by the same quota limits because all are under the same project.
Three separate projects.
Now if you created three different projects and create a single service account credential for each of the different servers. Then you would see a difference as they are different projects so should be bound by different quota limits.
quota
The Google drive default quota is so high anyway i'm not sure that it really matters what you do.
Security
Even security wise if you have a different file and you were hacked on one server you would't gain or loose anything by the other servers not having the same or different key files.
I have a project and I'm planning to start the web app as an Azure Web Site and then migrate it to an Azure Cloud Service (also called Hosted Service) if it is needed as a scale strategy.
The decision is because I read that Azure Web Sites are more simple and fast to develop with almost no Azure-specific configurations or code. So starting fast and simple is a good starting point for the project.
But, is that a good starting point for you?
Is migrating an Azure Web Site to an Azure Cloud Service the same as you were migrating a normal ASP.NET Website to an Azure Cloud Service?
Would you start with an Azure Cloud Service right from the beginning? If yes, why?
Thanks for your time.
There are benefits to both deployment models, it will eventually come down to what you are trying to achieve and ultimately the success of your application.
Below I've outlined the Pros and Cons of each of the models to ensure that you're making the right choice for your applications goals.
Windows Azure Web Sites
You have properly identified that Windows Azure Web Sites is a great starting point for an application, however you could also consider that Web Sites does offer enough scalability for many solutions.
Pros
10 Free sites during preview [Free for 12 months]
Easy Deployment (use Git, TFS, Web Deploy or FTP)
Quick Scalability (You can move to your own dedicated cluster [aka reserved standard])
Simple Development (Supports Classic ASP, ASP.NET, Node.js, Python & PHP)
Persistent Environment (most people are used to this)
Cons
No SSL Support on Custom Domains
in Preview (currently no SLA)
Windows Azure Cloud Services
Cloud Services (formerly known as Hosted Services) is definitely the vision for the future of Web Applications. It is built with resiliency in mind to keep the cost of applications affordable by scaling to meet demand, and dial back capacity when your traffic slows.
Pros
Increased control over the cost of your application (if architected correctly)
Flexibility (You have full control over the environment)
SSL Support
Language Agnostic
Web Server Agnostic (although IIS is available by default)
Auto Management of Servers
Cons
Architecture should be carefully considered
Deployment time is slower (Slows development cycle)
Things to consider for Portability
The items above might have given you enough to plan the immediate future of the application and it is very likely that you might want to consider Cloud Services in the future (it fits a number of application scenarios better in the long run).
Here is a list of things to help portability between Web Sites to Cloud Services:
Start thinking Stateless
Windows Azure Web Sites is nice as it is a persistent environment, which means you are able to store things like session state and assets to the disk.
Although this is a good feature, it's best to start planning towards a stateless application, if your end goal is to be in Cloud Services. Here are a few things you can do to start thinking stateless:
Don't rely on Session State
If you need it, come up with a strategy to make it scale (Caching Service, SQL, or Storage)
Use the Storage Service
Assets such as Static HTML, css, javascript and images are better placed in Storage
Avoids additional bandwidth on your Web Site (potentially stay shared longer for lower cost)
Can be CDN Enabled, provides a better experience for International markets
Easier to update web assets when application is migrated to Cloud Services
Storing User content
If your application already stores to the Storage Service, there is one less code modification in the future when moving to cloud services.
Make it easy to discover patterns in your Data
The benefit of Cloud Services is it enables you to reduce cost by only scaling what needs scaled. Starting the process of identifying your scale units i.e. How you partition your database or Tables in Storage.
I read all post and all of them are very helpful.
In addition to all post , I found an info on msdn : Windows Azure Websites, Cloud Services, and VMs: When to use which?
With Windows Azure Websites you can:
Build highly scalable web sites on Windows Azure.
Quickly and easily deploy sites to a highly scalable cloud environment that allows you to start small and scale as needed.
Use the languages and open source applications of your choice then deploy with FTP, Git or TFS, and easily integrate Windows Azure services like SQL Database, Caching, CDN and Storage.
With Cloud Services you can:
Build or extend your enterprise applications on Windows Azure.
Create highly-available, scalable applications and services using a rich PaaS environment. Support advanced multi-tier scenarios, automated deployments and elastic scale. Deliver great SaaS solutions to customers anywhere around the world.
And also there is summarizes the option on msdn :
And comparing some features Web Sites and Cloud Services on msdn:
Azure is a great place to have your app, but there are some considerations you need to know before start migrating it.
Azure Websites and Hosted Services are really trivial to deploy. With
Visual studio you generate the package and simply upload it. Then you
have a Development environment to check it. If it's ok for you, swap
ips. If it's not ok for you, upgrade again.
Your instances have some properties that could be annoying. For
example, you cannot be sure about your IP. Then if your app works
with some provider using IP restriction, you will need to figure out
how to proceed.
More considerations. Your "server" could be reimaged at any moment.
If you store something on the local disc, that file could go away at any moment.
Azure works very nice if you have at least 2 instances or more for
each website. Maybe your app is not prepared for that. The first step
will be managing the sessions with the appFabric. Is really
easy, just a change on your web config. Be careful because this
session state doesn't work exactly as the "old one". You cannot store
non-serializable objects (should be easy to adapt) or a very large objects (more than 8MB).
If you are going to develop something from zero, I suggest you to start into azure from the beginning. The reason is simple: it's really cheap to start and you will not pay serious money until the app have lot's of visits. It's also very cheap to setup a SQLAzure and a storage account. One you have all in place, it's easy to add more instances or scale up.
Example:
Imagine you have an idea and you wish to show up to some possible investors.
You start setting up a little SQLAzure database (1GB ), $9,99 monthly.
Then you build a site and you put 2 extra small instances, $18,72 monthly.
Let's say you need 100 GB of space (images, backups, ...), $12,50 monthly.
At his point, you have all in place to start your business paying less than $50 monthly.
If you site have exit and the visits starts to come, you change your instances for small instances (it's really dangerous to have production environment with extra small instances, because do not have cpu reservation). Then you change the extra small cost ($18,71) up to $57,60. Maybe you need more space to that SQL Azure? etc...
prices calculated from here: http://www.windowsazure.com/en-us/pricing/calculator/?scenario=web .
Those are few tips, there is a lot more. My advice is to start a trial account and play with it.
Final advice: Its very easy to solve everything just purchasing more resources. Sometimes you need to refactor and optimize your code. If you simply add more resources each time you have a problem, you could end with a huge bill and a very messy code.
Hope it helps!
Another advantage of Windows Azure Cloud Services over Web Sites is that a cloud service can be added to an Azure Virtual Network. This can give it access to on-premises resources like databases. So if your requirements are such that you need the scalability offered by Azure but need to keep your data on-premises due to security restrictions, cloud services is a better choice.
Azure web sites cannot be part of an Azure virtual network. To access on-premises resources mechanisms such as Azure Service Bus Relay must be configured.
We've had our web site running on PHP on some hosting and at some point decided to move it to Azure (where sits main part of our service). We've started with Azure Web Sites which was great from development point of view (mainly integration with git). But after about a week of testing (when we've decided to actually move the production web site) we've found that currently
No SSL for custom domains
Custom domains are available only for reserved instances (no shared infrastructure)
SLA
So we moved to Hosted Service. The main problem for us was lack of ability of simple deployment (need to build package and upload whole package of the web site), and found solution was to use dropbox - as a startup task for role, we're installing dropbox service on the machine, which takes all the web site from dropbox, which in turn have SVN checked out folder, so site updates became very easy.
I'm researching some Windows Azure stuff, in order to make a decision whether to move to Azure or not.
Basic information
To answer the question, you'll need some basic understanding of my app so here goes.
The app is an ASP.NET MVC 3 application that connects to a SQL Server database.
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server, deployed to IIS 7 as a website.
I have one SQL Server, where each instance has its own database.
I also have a set of Windows Services to do some background processing. That should be straight forward, as I'll just rewrite those to use a Worker Role in Windows Azure - most of the logic in the services is located in their own class (library) anyway, so the service it self just calls one or more methods in a class.
Now to the question
Whenever someone signs up for a free trial, I add a record to an Admin database I have.
I then have a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders, runs the database deployment script and updates the record to reflect that it has now been deployed, and finally sends an e-mail to the prospect that their free trial has been created - here's how you access it.
So, how can I deploy a new instance in Windows Azure from a Worker Role? Preferably, I'd just add a new website to an existing Azure instance and create a new SQL Azure database for that particular site to use.
Does this require a lot of work to set up? Is it even possible?
Based on two quotes, I would like to suggest calling this a multi-tenant application:
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server,
And...
a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders
If I understand correctly, there is "one" IIS server (well, in Windows Azure, it's one Web Role, scalable to multiple instances), and with each new "tenant", you set up some new stuff to support that tenant.
If that's indeed the case, you can definitely do this from a worker role - just look at Nate Totten's multi-tenant web role blog post and related code. Look at the webdeploy code that actually manipulates IIS.
Further: take a look at Cloud Ninja, a project a few of my teammates published along with Fullscale180. This is a multi-tenant app that demonstrates how to manage multiple customers in a single deployment, as well as monitoring and scaling.
Finally: should you need to actually create brand new service hosts and storage accounts, the latest updates to the Windows Azure Management API support this.
I hope that helps a bit...
I think most of the things you want to achieve are possible.
It will definitely require some work to setup!
For some ideas on how to achieve what you are looking for, take a look at the MS SaaS example - http://www.fabrikamshipping.com/ - especially designed for porting existing apps to SaaS on Azure. Inside this app they have an "onboarding process" - and that process includes setting up new SQL connections and new portals.
There's lots of good blogging (watch the video) about this on http://blogs.msdn.com/b/vbertocci/archive/2010/10/07/new-online-demo-introducing-fabrikamshipping-saas.aspx
If i have a multi-tenant asp.net MVC application, something like basecamp ,what's the suitable hosting plan for me, is it a "Shared Hosting" or "Dedicated Server" is best fit for me.
Some parameters for the project:
- Each tenant will have a different database.
- Each tenant will have its own sub-domain.
- Expected number of tenants in the first year for the product, about 1000 tenant.
So how can I manage the hosting part of this project ?
Am open for any suggestions even if they are not part of my question.
To decide which infrastructure best fits your application you need to take into account parameters like how "active" your tenants will be or how "heavy" your application is.
For example, a simple, read only application for 1000 user may fit a pretty small dedicated server. But a different system may need a couple of DB servers and 3 web servers in a load balanced configuration (a basecamp-like with 1000 users may need a configuration like that)
You should not underestimate this problem: I don't think that a single server would be powerfull enough, and when you have more than one server your sysadmin problems start to grow :)
Remember that another viable alternative is hosting your application in a cloud environment (ie: http://aws.amazon.com or Microsoft Azure). But sometimes going to the cloud need a different approach on application's architecture.
Also, remember to take into account consideration like the availability of your application (ie: what happens when the server goes down?)
I am a web developer that are working on several web applications. For my projects (running in a production environment), I always strive good performance.
So, I have started to look into Microsoft Azure. I have deployed some test-apps and they all work fine. They all run a lot quicker than on my regular shared hosting environment.
My questions are:
1. What should be ran at Azure? Are you suppose to deploy your whole web app (along with images, scripts etc) or are you just suppose to deploy services? (such as WCF)
2. It says "Data transfers within a sub region are free.", but what is a sub region?
3. CNAME works, but is it possible to use A-records of a domain to Azure?
For web sites that are just jQuery slabs calling web services Azure is very easy to adopt. Azure can store any type of file, so for traditional web sites follow this guide
Azure process to Azure process, or Azure SQL etc. May included other non Azure services within the same Microsoft network area. Basically they are saying LAN access if free, whoopee
What would you point you A-Name too? Azure is virtual
Here are the answers I can give you:
It depends on what you want and what kind of (web)application you want to build for Windows Azure. If you're going for fast performance, perhaps it is faster to deploy everything to the cloud (but face the financial costs)
A sub-regio is North-Europe, another one is West-Europe. So data transfering inside North-Europe will be free of charges. But if you have data transfering between North- and West-European hosted application/services you pay for this.
Note: North- and West-Europe form 1 region
Sorry, can't give an answer to this one
Azure is definitely geared to handle more than just hosting web services.
Putting all your web site's static content in Azure storage should enable you to take advantage of the Windows Azure Content Delivery Network (CDN) service, which basically replicates your static content out to geo-local caches at the edge of the cloud to reduce network load on your Windows Azure web roles and improves the responsiveness of your web app for your end users scattered around the world.
Read more about the Windows Azure CDN here: http://blogs.msdn.com/windowsazure/archive/2009/11/05/introducing-the-windows-azure-content-delivery-network.aspx