Having being unsuccessful to find a decent resource I am finally asking it over here. I have a legacy .Net Frmework Windows Service (which is now migrated to .Net Framework 4.7.2) which I want to eventually migrate to Azure PaaS. After looking around I found 3 ways I could do that and not counting the options like hiding it behind a web app hosted in IIS because I do not think that is the correct solution. I think the correct ways are:
1) Use Worker Role: This is provided by the legacy Cloud Services platform and due to its slow deployments and staging costs is out of question.
2) Use Web Jobs: It may need code changes but I am unable to find a decent article or tutorial in the context of windows services.
3) Use Containers: This seems to be the solution most suitable but I want some expert to guide me through it as I am completely new to docker and azure. Since the service is in .Net Framework, the target OS could only be Windows Server Core(https://learn.microsoft.com/en-us/dotnet/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers) but when I pull the image I get the message that it "cannot be used on this platform". I am using Windows 10. Does this mean that I need to be working on Windows server family OS to be able to pull image which effectively means that to be able to deploy .Net Framework application in an Azure container, I need to be working on Windows Server OS.
Links to a few good reads or videos are welcome as I am unable to find may be because I am not searching it correctly. I would imagine that windows service migration to Azure is a common scenario but I may be wrong.
Do follow the steps mentioned here
,
https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker
Also for your windows service, you do have a couple of other options as well
1) Convert your app into an Azure Function and run it on timer trigger. But your app must complete execution within 5 minutes.
2) Deploy your app as a timer triggered web job.
Related
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 have developed a windows service. i need to deploy it in Azure App Service. Please someone explain me how to do that. Is there any way to install it on console or any other option.
You can't deploy a Windows Service using App Service. One option is to convert your code into a Web Job. Another option is to use a Virtual Machine instead of App Service.
Azure App Service is the service that should be used for Web/Mobile and basically is the web-server-as-a-service. You have almost no access to the underlying system, and system-wide actions like a working windows service is likely impossible.
I see three ways:
1) Migrate to Worker Role, but it is classic model. There is a good article on how to do that, i took a look and did not see any potential problems. It is more simple way.
2) Migrate your windows service to Web Job and run it as a background service. It will need you to rewrite some parts of your service, i think - but there are supported executable formats out-of-the-box. Take a look at how it works.
3) Take a look at Azure Functions - it is "trigger-and-invoke" service that can be used for listening for events and executing actions.
But, if you need to catch some events from DB, then i am not sure that it will be possible with that, because Web Job is more like a service that listens for external events, and yours scenario looks like you want to catch events from the same server. That way, i would recommend you to place it on a virtual machine to avoid the rewriting or migrating time-consuming issues.
Exist three ways for deploy Node.js app on Windows Azure, web-role, web-site and git-azure (link). I don't know whitch is most efficient for my needs. My app is readability algorithm with RESTful API, whitch parse news sites, simple computing, but highload. Of course, I need transparent horizontal scaling. I hope for your help.
My $0.02.
If your product is only based on Node.js, without many layers and components such as background workers, business logic layer and API layer, Windows Azure Web Site should be the best choice. It's very simple to deploy Node.js application through Git, GitHub, TFS, FTP, etc. It also provides scaling-up (in reserve mode) and scaling-out options. But keep in mind that all applications under Windows Azure Web Site will be running in 32bit WOW mode.
Windows Azure Web Role is similar as Windows Azure Web Site, but you need configure the Node.js environment by yourself. (If you are using the azure powershell tool, it can help you establish the node stuff by using some startup commands.) If you need something working in worker roles, or the caching (not the shared caching), Web Role may be better.
I've never heard about the git-azure but it looks like a tooling that you can host more than one node application on worker role.
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.
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.