Function as a Service (FaaS) is quickly finding use in a variety of operational and development contexts.
While the rising star of cloud computing is often mentioned in conjunction with APIs and IoT and mobile apps, there is significant use outside development for the technology. In the "Guide to Serverless" report from The New Stack, we find that the technical use cases for serverless span a robust set of uses:
Technical Use Cases for Serverless
As expected, applications rule the roost with nearly three-quarters of respondents making use of serverless for REST APIs and web applications. But after that it gets more interesting. Batch jobs and scheduled tasks, as well as the nebulous "business logic" still garner greater than half of respondents' use cases.
Falling into the "scheduled tasks" arena is the use of cloud functions to manage cloud assets. One of the capabilities cloud and containers give enterprises is the means to optimize the use of resources. Usually we think of this in terms of scalability - especially when paired with containers and microservices. By only scaling those pieces of an application that require scaling, you save compute resources (and therefore costs).
But the other side of that equation is the ability to shut down resources when they aren't in use. The appeal, in part, of function as a service and serverless (no, they aren't the same thing necessarily) is the true utility pricing model. You really do only pay for what you use. Because ideally there are no idle resources in a serverless/FaaS environment, you aren't paying for them. In the cloud, however, you may be paying for idle resources at the same cost as if those resources were executing some app or service. It's a minor nit, but one that can add up if you have a lot of downtime for an application.
Here's where cloud functions can help. By taking advantage of the function as a service capabilities of the cloud you're running in, you can schedule a task to shut down instances when they aren't in use and restart them later. This assumes a fairly static schedule, like an application that's only used during a well-defined workday. Such applications are often traditional "business" applications that are used by employees but only during the day - and the work week. Shutting down the instances that comprise a business app on the weekend can save considerable costs over time.
Using your cloud provider's function as a service offering may provide you a route to cutting the cost of keeping those applications "warm" overnight and during the weekend. Even if you're looking at a twelve-hour work day, you could cut your costs in half by shutting them down during the other twelve hours.
If you're curious about how to go about implementing what sounds to me like a cloudy version of cron, check out these resources: