Fotolia
Evaluate the Azure serverless tools to ease deployment anxiety
So you want to build a serverless application on Microsoft Azure? Explore the tools and features that support those apps and determine how you want to manage your eventflow.
To successfully build a serverless app on Microsoft Azure, you first need to determine its components -- both on premises and in the cloud -- and how those disparate pieces must work together.
Enterprises often choose Azure for their serverless computing either because they're already on Microsoft's cloud, or because their applications have a transaction processing front end that's feeding traditional data center applications -- a hybrid cloud.
Microsoft has focused Azure, particularly its serverless hosting and related tools, on the hybrid-front-end mission. And while it's important to understand why an organization might choose Azure for its serverless app, in this piece, we'll focus on how an organization successfully implements that workload.
Tools
Microsoft has designed a set of tools to support serverless computing, including Azure Functions. For consistency sake, it's important to only use these tools. While it is possible to use any general Azure web service with serverless, users may end up with pieces of their application in serverless form while others are conventional and persistent. This approach can defeat your goal of complete scalability and low management impact.
To make the most of Azure's serverless features, it's critical to start by laying out the eventflow -- the serverless equivalent of a workflow. The primary goal is to decide if the serverless application is either self-steering, where it directs work along the correct path based on its own logic, or orchestrated, where the event-to-process relationships and sequencing are defined by something else.
This will let users decide if they have a pure Azure Functions application or whether a service, such as Logic Apps or Event Grid, is also needed for an app with a mix of serverless and conventional resources.
Self-steering
A self-steering Azure application usually looks like the storefront design pattern -- where a function receives events and commonly passes them on to the proper function for handling. A good Azure feature to use is Azure Function Proxies, which provides some API management to specify endpoints and breakup large APIs into microservices.
If the goal is to process a transaction, there are multiple steps or events associated with a single transaction. Users will want to handle state, because functions are typically stateless. For self-steering applications, the easiest approach is to have the client device -- a browser or mobile app -- manage state and pass along needed information, which then follows the event through the serverless process.
Azure storage, a key component of self-steering apps, provides unstructured storage between processes as well as queuing from one function to another. The Azure File Storage service can fit most self-steering applications, but Azure Blob Storage is best for massive scalable needs.
Orchestrated
If an application isn't self-steering, users will need to define an external orchestration framework. There are two choices offered by Azure: Logic Apps and Event Grid.
Logic Apps is a set of visual-oriented connectors that describe an eventflow relationship as a string of processes and APIs. It's best for enterprise transaction processing that's developed entirely as functions. Logic Apps handles much of the integration of data and stateful processes with stateless/serverless functions, so it's a natural fit for writing most transaction front ends in serverless mode.
Due to the natural message orientation of Logic Apps, it integrates well with manual processes or with business partners, including those who use electronic data interchange, or EDI, to link commercial systems.
The orchestration of combined serverless and conventional components is a top challenge in serverless because it requires thinking in two modes -- stateless, fully scalable, nonpersistent processes versus stateful, static processes. Users never want to directly connect the two -- instead, use queues and signals to link data to processes.
This is where Event Grid, in particular, excels. Azure Storage can handle the queues and support the work exchanges. Additionally, Logic Apps can combine with Event Grid if needed.
Transactional processing is inherently stateful. And, for most enterprises, those processes are run in the data center. This makes it a natural fit for hybrid cloud for organizations that don't plan to move those processes off premises, but still want to extend the app to cloud-based front ends. That means that a serverless application has to harmonize with a traditional application that's stateful and nonscalable.
Azure Service Bus, a service mesh offering, forms a logical bridge between serverless front-end transaction processing and the rest of the application, which is usually in the data center, but can be migrated to the cloud using traditional Azure cloud services.
Most enterprises will use Azure Service Bus as the on-ramp between scalable/agile portions of their applications -- serverless or traditional -- and their conventional data center apps. In most cases, the serverless apps are feeding Service Bus rather than being connected through it. However, Service Bus can be used to connect services within the cloud. If the goal is the latter, use the Service Bus design and orchestration selection together to ensure the two are fully compatible.
