Serverless is a big deal, and for good reason. As Pariveda Solutions architect Phillip Manwaring has suggested, serverless computing, a la AWS Lambda, is a way for developers to focus on “ephemeral functions which encapsulate your business logic and expose organizational capabilities,” thereby structuring “your solutions and tak[ing] care of boilerplate, undifferentiated heavy lifting for you.”
In other words: Serverless helps developers focus on solving business problems, not futzing with technology infrastructure.
That’s the good news. The bad news is that serverless can make things so much easier that good developers can find themselves making really bad decisions about security. Redmonk analyst James Governor hit on this in a recent post, arguing that the very convenience of serverless can lead to “poor code hygiene” which “essentially leads to bigger attack surfaces.”
1. Sacrificing security for convenience
Serverless, declared Manwaring, makes “doing the right thing easier.” In addition, he continued, “it makes your existing product teams smaller by helping you decompose your monoliths into microservices, and it reduces the amount of specialization needed to take an application from idea to production – thereby reducing the number of people needed to support this work.” So much awesome, right?
Well, mostly. As Governor called out:
[W]hat happens in the serverless economy, where you don’t need to pay for a function until it is actually used? Well for one thing, just like plastic bottles, you’re less likely to dispose of them effectively. In microservices we talk about disposability as a virtue, but with serverless it’s so easy to deploy code, why bother getting rid of it? When it comes to security though, poor code hygiene essentially leads to bigger attack surfaces, which is A Bad Thing.
As he summarized, “It turns out that serverless, by the very fact of its convenience and low cost model, may lead to laziness, and poor security.” But, that’t not all.
2. Vendor lock-in
One of the biggest issues with serverless is that you’re not, in fact, running without servers. You’re just building on someone else’s servers, using API calls that tie you deeper and deeper into that platform. As outlined by Simform Solutions’ Rohit Akiwatkar: “Giving up system control while implementing APIs can lead to system downtime, forced API upgrades, loss of functionality, unexpected limits and cost changes.”
SEE: Why AWS Lambda could be the worst thing to happen to open source (TechRepublic)
The upside is increased freedom to get more done. The downside is that you’re getting the “more done” subject to the platform’s control, without the ability to easily move to a rival cloud. If you want to switch from Microsoft Azure to AWS, for example, you’re going to need to rewrite your application.
This isn’t to suggest developers shouldn’t take advantage of the benefits serverless can provide. They should. But it does indicate a need to proceed with a measure of caution, such that security and independence can be maintained.