In a stealthy way, serverless APIs have moved out of the “shiny new thing” phase to being enterprise software developers’ favorite way to bypass development overhead when delivering applications, APIs and microservice functions
Rich Sharples, Red Hat senior product management director, said he was surprised when he found out about the popularity of serverless APIs at Red Hat Summit 2017, last May. During his presentation there, he claimed he hadn’t spoken to many customers who were deploying business apps and APIs on serverless frameworks. That changed after his presentation.
“By the time I left the hall, I’d spoken to 15 customers who were using serverless APIs,” he said, adding that since then he’s talked to dozens more and heard of many other serverless API adopters. “Interest and adoption has ramped up very quickly.”
In serverless computing, a form of utility computing, a cloud service provider offers a pay-per-use compute runtime with a back-end that is invisible to the user. The cloud provider supplies and manages the servers and infrastructure, so that developers can focus on creating code.
However, businesses are not building, for instance, their next airline booking system or CRM system using serverless, Sharples said.
“It isn’t at that level,” he explained. “But serverless is there in terms of doing critical business functions.”
What’s driving increased serverless API use? The main attractors are freedom from provisioning servers, autoscaling capabilities, a small learning curve for developers, increased speed of development and the pay-as-you-go model, Sharples said. With serverless, a developer just has to care about a small fragment of code.
“They can be more task-focused and really push the responsibility of scaling and managing the infrastructure to somebody else,” Sharples said.
Developers deploy APIs on serverless frameworks to bypass the complexity of creating and deploying microservices whenever possible, he said.
“As adoption of microservices increased, developers realized that building them is hard,” Sharples said, adding that they see an API can cover some functions or features that a microservice does.
Serverless APIs win when the choice is between building that function within minutes or hours as an API versus taking more time to build a microservice, Sharples explained.
“I task anybody to go build a resilient measure of microservices in less than a few days,” Sharples said. He also said that serverless API users are making future plans around integration, design plans, event-driven architecture and next generation applications.
Tempering his enthusiasm with reality, Sharples stressed that serverless is not a silver bullet. Deploying APIs on serverless frameworks is good for certain use cases that can benefit from the runtime efficiency.
“There is an envelope where serverless makes sense,” he said. “Outside the envelope, a more traditional long-running microservice would probably make a lot more sense.”