3

I have a .NET Core Console Application that I need to deploy to Azure and schedule to run once a day. The application is creating a TCP Socket to get market data. I need to schedule it to run in the morning, and the application will receive a close message near the end of the day from the market and automatically close. Approximately run time is estimated at 16 hours, 5 days a week.

Here are the option I've looked researched:

  • Cloud Service, which might be deprecated (I'm having a hard to validating the comments I've read to this effect)
  • Service Fabric - but this really looks like it's tailored for stateless applications that can spin up and down for scale. In my case, it should always be a single instance (I do like the self "healing", if my service does go down, it would be great if it is automatically restarted or a new one is spun up)
  • Azure Web job and azure scheduler. It looks like I could set this to "always on" and add a settings file that has cron configuration, but it seems like a waste of resources to have it "always on". This option also appears to be limited in it's deployment options - I can't set up (that I see) a git integration and auto-deploy. This does seem like the way to go

I'm looking for the pro's and con's of these options above for my use case, or any other options that I might have missed.

Community
  • 1
  • 1
Prescott
  • 7,312
  • 5
  • 49
  • 70

5 Answers5

3

There's one thing that seems to be overlooked here. This part:

The application is creating a TCP Socket to get market data.

Is that 80/TCP or 443/TCP? Does it talk HTTP over one of those ports? Because if your application talks custom protocol over an arbitrary TCP port, you can't use WebJobs. The App Service sandbox does not allow arbitrary port binding. This applies ingress. Egress (outbound), there's no restriction. You can make raw TCP requests from the WebJob to any destination and port.

From https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#network-endpoint-listening:

Network endpoint listening

The only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet.

There's no need to involve the Azure Scheduler service. WebJobs have a built-in cron implementation which is completely free.

Also, the Always On feature really means hit this site with synthetic requests every couple minutes so it serves a 200 OK, and thus prevent the Application Pool from being unloaded from memory due to inactivity.

I would use the tank. Can't find anything wrong with the tank if you can pick your tank size. There's also very little maintenance with tanks.

Size (id)     Cores   Ram       Net Bandwidth   Total disk size
---------------------------------------------------------------
ExtraSmall    1       0.75 GB   Low             19 GB
Small         1       1.75 GB   Moderate        224 GB
...

ServiceDefinition.csdef if you need to listen on a socket:

<Endpoints>
  <InputEndpoint name="aRawTCPEndpoint" protocol="tcp" port="54321" localPort="54321" />
</Endpoints>

Where does your application keep state? Memory/disk/off-the-box database? Cloud Service roles are stateless in nature and if one instance gets sick it's barbecued and a new one is spun up. It's crucial that state be kept off-the-box, in durable storage - Blob/Table storage, Azure SQL, DocumentDB, etc.

Imagine you've build your house 6 years ago. And you've used this material called ClassicBrick in the structure. It is a good material, strong, waterproof, scratch-resistant. But recently this newer and better material - let's call it Armritis (which by the way is designed to be used in BRIDGES not houses, but i digress) came out which everybody tells you is better in every way. Do you tear down the house? Cloud Services are not deprecated and until i see an official Microsoft roadmap telling the opposite i'm not going to entertain this in any way.

On the topic of Service Fabric, it CAN do stateful and it's actually one of its biggest selling points:

From https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-quick-start/:

Create a stateful service

Service Fabric introduces a new kind of service that is stateful. A stateful service can maintain state reliably within the service itself, co-located with the code that's using it. State is made highly available by Service Fabric without the need to persist state to an external store.

Azure Functions is also worth a good look if you can speak HTTP over standard ports.

Community
  • 1
  • 1
evilSnobu
  • 24,582
  • 8
  • 41
  • 71
  • 1
    WebJobs have the built-in Cron, but it is only meant for testing in Free mode. Basically they mention in documentation that you should have at least Basic tier to use the Cron scheduling. [Link to doc](https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/#CreateScheduledCRON) – juunas Sep 30 '16 at 12:14
  • 1
    Always On is required since the `w3wp.exe` process that hosts the Web Job may go to sleep if there are no requests hitting the SCM site. If `w3wp.exe` is unloaded, there's noone around to kick off the cronjob. – evilSnobu Sep 30 '16 at 13:32
0

First, we need to compare the pricing between Cloud Service, Service Fabric, Web job &Scheduler if you doesn't want to wast resources. Here is the pricing calculator. Because your console application job will have special scheduler time to work. It is better to save money if the job is not work. So, Web job(if you have web app meantime) &Scheduler will be good choice to achieve your purpose.

Jambor - MSFT
  • 3,175
  • 1
  • 13
  • 16
  • 1
    I appreciate the feedback regarding pricing. Definitely something I want to think about. The piece about Web Jobs that bothers me is that I don't need the "Web App" piece, just the job. This solution, while seems like the one based on everything I've found, feels awkward – Prescott Sep 28 '16 at 10:38
0

Using a cloud service for such a tiny job is like using a tank to go to work

Service Fabric is mainly for building Micro-services style application not a console apps or jobs that run once a day

Web Jobs require a web app, so you have the remaining option which is the base for web jobs.

You can create the scheduler and make it run every day at specific time or execute it manually on demand

Haitham Shaddad
  • 4,336
  • 2
  • 14
  • 19
  • Do you know if cloud services are deprecated? Everything I've read seems to agree with your assessment of Service Fabric. – Prescott Sep 28 '16 at 11:08
  • Nothing formal, but I believe all the factors now point to its deprecation, I remember I watched a video on Azure Friday and the guy said that Cloud Services is deprecated and should not be used anymore, for new sites and applications we should go for the Azure Web Apps – Haitham Shaddad Sep 28 '16 at 11:14
  • I teach Azure courses, and Cloud Services were removed from the official Azure developer course. – juunas Sep 30 '16 at 12:25
0

I would go with either one solution, in this priority:

  1. App Service: Web Apps (Web Job)
  2. Virtual Machine
  3. Cloud Service

App Service: Web Apps (Web Job) provides a free plan. And it started to support Web Jobs in a free plan. You will be able to work with files, should you need it. Just as mentioned in other answers, just set a scheduler. If you have doubts and think it is not kosher to do it on a website, then think of it as getting a free website (if you use paid plan) as a bonus. Either way, everything runs on a machine - be it with web-server or without. Maybe you will even start some long-ago-forgotten web project of yours?

Cloud Service and Virtual Machine are both straightforward and simple. Gotta be honest, I haven't used Cloud Service, yet I think you can connect to it via Remote Desktop just like to an ordinary VM. You will have complete control. I would choose Virtual Machine over the Cloud Service though, just because it is cheaper.

Solutions that will NOT work:

Azure Scheduler does not fit you, because it allows only HTTP/S requests and posting messages to Azure Storage queues, Azure Service Bus queues, or Azure Service Bus.

Gabrielius
  • 1,045
  • 12
  • 18
  • But couldn't Scheduler be a good option for invoking the WebJob that actually does the processing? – juunas Sep 30 '16 at 12:11
  • @juunas, `Web Job` has its own scheduling system, no need to use `Azure Scheduler`. – Gabrielius Sep 30 '16 at 16:06
  • Yes but then the Web App must be at least Basic tier, costing more – juunas Sep 30 '16 at 16:08
  • @juunas, I just rechecked, you can create a `Web Job` and schedule it in a **Free-Tier**. – Gabrielius Sep 30 '16 at 16:31
  • 1
    Not with CRON expressions, you **need** AlwaysOn. [Documentation](https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/#CreateScheduledCRON) [Blog article](http://blog.amitapple.com/post/2015/06/scheduling-azure-webjobs/) – juunas Sep 30 '16 at 19:27
  • Also the [GitHub wiki](https://github.com/projectkudu/kudu/wiki/Web-Jobs) – juunas Sep 30 '16 at 19:33
  • @juunas, oh, I see what you mean. I completely forgot that **Free-Tier** does not support `Always On` feature. What I meant in my answer is that `Azure Scheduler` alone won't work. – Gabrielius Oct 05 '16 at 17:41
0

Personally I would go with a WebJob without AlwaysOn, and use Azure Scheduler to fire the WebJob at the desired times using HTTPS. Then the WebJob can do the calls needed to get the data. This does not need AlwaysOn since the Scheduler call wakes it up anyway.

Azure Functions might also be worth a look, though they aren't meant for long-running tasks.

This would also probably be the cheapest option as the Web App can probably run on Free tier (depending on how long the job takes) and the Scheduler can also be Free tier.

juunas
  • 54,244
  • 13
  • 113
  • 149