Does one thing always mean the end of something else? In the tech world this can be the case, and the inability to innovate can become existential (just ask Netscape or Blockbuster – yeah I know about Dish, AOL and Firefox but you get my drift).
According to a recent survey by the UK’s Computing magazine, more than half of those surveyed did consider that serverless cloud could spell the end of containers for most DevOps tasks. Great news for Amazon Lambda et al, bad news for Docker et al. At least on the surface.
It’s an interesting debate given we’ve previously explored containers as an option for legacy modernization (an application of containers actively marketed by Docker in particular) as well as the role microservices can play as an alternative to monolithic applications.
This next, short, explanation is aimed at the non-IT folks who’ve found the journey from virtualization to containers to microservers to PaaS and IaaS/FaaS (serverless) to be an almost nauseating acronym soup with jargon croutons. If you are an IT-savvy reader then skip the next few paragraphs and check the commentary around serverless is just for net new application development.
Firstly, ‘serverless’ doesn’t imply there are no servers, just that the provisioning of cloud resources is done automatically (leading to usage-based pricing) rather than having to have developers figure out the [varying] workload themselves and allocate resources appropriately (which invariably led to too little resource/poor service or too much resource/higher costs, i.e. billing and performance was based on reserved capacity, not usage).
The original public cloud solutions (AWS, Azure etc) relied on their customers’ developers to allocate resources (not optimum and to be ‘corrected’ with serverless) and also benefitted from the rise of containerization and the benefits of portability afforded by container technology. Once you have your application in a container, you should be able to move that container from public cloud to public cloud and from public to hybrid and private.
And there’s the first knock against serverless technology, today there is no portability between Amazon’s Lambda and Microsoft’s Azure Functions.
Serverless provides cost benefits from being usage-based and from freeing up developers from having to perform resource allocation tasks (which they’re not skilled in anyway) but doesn’t [yet] afford the benefits of portability.
The second knock on serverless is that it’s much more for net new application development and not suitable for legacy applications, while containers can be applied to existing applications, thereby, enabling a degree of legacy modernization.
We dealt with the suitability of containers as a legacy modernization vehicle in the two posts linked to earlier in this article – it’s basically a quarantining solution at best which may be of value short term but won’t address the longer term challenges associated with the legacy application which then comes down to the modernization driver to determine longer term suitability of containers for modernization.
The issue that serverless is the domain of net new application development only requires further scrutiny. I’ve read ‘square peg in a round hole’ when thinking of taking a legacy application to serverless but that figures without Morphis and the outstanding technical team we have working on our legacy modernization platform. Watch this space for coming announcements! If you have a legacy application that you need to take serverless and would like to talk about our plans ahead of any announcement then please contact us.
So, does serverless spell the end of containers? Serverless wins on cost, but loses [today] on portability. When it comes to legacy applications, the current thinking is that containers have the advantage. We love proving the current thinking wrong.