3 Questions about Serverless Technology
Feature image by Scott Webb via Unsplash.
As a fairly new technology, serverless can be both exciting and confusing. Early adopters have found that this is not a cloud architecture option where developers can ask questions on Stack Overflow and see who has previously encountered that same problem. Instead, devs must problem-solve in teams, and then share their results with others to help advance the community.
Startups are emerging like IOpipe and Snyk that have assessed the market and identified key tooling areas where they can add value by filling gaps. But key questions remain about this new technology. Is “serverless” the same as functions-as-a-service, or is it a wider event-driven architecture? What are the opportunities for standardization? And how do you manage for reliability?
1. FaaS Platform or Event-Driven Architecture?
At AWS re:Invent in 2016, David Potes and Ajay Nair from Amazon Web Services outlined the “Serverless Compute Manifesto” which contained eight core tenets. Top of the list was “Functions are the unit of deployment and scaling.” And while functions are an event-driven piece of code, the wider serverless community seems to be pulling back from a focus on “functions-as-service,” instead of leaning towards a definition that recognizes that the starting point is the event trigger that kicks up the function to start.
Indeed many people have called serverless technologies “functions-as-a-service.” But are they the same thing?
Author of the “DevOps Handbook,” Patrick Debois, has suggested in several of his presentations that it is not so much “serverless” as “service-full.” What this definition suggests is that there are more event triggers and components involved than just functions.
A simplified definition of serverless has been shared by Chris Munns, who is the AWS senior developer advocate for serverless. At Serverlessconf in Austin earlier this year, he distilled serverless down to four characteristics:
- no servers to provision or manage
- scales with usage
- never pay for idle
- availability and fault tolerance built in.
Note there is no stringent requirement that “functions” make up part of that serverless definition. Instead, he presents a worldview in which FaaS sits within a wider serverless paradigm:
Chris Munns’ concept of FaaS as part of a wider event-driven architecture paradigm
“I think there are two things going on,” said Ben Kehoe, a regular writer on the serverless maturity process. He outlined:
One is that Serverless is bigger than just FaaS. “FaaS is just your compute layer,” explained Kehoe. “If you’re running Kafka to feed events into FaaS, you’ve got servers to manage there. If you use AWS Kinesis instead, you still have to provision (for sharding), but your operational load is vastly reduced. Similar for all the other parts of an application: databases, blob storage, authentication layer, encryption, analytics, logging, metrics, etc.
“So being serverless is about putting your business logic in FaaS and using managed services for everything else,” he said.
Kehoe also noted that event-driven architectures are a natural fit for FaaS.
“Events trigger functions. But FaaS isn’t inherently event-driven and event-driven isn’t exclusive to serverless architecture,” he said. “My feeling is that it’s too big a jump to go event-driven and serverless at the same time for most organizations.”
2. Serverless Standards?
As a newer technology, serverless is not yet mature enough to have a diverse ecosystem of tools available for developers, and similarly, no standards or conventions have yet bubbled up that are accepted across the industry as the appropriate way to deploy.
One immediate concern suggesting the need for standards is the emergence of SaaS providers — like Auth0 and Twilio — providing functions. While this may lower the barrier for entry for newcomers to serverless, the concern is that in production use, it means that code is spread out across (potentially) multiple providers, making it even more challenging to maintain, monitor and debug. Also, there is nothing stopping each SaaS provider from using a slightly different nomenclature or approach in how their serverless function code should be written, potentially creating challenges for developers who are using multiple serverless platforms from SaaS providers.
One developer using Auth0 Extend is creating an integration so that their customers can use a data pre-processing function.
“We work in industrial Internet of Things, and one of the features of our product is that you can upload your sensor data,” the developer noted. “The intent is that when sending in sensor data, you can use Extend to transform the data before it is imported. For example, our dashboard analytics may expect data to be sent in a specific CSV or JSON shape, so our customers would use Extend to transform the data as it is uploaded.”
Currently, in this use case, there are no other serverless elements to the workflow — the architecture is cloud-based — although the system does use Azure Functions for some cron-like backend jobs. But it is not far-fetched to imagine that alongside using Auth0 Extend, this developer team could also use, for example, a SendGrid-like serverless platform to create a function that notifies customers if the data preprocessing was not inputted as expected.
The beauty for the developer team in offering this to their clients is that with Auth0 Extend, customers can create the pre-processing function within the developer’s interface. “One of the reasons we like Extend is that the experience is fully in our app,” the developer told us. “Our customer could do this in AWS Lambda before the data reaches us. You could accomplish the same thing. But then our customer would be in two platforms. This was just a natural extensibility point.”
The downside is that if they were stitching together additional SaaS serverless platforms, complexity could easily outweigh the convenience and ease they are able to offer the customer base.
3. Function Reliability
A final issue raising some confusion in serverless design is how to monitor and respond to functions when they don’t get triggered as expected. There are multiple reasons this could happen: the function might not respond to the API gateway, may fail to execute because of coding errors, or fail because of a lack of memory or other resources available.
What if one step in a workflow fails and so the function doesn’t get triggered in the next step? What functions are mission critical? How are functions audited and monitored?
AWS has some documentation on retries on function errors. If a function fails because it times out trying to reach an endpoint, fails to parse input data or experiences out-of-memory or other resource constraints, Lambda throws an exception, but how those exceptions are dealt with will depend on whether the function was invoked synchronously or asynchronously (asynchronous for example, leads to two retries).
But work on industry approaches to dealing with function errors and ensuring there is in-depth function monitoring (like that released by IOpipe recently), is just beginning.
To help encourage a shared industry view with input from a range of platforms, tool providers, and projects, The Cloud Native Computing Foundation has created a Serverless Working Group, which to date has included participation from AWS, IBM, Microsoft, Red Hat, Auth0, VMware, and Docker, among others.
At present they are working on a Serverless White Paper to describe the field, where several of these debates are currently being worked through. As further clarity is made, several of the working group participants are expected to share their views at the next Serverlessconf in New York from Oct. 8 – 11.
“The next 12 months will see serverless technologies and architectures evolve and mature quicker than ever before. There will be a greater focus on serverless security, operations, patterns and architectures coming from vendors, early adopters and enthusiasts,” Serverlessconf organizer Peter Sbarski, who also authored “Serverless Architecture on AWS.”
“We will also see greater adoption of serverless technologies from large enterprises as they try to find that competitive advantage and beat slower-moving competition,” Sbarski said.
