In 2024, I wrote an article about cloud repatriation (aka reverse cloud migrations) and the fact that businesses are adopting a more nuanced workload-centric strategy, instead of just bringing some of the workloads back to on-premises data centers. The article did not focus (primarily) on costs, but now it seems to be the right time to take a closer look at cloud economics and why Oracle Cloud Infrastructure (OCI) is a path worth investigating.

Disclaimer: The views and opinions are my own, not my employer’s.

Why Enterprises Are Bringing Workloads Back and Why They Are Still Missing the Obvious Answer

Let us be honest, cloud repatriation is happening because customers feel let down. The promised land of cloud economics has not delivered. CFOs and CIOs are looking at their monthly cloud bills and asking the same question: “Where are the savings we were promised?”

Many jumped in expecting linear cost efficiency, which means that you pay for what you use, scale when you need, and save when you do not. But instead, they found themselves locked into complex pricing models, surprise data egress charges, and massive bills that just do not line up with actual value. It is no wonder so many companies are taking a second look at their on-prem strategies.

While the cloud offers a ton of advantages, not all clouds are created equal. Most enterprises default to the big two or three providers, thinking that is the safest, smartest choice. But over time, they realize their workloads – especially those that are I/O-heavy, latency-sensitive, or simply require consistent performance – are not running efficiently, and they are costing a fortune.

Is cloud economics more myth than math? The bigger question we should all be asking is: why are we ignoring better options, especially when they are cheaper and more performant?

Geopolitics – The New Cloud Strategy Trigger

Beyond cost and performance, geopolitical uncertainty is now a major factor as well shaping cloud decisions. From shifting data sovereignty laws to rising tensions between global superpowers, enterprises are realizing that overreliance on a single hyperscaler can expose them to regulatory, compliance, and supply chain risks.

Guess what…The problem was always there. It is nothing new. And “the problem” is much bigger than just public clouds. But let us park this topic for a while.

So, why are we ignoring better options?

OCI was architected from the ground up with a modern, high-performance, cost-predictable mindset. And yet, for reasons that still are not 100% clear to me, it gets overlooked/ignored far too often.

Let us talk numbers and say that OCI delivers a 30–50% lower TCO compared to other hyperscalers. Let us assume that this is not fluff but the reality: Compute, storage, and networking are simply cheaper on OCI, and they come with better performance.

What is the Problem?

Here is what I do not get: if cost and performance are the two biggest drivers of cloud repatriation, and OCI excels at both, why are not more customers seriously considering Oracle Cloud? Does it have something to do with the KPIs decision-makers are measured on? Is it about not losing face? Is it about sunk cost fallacy? All the above? Is it because Oracle is not screaming as loudly as the others? Or is it just inertia and sticking with what is familiar, even if it is not working? Or is it about doing the same (mistake) others are making?

Whatever the reason, it is time for a reset. Enterprises need to look beyond the usual suspects and start asking themselves some hard questions:

• Are we really getting value from our cloud provider?
• Are we paying a premium for subpar performance?
• Are we repatriating workloads simply because we chose the wrong cloud in the first place?

The Real Value of OCI – Look Beyond Price

Everyone loves talking about cloud cost savings, and yes, OCI delivers big on that front. But the conversation should not stop there. In fact, some of the biggest reasons customers stay with OCI long term have nothing to do with price tags and everything to do with how it actually feels to run real workloads on a platform built the right way.

Let us talk about security. With OCI, it is not something you bolt on after the fact or pay extra for, it is built in from the ground up. Encryption is always on. Patching is automated and proactive. The way tenancy and network isolation work in OCI gives you far less surface area to worry about.

Again, performance is another big one. It is not just fast, it is predictably fast. You do not have to overprovision or tweak the system to get the speed you need. The network is high-bandwidth and low-latency by default. Compute and storage are designed to handle enterprise-grade workloads without the tuning. It just works, out of the box.

But here is the part that is harder to quantify and just as important: operational peace of mind. With OCI, teams spend less time firefighting and more time building. You are not constantly chasing down unpredictable behaviour or buried in billing surprises (SLAs and prices are the same for ALL regions!).

And if control and flexibility are part of your strategy, then OCI goes even further. With OCI Dedicated Region, you can bring the full power of public cloud into your own data center, fully managed by Oracle, with no compromises. For partners and service providers, Oracle Alloy offers the ability to build and brand your own cloud, running on OCI’s infrastructure, while retaining control over operations and customer relationships. And when data residency, air-gapping, or national security are non-negotiable, Oracle Cloud Isolated Region delivers a physically and logically isolated cloud, fully disconnected from the public internet. No other cloud provider comes close to offering this kind of architectural flexibility at this level of maturity.

Final Thoughts

But now back to topic. 🙂 Cloud repatriation is much more complex and bigger than most of us think. Cloud repatriation should not just be a retreat, it should be a recalibration. And that recalibration should include a serious look at OCI. If you want predictable costs, industry-leading performance, flexibility, real cloud economics, and not just marketing slides, then it is time to rethink what cloud success really looks like.

Because at the end of the day, the cloud should not be about what is trendy. It should be about what works and what pays off. And about who can execute your strategy.

DevSecOps is the backbone of modern software delivery. Whether you are a fast-moving digital startup or a large enterprise modernizing legacy systems, having an automated, secure CI/CD pipeline is what separates high-performing teams from those always stuck firefighting. Most teams stitch together DevSecOps pipelines using a mix of open-source tools, third-party platforms, and scripts.

OCI gives you a clean, enterprise-grade stack for DevSecOps that is ready out of the box. We are talking source control, automated builds and deployments, secret management, container orchestration, real-time monitoring, and everything is tightly integrated, deeply secure, and easy to use.

So, the second part of this blog series is about OCI’s developer services. If you missed the first part about Oracle Kubernetes Engine (OKE), click here.

Why Enterprises and Digital Natives Should Look at OCI

Let’s break it down:

• Enterprises get the compliance, SLAs, and governance they need with a cloud-native platform that integrates with existing Oracle workloads and mission-critical systems.

• Digital natives and startups get a modern, developer-first experience without juggling 15 different tools. OCI’s pay-as-you-go model and generous free tier also help teams stay lean while scaling.

And it is built for hybrid and multicloud from the start. OCI works whether you are running greenfield Kubernetes apps or still managing monoliths.

How to Build a Complete DevSecOps Pipeline on OCI

As part of the journey of becoming a certified OCI DevOps Professional, you need to understand how you can build a complete and secure pipeline using Oracle Cloud Infrastructure’s native services. Think of this as your blueprint for DevSecOps: secure, scalable and automated from code to production. The following diagram illustrates this reference architecture:

Plan, Collaborate & Set Up Infrastructure

OCI DevOps Code Repositories

Private Git repositories hosted by the DevOps service. You can store, manage, develop source code with OCI DevOps Code Repositories and create your own private code repositories or connect to external code repositories such as GitHub, GitLab, Bitbucket Cloud, Visual Builder Studio, Bitbucket Server, and GitLab Server. It is perfect for managing application code, Terraform configurations, and CI/CD definitions all in one place.

OCI Resource Manager (Terraform as a Service)

Automate infrastructure provisioning and lifecycle using Oracle’s managed Terraform service:

• Write declarative infra-as-code
• Apply it across multiple compartments with consistent governance
• Integrates with Vault, IAM, and tagging for full automation
• This lets you define environments (dev/stage/prod) as code, and roll them out safely and repeatably.

The following image represents a generalized view of the Resource Manager workflow:

OCI Vault

Every DevSecOps pipeline needs a central place for secrets and encryption keys. Vaults are logical entities where the Key Management Service creates and durably stores vault keys and secrets.

• Store passwords, API tokens, certs, and encryption keys securely
• Integrated with KMS (Key Management Service) for encryption at rest and in transit
  • Integrates encryption with other OCI services such as storage, database, and Fusion Applications for protecting data stored in these services
• Automate access via IAM policies and code

Develop, Build, and Test Code

OCI DevOps Build Pipelines

A build pipeline takes a commit ID from your source code repositories and uses that source code to run your build instructions. Build pipelines define a set of stages for the build process – building, testing and compiling software artifacts, delivering artifacts to OCI repositories, and optionally triggering a deployment.. You define the flow and instructions of your build run in the build spec file. Define build pipelines using YAML or the console:

• Automate Java, Python, Node.js, Docker, and Go builds
• Customize steps for unit tests, code quality scans (e.g., SonarQube)
• Connect directly to OCI repos or GitHub

The Application Dependency Management (ADM) service provides you with an integrated vulnerability knowledge base that you can use from the Oracle Cloud Infrastructure (OCI) DevOps build pipelines to detect vulnerabilities in the packages used for the build.

OCI Cloud Shell

A browser-based Linux shell.

OCI CLI

Git, Docker, Terraform, kubectl, Helm, and more

Ideal for quick testing, debugging, or managing your pipeline without installing tools locally.

OCI Application Performance Monitoring (APM)

Do not wait until production to spot performance issues:

• Distributed tracing across microservices
• Real User Monitoring (RUM)
• Availability Monitoring
• Server Monitoring

Shift-Left Security from the Start

OCI Vault (again, because security is never just one step)

Use Vault throughout your pipeline to securely inject secrets into build/deploy steps.

OCI Cloud Guard

Cloud Guard examines your Oracle Cloud Infrastructure resources for security weaknesses related to configuration, and your operators and users for risky activities. Upon detection, Cloud Guard can suggest, assist, or take corrective actions, based on your configuration.

• Monitors for risky configurations (open ports, unused keys, misconfigured buckets)
• Uses rules and detectors to flag and respond to threats
• Integrates with other OCI services for automated remediation

Perfect for enforcing security baselines as part of your CI/CD process.

OCI Security Zones

Apply guardrails with security policies baked into the compartments:

• Blocks risky actions (e.g., public DBs)
• Ensures workloads meet compliance and governance standards automatically

Security Zones let you be confident that your resources in Oracle Cloud Infrastructure, including Compute, Networking, Object Storage, Block Volume and Database resources, comply with your security policies.

Deploy Automatically (and Confidently)

OCI DevOps Deployment Pipelines

A sequence of steps for delivering and deploying a set of artifacts to a target environment. The flow and logic of your software release can be controlled by defining stages that can run in serial or parallel. The delivery side of CI/CD:

• Create multi-stage pipelines with approval gates, rollbacks, and parallel deployments
• Deploy to OKE, Functions, Compute, or custom targets
• Track deployment history and success/failure per environment

Works seamlessly with build pipelines for full Git-to-production automation.

OCI Functions

Event-driven, serverless compute built on Fn Project:

• Write functions in Java, Python, Node.js, Go
• Scale automatically based on events or triggers
• Deploy from build artifacts or container images

Great for microservices, APIs, scheduled jobs, or glue logic in your pipeline.

Oracle Kubernetes Engine (OKE)

The reference architecture deploys the OKE cluster as one of the target environments. The worker nodes are deployed on Oracle Linux OS. This architecture uses three worker nodes in the cluster, but you can create up to 5’000 nodes on each cluster. Managed Kubernetes, Oracle-style:

• CNCF-compliant, fully managed clusters
• Integrated with IAM, Container Registry, Load Balancers, and Logging
• Auto-scaling, node pools, and lifecycle management

Perfect for teams building containerized applications or adopting GitOps practices.

OCI Container Registry

This architecture deploys registry as a private Docker registry for internal use. Docker images are pushed to and pulled from the registry. You can also use registry as a public Docker registry, enabling any user with internet access and knowledge of the appropriate URL to pull images from public repositories in OCI.

• Push/pull images securely
• Scan images with third-party security tools
• Deploy directly into OKE or Functions

Acts as the bridge between build and deploy stages in your pipeline.

Observability – Monitor, Operate, and Optimize

OCI Logging

OCI Logging service stores logs related to the deployment. The deployment runtime output and the final results of the deployment are shown as log entries. OCI Notifications service provides visibility into the latest state of the deployment project and its resources and takes any necessary action. For example, you’re notified when an important event, such as a stage in a deploy pipeline waiting for approval. When you receive the notification message, you can go to DevOps deployment pipelines and approve the stage. Centralized logging across all OCI services and custom apps:

• Collect, search, and filter logs in real time
• Create custom queries and alerts
• Export logs to Object Storage or third-party SIEMs

Feeds directly into security tools and helps debug issues post-deployment.

OCI Monitoring

Metric collection and alerting at every level:

• Out-of-the-box metrics for compute, load balancers, databases, Kubernetes, and more
• Custom metrics via SDKs
• Alarms with notifications (e-mail, Slack, etc.)

Events

Oracle Cloud Infrastructure Events enables you to create automation based on the state changes of resources throughout your tenancy. Use Events to allow your development teams to automatically respond when a resource changes its state.

Here are some examples of how you might use Events:

• Send a notification to a DevOps team when a database backup completes.
• Convert files of one format to another when files are uploaded to an Object Storage bucket.

Final Thoughts

Oracle Cloud Infrastructure might not always be the flashiest name in DevOps circles, but when it comes to building a secure, scalable, all-in-one DevSecOps pipeline, it delivers.

Whether you are modernizing a legacy stack or building cloud-native microservices, OCI gives you the tools to:

• Automate everything

• Bake in security and governance

• Monitor, understand, and optimize

You just need the right foundation, and OCI makes it possible.

I have just started diving into the OCI DevOps Professional certification course, so why not share some lessons and important information I gathered from the official Oracle course as part of my preparation? My goal? To pass the exam in the next few weeks. In this first part, I’m covering the core concept of Oracle Kubernetes Engine (OKE). Please note that I am also copy-pasting parts of the official documentation.

What is Oracle Kubernetes Engine?

Oracle Kubernetes Engine (OKE) is Oracle Cloud Infrastructure’s managed Kubernetes service. It is designed to let you deploy, manage, and scale containerized applications using Kubernetes, but without the heavy lifting of setting up and maintaining the control plane yourself.

OKE is:

• Certified by the CNCF (Cloud Native Computing Foundation)

• Fully integrated with OCI services like networking, load balancing, and IAM

• Designed for production workloads, with a choice between traditional VM-based clusters or serverless options.

You get the flexibility and power of Kubernetes, but Oracle handles the control plane: updates, availability, and scaling

Kubernetes Clusters

OKE supports two types of Kubernetes cluster options: Basic and Enhanced

• Enhanced cluster: Enhanced clusters support all available features, including features not supported by basic clusters (such as virtual nodes, cluster add-on management, workload identity, and additional worker nodes per cluster). Enhanced clusters come with a financially-backed service level agreement (SLA).
  • Cluster add-ons: In an enhanced cluster, you can use Kubernetes Engine to manage both essential add-ons and a growing portfolio of optional add-ons. You can enable or disable specific add-ons, select add-on versions, opt into and out of automatic updates by Oracle, and manage add-on specific customizations.
• Basic cluster: Basic clusters support all the core functionality provided by Kubernetes and Kubernetes Engine, but none of the enhanced features that Kubernetes Engine provides. Basic clusters come with a service level objective (SLO), but not a financially-backed service level agreement (SLA).
  • Cluster add-ons: In a basic cluster, you have more responsibility and less flexibility when managing cluster add-ons. You are responsible for upgrading essential add-ons, but you cannot install or disable specific add-ons, select add-on versions, opt into and out of automatic updates by Oracle, or manage add-on specific customizations. In addition, you are responsible for installing, managing, and maintaining any optional add-ons you want in the cluster

If you are aiming to build scalable, secure, and production-ready apps, enhanced clusters are the way to go.

Note: A new cluster using the console is created as an enhanced cluster by default. If you are using the CLI or API to create a cluster, a new cluster is created as a basic cluster by default.

Kubernetes Cluster Controle Plane

The Kubernetes cluster control plane implements core Kubernetes functionality. It runs on compute instances (known as ‘control plane nodes’) in the Kubernetes Engine service tenancy. The cluster control plane is fully managed by Oracle.

The cluster control plane runs a number of processes, including:

• kube-apiserver to support Kubernetes API operations requested from the Kubernetes command line tool (kubectl) and other command line tools, as well as from direct REST calls. The kube-apiserver includes admissions controllers required for advanced Kubernetes operations.
• kube-controller-manager to manage different Kubernetes components (for example, replication controller, endpoints controller, namespace controller, and serviceaccounts controller)
• kube-scheduler to control where in the cluster to run jobs
• etcd to store the cluster’s configuration data
• cloud-controller-manager to update and delete worker nodes (using the node controller), to create load balancers when Kubernetes services of type: LoadBalancer are created (using the service controller), and to set up network routes (using the route controller). The oci-cloud-controller-manager also implements a container-storage-interface, a flexvolume driver, and a flexvolume provisioner (for more information, see the OCI Cloud Controller Manager (CCM) documentation on GitHub).

Kubernetes Data Plane and Worker Nodes

Worker nodes are where you run the applications that you deploy in a cluster.

Each worker node runs a number of processes, including:

• kubelet to communicate with the cluster control plane
• kube-proxy to maintain networking rules

The cluster control plane processes monitor and record the state of the worker nodes and distribute requested operations between them.

A node pool is a subset of worker nodes within a cluster that all have the same configuration. Node pools enable you to create pools of machines within a cluster that have different configurations. For example, you might create one pool of nodes in a cluster as virtual machines, and another pool of nodes as bare metal machines. A cluster must have a minimum of one node pool, but a node pool need not contain any worker nodes.

Worker nodes in a node pool are connected to a worker node subnet in your VCN.

Supported Images and Shapes for Worker Nodes

When creating a node pool with Kubernetes Engine, you specify that the worker nodes in the node pool are to be created as one or other of the following:

• Virtual nodes, fully managed by Oracle. Virtual nodes provide a ‘serverless’ Kubernetes experience, enabling you to run containerized applications at scale without the operational overhead of upgrading the data plane infrastructure and managing the capacity of clusters. You can only create virtual nodes in enhanced clusters.
• Managed nodes, running on compute instances (either bare metal or virtual machine) in your tenancy, and at least partly managed by you. You are responsible for upgrading Kubernetes on managed nodes, and for managing cluster capacity. You can create managed nodes in both basic clusters and enhanced clusters.

Note: You can choose to upgrade the basic cluster to an enhanced cluster later, but you cannot downgrade an enhanced cluster to a basic cluster.

Supported Images for Managed Nodes

OKE supports the provisioning of worker nodes (managed nodes only) using some, but not all, of the latest Oracle Linux images provided by Oracle Cloud Infrastructure.

Platform Images:

• Provided by Oracle and only contain an Oracle Linux operating system
• The managed nodes’ initial boot triggers a software download and setup by OKE

OKE Images:

• Built on platform images
• OKE images are optimized for use as managed node base images, with all the necessary configurations and required software
• For faster managed node provisioning during cluster creation and updates

Custom images:

• Can be built on supported platform images and OKE images
• Custom images contain Oracle Linux OSes with customizations, configurations and software that were present when you created the image.

Shapes for Managed Nodes and Virtual Nodes

OKE supports the provisioning of worker nodes (both managed nodes and virtual nodes) using many, but not all, of the shapes provided by Oracle Cloud Infrastructure. More specifically:

• Managed Nodes
  • Supported for managed nodes:
    • Flexible shapes, except flexible shapes to create burstable instances (for example, VM.Standard.E3.Flex)
    • Bare Metal shapes, including standard shapes and GPU shapes;
    • HPC shapes, except in RDMA networks;
    • VM shapes, including standard shapes and GPU shapes;
    • Dense I/O shapes
    • For the list of supported GPU shapes, see GPU shapes supported by Kubernetes Engine (OKE).
  • Not Supported:
    • Dedicated VM host shapes
    • Micro VM shapes
    • HPC shapes on Bare Metal instances in RDMA networks
    • flexible shapes to create burstable instances (for example, VM.Standard.E3.Flex).
• Virtual Nodes
  • Supported for virtual nodes:
    • Pod.Standard.A1.Flex, Pod.Standard.E3.Flex, Pod.Standard.E4.Flex.
  • Not Supported: All other shapes.

Self-Managed Nodes

A self-managed node is a worker node hosted on a compute instance (or instance pool) that you have created yourself in Compute service, rather than on a compute instance that Kubernetes Engine has created for you. Self-managed nodes are often referred to as Bring Your Own Nodes (BYON). Unlike managed nodes and virtual nodes (which are grouped into managed node pools and virtual node pools respectively), self-managed nodes are not grouped into node pools.

Using the Compute service enables you to configure compute instances for specialized workloads, including compute shape and image combinations that are not available for managed nodes and virtual nodes.

Note: You can only add self-managed nodes to enhanced clusters.

Supported Images and Shapes for Self-Managed Nodes

Kubernetes Engine supports the provisioning of self-managed nodes using some, but not all, of the Oracle Linux images and shapes provided by Oracle Cloud Infrastructure. More specifically:

Prerequisites to create an OKE Cluster

Before you can use Kubernetes Engine to create a Kubernetes cluster, you have to meet prerequisites before you can use OKE. The list can be found here: https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengprerequisites.htm

Part 2: https://www.cloud13.ch/2025/04/29/becoming-an-oracle-cloud-infrastructure-certified-devops-professional-part-2-devsecops-with-oci/