Skip to content

Solutions

Start with the workload.
Design the connections.

Practical configurations for web applications, test environments and self-managed databases. Choose the runtime, map the connections and define ownership.

Discuss your requirements Explore products

01 / Web applications

Give each service a clear role.

Use a VM for a custom Linux stack or a container for an OCI image. Configure the application endpoint, dependency connections and persistent storage separately.

Plan application networking ↗
Read the setup guide ↗Discuss this architecture ↗
Before launch

Test a complete user journey, from name resolution to a database read and write. Include an unavailable dependency in the test.

Web applications
  1. 01
    Application domain

    A DNS record directs clients to your public endpoint.

  2. 02
    Web service & API

    A VM or container serves requests and calls its dependencies.

  3. 03
    Application data

    Restrict database access and test your backup and recovery process.

Application pattern — configure and validate each connection for your selected environment.

01VMs or OCI workloads for the application

02Networks and firewall rules for service connections

03DNS records and supported certificate workflows

Validate traffic behavior and failure handling for the chosen configuration. Multiple services alone do not provide high availability.

02 / Development environments

Build around your team's actual stack.

Give the release candidate its own configuration and sample data. Use a Linux guest or versioned OCI image, with reproducible setup instructions in the project.

Explore container deployments ↗
Read the setup guide ↗Discuss this architecture ↗
Before launch

Start from a clean environment and follow your setup instructions. Another team member should be able to reproduce the same result.

Development environments
  1. 01
    Project configuration

    Keep setup instructions and image versions with your code.

  2. 02
    Separate test runtime

    Use dedicated configuration and authorized sample data.

  3. 03
    Release evaluation

    Check the change, record the result and retire resources you no longer need.

Application pattern — configure and validate each connection for your selected environment.

01Cloud-init for supported VM configuration

02OCI images for packaged dependencies

03Console and Cloud Shell for operational access

Separate test data and credentials from production. Review resource lifetime and costs when creating temporary environments.

03 / Self-managed databases

Keep database ownership explicit.

Install your database engine on a VM. Size resources around the working set, restrict network access and assign ownership of updates, backups and restore testing.

Explore virtual machines ↗
Read the setup guide ↗Discuss this architecture ↗
Before launch

Validate the working set and representative queries. Restore a backup into a separate environment before relying on the recovery procedure.

Self-managed databases
  1. 01
    Application service

    Connect with a dedicated database credential.

  2. 02
    Restricted network path

    Allow the intended application and administration connections.

  3. 03
    Database VM

    Your team manages the database engine, data, updates and recovery.

Application pattern — configure and validate each connection for your selected environment.

01A VM for your selected database software

02Restricted network access to the database

03A backup and restore process owned by your team

This is a self-managed deployment pattern, not a managed database product. Replication, upgrades, failover and recovery remain your responsibility.

Include the whole data path.

  • Application and backup storage locations
  • Administrator access and service credentials
  • External dependencies and contractual requirements

Deployment requirements

Plan where data and access belong.

Record where data may be stored, who may access it and which service commitments your application needs.

Confirm the selected offer and include backup destinations and external dependencies in your review before moving data.

Discuss deployment requirements ↗

Migration assessment

Make the first move a measured one.

Evaluate a bounded workload before deciding how much of your environment to move. Provider-specific APIs and managed services may require application changes.

  1. 01

    Discover and compare

    Map runtime dependencies, data volumes, traffic paths and the complete bill. Compare equivalent configurations rather than headline prices.

  2. 02

    Prove the workload

    Test deployment, access, connectivity and recovery with representative data. Establish acceptance criteria and a rollback procedure.

  3. 03

    Plan the cutover

    Rehearse data synchronization and routing changes. Assign owners, observe the result and retain the previous environment until validation is complete.

Compare total operating cost.

Include compute, storage, network traffic, licensed software, backups and your team’s operating time. Savings and migration effort depend on the actual workload; no fixed percentage is assumed.

Your next step

Start with the workload. Build a clear plan.

Tell us what you run, how it connects and what your team needs to operate it.

Discuss your requirements