Azure Webjobs vs Funzioni di Azure: come scegliere


163

Ho creato alcuni Webjob di Azure che usano i trigger e ho appena imparato a conoscere Funzioni di Azure .

Da quanto ho capito, Funzioni di Azure sembrano sovrapporsi alle funzionalità di Azure Webjobs e ho qualche difficoltà a capire quando scegliere tra Funzione e Webjob:

  • A differenza di Webjobs, le funzioni possono essere attivate solo, non è stato progettato per eseguire processi continui (ma è possibile scrivere codice per creare una funzione continua).

  • È possibile scrivere Webjobs e funzioni usando molte lingue (C #, node.js, python ...) ma è possibile scrivere la propria funzione dal portale di Azure in modo che sia più facile e veloce sviluppare test e distribuire una funzione.

  • I webjob vengono eseguiti come processi in background nel contesto di un'app Web del servizio app, un'app API o un'app mobile mentre le funzioni vengono eseguite utilizzando un piano di servizio app classico / dinamico.

  • Per quanto riguarda il ridimensionamento, Funzioni sembra offrire maggiori possibilità in quanto è possibile utilizzare un piano di servizio di app dinamico ed è possibile ridimensionare una singola funzione mentre per un webjob è necessario ridimensionare l'intera app Web.

Quindi sicuramente c'è una differenza di prezzo, se hai un'app Web esistente in esecuzione puoi usarla per eseguire un webjob senza alcun costo aggiuntivo ma se non ho un'app Web esistente e devo scrivere codice per attivare una coda dovrei usare un webjob o una funzione?

Ci sono altre considerazioni da tenere a mente quando è necessario scegliere?


6
Questo è un post sul blog che devo. :) Cercherò di preparare una risposta, ma questo potrebbe essere un po 'aperto per StackTranslate.it, quindi potresti doverlo chiedere su MSDN se viene chiuso.
Chris Anderson-MSFT,

Nizza (breve) post sul blog su questo argomento geekswithblogs.net/tmurphy/archive/2016/06/02/…
Todd Menier,

Ehi Todd, sentiti libero di modificare la mia domanda per aggiungere il link. Articolo interessante ^^
Thomas,

@ chris-anderson-msft Possiamo eseguire PowerShell come webjob? Possiamo installare il pacchetto PowerShell su Webjob?
Anomepani,

Risposte:


170

Ci sono un paio di opzioni qui in Servizio app. Non toccherò App per la logica o Automazione di Azure, che toccano anche questo spazio.

Azure WebJobs

Questo articolo è onestamente la migliore spiegazione, ma riassumerò qui.

On Demand WebJobs aka. WebJobs programmati aka. WebJobs attivati

I WebJob attivati ​​sono WebJobs che vengono eseguiti una volta quando viene chiamato un URL o quando la proprietà schedule è presente in schedule.job . I WebJob pianificati sono solo WebJobs in cui è stato creato un processo Scheduler di Azure per chiamare il nostro URL in base a una pianificazione, ma supportiamo anche la proprietà di pianificazione, come menzionato in precedenza.

Sommario:

  • + Eseguibile / Script su richiesta
  • + Esecuzioni pianificate
  • - È necessario eseguire il trigger tramite endpoint .scm
  • - Il ridimensionamento è manuale
  • - La macchina virtuale è sempre richiesta

WebJobs continui (non SDK)

Questi lavori durano per sempre e li svegliamo quando si schiantano. È necessario abilitare Always On affinché funzionino, il che significa eseguirli nel livello Basic e superiore.

Sommario:

  • + Eseguibile / Script sempre in esecuzione
  • - Richiede sempre attivo: livello base e superiore
  • - La macchina virtuale è sempre richiesta

WebJobs continui con l'SDK di WebJobs

Questi non sono nulla dal punto di vista di "WebJobs the feature". In sostanza, abbiamo questo dolce SDK che abbiamo scritto come target WebJobs che ti consente di eseguire il codice sulla base di semplici trigger. Ne parlerò più avanti.

Sommario:

  • + Eseguibile / Script sempre in esecuzione
  • + Registrazione / dashboard più ricchi
  • + Trigger supportati insieme ad attività di lunga durata
  • - Richiede sempre attivo: livello base e superiore
  • - Il ridimensionamento è manuale da configurare
  • - Iniziare può essere un po 'noioso
  • - La macchina virtuale è sempre richiesta

SDK di Azure WebJobs

Azure WebJobs SDK è un SDK completamente separato dalla funzionalità della piattaforma WebJobs. È progettato per essere eseguito in un WebJob, ma può davvero essere eseguito ovunque. Abbiamo clienti che li eseguono su ruoli di lavoro e persino su prem o altri cloud, sebbene il supporto sia solo il massimo sforzo.

L'SDK sta semplicemente semplificando l'esecuzione di codice in risposta a qualche evento e rendendo vincolante per servizi / ecc. facile. Questo è onestamente meglio trattato in alcuni documenti , ma il cuore è che la natura "evento" + "codice". Abbiamo anche svolto un ottimo lavoro di estensibilità, ma questo è secondario rispetto allo scopo principale.

Sommario:

  • Molti di questi sono menzionati sopra
  • +Puoi estendere ed eseguire quello che vuoi. Pieno controllo.
  • - La roba HTTP è un po 'traballante, ma funziona

Funzioni di Azure

Funzioni di Azure consiste nel prendere quello scopo principale dell'SDK di WebJobs, ospitarlo come servizio e semplificare l'avvio con altre lingue. Introduciamo anche qui il concetto di "Serverless" perché ha molto senso farlo - sappiamo come il nostro SDK si ridimensiona, quindi possiamo fare cose intelligenti per te.

Funzioni di Azure è un'esperienza gestita in modo molto pesante. Non stiamo supportando il tuo host. Al momento, non supportiamo le estensioni personalizzate ma è qualcosa su cui stiamo indagando. Siamo convinti di ciò che puoi e non puoi fare, ma per le cose che abilitiamo sono chiari, facili da usare e da gestire.

La maggior parte delle cose "quadro" che abbiamo fatto per migliorare le funzioni passano attraverso l'SDK di WebJobs. Ad esempio, caricheremo un nuovo NuGet per WebJobs che aumenta notevolmente la velocità di registrazione, con enormi vantaggi per gli utenti dell'SDK di WebJobs. Nelle funzioni di spedizione come "WebJobs SDK as a Service" abbiamo davvero migliorato molti problemi di esperienza.

Probabilmente sono di parte dato che Funzioni è il nostro ultimo e più grande, ma mi sento libero di girare più contro per Funzioni a modo mio.

Probabilmente finirò per pubblicare un blog che elabora un po 'di più, ma ho cercato di mantenerlo il più breve possibile per questo forum.


1
Sembra fantastico. DM me su Twitter (@crandycodes) se avete domande. Posso aiutarti a ottenere i tuoi campioni promossi su Azure.com se vuoi, anche se vuoi condividerli.
Chris Anderson-MSFT,

1
L'ho visto utile. So che c'è molto spazio per discutere su come passare da modelli di applicazioni server a serverless. Questo tipo di sembra legato a ciò che hai appena descritto.
Chris Anderson-MSFT,

1
Fondamentalmente, prendiamo il tuo codice e la tua configurazione e creiamo una funzione SDK WebJob (da cui il nome Funzioni di Azure) sotto le copertine. Quindi il tuo codice viene eseguito all'interno di una funzione SDK WebJob che stiamo gestendo per te.
Chris Anderson-MSFT,

1
Ogni app per le funzioni ha 1 host (che potresti pensare come un WebJob). Le funzioni all'interno di un'app per le funzioni condividono un file system, le impostazioni dell'app, la memoria, la CPU, ecc. Sentiti libero di porre una nuova domanda.
Chris Anderson-MSFT,

2
Sì. Il grilletto del timer. Espressione cron di {0 * / 30 * * * *} azure.microsoft.com/en-us/documentation/articles/…
Chris Anderson-MSFT

17

Essendo Funzioni di Azure basate sull'SDK di WebJobs, forniscono la maggior parte delle funzionalità già disponibili in WebJobs, ma con alcune nuove interessanti funzionalità.

In termini di trigger , oltre a quelli già disponibili per WebJobs (ad es. Bus di servizio, code di archiviazione, BLOB di archiviazione, pianificazioni CRON, provider WebHook, EventHub e File Cloud Storage), le funzioni di Azure possono essere attivate come API. E le chiamate HTTP non richiedono credenziali kudu, ma possono essere autenticate tramite Azure AD e provider di identità di terze parti.

Per quanto riguarda gli output , l'unica differenza è che le funzioni possono restituire una risposta quando vengono chiamate tramite HTTP.

Entrambi supportano una vasta gamma di lingue , tra cui: bash (.sh), batch (.bat / .cmd), C #, F #, Node.Js, PHP, PowerShell e Python.

Essendo le funzioni attualmente in anteprima, gli strumenti non sono ancora ideali. Ma Microsoft ci sta lavorando. Speriamo di avere la stessa flessibilità di sviluppo e test delle funzioni a livello locale come attualmente facciamo per WebJobs con Visual Studio.

I vantaggi più significativi e interessanti offerti da Functions è l'alternativa di disporre di un Piano di servizio dinamico con un modello "Serverless" , in cui non è necessario gestire istanze di VM o ridimensionamento; è tutto gestito per noi. Inoltre, non avendo istanze dedicate, paghiamo solo le risorse che effettivamente utilizziamo.

Un confronto più dettagliato tra i due qui: https://blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)


Grazie per la tua risposta Paco! Questo confronto può interessare molte persone :-) Ma non stavo cercando un confronto ma stavo solo cercando di capire quando dovrei andare con le funzioni piuttosto che con i webjob!
Thomas,

6
È difficile avere una guida chiara senza conoscere il contesto. Ecco perché credevo che un confronto potesse essere di aiuto per le persone a scegliere :) Direi che: if (((preference == "Serverless") || (isRequired(flexibleHttpTriggers)) && (isOk(currentFunctionsTooling))) { goWithFunctions(); } else { continueWIthWebJobs(); } :)
Paco de la Cruz

Le funzioni possono restituire una risposta quando vengono chiamate tramite HTTP, ma le funzioni si basano sull'SDK di WebJobs. Strano, vero?
RudyCo

Probabilmente è meglio dire che erano basati sull'SDK di WebJobs, ma si sono evoluti un po 'da lì :)
Paco de la Cruz,

14

Secondo i documenti, Funzioni di Azure ha quanto segue che WebJobs non ha:

  • Ridimensionamento automatico (CPU e memoria vengono ridimensionate in base alle esigenze determinate in fase di esecuzione)
  • Prezzi pay-per-use (piano di consumo anziché piano di servizio app)
  • Altri eventi trigger (come WebHooks)
  • Sviluppo nel browser (Visual Studio ancora possibile)
  • Supporto F #

In poche parole: Azure Functions è l'animale più recente. Se non disponi già di un piano di servizio app, sceglierei Funzioni perché a lungo termine non vedo alcun motivo per cui iniziare con WebJobs sarebbe meglio (gli strumenti di Funzioni potrebbero non essere già stabili).


14

Vorrei aggiungere altri due punti ai precedenti post lunghi e un po 'vecchi. se si sceglie un piano di consumo con funzioni azzurre, di seguito sono riportati i limiti

Se si desidera eseguire lavori per più di 10 minuti, selezionare webjobs. Le funzioni di Azure vengono eseguite solo per 5 minuti per impostazione predefinita, se il processo supera i 5 minuti, la funzione azzurro genera un'eccezione di timeout. È possibile aumentare il timeout a 10 minuti in host.json .

Nota: non si verificano problemi di timeout se si utilizzano le funzioni azzurre del piano di servizio app.

Un altro motivo per distinguere è. se si utilizza la funzione azzurro, l'ora di inizio iniziale sarà lenta poiché le macchine (contenitori) vengono create al volo e distrutte una volta utilizzate.

Per evitare l'avvio a freddo, l'app per le funzioni azzurro ha rilasciato un piano premium, in cui un'istanza sarà sempre in esecuzione e in base al carico l'app per le funzioni inizierà a ridimensionare e ti verranno addebitati i costi per un'istanza e altre istanze in base al consumo.


Il tuo primo punto vale solo se stai utilizzando il piano di consumo, con uno sku pagato non hai alcun limite di timeout. Sono d'accordo con il secondo punto.
Thomas,

penso che entrambi i punti siano validi per il piano di consumo. Grazie per averlo segnalato
Karthikeyan VK,

4
Grande menzione dei timeout. Per noi questo è un fattore importante
Niels Filter,

1
Ma puoi scegliere il piano di servizio app durante la creazione di funzioni azzurre. Ma sconfigge l'intero scopo
Karthikeyan VK,

1
@KarthikeyanVK, non sono sicuro che sia ancora preciso in quanto la funzione runtime v2 consente più di 10 minuti?
Thomas,

6

Mi rendo conto di essere molto in ritardo con questa risposta, ma dato che questo è ancora un risultato di ricerca importante su Google, volevo dare una guida su questo argomento rigorosamente dal punto di vista dei costi poiché sembra che il PO abbia alcune preoccupazioni sui costi . Ci sono già alcune grandi risposte qui che parlano dei limiti tecnici e dei dettagli di come funziona ciascun servizio, quindi non ho intenzione di ripassare quelle risposte.

Se hai assolutamente bisogno di qualcosa che funzioni "gratuitamente" (come nessun costo aggiuntivo rispetto a quello che hai già pagato per la tua app Web), hai due opzioni:

  1. Webjobs: distribuito insieme all'app Web esistente e utilizza le stesse risorse dell'app Web. Non ci sono costi monetari aggiuntivi per usare i webjob ma ci sono alcune limitazioni, come già detto, che possono portare a costi di performance sulla tua app web.
  2. Funzioni: quando si utilizza il piano di consumo, viene assegnata una determinata quantità di esecuzioni gratuite. Il numero al momento della stesura di questo articolo è in realtà piuttosto elevato, 1 milione di esecuzioni gratuite. Tuttavia, il limite di esecuzione di 1 milione non è il limite che potrebbe causare problemi; sono i 400K GB-s (gigabyte di secondo). Questo è fondamentalmente un calcolo della quantità di memoria utilizzata dalla tua funzione moltiplicata per il numero di secondi che esegue (vedi il calcolo ufficiale nella pagina dei prezzi qui ). Rimarrai sorpreso dalla rapidità con cui questa assegnazione gratuita viene esaurita.

Se sei preoccupato per i costi ma non ti limiti a nessun costo , allora hai più opzioni disponibili.

  1. Funzioni: è possibile eseguire il piano di consumo o il piano di servizio app per un prezzo relativamente economico. Tieni presente, tuttavia, il modello di fatturazione di GB. Se stai usando il piano di consumo e stai facendo un lavoro frequente, "pesante", potresti essere sorpreso da una grossa fattura.
  2. Servizi cloud: questa opzione non è stata discussa come alternativa, principalmente perché l'OP non ha chiesto nulla al riguardo. Ma questa è anche un'opzione praticabile. I servizi cloud sono in definitiva solo macchine virtuali in esecuzione nel cloud, quindi puoi eseguire qualsiasi processo in background di cui hai bisogno e si scalano abbastanza bene (anche se devi collegare i tuoi trigger per l'esecuzione, un leggero inconveniente rispetto a webjobs / funzioni ). Hanno un costo iniziale più associato (perché paghi per istanza che tu lo usi o meno) ma se hai lavori che devono essere eseguiti costantemente e stanno facendo un sollevamento "pesante", i servizi cloud potrebbero essere una scelta migliore perché è più facile gestire / monitorare una VM a prezzo fisso rispetto alle esecuzioni e ai gigabyte di secondo, secondo me.

Se sei interessato a leggere alcuni scenari specifici e perché dovrei scegliere uno (webjobs, funzioni, servizi cloud) rispetto all'altro, di recente ho scritto un post sul blog su webjobs vs funzioni vs servizi cloud .


1
Grazie per la risposta @ Dan :-) Direi che il servizio cloud è ancora bello, ma stavo pensando di confrontare webjob e funzioni in quanto condividono lo stesso SDK di base e 2 anni e mezzo prima, non capivo davvero lo scopo del serverless :-)
Thomas,

3

Una considerazione importante è che Funzioni di Azure ha smesso di supportare .NET Framework completo dopo la versione 1, che è stata interrotta con la v2.0 e che non cambierà nell'ora di anteprima in v3.0. 😔

Nel frattempo, questo forte approccio armato non è stato fortunatamente applicato - ancora - ad Azure WebJobs :

La versione 3.x di WebJobs SDK supporta app per console .NET Core e .NET Framework.


Sì, buon punto. Tuttavia, d'ora in poi le persone dovrebbero provare a usare il core della rete il più possibile.
Thomas,

0

Vorrei fornire quali sono i punti in comune e le differenze tra le due funzioni di Azure basate su AppService e WebJobs SDK. WebJobs SDK ti darà più libertà di giocare mentre le funzioni di Azure sono più strutturate con meno responsabilità per gli sviluppatori.

Quando si osservano i punti in comune Entrambi utilizzano la modalità di programmazione orientata alle funzioni, i collegamenti per trigger / input / output, supportano le librerie esterne e possono eseguire ed eseguire il debug in locale dei prodotti da bagno Supportruntime.

differenze

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------

inserisci qui la descrizione dell'immagine

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.