Modern App Development on OCI: Serverless, APIs, and Events

Most conversations about Oracle Cloud Infrastructure start with the database, and for good reason. Exadata, Autonomous Database, and the licensing economics around them are why most organisations arrive on the platform in the first place. But once the data tier is on OCI, a second question follows quickly: what about the applications? The services that read and write that data, the APIs that expose it, the integrations that react to it, and the new products the business wants to build on top of it all need somewhere to run, and running them next to the database is usually the right answer for latency, for egress cost, and for operational simplicity.

The good news is that OCI has quietly assembled a genuinely complete application platform. There is a serverless functions service built on an open source core, a managed API gateway, a serverless container service for teams that want containers without a cluster, a strong managed Kubernetes offering, a family of event driven messaging services, a native DevOps service for CI/CD, a managed vault for secrets and encryption keys, a mature low code platform in APEX, and Ampere ARM compute that changes the price performance math for almost everything that runs on it. The catalog is smaller than what AWS or Azure offer, but it covers the patterns that real applications actually use, and it is usually cheaper to run.

This article is the pillar for our application development series. It walks the full landscape one theme at a time, links to the deep dive article on each service, and finishes with a comparison of the compute options and a seven step framework for adopting the platform deliberately rather than by accident. If you are planning a broader modernisation effort, our app modernization on OCI page covers how this platform work fits into a wider migration and replatforming program.

The OCI app platform at a glance

Before going deep on any single service, it helps to see the whole board. The OCI application platform breaks into six groups, and almost every modern architecture on OCI is a composition of pieces from these groups.

• Compute for application code. OCI Functions for serverless event handlers, Container Instances for serverless containers, OKE for full Kubernetes, and ordinary VMs for everything that does not fit the newer models. Ampere A1 ARM shapes are available across all of them.
• API management. API Gateway sits in front of functions, containers, and Kubernetes services, handling routing, authentication, rate limiting, and request transformation.
• Event driven messaging. The Events service emits structured events when resources change state, Queue provides reliable point to point messaging, Notifications fans messages out to many subscribers, and Streaming handles high throughput ordered data with a Kafka compatible API.
• Delivery tooling. The OCI DevOps service provides code repositories, build pipelines, artifact storage, and deployment pipelines, and it coexists happily with GitHub Actions and other external CI systems.
• Security primitives. Vault manages secrets and encryption keys, and resource principals let workloads authenticate to OCI services without long lived credentials in configuration.
• Low code. APEX, included with every Oracle database, builds data centric web applications at a speed that custom code cannot match for the right class of problem.

None of these services is exotic on its own. The value is in how they compose, and the rest of this article works through each group with an eye on the composition.

Serverless compute with OCI Functions

OCI Functions is the platform's serverless compute service. You write a function in Python, Java, Node.js, Go, or any language that can be packaged as a container, push it to a registry, and OCI runs it on demand, scaling from zero to whatever the workload needs and billing you only for the time the code actually executes. The service is built on the open source Fn Project, which matters more than it might sound: the function format is a plain container image with a defined contract, so there is no proprietary packaging to learn and considerably less lock in than the equivalent services elsewhere.

The classic serverless weakness is the cold start, the delay while the platform provisions a container for a function that has not run recently. OCI addresses this with provisioned concurrency, which keeps a configured number of function instances warm and ready, trading a modest standing cost for predictable latency. For interactive APIs where a two second cold start is unacceptable, provisioned concurrency on the hot paths is usually the difference between functions being viable and not.

Functions fit best where the work is genuinely intermittent and event shaped: handling a webhook, processing an uploaded file, reacting to a resource change, running a scheduled job, gluing two services together. They fit poorly where the process is long running, stateful, or needs consistent low latency at high volume. Our complete guide to OCI Functions covers the development workflow, configuration, limits, and the patterns that work in production.

API management with API Gateway

Functions and backend services need a front door, and on OCI that front door is API Gateway. The service is a fully managed, regional gateway that terminates TLS, routes requests to backends including Functions, Container Instances, OKE services, and arbitrary HTTP endpoints, and applies policy on the way through. The policy set covers the essentials well: authentication with JWT validation or custom authorizer functions, rate limiting per client or per route, CORS handling, request and response transformation, and usage plans that let you treat internal and external consumers differently.

The architectural role of the gateway is easy to understate. It is the layer where you stop exposing implementation details to consumers, which is what lets you swap a function for a container, or a monolith endpoint for a microservice, without breaking anyone. It is also the natural enforcement point for the security and throttling rules that otherwise end up reimplemented inconsistently in every backend. The mechanics of deployments, routing rules, and authorizers are covered in our guide to OCI API Gateway.

Beyond the mechanics sits the governance question: who may publish an API, what standards it must meet, how versions are retired, and how consumers discover what exists. Most organisations get the gateway running in a week and then spend a year discovering they needed answers to those questions on day one. We have written up the operating model side separately in our API management strategy for OCI, and we would argue it is the more important read of the two.

Containers without Kubernetes: Container Instances

Between the function and the cluster sits a gap that OCI fills with Container Instances: you give the service a container image, a CPU and memory allocation, and networking details, and it runs the container on serverless infrastructure with no cluster, no nodes, and no orchestrator to manage. Billing is per second for the resources allocated, and the instance can run for minutes or for months.

This is the right tool far more often than its low profile suggests. Long running workers that consume from a queue, scheduled batch jobs that outgrow the function time limit, third party containers you need to host but do not want to own a cluster for, build and test workloads, and small internal services with steady but modest traffic all fit Container Instances better than either Functions or OKE. The service deliberately does not do orchestration: there is no auto scaling group, no rolling deployment primitive, no service discovery. If you need those, you have outgrown it. Our deep dive on OCI Container Instances covers the configuration model, the networking options, and the patterns where it shines.

Full Kubernetes on OKE

When the application is a system of services rather than a handful of containers, Kubernetes earns its complexity, and Oracle Kubernetes Engine is OCI's managed offering. The control plane is free in the basic tier, worker nodes are ordinary OCI compute billed at ordinary compute rates, and the service supports both managed node pools and virtual nodes that remove node management entirely. Combined with Ampere ARM worker shapes, OKE is consistently one of the cheapest places in the public cloud to run Kubernetes at scale, which is a sentence that surprises people who have not priced it.

Running Kubernetes well is less about the cluster and more about the patterns you run inside it. Service decomposition, ingress design, namespace and tenancy strategy, resource requests and limits, horizontal pod autoscaling, and disruption budgets determine whether the platform is a productivity multiplier or a source of incidents. We cover these in microservice patterns on OKE, which is the practical companion to this section.

As the number of services grows, the connective tissue between them becomes its own problem: mutual TLS between services, retries and timeouts applied consistently, traffic splitting for canary releases, and observability into who calls whom. That is the job of a service mesh, and our article on service mesh on OCI looks at when a mesh is worth its operational weight and when simpler tooling does the job. For the broader platform build, including landing zone integration, cluster topology, and day two operations, see our Kubernetes on OKE solution.

Comparing the compute options

With four ways to run application code, the obvious question is which to use when. The table below is the short version; the rest of this article and the linked deep dives are the long version.

Event driven architecture: Events, Queue, Notifications, and Streaming

Modern applications increasingly communicate by reacting to things that happen rather than by calling each other directly, and OCI provides four services that cover the spectrum of event driven communication.

The Events service is the platform's nervous system. When a resource in your tenancy changes state, an object lands in a bucket, an instance launches, a database backup completes, the service emits a structured event in CloudEvents format, and rules route matching events to a function, a stream, or a notification topic. This is automation without polling, and our guide to the OCI Events service walks through the rule syntax and the most useful event sources.

The Queue service handles reliable point to point messaging: a producer enqueues work, a consumer dequeues it, processes it, and deletes it, with visibility timeouts and dead letter handling for the failure cases. Queues are how you decouple a fast front end from a slow back end and how you absorb traffic spikes without dropping work. The semantics and sizing guidance live in our deep dive on OCI Queue.

The Notifications service is fan out: one message published to a topic is delivered to every subscription, whether that is email for humans, a function for automation, or an HTTPS endpoint for a third party system. It is the standard delivery channel for alarms and the simplest way to get one event in front of many consumers, covered in our guide to OCI Notifications.

The Streaming service rounds out the set for high throughput, ordered, replayable data: clickstreams, telemetry, change data capture, and log pipelines. Its Kafka compatible API means most existing Kafka producers and consumers work against it with a configuration change rather than a rewrite.

The art is in composing these into architectures: an object upload emits an event, the event triggers a function, the function enqueues work items, container workers consume the queue, and a notification reports completion. These reference compositions, along with idempotency, ordering, and error handling patterns, are the subject of our pillar companion on event driven architecture on OCI.

CI/CD: the OCI DevOps service and GitHub Actions

Code needs a path to production, and OCI offers a native one. The OCI DevOps service bundles managed Git repositories, build pipelines defined in a YAML specification, an artifact registry, and deployment pipelines that target OKE, Container Instances, Functions, and VM instance groups, with built in support for rolling, blue green, and canary strategies. Because it is a native service, it authenticates to the rest of OCI with resource principals rather than stored credentials, which quietly removes a whole class of secret sprawl. Our guide to the OCI DevOps service covers the pipeline model end to end.

In practice, many teams arrive with their CI already living in GitHub, and there is no reason to move it. A GitHub Actions workflow can build and test on GitHub runners, push images to OCI Registry, and deploy to OKE using workload identity federation so that no long lived OCI keys ever sit in GitHub secrets. We maintain a worked example in CI/CD to OKE with GitHub Actions, and the hybrid pattern, GitHub for CI and the OCI DevOps service for deployment, is often the best of both. The delivery pipeline is also where infrastructure as code belongs, with Terraform runs gated through the same review discipline as application code; our DevOps and infrastructure as code solution covers that operating model.

Secrets and keys: OCI Vault

Every application has secrets, database passwords, API keys, signing certificates, and the difference between a mature platform and a risky one is where they live. OCI Vault is the managed answer: secrets are stored encrypted, versioned, and access controlled through IAM policy, and encryption keys are held in hardware security modules with the option of customer managed keys for services across the platform. Applications retrieve secrets at runtime using resource principals, so a function or a pod proves its identity to OCI rather than carrying a credential to fetch other credentials, and rotation becomes a configuration change instead of a redeployment.

The practical rule we give every team is simple: no secret in code, no secret in an environment variable that is set by hand, and no key material on a developer laptop. Everything sensitive resolves through Vault at runtime, and IAM policy defines exactly which workloads can read which secrets. The setup, the rotation patterns, and the integration with Functions, OKE, and the DevOps service are covered in our guide to OCI Vault and secrets management.

Low code with APEX

Not every application deserves a microservice architecture, and pretending otherwise is one of the more expensive mistakes a development organisation can make. Oracle APEX, included at no extra licence cost with every Oracle database on OCI, builds data centric web applications, forms, reports, dashboards, and admin tools, at a fraction of the effort of custom code. For internal applications whose essence is reading and writing database tables, an experienced APEX developer routinely delivers in days what a custom stack would deliver in months.

The right place for APEX in an application strategy is alongside the custom platform, not instead of it. Customer facing products with demanding UX, complex integration surfaces, and independent scaling needs belong on Functions, Container Instances, or OKE. The long tail of internal tooling, the approval workflows, the reference data editors, the operational dashboards, belongs on APEX, where it costs almost nothing to build and run. Teams already on Autonomous Database have the runtime sitting there unused. We map the fit honestly, including where APEX runs out of road, in low code on OCI with APEX.

Ampere ARM and the price performance argument

One of the strongest and least discussed cards OCI holds is Ampere ARM compute. The A1 shapes are flexible, you choose OCPU and memory independently, they are priced well below comparable x86 shapes, and for the workloads that dominate application platforms, web servers, API backends, queue workers, and containerised microservices, they deliver equal or better throughput per dollar. The always free tier even includes a generous A1 allowance, which makes experimentation costless.

The migration effort is smaller than most teams fear. Modern language runtimes, Java, Go, Node.js, Python, and .NET, all run natively on ARM, container tooling builds multi architecture images in one pipeline step, and OKE happily runs mixed node pools so you can move services across one at a time and measure as you go. The main caution is third party binaries and older native dependencies, which need checking before commitment. We cover benchmarks, the multi architecture build setup, and a phased migration plan in Ampere ARM compute on OCI. For a platform being built today, our default advice is to make ARM the baseline and treat x86 as the exception that needs justifying.

Choosing serverless versus containers per workload

With the landscape mapped, the recurring decision is the one in this article's title: serverless or containers for a given workload. The honest answer is that it is a per workload decision, not a platform religion, and the deciding variables are consistent. Traffic shape matters most: spiky, intermittent traffic favours Functions because you pay nothing between invocations, while steady traffic favours containers because an always on allocation is cheaper than millions of invocations. Execution profile matters next: long running processes, websockets, and anything stateful rule out functions. Latency sensitivity matters where cold starts hurt and provisioned concurrency would erase the cost advantage. And team shape matters more than architects admit: a platform team that already runs OKE well can absorb another service cheaply, while a small product team with no Kubernetes experience ships faster on Functions and Container Instances.

Most real systems land on a mix: functions on the event driven edges, containers in the steady core, and the gateway in front making the seams invisible to consumers. We work through the decision with worked cost examples in serverless versus containers on OCI, which is the recommended next read after this pillar.

How OCI compares with AWS and Azure

Teams evaluating OCI for application work are usually comparing it with what they know, so a high level calibration is fair. OCI Functions maps to AWS Lambda and Azure Functions, API Gateway to Amazon API Gateway and Azure API Management, Container Instances to AWS Fargate and Azure Container Instances, OKE to EKS and AKS, Queue to SQS and Azure Storage queues, Notifications to SNS, and Streaming to Kinesis and Event Hubs. The mapping is close enough that architecture knowledge transfers directly.

Three honest differences matter. First, cost: OCI is consistently cheaper on compute, dramatically cheaper on egress, and the free OKE control plane plus Ampere pricing compounds the gap for container platforms. Second, catalog depth: AWS and Azure each offer several times as many services, richer edge networks, and bigger third party ecosystems, so if your roadmap depends on a long tail of specialised managed services, the larger clouds keep an advantage. Third, gravity: for organisations whose data already lives on OCI because of the database estate, running the application tier in the same cloud avoids egress charges, cross cloud latency, and a second operational surface, and that advantage usually outweighs catalog depth for the application patterns described here. The pragmatic conclusion we give clients is that OCI is a strong, often cheaper home for the mainstream patterns, and the case is strongest when the database is already there.

A seven step platform adoption framework

The failure mode for application platforms is accretion: each team picks tools independently, and two years later the estate has four CI systems, secrets in five places, and no shared answer to anything. The fix is to decide the platform deliberately. Here is the sequence we use in engagements.

Bringing it together

The OCI application platform is smaller than its hyperscale rivals and better than its reputation. Functions, API Gateway, Container Instances, OKE, the event driven quartet, the DevOps service, Vault, APEX, and Ampere ARM cover the patterns that the overwhelming majority of business applications actually need, at a price point the bigger catalogs struggle to match, and with a natural gravity for any organisation whose data tier is already on OCI. The risk is not that the platform lacks a capability you need; it is that the platform gets adopted piecemeal, without defaults, governance, or a delivery pipeline worth the name.

From here, the best next reads depend on where you are. If you are weighing compute models, start with serverless versus containers linked above. If you are designing integrations, the event driven architecture pillar is the one. And if you want help making these decisions against your actual portfolio rather than in the abstract, our OCI implementation practice designs and builds these platforms as fixed fee engagements, from landing zone through first production workload.