Skip navigation
serverless-cloud-containers.png

Defining Serverless at Container World

Serverless Summit, a pre-opening event at this year's Container World, indicated that serverless is a technology still finding its footing.

SANTA CLARA, Calif. -- Although Container World 2019 officially launched Thursday, on Wednesday the annual Silicon Valley-based conference got an early start with one of those pre events that seem to have become an essential component of modern tech conferences.

While some conferences use a pre event as a way to present a slate of intensive workshops, something Container World has done in the past, this year the conference planners took a page out of last year's playbook and offered a track of presentations focused on a single subject.

Last year the focus was on Kubernetes, with presentations by Heptio, the Kubernetes startup that was purchased by VMware in November. This year the pre event, Serverless Summit, moved into the territory of serverless computing, which in many ways supports cloud container use.

These days DevOps teams are being lured by cloud providers to add their serverless services to container-based cloud infrastructures with the promise of lower cost and increased productivity. However, there is some confusion among potential adopters as to what serverless really means.

Defining serverless in a way that's easily understandable is difficult, partly because of the unfortunate choice of name for the process, which Kuldeep Chowhan, distinguished engineer at Expedia, pointed out in his talk that opened the day at Container World's Serverless Summit.

"A lot of folks ask, 'Does serverless mean like without servers?'" he said. "They could have named it anything they want, but they chose serverless."

On a broad surface level, serverless is easy to define. It's letting services, mostly provided by cloud providers, do much of the tedious grunt work that traditionally would have been part of the process of running servers. This frees DevOps from having to worry about things like allocating machine resources so they can concentrate on writing and deploying code.

But serverless is a work in progress, and therein lies the problem. Like DevOps in its early days, serverless represents a variety of processes with boundaries and use cases that are still being discovered, and even among those who advocate the serverless approach there is disagreement on the finer points of what serverless is or isn't.

This was very much apparent at Wednesday's summit. During his presentation, Chowhan explained his version of what serverless is or isn't, stressing that "it's not just functions," a key component of serverless, and noted that serverless might not be indicated in situations where low latency is needed due to cold start times with functions, because the clouds put a maximum execution time of between five and 15 minute on functions.

Chowhan was followed by David Nugent, a developer advocate at IBM who talked about serverless and blockchains, who disagreed with that definition and indicated he thinks functions to be key. Marek Sadowski, another IBM developer advocate, who demonstrated using serverless techniques in IBM's cloud, opined that latency isn't a big issue because the cold start's lag time can be worked around by automatically cold starting functions every five minutes or so independent of processes depending on the functions.

These minor differences of opinion are relatively meaningless, but they indicate that serverless is a technology that's still seeking to find itself. My guess is that within a couple of years, as the serverless approach is more widely adopted and best practices are fine tuned, that these differences of opinion will all but disappear.

That's how it worked with DevOps.

Disclaimer: Container World is produced by Informa, ITPro Today's parent company. 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish