Every time I start a new programming project, I follow the same steps. Start with a template or folder structure that I've developed over the years, start scaffolding out the UI (whether it be an API definition or CLI surface), and finally organize and implement the different components. Hours later, I'm ready to start with the actual business logic. It's like designing a room, except you have to build the house first. What if you could skip the redundant parts?
Functions are the atom of programming. They turn inputs into outputs. Everyone has used a function in Excel and possibly even chained a few functions together. For example, here's a basic function in Go that sums the input numbers.
func sum(numbers ...int) int {
sum := 0
for _, x := range numbers {
sum = sum + x
}
return sum
} While this is valid Go code, this won't compile to a Go program. Instead, you'll need to tell it things like what function to start with and write extra code that accepts receives inputs (from the command line, from reading a file, or from a HTTP request) and does something with the outputs.
Functions-as-a-Service (FaaS) lets you host the function in the cloud. FaaS turns your functions into APIs. FaaS is often serverless, in the sense that functions can be scaled up or down depending on the load, and customers don't manage the servers directly.
Today, AWS Lambda is the most used FaaS platform. Companies use AWS Lambda in tasks like preprocessing data for machine learning or processing real-time streaming data. Other services include Cloudflare Workers, which provide edge functions distributed around the world that minimize latency.
There's a lot of cases where FaaS isn't useful. For example, suppose your function is "chatty" and needs to talk to different services such as a database, other functions, or access otherwise shared resources. FaaS might be slow because it can't share database connections or needs to make a network call to a different function. In that case, there are benefits to having functions compiled into the same program. Functions are often autoscaled to fit demand. When there are no requests, functions scale to zero. However, on the following function call, starting a function from zero to one can take a considerable amount of tie to start up (~1 second). "Cold starts" have historically been a problem for FaaS and serverless in general, but developers are tackling solutions. Another problem has been language runtimes - functions can change behavior between different versions of a programming language. Platforms end up with a combinatorial problem of supporting different languages at different versions. Luckily, containers solve some of these issues. I'll write a blog post on containers soon since that's my area of expertise.
Predictions: Functions aren't a one-size-fits-all solution. Developers are sometimes hesitant to use them because they can complicate infrastructure at scale.
But functions are easy to write and easy to understand. Even non-technical users can understand how to call functions and sometimes even write basic ones. We learn functions like f(x) = x² at a young age.
Functions-as-a-Service will play a significant role in the future of computing, but it won't look anything like it looks today.