I have a need to implement an architecture which might be delivered on Azure but also has to run on a standard Windows Server. There is a direct correllation between Microsoft AppFabric Distributed Caching and the Azure Cache, but what technology could you recommend to proivide similar functionality to the Azure Queue on Windows Server.
I have three candidates
1) MSMQ
2) SQL Server Service Broker.
3) RabbitMQ.
The first is deprecated and the second requires a heavyweight SQL Server installation, and the third is popular but I dont have direct experience of it. Are there any other candidate technologies that I should consider ? (hopefully Microsoft just for tidy-ness, but I'd consider others).
Have you looked at Service Bus for Windows Server? It does still require a SQL DB, but you can use SQL Express 2008 R2 and higher.
Related
I am developing Mobile App .Net server and want to use the service on self hosted servers for production usage. The service will be deployed on IIS instead of Azure portal. I am working on offline data sync feature using Microsoft.Azure.Mobile.Server package. And for client Microsoft.Azure.Mobile.Client is being used. And all these packages and dependent libraries are open source as its available on github.
So, what about its licencing? Is there any limitation or licencing clause that restricts from using these applications without Azure portal?
Or its free to use?
As you mentioned, these libraries are open source licensed with Apache 2.0. So, you can use them without any problem, as long as you mention the original authors.
i have a web application which is created using .net framework 2.0 which is running on windows server 2003.is it possible to migrate that to Microsoft azure.if so does it require an entire rebuild on azure?
A really useful utility for this case is Azure Migration Assistant.
https://azure.microsoft.com/en-us/downloads/migration-assistant/
It will check all your IIS sites and show you if it can be moved up to an App Service, checking target framework, port bindings, etc.
If everything is ok, it can do the migration for you.
Worst case scenario, you can move your application to Azure inside a VM.
It depends on what you mean by "migrate".
If you think about moving as is, you have an option to choose IaaS, where you'll just get a VM and do what you want on it. That'll give you both full control as well as full responsibility over your app.
Otherwise, if you want to avail of the PaaS offering, you'll have to make minor tweaks to your application (assuming the framework version is supported).
I'm interested in the new proposal from Microsoft. And before I do something I'll ask some important questions.
Because I haven't found direct contact with Microsoft support I'm here.
What we have now
It's 4 virtual machines:
Windows Server with SQL Server;
Windows Server with 4 our services (.net 3.5);
Windows Server with our services (Bitrix(Apache on Windows with some features));
Linux as vpn server.
Questions
Main question is what's the best way to migrate our infrastructure to Microsoft.
It's some considered aspects
performance
easy setup
reliability
cost (it doesn't matter now)
Details
Will it be better to stay on virtual machines or try to migrate in azure as app services?
Will it be difficult to migrate from windows service app on .Net 3.5 to cloud app?
As I know Microsoft has its own offer for data storage and I don't need to get virtual machine for it do I?
Can it be private access to SQL DB only from my services or virtual machines (just paranoid)?
Ok... here we go...
Q:Will it be better to stay on virtual machines or try to migrate in azure as app services?
A:Depends on your application. If your application is cloud ready then azure services is your answer, if not, go for traditional hosting...
Q:Will it be difficult to migrate from windows service app on .Net 3.5 to cloud app?
A: Impossible to say without checking your source code. Thumb-Rule? No, it wont be a problem...
Q:As I know Microsoft has its own offer for data storage and I don't need to get virtual machine for it do I?
A:Depends. If by data storage you mean blobs then no you don't but be careful because the storage on the machines are not expansible! You should consider refactoring your code to use blob storage. BUT if by data storage you mean SQL Azure storage you have to be extra careful because of the 150GB limit... consider major refactor for database "sharding" in this case...
Q:Can it be private access to SQL DB only from my services or virtual machines (just paranoid)?
A: Depends. If by SQL DB you mean SQL Azure then YES, this is a native thing BUT if by SQL DB you mean the one that you're going to host on your VM, you CAN too but it's not a native solution. You'll have to get your hands dirty messing with the virtual network...
EDIT1: My personal recommendation is: Migrate your app to a cloud native app, specially if you have a multi-tenant scenario or you want to better deal with usage peaks or save on hardware/infra-structure investments. Remember "your business is to build and run software, not hardware"! (I don't know if that's your case... but its mine...)
Is there any ability to install a "development environment" for Azure, or a local equivalent that supplies all the same APIs, storage methods etc?
The end game is to not pay for Azure while I'm developing.
Yes, Azure SDK and Tools come with a local emulation environment that closely resembles real Azure and allows one to do most of development without ever deploying a single bit to Azure.
Emulation is provided for Roles and Azure Storage (Tables, Blobs, Queues).
If you need SQL Azure, suggestion is to use regular SQL Server and closely stick to compatible functionality only.
Just go to the Windows Azure page to download the SDK and tools - the installation is streamlined using the Web Platform Installer.
The local simulation environment simulates blobs, tables, and queues, as well as compute instances (although as separate processes, not as separate VM instances). The APIs all work in the local simulation environment.
To use SQL Azure, you'd need a real account. Same thing for the AppFabric services.
Just so you know: you can get a completely free account for 30 days, with SQL Azure, AppFabric services, and a few compute instances. Go to www.windowsazurepass.com, and use promo code DPWE01.
EDIT: Agreed with Igor in his answer: you can develop with SQL Server and then push your database up to SQL Azure. The latest SQL Server Management Studio supports SQL Azure-compatible sql output scripts. As Igor points out, just stick to compatible SQL (which is a very large subset of SQL Server).
The SDK is the way to go, but note, deploying worker role instances can be quite a bit more complicated, but testing locally once the SDK is installed, is fairly straight forward.
What type of projects/software applications are suitable for Azure and why?
Thanks
Rather than thinking of what can be supported in Azure, it might be more helpful to think about its challenges as you decide to port your app over:
Web applications. Since a Web Role hosts IIS, you'll generally have little issue porting a general-purpose asp.net or asp.net mvc website to Azure. There are some glitches you'll run into - see my related answer for more details.
UI. If your app has specific output similar to a WinForms app, you won't be able to run it since you have no video output.
GPU dependencies. If you're doing some background processing dependenton a specific GPU, you won't be able to run in an Azure VM.
Registry and other system-level access. If your app needs to update the registry or run an MSI, you won't be able to install your app.
Instance affinity. If your app requires session stickiness (e.g. a logged-in user MUST visit the same server instance with each access), you won't be able to accomplish this.
COM interop. COM interop is very limited, since you can't install anything via the registry. If you rely on Excel Services, you won't have that capability.
SQL limitations. SQL Azure is limited to 50GB today, and offers no ability to custom-tune the server instance. Also, while it does support a big subset of SQL Server, it doesn't support 100% of SQL Server, so it's possible some of your sprocs may no longer work. There's no SQL Agent today, so you'd need to recreate that functionality in a worker process.
That's just a quick braindump of some challenges you might run into - I'm sure there are others.
Just keep in mind that Azure is providing Windows 2008 Server images for your app to run on, so if your app can run in that environment today, and doesn't require things I listed, you should be in pretty good shape.
You can make most of the .NET projects working in Azure. Azure has support of following project types: web site (both ASP.NET and ASP.NET MVC), worker (background application) and wcf service.
Don't forget security too - there's various ways of authenticating onto Azure but none are as simple as just setting IIS/ASP to windows auth.