Serverless Works Best in API Architectures
At Serverlessconf last month, new features and tooling were unveiled for both IBM OpenWhisk and Microsoft Azure Functions that lean heavily on what has proven to work in API-enabled architecture.
One of the central tenets of introducing APIs into an IT architecture is that it enables each component of a larger system to be used independently, reconfigured, and daisy-chained into new workflows. Serverless takes that a step further by offering to do all of that linking together on an as-needed basis, spinning up compute power to get stuff down and then disappearing again when the need has passed, all without having to manage the servers that carry out that processing.
Hybrid Serverless
That is why one key entry point into serverless computing could be via API serverless architecture products that let users build an API in the cloud, with the data being called by these APIs also stored in cloud hosted storage. That could be a key resource for then bringing in business capabilities and assets into a serverless workflow.
But while that may make some sense, overwhelmingly, the market has started with more of a microservices-type approach, where microservices that are triggering events has been the common starting point for creating serverless solutions.
This reflects the place where serverless is naturally sitting in an overall enterprise architecture. At Serverlessconf, several speakers spoke more of serverless being part of a hybrid architecture that combines either on-prem with cloud. Events may trigger a set of processing tasks that is done within a serverless paradigm — with containers spun up to perform a set of functions in order or asynchronously — and then the results are returned to the workflow to continue in the on-prem/virtual private cloud architecture.
Serverlessconf opening keynote speaker Austen Collins, founder of the Serverless Framework, said that serverless is being used for event-driven workflows and is increasingly leading to a “serverless-first” mentality amongst architecture teams who prefer “to do as much as they can in serverless and then fall back to other tech when serverless absolutely doesn’t work.”
Microsoft Azure Architect John Gossman alluded to a similar idea when he joked that “legacy” is another word for “stuff that works.” Charity Majors from Honeycomb and Florian Motlik from Codeship both argued that serverless has its place, but it is possibly not for everything. Image processing, for example, is a great use case for serverless, suggested Majors. Motlik explained that serverless is about giving up control and responsibility over particular processes, so while it is suited to experimental solutions and some event processing, it is perhaps not best for managing core business tasks.
Azure Bindings for APIs Integrations
Given this shift to seeing serverless as part of a hybrid architectural approach, serverless platforms are extending their tooling to enable developers to integrate serverless workflows in much the same way they would integrate a full API.
Microsoft Azure revealed several new features that bring standard API design patterns and approaches into the serverless realm. The first of these is the concept of binding, used to replace the need for SDKs in serverless code.
“Bindings let you define input and output parameters to your functions,” said Yochay Kiriaty, a principal program manager at Microsoft Azure. “Bindings are an abstraction of services. It is an efficient tool that lets developers consume services.”
Kiriaty gives the example of sending an email using the SendGrid API through a serverless workflow. “If I want to do that, I would need to bring in the SDK, configure it, and write a few lines of code to do that. But with bindings, it abstracts all of that work.”
Kiriaty explained that a binding implementation wraps the SDK so that it is an Azure Function at runtime. The API username, password and API key are properties of the binding and are mapped to an environmental variable. That way, instead of integrating the SDK and writing specific code, a developer can simply write sendgrid.sendemail in their console and Azure Functions does the rest.
For now, there are 21 ready made binding implementations in Azure’s catalog, although because it is open source, API providers can write their own bindings for their SDKs if they want them available to Azure functions users.
OpenWhisk’s API Gateway
Meanwhile, IBM announced at Serverlessconf that it had introduced API Gateway tooling into the OpenWhisk serverless platform. The goal here was to bring in the security capabilities learned from managing APIs into the serverless fold.
“It is about integration of API gateway functions, but without the complexity of managing that infrastructure,” said CTO and VP of IBM Cloud Platform, Jason McGee. “We have brought in advanced rate limiting, API keys, developer dashboards with analytics around how those APIs are used.”
McGee says that one of the key enablers of the new gateway is to allow developers to secure the execution of their code. The API Gateway helps expose a function as an API, potentially to third-party developers, without all of the heavy lifting usually associated with API management.
“Besides the actual design and construction of the API, you have to worry about security, identity access, the ability to validate data, analytics on the usage of the API… these are all common API management concerns and we want to make it easy to implement an API on OpenWhisk without having to manage all of those things yourself,” said McGee.
Example Serverless Hybrid Use Cases
McGee gives a couple of examples of use cases that show how serverless is being used like APIs and how they are forming part of a hybrid system where particular processes are taken out of a larger value chain to be spun up and run in a serverless environment.
Dutch business SiteSpirit wanted to allow customers to take new images and make them available in their catalog automatically. That requires some image processing tasks. “They are using OpenWhisk to do that,” said McGee. “When a new object is added to object storage, it triggers those image processing events, updates the metadata and then uploads the new standardized to a destination object storage. SiteSpirit saw a 10X increase in speed when adding images to a catalog, at 90 percent less cost.”
Highlighting the hybrid serverless case, McGee also spoke about Santander Bank, which uses OpenWhisk’s serverless platform for a check processing pipeline. A bank is not going to run all of its core processes in serverless, but a task like check processing is a great fit. During the week, there may not be much call for managing compute and processing resources for check transactions, but come Friday afternoon when people are cashing their week’s wages, there is a “tremendous spike.” said McGee. “This is very event-driven. Santander takes an image of the check, uses OCR to check signature and amounts, drives a backend check clearance system and sends a notification to the customer.”
Like Collins, Majors, and Kiriaty, McGee said he expects this to be the dominant use of serverless in the future. “There is a tendency to say this will solve the whole application problem. I think that is dangerous, it is more a question of: how can we blend them together?”
Feature image: Charity Majors presenting at Serverlessconf in Austin, 2017
