You are here

You are here

Serverless and containers: Is a throwdown under way?

Christopher Null Freelance writer

If Internet chatter is to be believed, a battle is brewing between serverless computing and containers—and when the dust settles, containers, the darling of DevOps, will be down for the count.

But are containers really on the ropes, or is it all hype? Here's an analysis of the matchup.

Serverless pros and pitfalls

There's no question that serverless offers some clear advantages. It saves money, increases the efficiency of the IT spend, and reduces resources and maintenance requirements, allowing developers and IT to focus on higher-value tasks. With perks such as these, it's easy to see why folks would be enthusiastic about the technology.

But the path to serverless isn't necessarily pain-free.

Ashish Datta, a partner with Setfive Consulting, said that migrating a container-based architecture to a serverless one usually requires re-architecting significant parts of the system

"The jump from containers to serverless is much more dramatic compared to the transition from VMs to containers, because the compute environment between containers and serverless fundamentally changes."
Ashish Datta

In contrast, the move from VMs to containers is more straightforward because that's really just a change in deployment philosophy. "The same software is running, at the end of the day," Datta said.

Stackery CEO Nate Taggart said that chief among the barriers to serverless was that you can't simply just move to serverless. 

"[Serverless applications] must be designed for a serverless infrastructure. This may be fairly economical for new development, but it can be burdensome for migrating legacy applications—and in some cases even impossible."
Nate Taggart

Today's serverless offerings have resource limitations, Taggert explained, including memory, compute, and time limits; limited language support; and special considerations with managing state between requests. All of these must be "baked into the application design from the outset," said Taggert.

Migrating to serverless may also require a significant rethink of existing infrastructure,  said James Riseman, director of product marketing at PubNub.

"Serverless computing requires a very modern, componentized architecture. Systems and applications have to be broken down into discrete logical functions, and groups like quality assurance can lose control."
James Riseman

Another issue with serverless is pricing. "Companies are now charged per transaction or per second of compute time, rather than on more traditional infrastructure terms," Riseman said. "That makes pricing more difficult to predict."

On top of the need to address migration requirements, transitioning to serverless computing also compels a change of mindset.

"One of the biggest hurdles is the mental shift that's required to think of compute resources in discrete units versus having an always-on and always-there capability. That dovetails with the restrictions on things like memory usage and runtime that frameworks like Amazon Lambda impose."

Adversaries or allies?

Pros and cons aside, pitting containers and serverless in a head-to-head battle presupposes that they are mutually exclusive solutions. But every person TechBeacon asked said it's a mistake to think of them this way.

Todd Millecam, CEO and principal consultant of Swym Systems, said it was an apples-and-oranges comparison.

"They both have uses, and if you look at the way most serverless technologies operate, they're just running containers in the back end."
Todd Millecam

Serverless and containers fill different but overlapping roles. Taggart said that while both can be used for compute tasks, each has its advantages and disadvantages. For its part, serverless is ideal for bursty, unpredictable workloads that have small resource needs and short-lived transactions.

Containers have advantages for long-running processes and generally predictable workloads. Containers also offer more flexibility in terms of application design but require more management of the underlying infrastructure.

Serverless, on the other hand, requires a serverless-centric application model but abstracts away infrastructure almost entirely.

"As a serverless operations console product, we have an almost entirely serverless back end," Taggart added, but we still use containers for certain workloads in which they are the better tool for the job.

"Dogmatism for one model or the other is counterproductive."

Is the future serverless?

To invoke an old saw: It seems, then, that rumors of containers' demise have been greatly exaggerated.

Different architectures and applications will always require varying degrees of abstraction and, similarly, different teams will be comfortable with making different tradeoffs, Datta said.

"Just as containers haven't replaced VMs, and VMs didn't replace bare-metal servers, abstractions will never be an existential threat to tried-and-true 'closer to the metal' solutions."

As for serverless, it should be seen more as an evolution of technology. As such, most observers caution that serverless is still immature and doesn't yet have established architectural patterns and robust developer tools in place. It also necessarily means coupling your application's fate to a specific cloud vendor, which presents its own risks.

Because of all this, it will likely take years for serverless to reach widespread adoption in the enterprise, despite its enormous potential.

In the meantime, serverless may have more of an impact in startups.

"Serverless computing provides a way to host your code and make it available on the web for less than the cost of going out to eat once a month. Until you have a highly active and large user base, serverless is a cost-effective way to build any app for the web."

As serverless computing matures, though, architects will find it increasingly hard to resist, said Jake Bennett, CTO of the digital agency POP.

"Serverless computing just solves too many problems to ignore. The ability to offload scalability concerns to a third-party vendor is the dream of every developer, and having someone else worry about server maintenance is a long-standing fantasy of IT Ops."
Jake Bennett

Keep learning

Read more articles about: Enterprise ITIT Ops