Published: Dec 23, 2019 by Matt Wood
TL;DR: FaaS can help you scale, but take care to avoid security and cost pitfalls
Serverless computing (functions-as-a-service/FaaS) takes advantage of on-demand compute resources to run your software applications without server hardware explicitly dedicated to your application. Effectively, you pay only for the resources that your application uses. From the provider’s standpoint, packing as many of these FaaS applications onto shared hardware results in better utilization of fixed resources – idle server usage goes down. This paradigm is not new (the buzzword emerged around 2015), and is quickly becoming the de facto method for running code as everybody and everything drives towards more resource/cost efficiency. This article leans toward managed FaaS providers like those found on AWS and Azure, but there are systems available to enable your business to do this on-premises, which probably better applies to the massive enterprises with “private clouds” and restrictions on public cloud use. Let’s discuss the benefits your business can gain from serverless and how to avoid some of the associated pitfalls.
Cost Benefits
Paying for unused technology resources hurts your bottom line. The established companies will inevitably make the quick argument against any paradigm shift, citing costs of performing any change. The fact is that differences in cost with FaaS can be on the orders of magnitude – we have clients that now spend less than $500/mo on compute who had previously spent several times that on their monthly electric bill for their servers alone. For an on-prem FaaS deployment, this should result in fewer underutilized machines. Other associated cost benefits are:
- Avoid fixed cost depreciation of server hardware and associated facilities (provider FaaS)
- Avoid hardware maintenance (provider FaaS)
- Avoid o/s maintenance (provider FaaS)
- Likely better uptime SLA due to provider efficiencies of scale. Your application isn’t pegged to specific hardware, enabling greater redundancy.
- Better uptime due to the prescriptive nature of provisioning FaaS. You won’t have configurations laying around from an application that was sunset years ago affecting how your new code works.
- Cybersecurity: FaaS and cloud platforms in general tend to have a secure-by-default initial configuration, making any expansion of access a deliberate action. See security section.
- Cybersecurity: Likely lower cost of maintaining a secure cybersecurity posture due the provider having legions of people hired to focus on this. Your firm’s cybersecurity program can inherit many of the benefits of your FaaS provider’s stringent security controls and programs.
- Depending on your business, transforming IT into more of a variable cost may be beneficial. This was a strong driver for some of our clients.
- Scale infrastructure upward and downward when needed (see scale section) in a cost-efficient manner
Cost Negatives
To be transparent, there are new costs associated with serverless:
- Your development/IT team will have to spend the overhead of retooling. This will involve setting up test environments, deployment pipelines, reading documentation, etc. The good news is that it’s an initial investment and also career development for them, making your team stronger and more committed.
- There is risk to changing any system. The good news is that this stuff can be done gradually. Making small, calculated steps can help avoid big problems.
- Potentially higher bandwidth consumption. Depending on your architecture, you may be shuffling more data though expensive bandwidth pipes till you’re moved fully to the cloud infrastructure.
- Mistakes: On-demand pricing can turn small mistakes into big expensive ones. I’ve dedicated the monitoring section below to this.
- Cybersecurity: your security team will need to know the cybersecurity implications of what they’re doing to avoid exposing your data to the public (see security section).
Monitoring
In serverless, wayward code performing calculations on all of your firm’s held securities in an endless, non-terminating loop can send your bill from $500/mo to $15,000 in a weekend, thus the importance of monitoring. We’ve found success by implementing the following:
- Budgets: AWS and Azure let you set cost budgets. These things can kick off alerts at certain intervals of the budget and finally deny service after the budget has been hit in some cases. Set these when you first set the account up before deploying anything.
- Monitoring software: We’ve written custom code to monitor message queue sizes, orchestrator queue sizes, function invocation counts, etc. You can do the same or use the functionality built into azure/AWS to do this.
- Team procedures: Monitors and alerts are useless if nobody sees them. Our blast to email, slack and SMS depending on severity. Establish who is ultimately responsible each week(end) for watching and responding to these.
Scale
The major positive with (properly planned/configured) on-demand infrastructure is its ability to scale dynamically to meet demand. Your calculation engine can stay shutdown until new data arrives. When this data arrives, the system can grow from 1 instance of the application to 20, multiplying speed and cutting process time. We’ve found that scaling horizontally like this has been more cost effective than leaving a single instance to grind out a given segment of work over a longer period of time. Instead, 20 instances come online, process the work, then die – keeping total billable run time to a minimum. The caveat here of course is that your software architecture be designed for parallel processing by using message queues and the like.
Security
Another positive of using cloud-based FaaS services: secure-by-default configuration. In fact, this technology is among the few to have really changed the game in favor of the good guys for cybersecurity intrusions according to a defcon talk I attended (which I’ll link to when I find it).
However, a perceived negative for some is that your firm’s IT/cybersecurity team will have to be up-to-date on security best-practice in the cloud to avoid costly cybersecurity mistakes. Again, this training is positive career development, which helps all involved.
Conclusion
We see this “buzzwordyness” of serverless gradually going away and becoming the standard operating methodology for any on-demand service. If you aren’t planning on moving in the direction of on-demand microservices, you’re most likely giving your competitors an edge.
Feel free to weigh in with your experiences in the comments section. Till next time!
