Recommended Configurations for Migrating to Windows Azure
-
2012년 3월 27일 화요일 오전 4:47
HI,
My company is entertaining the idea of migrating our offering to azure, and really we're infants in this space and not really sure what directly to go to; we've had a profile of the services and the HA offerings etc, set up some test accounts played around, looked at costing. And now in the phase of doing benefit analysis of moving;
27 Standalone applications
8 Web Services
9 Windows Services
16 Databases
To azure.
Though the biggest thing here is, where on earth do you start? what type of configurations are recommended? I can easily just jump on there and order 6 large servers, but i'm thinking that'll be over kill.
Some configuration's I've seen have been;
2 small instances per 1 application, would that be the most accurate method?
모든 응답
-
2012년 3월 27일 화요일 오전 5:44
Hi ausipr,
Please do not look at cloud from a traditional server space angle. You've to consider the following before you start designing the infrastructure:-
- Plan to fail
- Minimum 2 instances to guarantee availability
- 2 instances - forces your apps to be stateless
- Retry logic need to be built into apps to ensure connectivity to db and storage
- Capacity planning based on performance needs of applications
Unlike traditional hosting setup, Windows Azure is an hands off approach towards infrastructure. Your apps need to be compatible to the platform and you deploy your app via portal. No need to log into server and configure everything. Its a platform based approach towards deployment.
So before you start with Azure, analyze your apps on the points mentioned above and then deploy the applications.
A better approach is to take small steps towards Azure adoption. Move a non business critical app to cloud to get your hands dirty. The lessons will help your team to plan the rest of the migration better.
Thanks,
Jithendra
Cloud Architect
Thanks, Jay
- 답변으로 제안됨 BrentDaCodeMonkeyModerator 2012년 3월 28일 수요일 오전 11:23
- 답변으로 표시됨 MingXu-MSFTModerator 2012년 4월 2일 월요일 오전 6:23
-
2012년 4월 29일 일요일 오전 3:10
I would suggest starting as small as you can, and working your way up. The larger servers offer more RAM, more CPU cores and more network bandwidth, but you may be better off from a development and management perspective to partition your app among multiple smaller servers. You can easily switch from one instance size to another when you deploy.
Keep in mind that while having multiple apps on a single server is possible, it's not quite the same as running on a dedicated server (for example, SSL certs are visible from one app to another). Also, since local storage isn't persistent, and since blob storage comes with per-transaction costs, your apps may need to adjust accordingly.
Another way to say it is that architecture should come first.
Check out my book: Ultra-fast ASP.NET: Building Ultra-Fast and Ultra-Scalable Websites using ASP.NET and SQL Server

