OCI Functions and Serverless

Running a server to handle work that happens occasionally is a quiet form of waste. The machine sits idle most of the time, yet it still has to be patched, monitored, and paid for, all to be ready for bursts of activity that may be brief and irregular. Serverless computing removes that waste by running code only when there is work to do and charging only for the time it runs. This guide explains OCI Functions, the serverless platform on Oracle Cloud Infrastructure, what it is good for, where it fits, and how to think about building with it.

It is part of our DevOps and automation on OCI cluster. It pairs closely with our guide to OCI events and functions automation, connects to the deployment patterns in CI CD on OCI end to end, and complements the provisioning side covered in automated provisioning on OCI.

What serverless means

Serverless does not mean there are no servers. It means the servers are entirely the provider's concern, so that the team writes the code and the platform takes care of where and when it runs, scaling it up when there is work and down to nothing when there is not. The team never provisions a machine, never patches an operating system, and never pays for idle capacity, because there is no idle capacity to pay for. What remains is the code and the events that trigger it, which is a dramatically smaller surface to manage.

OCI Functions is OCI's implementation of this model, built on the open source Fn project, which means the functions are portable and not locked to a proprietary format. A function is a small piece of code that does one job, is triggered by an event or a request, runs, and then goes away. This event driven, ephemeral nature is what makes serverless efficient for the right kind of work, and understanding which kind of work that is is the key to using it well.

Where serverless fits and where it does not

Serverless shines for work that is intermittent, event driven, and naturally broken into small independent pieces. Responding to a file being uploaded, processing a message from a queue, reacting to a change in a resource, running a scheduled job, or handling a lightweight API request are all natural fits, because the work arrives in discrete events and does not need a server standing by between them. For this kind of work, serverless is both cheaper and simpler than running a server.

Serverless is a poor fit for work that runs constantly, holds long lived state, needs very low and predictable latency on every single call, or runs for a long time per invocation. For those workloads a running compute instance or a container on OKE is the better tool, because the assumptions serverless is built on, brief stateless bursts, do not hold. Knowing the boundary is what separates teams who get value from serverless from teams who fight it.

How OCI Functions is triggered

A function does nothing until something invokes it, and the ways it can be invoked are what make it useful. Functions can be called directly through an endpoint, invoked on a schedule, or, most powerfully, triggered automatically by the OCI Events service when something changes in the estate. This last pattern, an event in the platform firing a function that responds, is the heart of event driven automation on OCI and the reason functions and events are so often discussed together, as we do in our guide to OCI events and functions automation.

This triggering model is what lets functions act as the glue of an automated estate, responding to things happening rather than being called explicitly. A resource is created and a function tags it, an object is uploaded and a function processes it, an alarm fires and a function takes a corrective action. The function is small, but the pattern of platform events driving small responses is what makes a large estate able to look after parts of itself.

Building and deploying functions

A function is packaged as a container image, which means it carries its own dependencies and runs the same way everywhere, and that image is stored in the OCI registry and deployed from there. Because functions are container images, they fit naturally into the same CI CD pipelines that handle the rest of an application, built, tested, and deployed by the same automated path described in our guide to CI CD on OCI end to end. There is no separate special process for shipping functions; they are artifacts like any other.

The discipline in building functions is to keep them small and focused, doing one job and depending on as little as possible, because small functions start faster, are easier to reason about, and compose better. A function that tries to do too much loses the advantages of the model. Thinking in small single purpose functions, triggered by events and composed into larger behaviours, is the mindset that makes serverless productive.

Cost and the serverless trade

The headline appeal of serverless is paying only for what runs, and for intermittent workloads this genuinely is cheaper than keeping a server running to wait for occasional work. But serverless is not universally cheaper, and a function invoked constantly at high volume can cost more than a right sized running instance doing the same work. The trade is real, and getting it right is part of the cost discipline we bring through our OCI cost optimization service, where matching the execution model to the shape of the load is one of the levers that moves spend.

Used for the work it suits, OCI Functions removes both cost and operational burden, letting a team respond to events without running and minding servers to do it. It is one of the most useful tools in the OCI automation toolkit, and standing up event driven serverless patterns is something we do regularly within our DevOps and IaC solution. Matched to the right workloads, serverless is a quiet, efficient way to let an estate do more with less.