This is a little bit of a frustration of mine. I’m hearing this more and more often, as an argument to rewrite into one of those platforms. However, it’s simply not true. It’s a different pricing model, that has definite benefits in a lot of usecases, but NOT all.
To be clear, with the right use case, you can save thousands (if not tens or hundreds of thousands in extreme cases). However, such a swiping statement, without first properly understanding the usecase and how you might implement it, is negligent.
FaaS offerings are an amazing string to the bow of a developer and architect. There are certain use cases when they can save money, and certain ones where they can provide a level of SLA that is unsurpassed without spending the GDP of a small country. There are, however, some use cases where you will end up speeding more, for no tangible benefit.
It’s important to remember that FaaS is simply a different pricing model. Instead of paying for servers, which are either always on, or turning them on when you need, you pay per execution (more specifically, the time it takes to run). This model works great when:
- The load is not constant
- The traffic is unpredictable
- Response times are more important than cost
- An increase in server load, normally means an increase in revenue.
In contrast, if you want predictable costs, and don’t mind that, under load, certain functions may take longer to respond, FaaS is not the right choice.
What are the best use cases?
Maintaining SLA and response times
When you need a function to ALWAYS return in a predictable amount of time, regardless of the site load. This could be a login/password hash function, or possibly something like a high load call such as parsing or import functions.
Rarely used functions
When a function is used very infrequently, and they have no where else to to host it. It’s important to consider here, that if you are already paying for a server 24/7, and this function is used, when that server is not under load, you’re going to pay more. This could be an conversion activity, virus scan, etc.
What’s a bad usecase?
Think about hosting your personal blog in a pure serverless architecture. Unless you’re generating money for post views, an increase in load could mean that you’re actually paying people to view your blog. You will, however, get a very consistent load time. This kind of model doesn’t work well, and can end up costing you a small fortune, with zero return.
Conclusion
In short, examine the use case properly, justify the fact that you’re moving from a timebased pricing metric, to a “per execution” pricing metric. Make sure that your costings are properly worked out.
MartinDotNet 
Leave a Reply