Serverless continuous deployment for the AWS crowd: Feeding time in Lambda-land

Source – theregister.co.uk

Continuous Lifecycle “You’ll never go hungry if you know AWS,” one of the workshop participants at the Continuous Lifecycle* devops-focused conference in London remarked.

Mike Roberts, co-founder of consultancy Symphonia Cloud, was behind the lectern yesterday afternoon, preparing to conduct a tour of serverless continuous deployment on AWS.

Such sentiment is transitory in the tech industry. In the mainframe era, people used to say, “Nobody ever got fired for buying IBM.” Today, that has become: “IBM fires everybody.”

Nonetheless, AWS looks like a meal ticket for IT practitioners du jour, which explains why over a dozen developers chose to spend a sunny London day indoors, under fluorescent light, learning more about serverless computing using AWS Lambda.

AWS Lambda, launched in 2014, accounts for the majority of serverless usage, Roberts said.

There’s also Azure Functions, Google Cloud Functions, and various open source alternatives. But as another workshop participant put it, AWS is “the eight-hundred pound gorilla” of the cloud infrastructure business.

Roberts began with a succinct justification for cloud computing. “Before I started using the cloud, if I wanted a server, it would take nine months,” he said, alluding to the glacial pace of financial industry IT a decade ago. “Now it takes five minutes.”

Serverless, he said, “is just the next evolution of the cloud.”

It’s the stage that comes after Platform-as-a-Service and Containers-as-a-Service.

Companies use the cloud for two primary reasons, he said: reducing cost and accelerating delivery.

“It’s typically less work for a company to use a cloud provider than to do everything themselves, unless they’re a massive company,” said Roberts.

Savings accrue not just in terms of operations personnel but also in terms of the actual cost of infrastructure. “Cloud providers have economies of scale,” said Roberts.

Serverless, he said, consists of two different groups of technologies. “The first part is what we call backend-as-a-service,” he said, pointing to services like GitHub, Travis CI and Salesforce.

The second part is functions-as-a-service, in which instead of deploying an application that contains a set of linked functions, individual functions get triggered in response to events, he added. These arrive via message bus, network file system, time-based events or http requests.

Roberts pointed to five common characteristics of serverless applications:

1. No management of server hosts or server processes.
2. Self auto-scaling and auto-provisioning based on load.
3. Cost-based on precise usage.
4. Performance capabilities defined in terms other than host size and count.
5. Implicit high availability.

And to what end? Well, Roberts argued serverless app development can be phenomenally fast. “It’s far faster to build serverless applications than any other application I’ve built in my career,” he said.

An app that would take three months to develop, coordinated across multiple teams, Roberts said, “I’ve seen that take a week.”

And it can be less than that. He recounted that AWS veep Adrian Cockcroft last year said, “We starting to see applications being built in ridiculously short time periods,” by which he meant production Lambda apps are going up in a day.

“This is because of the leverage we get from serverless technologies,” said Roberts. “We don’t have to think about whether our Kafka instance can take the load. It actually changes how we can build products entirely.”

It’s also potentially cost efficient since it only runs when needed, assuming your application requirements aren’t ill-suited to serverless: low-latency, synchronous operation; large-scale, stateful operation; or long-running, stateful operation.

There are some downsides.

“Serverless is not a land of rainbows and unicorns,” said Roberts. “It does have problems.”

Tooling, he said, is not great. There’s a need for better deployment and distributed monitoring tools to trace what’s going on across multiple microservices, and you can’t rely on state-based architectural patterns.