Developing on Oracle Cloud Infrastructure

Developing on Oracle Cloud Infrastructure is a hands-on guide to building, deploying, and operating modern cloud applications on OCI, from your first resources all the way to production-ready architectures.

What the book is about

This book focuses on development on OCI: how to turn ideas into working cloud solutions using OCI’s core building blocks (networking, compute, storage, databases, identity) plus cloud-native services (containers, serverless, API management, streaming, events, observability). Instead of treating services in isolation, it connects them into realistic end-to-end architectures.

A running example—AuroraRetail 360—ties the chapters together, showing how a typical digital business evolves: from a simple app to a scalable platform with automation, security controls, and event-driven workflows.

What you will learn

By the end, you’ll be able to:

  • Design OCI architectures: compartments, IAM policies, networking (VCNs, subnets, gateways), and secure patterns.
  • Build and run workloads on compute and containers (including OKE) and understand when to choose which.
  • Create serverless and event-driven systems with Functions, API Gateway, Streaming, Events, and Notifications.
  • Automate infrastructure with Terraform and OCI Resource Manager, and adopt repeatable deployment workflows.
  • Work with data services and pick the right storage/database options for app needs.
  • Operate in production: logging, metrics, tracing, alarms, and troubleshooting with OCI observability tools.
  • Apply real-world security: least privilege, secrets, network segmentation, and governance practices.

Who the book is for

This book is for:

  • Software developers who want to build cloud-native apps on OCI (backend, platform, integration-focused).
  • Cloud engineers / DevOps practitioners moving from another cloud to OCI or standardizing OCI development practices.
  • Solution architects and technical leads who need practical guidance and reference architectures.
  • OCI learners who prefer “build it like a real system” over purely theoretical service overviews.

If you’re comfortable with basic programming concepts and have some familiarity with web APIs or cloud fundamentals, you’ll get the most out of it, and if you’re new to OCI, the book is structured to ramp you up quickly while keeping things practical.

In the following you find the table of contents, the introduction and the first chapter.

Table of Contents

About the Author 7

Acknowledgements 8

Introduction 9

Part I – Strategic Foundations on Oracle Cloud Infrastructure (OCI) 15

Chapter 1 – OCI in the Enterprise Cloud Landscape 15

Chapter 2 – Tenancy, IAM, and Enterprise Governance 40

Chapter 3 – Security & Compliance as a Baseline 63

Part II – Core Platform Building Blocks 89

Chapter 4 – Advanced Networking on OCI 89

Chapter 5 – Compute & Capacity Management 111

Chapter 6 – Storage Strategy for Applications 128

Chapter 7 – Databases on OCI for Developers 144

Part III – Application Platforms & Modern Architectures 162

Chapter 8 – Designing and Deploying Cloud-Native Apps on OCI 162

Chapter 9 – Containers & Oracle Kubernetes Engine (OKE) 181

Chapter 10 – Serverless & Event-Driven Development 198

Chapter 11 – Integration and Extension of Oracle SaaS 216

Chapter 12 – Low-Code and Pro-Code Together 232

Part IV – Data, Analytics, and AI on OCI 250

Chapter 13 – Data Ingestion and Pipelines 250

Chapter 14 – Analytics and Data Warehousing 270

Chapter 15 – AI/ML Services and MLOps on OCI 291

Part V – Delivery, Operations, and Reliability 313

Chapter 16 – Infrastructure as Code & Environment Management 313

Chapter 17 – DevOps and CI/CD on OCI 333

Chapter 18 – Observability & SRE Practices 351

Chapter 19 – Security Engineering for Applications 371

Part VI – Case Studies, Patterns, and Anti-Patterns 390

Chapter 20 – Case Study: High-Throughput API Platform on OCI 390

Chapter 21 – Case Study: Data Platform for Mixed OLTP/Analytics 410

Chapter 22 – Patterns, Anti-Patterns, and Migration Lessons 430

Appendices 449

Appendix A: Quick-start landing zone blueprint (tenancy, compartments, policies) 449

Appendix B: Sample Terraform modules and patterns 458

Appendix C: Example IAM policies and tagging strategies 461

Appendix D: Command and API cheat sheets (CLI, SDKs, DevOps, Functions) 471

Appendix E: Recommended documentation, training, and certification paths 479

Introduction

    Oracle Cloud Infrastructure is often introduced through a catalog of services: compute, storage, networking, databases, Kubernetes, serverless, analytics, AI. That catalog is real, but it is not how successful teams build platforms. Teams succeed when they treat OCI as a set of building blocks that solve recurring problems, secure connectivity, governed environments, reliable delivery, predictable operations, and then assemble those blocks into an architecture that can evolve under business pressure.

    This book is written for that reality. It’s for people who don’t want a tour of features, but a practical guide to developing and operating applications on OCI with the same discipline you would apply to any production platform: strong boundaries, repeatable environments, safe releases, and an observability and security posture that holds up on the worst day of the year.

    To keep the discussion concrete, the book follows a single running example: AuroraRetail 360, a multi-tenant retail platform that starts simple and becomes more capable chapter by chapter. AuroraRetail 360 is not a toy architecture. It reflects the kinds of constraints real platforms face: peak traffic bursts, integration with Oracle SaaS (Fusion ERP and others), event-driven workflows, data and analytics pipelines, multi-region concerns, and the operational demands of CI/CD, SRE, and security engineering. You’ll see the platform evolve, not only the “happy path,” but the trade-offs and anti-patterns that teams must recognize early.

    This introduction sets expectations: who the book is for, how it is structured, and how to use it as a practical reference while you build on OCI.

    1. What this book is about

    This is a development-focused OCI book, but it does not stop at development. Modern cloud systems fail when development and operations are treated as separate worlds. A service that compiles and passes tests can still be unusable if its network posture is wrong, its IAM policies are too broad or too tight, its scaling behavior collapses under bursts, or its release strategy turns every deployment into a gamble.

    So this book treats “developing on OCI” as an end-to-end discipline:

    • Designing environments and boundaries (tenancy, compartments, networks, governance)
    • Building services and event-driven workflows (OKE, Functions, Streaming, API Gateway)
    • Integrating with SaaS and other systems (Integration Cloud, adapters, OAuth2 flows)
    • Handling data as a first-class platform capability (Object Storage, ADW, Analytics, pipelines)
    • Operating the platform reliably (IaC, CI/CD, SLOs, runbooks, observability)
    • Engineering security into every hop (identity-first access, Vault, WAF, secure SDLC)

    You can read the book cover to cover, but it’s also designed to be used as a pattern library. Many chapters end with a small set of reusable architectural moves you can apply immediately.

    2. Who this book is for

    This book is written for practitioners who build and run software systems:

    • Backend and full-stack developers moving into cloud-native patterns on OCI
    • Platform engineers and DevOps engineers responsible for clusters, pipelines, and environments
    • SREs and operations engineers who need observability, SLOs, and runbooks that match real failure modes
    • Solution and cloud architects who want implementable architectures, not slideware
    • Data engineers and analytics teams building ingestion, transformation, and governed reporting on OCI
    • ML engineers and data scientists who need a sane path from training to deployment and monitoring

    You don’t need to be an OCI specialist to start, but you’ll benefit from basic familiarity with networking concepts, identity and access control, and modern application delivery practices. Where OCI-specific behavior matters, the book explains it through patterns and implementation decisions rather than vendor marketing language.

    3. How to read this book

    Different readers will use this book differently. AuroraRetail 360 is the spine, but you can follow paths that match your role:

    If you’re primarily building services, you can focus on the application platform chapters and return to governance and operations as needed. If you’re responsible for platform reliability, you may start with landing zone, IAM, observability, and CI/CD and then treat the application chapters as examples of what you’ll support. If you work in data and analytics, you can jump into the ingestion and warehousing parts and then use the security and operations sections to harden your pipelines.

    A useful way to read is to treat each part as a cycle:

    • Design the baseline
    • Build a thin slice end-to-end
    • Harden it for delivery and operations
    • Expand capability
    • Repeat

    This is also how AuroraRetail evolves through the chapters. The platform grows, but it doesn’t abandon early decisions. It refines them.

    4. The AuroraRetail 360 story: why one continuous example matters

    Cloud books often present a new example for each service. That makes it hard to understand how systems evolve, how one decision affects another, and why “best practice” sometimes changes once you operate at scale.

    AuroraRetail 360 gives us continuity:

    • Early on, it looks like a classic three-tier architecture and landing zone.
    • It evolves toward microservices on OKE with an event-driven backbone.
    • It integrates with Oracle SaaS (Fusion ERP) using secure OAuth2/token exchange patterns.
    • It builds a data platform that progresses from nightly batch to near real-time analytics.
    • It introduces MLOps with demand forecasting and model serving patterns.
    • It becomes operationally mature with IaC, CI/CD, SLOs, runbooks, and secure SDLC.
    • It faces and corrects common anti-patterns as it grows.

    You’ll see the same workloads and flows appear in different chapters, networking, security, observability, data, and delivery, because in real systems, those concerns intersect.

    5. A note on opinionated guidance

    This book is intentionally opinionated in a few areas because neutrality can be unhelpful when you have to make decisions:

    • Private-by-default networking is treated as a default posture, not a special case.
    • IAM policies are framed around least privilege and principals rather than static credentials.
    • Event-driven designs are preferred for decoupling and burst handling, especially on critical paths.
    • Infrastructure and governance are treated as code, promoted through environments like software.
    • Observability is tied to SLOs and runbooks, not just dashboards.
    • Security is framed as engineering: edge protection, identity propagation, encryption, and secure SDLC.

    That said, the book does not assume a single “correct” architecture for every case. Instead, it shows how to choose patterns based on constraints: latency, cost, compliance, organizational ownership, and change rate.

    6. What you’ll be able to do by the end

    If you work through the book and apply the patterns, you should be able to:

    Design a landing zone and compartment structure that supports multi-team delivery without chaos. Build and deploy cloud-native services and serverless workflows on OCI with a clear edge and a private core. Integrate safely with Oracle SaaS and external systems using secure token flows and anti-corruption boundaries. Build a data platform that supports operational dashboards, analytics, and ML without loading the transactional core. Operate the platform with repeatable environments, safe releases, measurable reliability, and continuous security.

    In other words, you’ll be able to build systems on OCI that can grow, more tenants, more regions, more teams, without becoming fragile.

    7. How to use the appendices

    The appendices are designed as practical tools:

    • Quick-start landing zone blueprint (tenancy, compartments, policies)
    • Terraform module patterns and policy-as-code approaches
    • IAM and tagging examples
    • CLI/SDK/DevOps/Functions cheat sheets
    • Learning and certification maps

    They exist so you don’t have to re-derive common commands and templates while you’re building. Treat them as reference material you keep open while implementing the main chapters.

    8. A final framing: building blocks, not menus

    OCI is a large platform. You can experiment endlessly with services and still struggle to ship. AuroraRetail’s architecture team treats OCI service families the way this book does: not as a menu to try everything from, but as a set of building blocks that solve specific problems. Your job as a developer, platform engineer, or architect is to pick the smallest set of blocks that meet the constraints, then build a system that is secure, observable, and repeatable.

    That’s what the rest of this book is about.

    Part I – Strategic Foundations on Oracle Cloud Infrastructure (OCI)

      Chapter 1 – OCI in the Enterprise Cloud Landscape

      The last decade has standardized a lot of cloud vocabulary. Regions, availability zones, virtual networks, managed databases, serverless runtimes – if you’ve built on AWS, Azure, or Google Cloud, none of that is new to you.

      What is different, especially when you live in an Oracle-heavy world, is how Oracle Cloud Infrastructure (OCI) fits into that landscape. For some organizations, OCI is the “third cloud” that joins an existing mix of AWS and Azure. For others, it’s the primary landing zone for their most business-critical Oracle workloads, with other clouds orbiting around it.

      In this book, we’ll explore that landscape through a concrete, opinionated example: AuroraRetail 360.

      AuroraRetail 360: a quick introduction

      AuroraRetail is a software company that provides a SaaS platform to mid-sized retailers. The platform, AuroraRetail 360, powers e-commerce sites and in-store operations around the world. Retailers run their online storefront, POS integration, inventory management, and loyalty programs on this platform, plus a growing set of analytics dashboards for store managers and HQ.

      Before its cloud migration, AuroraRetail’s architecture looks very familiar to anyone who has grown up with Oracle:

      • A large on-premises Oracle Database instance that hosts almost everything: tenant data, orders, payments, product catalogs, and configuration.
      • A Java EE monolith running on WebLogic in a pair of data centers.
      • Nightly batch jobs that extract data into a separate reporting database.
      • SFTP deliveries and SOAP integrations to various customer ERPs, including Oracle Fusion ERP for a few early adopters.

      This stack has served the company well. It is also at its limits. Black Friday peaks require elaborate capacity planning. New tenants can’t be on-boarded as quickly as sales would like. Compliance teams increasingly ask difficult questions about data residency and encryption. Product teams want to experiment with new services, especially around real-time recommendations and demand forecasting, but the monolith is hostile to change.

      AuroraRetail’s leadership decides to move AuroraRetail 360 to the cloud. The key decision: which cloud?

      They already have secondary workloads on AWS and some integrations with Microsoft-centric customers on Azure. But the core of their business is Oracle Database and Oracle SaaS. That is what brings them to OCI.

      Why AuroraRetail chooses OCI

      From a distance, AWS, Azure, Google Cloud, and OCI all appear similar: global regions, elastic compute, managed Kubernetes, object storage, and a menu of data and AI services. At that level, the choice is almost aesthetic.

      For an Oracle-centric organization like AuroraRetail, the decision becomes much more constrained. Three forces dominate their evaluation:

      1. Database gravity. AuroraRetail’s most sensitive data lives in an Oracle Database that uses advanced features – partitioning, Data Guard, PL/SQL packages – and must evolve rather than be rewritten. OCI offers Autonomous Database and Exadata-based services that are tightly integrated with the platform and optimized for Oracle workloads, including consolidation and high availability options that go beyond “Oracle on generic IaaS.”
      2. SaaS integration. A growing share of AuroraRetail’s customers are adopting Oracle Fusion ERP and other Oracle SaaS offerings. OCI’s integration services include prebuilt adapters and patterns for connecting to Oracle SaaS as well as third-party systems, which is attractive for a platform that needs to link deeply into its customers’ back offices.
      3. Economics and licensing. Running Oracle Database on OCI comes with tangible cost and governance advantages: license portability, favorable BYOL ratios, support rewards, and unified support for both the cloud platform and the database engine. These factors significantly change the total cost of ownership compared to running the same Oracle workloads on AWS, Azure, or GCP.

      On top of that, AuroraRetail’s architecture team notes that OCI’s region footprint has grown to dozens of public cloud regions across more than twenty countries, which makes it viable for their EU and North American customer base and gives them room to expand.

      They do not abandon other clouds entirely. Some customers run specific workloads on AWS or Azure and will continue to do so. OCI has an explicit multicloud strategy – including services such as Oracle Database@Azure and Oracle Database@AWS – that lets enterprises run Oracle database services close to applications deployed on other hyperscalers.

      But for the core transactional and analytical heart of AuroraRetail 360, OCI becomes the primary home.

      The rest of this chapter puts that decision into a broader context.

      1.1 Positioning OCI vs. AWS, Azure, and GCP for Oracle-centric workloads

      If you talk to teams whose systems revolve around Oracle Database, Oracle Fusion SaaS, and Oracle-based middleware, you’ll often hear a tension: they want the elasticity and velocity of modern cloud platforms, but they cannot simply switch off decades of investment in Oracle technology.

      For these teams, the cloud question is not abstract. It is very specific:

      “Where can we run our Oracle workloads with the least friction, the best economics, and the clearest operational story – without locking ourselves out of modern cloud-native patterns?”

      This is where OCI has a distinct position compared to AWS, Azure, and GCP.

      Co-engineered database services

      On AWS, Azure, and GCP, Oracle Database typically runs in one of two ways: on customer-managed virtual machines, or via database services that emulate Oracle but are not actually Oracle Database. In both cases, you’re responsible for a significant portion of configuration, patching, and tuning, and you may lose access to some advanced Oracle features or support paths.

      OCI’s flagship database services – Autonomous Database and Exadata-based offerings – are built and operated by the same organization that owns the Oracle Database engine. They expose the full feature set (including advanced options and RAC where applicable) and add cloud-native capabilities such as automated scaling, patching, and performance tuning.

      For AuroraRetail, this matters more than any individual feature bullet. Their order and inventory logic rely on PL/SQL packages that embed business rules and validation. Migrating that logic to a different database would be a multi-year project on its own. With OCI, they can bring those schemas and packages into an Autonomous Transaction Processing (ATP) instance and start modernizing around them, instead of rewriting them from scratch.

      In later chapters, when we move AuroraRetail’s legacy database to ATP and add Autonomous Data Warehouse (ADW) for analytics, this co-engineered stack becomes the foundation that everything else builds on.

      Licensing, support, and total cost of ownership

      Experienced Oracle customers know that licensing strategy is as important as technical design. AWS and Azure can certainly host Oracle databases, but the licensing and support story is more fragmented and often more expensive over time. BYOL in a non-Oracle cloud usually follows standard, relatively strict rules, with no extra incentives for using Oracle’s software there.

      On OCI, the picture is different. Oracle offers:

      AuroraRetail’s CFO doesn’t care about OCPU ratios or Exadata shapes by name. What they do care about is the ability to project costs for the next five years and reduce the “Oracle tax” that everyone complains about in hallway conversations. OCI’s licensing and support incentives are a major reason they can justify the migration investment.

      As we go deeper into cost management and FinOps in later chapters, we’ll revisit this from a more quantitative angle, including how AuroraRetail uses tagging, Compartments, and budgets to keep those economics under control.

      Proximity to Oracle SaaS and integration services

      For many enterprises, Oracle is not just a database vendor. It is the provider of their ERP, HCM, CX, SCM, and other core business systems. Those systems increasingly run as SaaS on top of Oracle Cloud.

      OCI’s integration services are tuned for this reality. They provide prebuilt adapters and managed connectivity for Oracle SaaS applications as well as popular third-party systems such as Salesforce, SAP, Shopify, and Workday.

      AuroraRetail depends on these connections. When a retailer uses Oracle Fusion ERP, AuroraRetail 360 needs to push orders and invoices into the customer’s ERP, synchronize product catalogs, and pull financial or inventory signals back. Doing this from OCI is not just a matter of low latency – it is about lowering integration friction and using supported patterns rather than custom glue.

      Throughout the book, we’ll see how AuroraRetail implements these flows with Integration Cloud, Functions, and API Gateway, and how they expose secure REST endpoints that Oracle SaaS can call in turn.

      Regions, resiliency, and multicloud

      From a regional footprint perspective, OCI used to lag significantly behind AWS and Azure. That gap has narrowed. Oracle now operates more than forty-five public regions worldwide, spanning over two dozen countries, with a consistent catalog of core services in each region.

      For AuroraRetail, that coverage is sufficient for their immediate markets: an EU region to serve European tenants under stricter data residency rules, and at least one North American region for US and Canadian customers. The region strategy also gives them a straightforward path to expand into the Middle East or Asia-Pacific without redesigning the platform.

      At the same time, OCI is not an island. Oracle’s multicloud initiatives – such as Oracle Database@Azure and Oracle Database@AWS – recognize that many enterprises will continue to run application tiers in other clouds. These offerings place Oracle database services on or next to other hyperscalers, with high-speed connectivity to applications running there.

      AuroraRetail’s architecture board deliberately leaves this door open. While they standardize on OCI for the AuroraRetail 360 platform itself, they know that some customers may want deeper integration with workloads that already live on AWS or Azure. OCI’s multicloud stance means they won’t have to choose between “all-in OCI” and “all-in someone else”; they can mix where it makes sense.

      How this frames AuroraRetail 360

      None of this means that AWS, Azure, or GCP are inferior clouds. For many generic workloads, they are excellent choices. The point is narrower: for organizations whose critical path runs through Oracle Database and Oracle SaaS, OCI presents a more natural center of gravity.

      AuroraRetail’s path through this book is an example of leaning into that center of gravity instead of fighting it:

      • They move their existing Oracle database into OCI’s managed database services rather than away from Oracle.
      • They exploit licensing and support synergies instead of treating them as constraints.
      • They use native OCI integration capabilities to connect to Oracle SaaS and third-party systems, rather than building those integrations from scratch.

      This positioning is the backdrop for every architectural decision you’ll see in the following chapters.

      A teaser: the target architecture for AuroraRetail 360 on OCI

      To make this concrete, it helps to look ahead at where AuroraRetail is going. Picture 1.1 sketches the target architecture you’ll see evolve throughout this book:

      P icture 1.1: Target Architecture of Aurora Retail 360.

      At the edge, customers interact with their storefronts and store managers access dashboards through a combination of DNS, WAF, and load balancers. API Gateway fronts both containerized microservices in OKE and serverless functions. Autonomous Transaction Processing hosts the transactional core, while Autonomous Data Warehouse powers reporting and analytics. Streaming and Notifications carry events, and shared services – Object Storage, Vault, Logging, Monitoring, and Integration Cloud – provide the glue and governance.

      In the next chapters, we’ll zoom into each of these building blocks: first through the lens of OCI concepts like regions, compartments, and IAM, and gradually through the more specialized needs of AuroraRetail 360 as it moves from a legacy Oracle stack to a modern, cloud-native platform anchored on OCI.

      1.2 Service families and what’s really relevant for developers

      Cloud providers love big numbers. OCI talks about more than a hundred fifty services across infrastructure, data, integration, AI, and applications.
      If you’re an architect or senior developer, that’s mildly terrifying. You don’t want a catalogue; you want a short palette you can actually design with.

      In this book we’ll treat OCI’s service families the way AuroraRetail’s architecture team does: not as a menu to try everything from, but as a set of building blocks that solve very specific problems in the AuroraRetail 360 platform.

      Think in layers:

      • a core infrastructure layer that keeps the lights on for compute, network, and storage,
      • a data and database layer built around Oracle’s strengths,
      • an application platform layer for microservices, APIs, and serverless,
      • an integration and SaaS extension layer, and
      • a cross-cutting layer of observability, security, and governance.

      Picture 1.2 gives an overview about the layers.

      P icture 1.2: Layers of AuroraRetail 360

      Everything we do with AuroraRetail 360 in the rest of the book will be some combination of these layers.

      Core infrastructure: enough to run the old world and host the new one

      AuroraRetail doesn’t get to start from a greenfield. The first versions of AuroraRetail 360 on OCI will still run a sizeable Java EE application and a pile of supporting processes. For that, the relevant services are the “boring” ones: Compute, Virtual Cloud Networks, load balancers, and the main storage options.

      OCI Compute is where the legacy WebLogic-based monolith lands in the early migration phase. The team treats it much like EC2 or Azure VMs: shapes are chosen, images are hardened, instance pools and autoscaling are introduced where it makes sense. What matters to them is not that this is “cloud native” – it’s that they can stop buying hardware, scale more predictably for Black Friday, and get into OCI without rewriting everything.

      Networking is the second leg. AuroraRetail uses Virtual Cloud Networks and subnets to reproduce the familiar layout they had on-premise: public entry points for web traffic, private subnets for application tiers, and dedicated connectivity back to the data center through VPN or FastConnect. This network design turns up again and again in later chapters: when they deploy Kubernetes, when they expose APIs, when they set up cross-region replication.

      Storage shows up in multiple guises. Block volumes back the monolith’s VMs and any stateful components that can’t move immediately. Object Storage quickly becomes a dumping ground for logs, static storefront assets, and raw event data that will later feed the analytics platform. File storage plays a quieter role for shared file needs. You don’t need to memorize every storage SKU; what you need to understand is that Object Storage is the lake and archive, Block is the disk, and the rest supports specific patterns.

      Throughout the book, whenever AuroraRetail has to deploy “something with an IP address”, these core services are the canvas it lands on.

      Data and database services: the gravitational center

      For Oracle-centric shops, the database layer isn’t just another service family; it’s the center of gravity. AuroraRetail is no exception. Their primary transactional database moves into Autonomous Transaction Processing (ATP); analytical workloads go into Autonomous Data Warehouse (ADW); some customers will eventually use Exadata-based services where extreme consolidation or performance is required.

      From a developer’s point of view, these services aren’t exciting because of marketing adjectives. They are exciting because:

      • they offer full-fidelity Oracle Database features (PL/SQL, advanced options, familiar data types);
      • they remove a lot of operational noise (patching, backups, many tuning tasks);
      • they plug cleanly into the rest of OCI (identity, networking, events, integration).

      For AuroraRetail, that means they can keep critical PL/SQL-based business logic in the short term, expose some of it via ORDS and REST, and gradually move more behaviour into microservices when it makes sense. It also means the data platform we’ll build in the analytics chapters has a first-class home: ADW plus Object Storage.

      Around the core database services there are satellites. Object Storage is the data lake and archive. Streaming captures clickstream and order events, which are later landed into storage and warehoused. NoSQL is an option for particular access patterns, such as high-throughput session or feature flag storage, though you’ll see that AuroraRetail is conservative here and prefers relational schemas where possible.

      When you read later chapters about data ingestion, analytics, and demand-forecasting ML, keep in mind that they all orbit this same layer. We are not building three different data stacks; we are extending a single, Oracle-centered one.

      Application platform and developer services: where your code lives

      The next family is where most developers instinctively look first: the things that run your application code. On OCI, the main pillars you’ll meet in this book are:

      • Compute for VM-based workloads, which we’ve already touched on.
      • Oracle Kubernetes Engine (OKE) for containerized microservices.
      • Functions for serverless pieces.
      • API Gateway and load balancers as the managed front doors.
      • DevOps service and Resource Manager for CI/CD and infrastructure automation.

      AuroraRetail’s journey moves gradually across these:

      In the early chapters, the monolith runs on Compute, fronted by a load balancer, pointing at Autonomous Database. That’s the “lift and improve” phase: little architectural change, big operational gains.

      As they refactor, they peel off customer-facing APIs into small services. These land in OKE, with each service owning its deployment and configuration but sharing common ingress and observability conventions. API Gateway starts to act as the stable endpoint for external clients; internally, Kubernetes services and service discovery handle traffic.

      Functions are introduced where the workload is naturally spiky or background-oriented: webhook handlers, scheduled jobs, workflow steps triggered by Streaming events. AuroraRetail doesn’t try to make everything serverless; they use Functions for glue and for small, well-bounded components.

      Behind all of this, DevOps and Resource Manager gradually replace ad-hoc scripts. Build pipelines compile and test microservices, produce container images, and roll them out to dev or staging OKE clusters. Resource Manager and Terraform modules describe the underlying infrastructure: clusters, gateways, databases, networks. You will see those modules evolve alongside the application code, not as a separate afterthought.

      The takeaway for you as a reader: you don’t need to master every niche runtime. If you can deploy code to OKE, Functions, and Compute, and you understand how DevOps/Resource Manager orchestrate them, you’ll be able to build almost everything we cover for AuroraRetail 360.

      Integration and SaaS extension: where OCI leans into its heritage

      Almost every AuroraRetail tenant needs to connect AuroraRetail 360 to something else: ERP, CRM, payment providers, logistics, sometimes all of the above. Many of those “something else” systems are Oracle Fusion applications.

      This is where the integration and low-code family matters: Integration Cloud, API management, Events and Messaging, and services like Visual Builder or APEX for building thin UIs on top of APIs and data.

      AuroraRetail starts with a very simple view: they want a handful of well-governed, versioned APIs that represent AuroraRetail 360 to the outside world. Behind those APIs, they often need to orchestrate multiple calls: talk to the tenant’s ERP, persist something in their own database, maybe emit an event. Some of that orchestration is written in microservices or Functions, some is modelled with Integration Cloud where adapters and visual flows save them from writing yet another “adapter microservice”.

      In later chapters, when we build an internal “Store Manager Portal”, APEX appears as a quick way to expose part of the AuroraRetail data model to business users without writing a bespoke React app. The important point is not the specific choice; it’s the pattern: use low-code tools to stand up internal, data-heavy applications quickly, while keeping your domain logic and external contracts in regular code and APIs.

      From a developer perspective, this family is less about technology novelty and more about integration velocity and governance. Done well, it prevents the platform from turning into a thicket of bespoke batch scripts and point-to-point REST calls.

      Observability and operations: services you’ll care about when things go wrong

      Every cloud has logging, metrics, and some form of traces. OCI is no different: Monitoring, Logging, Logging Analytics, Events, and Alarms are the core components AuroraRetail uses.

      We’ll treat them as a single, coherent “observability fabric” rather than separate boxes. Metrics from OKE, Functions, and Databases flow into Monitoring, where SREs define SLO dashboards and alerts. Application logs land in Logging, where they can be searched or shipped onwards. Events capture significant state changes in the OCI control plane and some services, which AuroraRetail occasionally reacts to with Functions (for example, when a resource changes shape or a job fails).

      For you as a developer, the important thing is how you instrument your code and infrastructure to play nicely with this fabric. That’s why, in the microservices chapters, we’ll pay attention to consistent logging formats, correlation IDs that tie API Gateway requests to service logs, and metrics that reflect business-level health (order throughput, cart abandonment) as well as technical health (latency, error rates).

      By the time we reach the SRE-focused chapters, you’ll see how these services turn from “nice to have” to the main tools AuroraRetail uses to run AuroraRetail 360 reliably under load.

      Security and governance as daily developer concerns

      Finally, there is the family that too many developers try to ignore: identity, security, and governance. On OCI, that means IAM (users, groups, dynamic groups, policies), Vault and Key Management, Cloud Guard, Security Zones, and tools for audit and configuration management.

      In AuroraRetail’s world, these are not only for the security team. Developers touch them constantly:

      • When a microservice in OKE needs to talk to Autonomous Database, it does so using resource principals and Vault-stored secrets, not hard-coded passwords.
      • When a new tenant is on-boarded, tagging and Compartments determine which resources belong to that tenant for cost and access control.
      • When AuroraRetail rolls out a new environment, security policies and guardrails are baked into the Terraform modules, not bolted on later.

      We will treat these services as first-class development tools, not as compliance checkboxes. The more you understand how IAM policies relate to SDK authentication, or how Vault integrates with Functions, the fewer late-night incidents you’ll have.

      Narrowing the field for AuroraRetail 360

      If you read through Oracle’s marketing site, you will find far more services than we’ve touched on here: blockchain, digital assistant, media processing, specialized AI APIs, and many others. Some of them may be perfect for your own projects.

      For AuroraRetail 360, we deliberately narrow the focus. The core of this book revolves around:

      • core infrastructure (Compute, networking, storage),
      • database and data (Autonomous DB, Exadata options where needed, Object Storage, Streaming, analytics),
      • application runtimes (Compute, OKE, Functions, API Gateway, DevOps, Resource Manager),
      • integration and low-code (Integration Cloud, APEX, occasionally Visual Builder),
      • the observability and security fabric that ties everything together.

      As you follow AuroraRetail from its legacy on-prem stack to a modern, multi-region SaaS platform, you’ll see the same services and patterns show up in different contexts. That repetition is intentional. By the end of the book, you should not just know what these OCI service families are, but how they feel in your hands when you build and run something as demanding as AuroraRetail 360.

      1.3 OCI reference architectures for typical enterprise scenarios

      When you first open Oracle’s Cloud Architecture Center, the experience is a bit like walking into a hardware store with every possible tool on display. There are diagrams for web apps, data lakes, ERP extensions, multicloud analytics, high-performance computing, and more.
      On paper they cover different use cases, but after a while you start to see the same shapes repeating: VCNs with public and private subnets, load balancers, API gateways, Autonomous Databases, Object Storage, Streaming, and a scatter of observability and security services around the edges.

      From a developer’s perspective, the value of these reference architectures is not that they are perfectly tailored to your application. They rarely are. The value is that they capture battle-tested patterns for a handful of recurring problems: serving web traffic, keeping data highly available, integrating with other systems, and surviving failures without spending a fortune. AuroraRetail 360 builds on those patterns rather than inventing its own.

      In this section we will look at three archetypes that appear again and again in OCI guidance and that underpin AuroraRetail’s design: the highly available web application, the data and analytics platform, and the hybrid or multicloud enterprise deployment. You will see their fingerprints throughout the rest of the book.

      Picture 1.3 gives an overview about the three archetypes.Reference Archetypes.


      Picture 1.3: OCI Reference Archetypes

      Highly available web and API applications

      The first archetype is the classic enterprise web application in the cloud: users arrive over the public internet, hit a DNS name protected by WAF, and are routed to some combination of API Gateway, load balancers, and application tiers running on Compute or Kubernetes. The back end is almost always a managed database, often Autonomous Transaction Processing or an Exadata-based service, sometimes with caching or search layers added in.

      Oracle’s reference diagrams for this scenario emphasise two ideas.

      The first is failure domain isolation. Each tier is spread across multiple availability domains or fault domains. Load balancers and gateways sit in front, routing around failed instances. Databases rely on features such as Data Guard and built-in replication rather than home-grown scripts. The resulting picture looks deceptively simple: a pair of load balancers, a farm of app servers, a pair of database instances. Behind that simplicity is careful use of OCI’s regional and domain structure to ensure that a rack failure or even the loss of an entire data centre does not bring the application down.

      The second is network segmentation. Public endpoints live in public subnets with tightly controlled ingress. Application and data tiers sit in private subnets, accessible only through specific paths: bastion hosts, VPNs, or peered VCNs. Security lists and network security groups enforce least privilege. References to this pattern show up in almost every networking best-practice document Oracle publishes, and for good reason: many security incidents trace back to overly flat networks.

      AuroraRetail 360 adopts this archetype almost literally in its early migration phase. The legacy WebLogic monolith is rehosted on OCI Compute in private subnets, fronted by a regional load balancer. Autonomous Transaction Processing replaces the on-premises database cluster, with Data Guard configured for high availability. The public storefront and API surface are exposed through DNS, WAF, and the load balancer. From the outside, the system looks modern enough; internally, many of the old components still run, but they now sit inside a topology that already follows OCI’s reference blueprint.

      This is intentional. AuroraRetail’s architects do not attempt a grand redesign on day one. They first align the existing system with a well-understood OCI pattern for highly available web applications. Only once that foundation is stable do they start to peel off microservices into OKE and to introduce API Gateway and Functions.

      As you read later chapters on networking, compute, and Kubernetes, keep this underlying archetype in mind. Most of what we do there is refinement: switching the application tier from monolith to microservices while preserving the security and availability properties baked into this reference design.

      Data and analytics platforms

      The second archetype you find in the Architecture Center is the data platform. It usually starts with one or more ingestion paths: batch files landing in Object Storage, event streams arriving via Streaming, database replication through GoldenGate, or SaaS data pulled through integration services. From there, data flows into Autonomous Data Warehouse or other analytical stores, with downstream consumers such as Analytics Cloud, data science notebooks, or external BI tools.

      In the diagrams, this tends to look like a conveyor belt: sources on the left, transformations in the middle, warehouses and lakes on the right, dashboards above. The reality in enterprises is messier, but the core pattern holds:

      • keep raw data in a durable, cheap store (Object Storage);
      • process and structure it into query-friendly forms (ADW, curated object buckets);
      • serve it to humans and machines with predictable performance;
      • manage the whole thing with lineage, catalogues, and security controls.

      AuroraRetail’s business model depends heavily on this pattern. Retailers expect detailed reporting and increasingly sophisticated analytics: sales by region and channel, stock-out predictions, campaign attribution, loyalty programme performance. The legacy architecture handled some of this with nightly ETL jobs into a reporting database. On OCI, AuroraRetail wants to move towards near real-time insights.

      The reference architectures give them a starting point. They sketch a path where:

      • operational systems emit events to Streaming and write operational data into ATP;
      • micro-batch or streaming jobs land those events into Object Storage;
      • Data Integration and Data Flow transform them into warehouse tables;
      • Autonomous Data Warehouse acts as the central analytical store;
      • Analytics Cloud and custom dashboards sit on top.

      AuroraRetail adapts this. For some tenants, raw clickstream data is captured and batched; for others, only aggregated metrics are stored to align with contractual constraints. The important part is that the flow of data follows a pattern OCI architects have already stress-tested: Stateless ingestion services push into Object Storage; durable storage feeds managed processing engines and warehouses; everything is guarded by IAM, VCN rules, and sometimes private endpoints.

      This archetype becomes the backbone of the “data and AI” section of the book. When we later introduce demand-forecasting models and recommendation engines, they plug into this same platform rather than inventing a second, parallel stack.

      Hybrid and multicloud enterprise topologies

      The third archetype is less visual but equally pervasive: hybrid and multicloud deployments. Many reference architectures in the OCI library recognise that enterprises will not move everything into a single cloud. Some systems stay on-premises for regulatory or economic reasons. Others live on AWS or Azure because of existing investments. OCI acknowledges this in its architecture guidance and in its well-architected framework, which covers connectivity patterns, identity federation, and governance across environments.

      In diagrams, hybrid often appears as a pair of boxes: an on-prem data centre on one side, an OCI region on the other, connected by VPN or FastConnect. Sometimes a third box represents another cloud provider, linked via interconnect or through the public internet with layered security controls. Databases may sit in OCI while applications remain elsewhere, or the other way round. Exadata-based services and Oracle Database@Azure / @AWS make this pattern more explicit by providing Oracle database capabilities “next to” non-Oracle compute.

      AuroraRetail’s reality fits this hybrid story very well. They cannot switch off their data centres overnight. Large customers may also insist that parts of the solution interact closely with workloads they have running in other clouds. In the early phases of the migration, AuroraRetail runs in what architects sometimes call a two-tier hybrid mode:

      • existing systems in their data centres still host certain back-office jobs, file stores, or integration endpoints;
      • the AuroraRetail 360 core moves to OCI, with secure connectivity back to on-prem;
      • identity is federated so that internal users authenticate once and gain appropriate access rights in both places.

      Later, as OCI’s multicloud database services mature, AuroraRetail keeps open the option to run parts of its data layer inside OCI while placing some application tiers near customers’ preferred clouds. The key is that the topology is deliberate and follows reference guidance: traffic flows over known, managed paths; security policies and monitoring are aligned; data residency and latency requirements are understood up front rather than discovered through painful incidents.

      For the purposes of this book, this archetype explains why so many chapters emphasise connectivity and identity. When we define VCNs and gateways, we already think about VPN and FastConnect. When we discuss IAM, we immediately consider federation with corporate identity providers. These choices are part of making AuroraRetail 360 comfortable in a hybrid world instead of pretending that everything will be “all in OCI” from day one.

      Reference architectures as starting points, not cages

      A common reaction to official reference diagrams is to treat them either as gospel or as irrelevant slideware. Neither attitude is useful. For AuroraRetail 360, the OCI reference architectures are closer to trail markers: they show that other teams have walked these routes before and survived, but they don’t dictate every step.

      In practice that means two things.

      First, the diagrams help frame decisions. When AuroraRetail’s team debates whether to place a service in a public subnet, they check what the high-availability web app blueprint does: public front ends, private internal tiers. When they design their data platform, they look at the analytics reference and confirm that landing raw data in Object Storage and curating it into ADW is not just fashionable but also operationally solid. When they plan DR, they lean on OCI’s high availability papers that describe how to stretch workloads across fault domains and regions while keeping cost in check.

      Second, the architects know when to deviate on purpose. AuroraRetail has multi-tenant requirements that generic diagrams don’t cover, so they introduce an additional layer of tagging and compartment structure. They have data residency constraints that lead them to isolate EU tenant data in specific regions and to treat cross-region replication differently. These adjustments are noted, reviewed, and documented precisely because they depart from the baseline.

      As you read the rest of this book, watch for where AuroraRetail follows Oracle’s reference patterns and where it bends them. The goal is not to produce the prettiest architecture diagram; it is to build a platform that behaves well under real load, integrates cleanly with the rest of the enterprise landscape, and can evolve without constant rewrites. OCI’s reference architectures are one of the few shortcuts we get on that journey, and AuroraRetail 360 takes full advantage of them.

      1.4 How Oracle DB, middleware, and SaaS reshape your OCI designs

      If you’ve spent years on AWS or Azure, it’s tempting to treat OCI as “just another cloud” and to sketch the same generic three-tier diagrams: stateless app tier, generic managed database, some queues, maybe a cache. That picture falls apart as soon as Oracle Database, Oracle middleware, and Oracle SaaS become more than footnotes in your landscape.

      For AuroraRetail 360 they are not just present, they define the shape of the system. The core order management data sits in Oracle Database. Some of the early business logic lives in PL/SQL and in Java EE components that were written for WebLogic. Many customers run Oracle Fusion ERP and expect AuroraRetail to talk to it as a first-class citizen. Those facts change the way the team uses OCI.

      P icture 1.4: How Oracle DB, middleware, and SaaS act as the “anchors” shaping the AuroraRetail 360 design.

      At the centre in Picture 1.4 sits the Oracle Database core with ATP, ADW, Exadata and the PL/SQL logic.
      Around it runs a middle ring that represents AuroraRetail’s middleware, the OKE-based microservices, serverless Functions and the ORDS/REST layer that exposes the database.
      The outer ring shows the wider ecosystem of Oracle SaaS, other clouds, on-prem systems and the various retail channels that interact with the platform.
      Next to the rings, the side panel highlights the main design consequences: how migration is approached, how the strangler pattern is used for the monolith, and how HA/DR, observability and IAM are planned across all of these pieces.

      The first shift is that the database stops being an interchangeable box. On a neutral cloud, you might size a generic VM or pick a platform service that “speaks SQL” and call it a day. On OCI, AuroraRetail leans into the full Oracle stack. Autonomous Transaction Processing becomes the heart of the transactional system; Autonomous Data Warehouse takes over analytics; Exadata-based services become an option when particularly demanding tenants appear. That choice brings along very specific capabilities, PL/SQL packages, partitioning, advanced security features, that are hard to replicate elsewhere. It also changes the migration story: instead of extracting logic out of the database as quickly as possible, the architects design around the assumption that some of that logic will stay in PL/SQL for quite a while. Later, when you see microservices calling into the database through ORDS or using REST-enabled schemas, you’re seeing this compromise in action: a modern API surface wrapped around a very traditional, very powerful core.

      Middleware history pulls in a similar direction. AuroraRetail’s monolith is not a random Java app; it is a WebLogic deployment with JMS, JTA, and a stack of libraries that assume an application server. When the platform moves to OCI, the team has options: they can lift WebLogic into Compute or into WebLogic Server on OCI Marketplace to minimise change, or they can begin carving out services straight into Kubernetes and Functions. In practice they do both. Early on, WebLogic runs almost unchanged on Compute instances in a private subnet, fronted by a load balancer. That keeps the lights on while they design the future. Over time, they replace chunks of that middleware with OKE-based services, but they do so in a way that respects existing contracts, HTTP APIs, message formats, transactional boundaries. You will see this particularly clearly in the “strangler” patterns we use later in the book: WebLogic continues to handle some flows, but new ones are routed to OKE and Functions via API Gateway, all within a coherent network and security model.

      Oracle SaaS exerts a different kind of force. For a retailer adopting AuroraRetail 360, the platform is only part of the picture. Orders, invoices, product and price lists, loyalty transactions, all of these ultimately flow into systems like Oracle Fusion ERP, CX, or SCM. AuroraRetail’s architecture cannot treat those as opaque external URLs; they are deeply integrated neighbours. That’s why OCI designs which look neat in isolation often grow extra limbs in the presence of SaaS: Integration Cloud instances in shared compartments, dedicated connectivity to Oracle SaaS endpoints, and a deliberate separation between “tenant-facing APIs” and “back-office integration flows”.

      For AuroraRetail this means that many “internal” design decisions are driven from the outside in. Data models and event schemas are chosen to map cleanly to Fusion objects. Identity flows follow what SaaS can support, OAuth2, SAML, delegated scopes, so that the same corporate users can move between AuroraRetail, ERP, and analytics tools without a mess of credentials. Even region choices are influenced by SaaS: if a key customer uses Fusion in a specific region, AuroraRetail wants its tenancy close enough to keep latency and data residency acceptable.

      All of this reshapes the non-functional side of the design as well. High availability and disaster recovery plans must consider not only OCI regions and Autonomous replicas, but also the behaviour of Fusion services and on-premises dependencies. Observability is built with an eye on cross-system traces: when a checkout fails, AuroraRetail’s logs and metrics are only half the story; the team also needs correlation with ERP calls and database operations. Security policies and IAM structures are written with database, middleware, and SaaS roles in mind, not as a generic “app/frontend/backend” split.

      The net result is that AuroraRetail 360 on OCI doesn’t resemble a generic microservice demo with a relational database bolted on. It looks more like an ecosystem: a modern application platform wrapped around a core of Oracle Database and selective legacy middleware, tied closely into Oracle SaaS. The reference architectures from the previous section still apply, but they bend around these anchors. As we move through the rest of the book, you’ll see that almost every design choice, how we cut services, how we shape VCNs, how we build pipelines and dashboards, starts with a simple question: what does this mean for the Oracle pieces in the middle?

      Want to read more, then buy the book.