Sturdy capabilities in Azure appear to resolve an important drawback of having the ability to run a fancy course of that requires stateful coordination between elements in a serverless style. They mix the facility of serverless with the flexibility to run one thing that may take longer to complete and requires intermediate states to be preserved. So you continue to pay for the time the concerned capabilities run simply that the method can run for longer.
It is true that sturdy capabilities open up a chance to course of one thing that’s going to take longer and is complicated when it comes to information switch and(or) stateful coordination between sub-processes, nonetheless, to attain the identical they arrive with sure constraints that may impression the execution of sub-processes or the way in which information is held and shared between elements and even the extent to which parallelism could be achieved.
Due to this fact it turns into crucial that after we select sturdy capabilities to resolve any of our use circumstances, we additionally have a look at the principles or constraints that we would wish to honor in order that we construct our options in probably the most environment friendly and efficient methods.
Let’s speak about a few of such constraints which we will consider,
Deterministic nature of Sturdy Features
Sturdy capabilities allow us to outline stateful workflows via Orchestrator capabilities. Orchestrator capabilities use occasion sourcing to make sure dependable execution and to take care of native variable states. The replay habits of orchestrator code creates constraints on the kind of code that you would be able to write in an orchestrator operate and one such constraint is that orchestrator capabilities have to be deterministic. Being deterministic means an orchestrator operate shall be replayed a number of instances, and it should produce the identical outcome every time.
The Sturdy Job Framework makes an attempt to detect violations within the deterministic habits of the operate. If it finds a violation, the framework throws a NonDeterministicOrchestrationException exception.
On account of the deterministic nature of Orchestrator capabilities, a few of the issues which gained’t work are,
DateTimeOffset.UtcNow
This worth goes to be completely different in every replay therefore it violates the deterministic habits of the operate. With the intention to have the present DateTime in an orchestrator operate, theIDurableOrchestrationContext gives the ‘CurrentUtcDateTime’ property which may safely be used within the orchestrator operate. This property can have the identical worth throughout replays till it’s used together with IDurableOrchestrationContext.CreateTimer() methodology that accepts a DateTime telling the context until when it has to sleep. As soon as the operate awakens, the CurrentUtcDateTime has the brand new worth in place.
GUIDs and UUIDs
When Guid.NewGuid() executes, it creates a brand new GUID each time subsequently if used inside an Orchestrator operate, it can trigger it to behave non-deterministic method. With the intention to work round this, the IDurableOrchestrationContext gives the NewGuid methodology which creates a brand new GUID and gives the identical throughout replays.
Setting variables or nonconstant static variables
Setting variable values can change over time and so is the case with nonconstant static variables, leading to non-deterministic habits of orchestration capabilities. As an alternative, these must be referenced from inside consumer or exercise capabilities.
Threading APIs
The Sturdy Job Framework runs orchestrator code on a single thread and might’t work together with another threads. Introducing new threads into an orchestration’s execution may end up in nondeterministic execution or deadlocks. If such APIs are essential, restrict their use to solely exercise capabilities.
Enter and output values for Sturdy Features
Orchestrator capabilities can invoke different orchestrator capabilities (as sub-orchestrators) or Exercise capabilities the place enter and output values could be handed. For every of those capabilities that take part within the full course of, the enter or output values should be JSON serializable as these are persevered to the orchestration historical past desk in Azure Desk storage.
For working with information of kind stream or file or bytes, it’s most well-liked to retailer them within the Azure Storage and use them via exercise capabilities. On a smaller scale, they are often transformed to base64 strings and used as enter or output values to go across the capabilities.
Single-Threaded behaviour of Orchestrator Features
The Sturdy Job Framework runs orchestrator code on a single thread. It will probably’t work together with another threads that may be known as by different async APIs or these that are created with out the usage of IDurableOrchestrationContext. This single-threaded habits of orchestrator capabilities permits them to be deterministic and in flip, ensures that the replay sample works appropriately and reliably.
Due to this fact any Async API or threading API calls should be executed inside Exercise capabilities and any blocking logic ought to use alternate options like Sturdy Timer.
I/O operations in orchestrator capabilities
Due to the deterministic nature of orchestrator capabilities and their capability to make use of replay patterns for going via a course of, I/O operations aren’t allowed inside their scope of execution. I/O operations can’t solely result in completely different values being set or returned every time replayed, however they’ll additionally trigger corruption of state on the supply or vacation spot. Furthermore, such operations can result in scaling and efficiency issues.
Due to this fact, when there’s a have to carry out I/O operations, the Exercise capabilities could be invoked which comprise the I/O logic. The enter/output information for/from these exercise capabilities could be moved round utilizing the Azure Storage linked to the Sturdy operate.
HTTP endpoint calls in Sturdy Features
Sturdy Features 2.Zero onwards, orchestrator capabilities can be utilized to invoke HTTP APIs. HTTP requests are despatched by orchestrator capabilities and their responses are serialized and persevered as messages within the Sturdy Features storage supplier which ensures dependable and secure orchestration replay. Nonetheless, the HTTP APIs which might be created and invoked from the orchestrator capabilities don’t help all the HTTP request options which might be potential from a local HttpClient. Some limitations are,
- Further latency is noticed with the HTTP request produced from inside orchestrator capabilities and customization of the HttpClient offered by the DurableOrchestrationContext can also be restricted.
- Orchestration efficiency additionally tends to get degraded with the massive request or response messages as massive messages should be compressed/decompressed and saved/retrieved in/from blobs as a substitute of queues.
- Payloads of Stream or byte kind aren’t supported.
- Calls that use Azure AD tokens for authorization are solely supported.
If any of those limitations have an effect on your resolution, it’s advisable to make use of exercise capabilities with personalized HTTP shoppers to make calls.
Identification administration in sturdy capabilities
APIs invoked inside Sturdy capabilities can solely absorb Azure Energetic Listing (Azure AD) tokens acquired via Azure managed identities for authorization. The Orchestration context has the aptitude to accumulate the OAuth 2.0 token, connect it to the related HTTP request as a bearer token and deal with the refresh and dispose of those tokens implicitly.
This makes it a boon for many who are able to make use of Azure AD tokens for his or her use circumstances nonetheless if the API or service being invoked from the Sturdy capabilities makes use of id administration completely different of Azure managed identities, then the method to acquire, keep and refresh the tokens should be carried out as a part of request execution and all of this must be executed inside the scope of exercise capabilities.
So these are a few of the constraints of Azure Sturdy Features to remember whereas designing an answer utilizing it. Sturdy Features resolve essential use circumstances utilizing a serverless strategy. It’s only a matter of understanding whether or not the use case you might have chosen to resolve utilizing the Sturdy Features matches with the given set of constraints.
