Practical ways to implement function as a service

The function-as-a-service implementation models

There are two possible implementation models for FaaS. The first is the workflow model, which is similar to traditional multicomponent application models. In this model, it helps to visualize the work as a transaction, an input that must process in order to create an output. The second type is the event flow model, in which each unit of work represents an event, a change in condition or status.

When it comes to basic function execution in the cloud or even in the data center, it's presumed that some sort of event triggers the execution of a specific function. FaaS applications that are based on event flow will rely on each function in the chain to generate a secondary event; that secondary event follows processing rules that will then invoke a different function. This, in effect, creates a cascade of events that would usually terminate in either a control response or a conversion to a traditional back-end transaction where the event flow acts as a front end to other business processes.

Event flow applications don't rely on special tools because the link between a process and data is fundamental to the implementation of functions. This means that the applications are, in a sense, self-organizing and self-scheduling. In a practical implementation, you need only ensure that the event chain is properly built and that you don't accumulate too much overall delay in the time it takes to identify, load and run each function in the chain.

Assessing available vendor offerings

Most enterprises today won't focus on pure event flow applications because their current apps are based on workflow. The structure of an application is more fixed when it uses FaaS for workflow applications. Because information follows a sequence of processing, you need a mechanism to steer work to processes one after the other, rather than relying on self-steering.

When you base an application's structure on stateless functions, you can use Amazon's Step Functions and Microsoft's Logic Apps to clearly define and control the structure.

Lambda and Step Functions

Amazon's vision of functional computing is perhaps the most radical of anyone's. AWS Lambda, its functions tool, assumes that almost everything in Amazon's web services inventory can both generate events and be activated by events. You could even argue that AWS Lambda is more about workflow and business application orchestration than about processing externally generated event flows. At its core, though, AWS Lambda integrates applications to Amazon services via events, so it's really an event flow application because of the fact that it's self-steering.

Step Functions is a good option because it defines a workflow that functions and traditional application components follow. It provides a second level of orchestration on top of AWS Lambda, and it's smart to plan any workflow use of functions by looking at Step Functions.

Azure Functions and Logic Apps

Microsoft has the advantage of a strong Windows customer base and an enormous population of Office users among workers. All of this activity can both generate events and be triggered by events, and it gives Azure Functions an unparalleled ability to build functions that integrate with legacy tools. Because of this advantage, many often see Microsoft as the leader in the enterprise cloud computing market.

Azure Logic Apps, which lets you build event-driven integration links using a form-based interface, expands the natural advantage of productivity app integration. Logic Apps extends the orchestration of applications through events and functions to even savvy line department users. Logic Apps is especially strong at integrating Microsoft tools and Azure applications into social media-driven frameworks -- a hot button for enterprises.

Google Cloud Pub/Sub, Functions and Firebase

Google has its own model for function orchestration based on Google Cloud Pub/Sub, Google Cloud Functions and Google Firebase. Firebase, a database-centric view of how events can activate database-related functions, is the one that likely interests enterprises the most.

However, Google has not exposed nearly as much of its function capabilities to orchestration, and it has nothing to integrate with on-premises tools unless users adopt Google Docs.

A final word on function as a service

The approach that cloud providers take is far too different to assume that you can sensibly move your functions from cloud to cloud without a lot of work. Find a platform that's best for your needs in the short term, and then design and test in that platform. Address portability concerns at a later time.

One reason for this approach is that functional applications and their tools evolve quickly. It's likely that all of the cloud providers will eventually provide similar capabilities in regard to enterprise desktop, data center, cloud application and social media integration. At this point, it's impossible to say just where that convergence will happen, so pick a workflow approach that works for you. Then, revisit the question in a couple of years, and evaluate for any portability needs.