Pros and cons of using serverless architecture for your application deployments
Serverless computing platforms are, in a way, the next level of the potential of cloud computing. Cloud platforms have long allowed organizations to scale computing power to match the needs of their workloads, without the need to personally oversee hardware lifecycle tasks that otherwise accompany it. Serverless architecture abstracts the environment from the code being run on it -- enabling developers to execute arbitrary code on demand, without concern for the underlying hardware.
SEE: Prepare for serverless computing (ZDNet special report) | Download the report as a PDF (TechRepublic)
Is serverless architecture right for your business?
Application migrations are generally long-term efforts, requiring significant amounts of developer resources, testing, and time to complete successfully. Not all applications can effectively be deployed using serverless platforms.
The best fit for serverless architecture are applications with stateless use cases, with operations that can tolerate a spin-up time of a few milliseconds, that execute cleanly, and that hand off the output to the next operation in a sequence, whether that's a user, a storage bucket, or another application. Conversely, serverless is not the right fit for always-on "24/7 applications that require very predictable, very consistent performance, that are reading and writing a lot of data into the back-end system," according to Arun Chandrasekaran, a Gartner analyst for technology innovation.
What are the pros and cons of using serverless architecture?
While there are clear benefits to serverless in specific cases, it isn't a panacea for every single use case -- and trying to brand something less than serverless as the real deal undercuts the potential that serverless can bring to your organization.
Pro: Serverless applications are cheaper to run and easier to maintain
Compared to traditional cloud-hosted virtual machines (VMs), a significant cost savings can be found when suitable applications -- nominally, the aforementioned stateless applications -- are developed around serverless platforms. Granted, the cost savings between serverless and traditional applications are not quite as vast as winning the lottery versus finding loose change between the couch cushions. At the same time, they're nothing to sneeze at.
"If you consider something like an IoT scenario, where messaging may be infrequent … the ability to have things there not eating up cycles, not incurring charges, and then when the messages actually come through, fire up process and then fire down again, you're potentially looking at dollars versus hundreds of dollars for a VM that always has to be up and running and listening," Jeffery Hammond, principal CIO analyst at Forrester, told ZDNet.
SEE: Serverless architectures: 10 serious security problems (free TechRepublic PDF)
Con: It's challenging to migrate existing applications to serverless architecture
Any type of major re-versioning or reimplementation for a large, business-critical application is likely to be a years-long, protracted process. "I see more companies starting new serverless than trying to rewrite existing products and services," Hammond said. "If existing applications aren't built around an event taxonomy, that's something you have to think about. If functionality is not clearly separated into subsystems or related sets of capability, it's gonna be a real challenge to ready that for serverless. Serverless benefits when you have the ability to decouple individual parts of an experience. And a lot of applications that have been built out there just really weren't designed that way."
Pro: You can migrate individual features or partial workloads to serverless functions
You can get started with serverless applications by porting over individual features to operate as on-demand events. Consider, for example, a video hosting plugin for WordPress (or any other CMS) that requires transcoding video for different bitrates and formats. This task is a poor fit for a production WordPress server, as resources should be dedicated to serving pages, rather than video encoding. (Likewise, WordPress installations on virtualized hosting platforms may not be able to utilize hardware acceleration for video encoding, further hampering the process.) This is an excellent use case for having serverless functions handle encoding and metadata creation. Similarly, for photography portfolio plugins for WordPress, using serverless functions can bypass the need for packages like ImageMagick, which are often prone to critical vulnerabilities.
Con: Debugging serverless applications is challenging with traditional tools
For exceptionally large enterprise applications that include hundreds of individual functions, with various nested microservices and dependencies inside these functions, debugging can be challenging with traditional development environments. "There is no option today to attach a debugger to your serverless application in the public cloud, and you must either debug locally (in a simulated environment you set up) or use logging for debugging," Erez Berkner, CEO of serverless application optimization platform Lumigo, told ZDNet. Without adequate visibility into how an application is executing, troubleshooting applications that are failing or working unpredictably can become an order of magnitude more difficult.
Changing the way you approach development is necessary for serverless computing. Increasingly, development teams are writing "their own DevOps tool chains, because some of the DevOps tools out there don't necessarily support this idea of very quickly deploying very, very small bits of code into running applications," Hammond said.
SEE: How can serverless computing be cost-justified? (ZDNet)
Pro: Serverless applications are less prone to software rot
Serverless applications are easier to maintain over time. "In a serverless world, you can actually see the various functions in the application and how they are executing. And you can see if certain functions are never getting executed," Hammond said. "So it potentially makes the ability to refactor applications and cut out dead code much easier than previous application architectures we've used."
That said, as cloud platforms will automatically sunset older frameworks when they reach end-of-life, the responsibility to actively maintain code is placed on developers. Though this may wreak havoc on developer schedules, sunsetting older frameworks is done with ample advance notice, as version lifecycles are often published on release. While this could create a temporary inconvenience, it can also prevent the buildup of decay over time.
Also See
- Hybrid cloud: A cheat sheet (TechRepublic)
- Hybrid cloud: A guide for IT pros (TechRepublic download)
- Top cloud providers 2019: AWS, Microsoft, Azure, Google Cloud; IBM makes hybrid move; Salesforce dominates SaaS (ZDNet)
- Best cloud services for small businesses (CNET)
- Microsoft Office vs Google Docs Suite vs LibreOffice (Download.com)
- Cloud computing: More must-read coverage (TechRepublic on Flipboard)