some organizations jump on the serverless bandwagon, even when there are strong reasons not to.
There are many factors to consider with a serverless deployment, but here are three specific warning signs that suggest it’s not a good fit for your enterprise.
1. An app’s inability to change
If you plan to deploy third-party software or legacy applications you can’t or won’t change, you will face a major problem with serverless. Serverless offerings from top cloud providers, such as Amazon Web Services Lambda, Azure Functions and Google Cloud Functions, are still fairly new, so older software was not designed with these in mind..
Arguably, serverless computing is derived from social network applications — most notably, Twitter – which follow an event-processing model. But most business applications today aren’t built for event processing. That doesn’t mean they can’t work that way, but you’ll need to change how those applications break out into components, as well as the logic of some of those components.
Some users find that nearly two-thirds of the applications they target for serverless can’t be changed, either because a third-party vendor owns them or the changes require lots of time and money. If you use third-party software, seek a contractual commitment from the software vendor that the application can run on a serverless architecture.
2. Your application always runs
You only incurs costs for serverless computing when an application function is needed. While this can be cost-effective, it can also lead to excess costs for applications that frequently run. An ideal serverless application is ready to run in a matter of milliseconds but isn’t called on often. An application that runs consistently will incur charges most of the time, and these charges are far higher than the cost of running a VM or container in the cloud.
It’s often difficult to know whether an application needs to run or just be ready to run. A good example of the former is an application that supports a credit terminal in a busy retail store. This application is called on for every purchase, which makes it a good fit for a more conventional infrastructure-as-a-service platform. An example of the latter is an application that monitors an environmental sensor in a warehouse that’s triggered by temperature fluctuations. This type of application needs to be ready to run all the time but won’t run often, which makes it a great candidate for serverless computing.
3. Your application is stateful
Since a serverless application loads and runs on demand, you can’t save things inside that application between uses. This saving action is called statefulness or context. If your application is inherently stateful — as is any business application that provides updates on something or supports a multistep dialog — stay away from serverless.
Amazon and Microsoft describe serverless computing as functional or lambda processing. This refers to a specific programming technique that avoids saving anything in an application or in an application component from one activation to another. Functional or lambda logic is always stateless, which enables any copy of an application component to process an event.
Google, for its part, describes serverless as microservice computing. A microservice should also be stateless, in part because applications might share the same logic, which makes it dangerous to save context that might then pass unknowingly to another application or user.
You might need to rewrite some or all of your application to address this stateless issue. Even if a rewrite isn’t necessary and you just need to change parts of your application design, have developers on staff who know how to handle state, context, lambda programming and microservices.