Considerations for Moving to the Cloud

Areas you should consider when moving to the cloud include networking and connectivity, high availability and disaster recovery, security, identity and access management, cost management and governance, monitoring, and the migration process.

Elements of the Validated Architectures

In customer deployments, there are many variations of architecture that will work. In some cases, these variations are designed to achieve a particular outcome, and in other cases they are to support a particular hardware capability (or limitation). And in still others, they reflect preferences of the architect. In every case, designing a new architecture can be time-consuming and comes with the risk that some important consideration has been overlooked. Oracle provides baseline architectures that take best advantage of Oracle Cloud Infrastructure capabilities, and also address most of the important technical and business requirements. This allows you to be confident that you will be successful in achieving your deployment objectives without investing in a long analysis project.

To meet any special requirements not covered by this reference architecture, other design choices are possible. Oracle expects that the design process for those changes becomes much easier when starting from a reference architecture.

Networking and Connectivity

The primary objectives for the networking and connectivity architecture is to provide secure, high-speed connectivity between your cloud resources, and the users and systems that need to access those resources. Additionally, it illustrates mechanisms by which you can design a network topology that best meets your needs, with the ability to isolate resources between bastion host, application tiers, database tiers, and load balancing for security and management purposes.

Outcomes this architecture can provide include:

  • Ability to design for availability, redundancy, and scalability
  • Load-balancing across multiple application nodes for performance and availability
  • Isolation from unauthorized customers and processes
  • Network-level isolation between web/application tiers and database tiers
  • Secure access to general cloud services such as Object Storage
  • Access to your Cloud Infrastructure and Applications
  • Dedicated access from corporate campuses to the application by using private network links
  • Secure network access to the application using encrypted links over the public internet
  • Private network connectivity to other systems or services hosted on Oracle Cloud Infrastructure
  • Monitoring and management access to all application and database tiers

Virtual Cloud Network (VCN) and Subnets

VCNs provide isolation for your application workload from any other workload on Oracle Cloud Infrastructure, including your other workloads in a different VCN. A VCN is basically your own private network. You can subdivide your VCN using subnets to ensure resource isolation and apply security rules to enforce secure access. You can also add route tables and rules to send traffic out of your VCN, similar to traditional network route rules.

You can create instances in a private or a public subnet based on whether you want to permit access to the instances from the internet. Instances that you create in a public subnet are assigned a public IP address and you can access these instances from the public internet. Conversely, as you cannot assign a public IP address to instances created in a private subnet, you can’t access these instances over the internet. You can, however, add a NAT gateway to your VCN to give instances in a private subnet the ability to initiate connections to the internet and receive responses for the purposes of applying OS and application updates. NAT gateways won’t receive inbound connections initiated by the internet.

Oracle recommends creating separate subnets for each tier, such as bastion host, database, application, and load balancing, to ensure that appropriate security requirements can be implemented across the different tiers.

Security Lists

A security list provides a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out.

Bastion host

The bastion host is an optional component that can be used as a jump server to access and manage Oracle Cloud Infrastructure instances in the private subnet. You can also access instances in a private subnet by using dynamic SSH tunneling.

Internet Gateway (IGW)

You can connect to instances that are placed in public subnets using the IGW. To access your private instances from the internet, you need to create your bastion host in a public subnet and access the bastion host from the IGW.

Service Gateway

Your virtual cloud network (VCN) can privately access specific Oracle services without exposing the data to the public internet. No internet gateway or NAT is required to reach those specific services. The resources in the VCN can be in a private subnet and use only private IP addresses. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet. The Oracle services that can be accessed this way include Object Storage, File Storage, Key Management, Streaming, and more.

FastConnect

If you require private connectivity that does not traverse the internet, as well as faster data transfer speeds, Oracle also offers FastConnect, which guarantees a certain level of accessible bandwidth. Multiple partners in regions across the world offer dedicated network connections between customer premises and Oracle data centers. This allows customers to access their application as if it was running in their own datacenter.

IPSec VPN

Connect from your HQ or on-premises data center to your application resources in Oracle Cloud Infrastructure via a private VPN connection using an IPSec VPN tunnel. From your on-premises environment, you can access your cloud instances in a private subnet by connecting through a Dynamic Routing Gateway (DRG). The DRG is the gateway that connects your on-premises network to your cloud network.

Load Balancing

Pre-configured, redundant load-balancers are available on private and public subnets to balance traffic within the implementation and from external connections, respectively. For accessing both internal endpoints and internet-facing endpoints, set up private load balancers and public load balancers. Set up private load balancers to serve internal traffic and set up public load balancers to serve the traffic from the internet. Register the public or private IP address of Oracle Cloud Infrastructure Load Balancing instances in your on-premises or public domain name server (DNS) for domain resolution of your application endpoint.

High Availability and Disaster Recovery

The primary objectives for these architectures are to ensure you can design high availability (HA) into your application environment and build disaster recovery (DR) in case of unforeseen events which would require you to failover and still keep your application up and running.

Outcomes this architecture can provide include:

  • Ensure no single point of failure across the board
  • Ensure anti-affinity, meaning that your application is available even if an instance goes down
  • Ensure your application is available even if one availability domain goes down
  • Have a DR site for your application in a different region
  • Have a backup and recovery strategy for the application and database
  • Ensure recovery point objective (RPO) in less than 1 hour and recovery time objective (RTO) in less than 4 hours

Reference Architecture for a Single Availability Domain

At a basic level, you can achieve HA for your application deployment even within a single availability domain:



The numbered components shown in the diagram are:

  • Availability Domain (AD) Number 1:

    In Oracle terminology, an AD is a collection of one or more data centers in a given region. In this architecture, redundant instances are deployed in the application tier and database tier to ensure HA within a single AD. This ensures that your application is available even when an application instance goes down. The other available application instances in the AD continue to process the requests. All application instances in the AD are active. The load balancer instances receive requests and sends it to the application servers. This high availability of an application within an availability domain can be achieved by placing application instances in separate fault domains.

  • Fault Domain (FD) Number 2:

    A grouping of hardware and infrastructure within an AD. Each AD contains three fault domains. Fault domains let you distribute your application instances so that they are not on the same physical hardware within a single availability domain. As a result, a hardware failure or hardware maintenance event that affects one fault domain does not affect instances in other fault domains. By using fault domains, you can protect your instances against unexpected hardware failures and planned outages.

  • Bastion Host Number 3:

    The bastion host is an optional component that can be used as a jump server to access and manage Oracle Cloud Infrastructure instances in the private subnet.

  • Load Balancer Tier Number 4:

    This tier contains the Oracle Cloud Infrastructure Load Balancing instances that load balances the traffic to application servers. The load balancer receives requests from users, and then routes these requests to the application tier.

  • Application Tier Number 5:

    This tier contains redundant instances of the application servers, and web servers to provide high availability. Set up redundant instances of all servers in the application tier to ensure that you can continue accessing the application even if an instance goes down.

  • Database Tier Number 6:

    This tier contains database system instances. For HA of databases, you can create two-node Real Application Clusters (RAC) database systems. The two nodes of RAC are always created in separate fault domains by default. So, the database nodes are neither on the same physical host nor on the same physical rack. This protects the database instances against the underlying physical host and top of the rack switch failures.

  • Backup and Recovery Number 7:

    Oracle recommends that the database and the applications deployed on Oracle Cloud Infrastructure have a robust backup of recovery strategy. It is recommended to store backup of databases and application instances in Oracle Cloud Infrastructure Object Storage. The databases and application instances in private subnets can be backed up to Oracle Cloud Infrastructure Object Storage by using a service gateway, which provides access to Object Storage without traversing the internet.

    The backup of applications can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Block Volumes provide you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy. This allows you to adhere to your data compliance and regulatory requirements. There are three predefined backup policies: Bronze, Silver, and Gold. Each backup policy has a predefined backup frequency and retention period.

    The automatic and on-demand database backups to Object Storage can be configured using the Oracle Cloud Infrastructure console. All database backups on Object Storage are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption. The automatic database backup service uses weekly incremental backup strategy to backup databases with a 30-day retention policy. It is also possible to perform an on-demand full backup of databases for ad-hoc requirements.

Reference Architecture with Multiple Availability Domains

To ensure that your application survives if a whole AD goes down, we recommend that you deploy across multiple ADs. This way you can still access the application instances in another AD if the first one goes down:



In this architecture, the VCN with the bastion, load balancer, application, and database hosts are placed in subnets across two ADs. All instances are active in the two ADs. The only passive components in the architecture are the database hosts in the second Availability Domain.

Your external DNS or Oracle Cloud Infrastructure DNS service receives requests for your application and round-robin load-balances them to one of the load balancers in the two Availability Domains. Oracle Active Data Guard in synchronous mode replicates the database across ADs.

Reference Architecture for Disaster Recovery to Another Region

In addition to ensuring HA for an application by distributing instances across ADs, we recommend also setting up a DR site for your application in a different geographical region:



This architecture deploys application servers across multiple regions while ensuring both high availability and disaster recovery. It ensures that you can access your application instances in a secondary DR region even in the unlikely event that all ADs in your primary region go down. All instances are active in the ADs in the primary region. The passive components in the architecture are the database hosts in the second Availability Domain of the first Region and all the instances in DR Region. Application and web tiers are replicated using rsync and the database tier is replicated using Oracle Data Guard.

It is also possible to have this architecture deployed in just one AD in the first region and one AD in the second region for disaster recovery. However, if the only AD where your application has been deployed is not available, you will need to invoke DR to failover your application to the second region.

Security

The objective of the security architecture is to enable you to maintain your security posture when running your business-critical applications in Oracle Cloud. Even though you may be reducing the overhead of building and maintaining data center infrastructure, you still need unparalleled control and transparency over what you’re running in the cloud.

Outcomes this architecture can provide include:

  • Ensure your applications and associated data assets are completely isolated from other tenants’ workloads, so as to limit the effect of noisy neighbors and prevent lateral movement of attacks
  • Protect your internet-facing applications from cyberattacks
  • Encrypt your data at rest and in transit in a way that allows you to meet your security and compliance requirements
  • Segregate operational responsibilities and restrict access to cloud services in order to reduce risk associated with malicious and accidental user actions
  • Be able to leverage existing security assets and third-party security solutions to access and secure your applications and data
  • Audit and monitor actions taken on your cloud resources so that you can meet audit requirements
  • Make sure your cloud services are securely configured
  • Keep up to date on security information and software patches
  • Detect anomalous user behavior and threats
  • Demonstrate compliance readiness to internal security and compliance teams, end-customers, auditors and regulators

As a cloud provider, it is Oracle's job to provide and operate our secure infrastructure. We’ve designed security into every aspect of our infrastructure to help our customers achieve better protection, isolation and control. We started with taking a unique design approach, separating the network and server environments. This way, if an attack occurs on a VM, we can contain that threat and prevent it from moving to other servers, resulting in better protection and lower risk for customers. We also hyper-segment our physical network and backend infrastructure for secure isolation between customer instances and backend hosts. Additionally, we’ve implemented hardware-based root of trust, making sure each server is pristine each and every time it is provisioned.

However, security is a shared responsibility between Oracle and our customers. Therefore, we provide security tools and controls covering core IAM, networking, compute, data management and more so you can run your critical workloads, and their supporting databases, securely on our cloud without having to rebuild your security posture.

Network Security

We discussed VCNs, subnets and security lists earlier in the Networking and Connectivity topic. For each customer’s VCN there is a range of defense in depth protections available:

  • Virtual firewalls: Implement virtual firewalls at the subnet level using VCN security lists.
  • Load balancing traffic securely: TLS 1.2 is supported by default to securely balance traffic within the implementation and from external connections
  • Secure traffic between ADs and regions: Communications between ADs are encrypted with Media Access Control security (MACsec) to prevent layer 2 security threats such as wiretapping, DDoS, intrusion, man-in-the-middle and playback attacks. VCN traffic that travel between regions are either sent over private links or are encrypted.
  • Secure connectivity to public internet: For security, a VCN has no internet connectivity by default. Therefore, internet bound traffic to/from a VCN must pass through an IGW. Virtual routing tables can be implemented with private IP addresses for use with NAT and 3rd party firewall devices for additional security.
  • Secure connectivity between your VCN and data center: Traffic can be routed through a DRG for private traffic. It is used with an IPSec VPN or FastConnect connection to establish private connectivity between a VCN and an on-premises or other cloud network.
  • Protect internet-facing applications: Oracle provides a Web Application Firewall (WAF) service with 250 pre-defined OWASP and compliance rules. Oracle Cloud Infrastructure WAF acts as a reverse proxy that inspects all traffic flows or requests before they arrive at the origin web application. It also inspects any request going from the web application server to the end user. Additionally, Oracle’s optional global anycast DNS service also takes advantage of DNS-based DDoS protections providing resiliency at the DNS layers.


Server Isolation

If you require complete workload and data isolation at the server level for security and/or performance requirements, you can leverage bare metal compute shapes. These shapes are single tenant so they offer consistently high performance and are immune to noisy-neighbor issues. There is also no Oracle managed hypervisor and Oracle staff have no access to memory nor local NVMe storage while the instance is running.

If you don’t have more flexible requirements for your applications, our multi-tenant VM shapes leverage a security-hardened hypervisor that provides strong isolation between customers. And regardless of shape type, bare metal or VM, all servers are wiped clean and installed with gold state firmware when newly provisioned.

Data Encryption

By default, all data that customers store with any of Oracle Cloud Infrastructure’s storage or data management services, including Block Volumes, boot volumes, Object Storage, File Storage, and Database, is encrypted at rest using strong AES keys or TDE in the case of database encryption. We also offer encryption in transit.

Key Management

For customers that require the ability to control their own cryptographic keys for security or compliance purposes, we offer Oracle Cloud Infrastructure Key Management. With Key Management, you can centralize key lifecycle management in FIPS 140-2 Level 3 hardware security modules (HSMs).

Identity and Access Management (IAM)

Identity management including authentication, authorization, the ability to leverage existing identity providers, and tools to help you organize and control access to resources based on your organizational hierarchy, is such a rich topic that we devoted a separate topic to IAM, following this topic.

Platform-level Audit and Logging

Oracle automatically records calls to all supported Oracle Cloud Infrastructure public application programming interface (API) endpoints as log events. Currently, all services support logging by Audit. You can leverage this data to perform diagnostics, track resource usage, monitor compliance, and collect security-related events.



The Oracle Cloud Infrastructure Console provides visibility across all Oracle Cloud Infrastructure compute and store resources. Use it to:

  • Define administrators, users, groups, and services
  • Set authorization levels
  • Enforce privilege levels

The Telemetry services are provided for visibility and analysis. With Telemetry, you can audit all activity levels.

Ensure Secure Configuration

Oracle offers a Cloud Access Security Broker (CASB) solution that performs security configuration checks for Oracle Cloud Infrastructure resources, monitors credentials and privileges, performs user behavior analysis (UBA) for anomalous user actions, and delivers threat analytics for identifying risk events. For example, Oracle CASB can detect publicly accessible object storage buckets, open VCN security lists, user passwords that are more than 90 days old, and if multi-factor authentication has not been enabled on an administrator account.

Compliance

Depending on where you do business and industry-specific practices, you may need to demonstrate compliance readiness to internal teams and to external auditors. Oracle continually engages with external assessment entities and independent auditors to meet a broad set of international and industry-specific compliance standards for service deployments on our cloud.

Identity and Access Management

With the Identity and Access Management (IAM) architecture, you can group and isolate resources according to your organizational structure and hierarchy, control who has access to cloud resources, what type of access a group of users has, and to which specific resources.

Outcomes this architecture can provide:

  • Securely isolate cloud resources based on organizational structure
  • Authenticate users to access cloud services via browser interface, REST API, SDK or CLI
  • Authorize groups of users to perform actions on appropriate cloud resources
  • Authorize application instances to make API calls against cloud services
  • Federate identities using your existing identity provider (IDP)

Oracle Cloud Infrastructure offers a single model for authentication and authorization, and we also integrate with your existing identity provider. We have architected IAM to be secure by default, leveraging the security principle of least privilege. This means that new users cannot access nor take any action on cloud resources unless an administrator grants them appropriate permissions to do so. To begin, we recommend organizing and isolating your cloud resources appropriately so that you can apply policies to grant the right groups of users access.

Compartments

Compartments are a fundamental component of Oracle Cloud Infrastructure for organizing and isolating your cloud resources. A common approach is to create a compartment for each major part of your organization. You use them to ensure isolation between business units and to logically group resources for the purposes of measuring usage and billing.

Authentication and Credential Management

By default, Oracle Cloud Infrastructure enforces a strong password policy for access to the console user interface and to the Swift client for database backups to Object Storage. Administrators can also modify password policies for all local or non-federated users using Oracle IAM service. All users can automatically reset their own console passwords and manage their own API keys. However, you must have administrator permissions to manage credentials for users other than yourself.

Policies

Leverage policies to authorize a group of users to take action on cloud resources in a specified compartment or across the tenancy. Oracle Cloud Infrastructure policies are written in human-readable language so they are simple to define and easy to understand.



With Oracle Cloud Infrastructure policies:

  • Avalable from console or via API, CLI, or SDK
  • Customer system admins can manage all customer policies from a single console
  • Isolate resources by compartment
  • Group database admins manage database

Instance Principals

Allow users to call IAM-protected APIs from an Oracle Cloud Infrastructure compute instance without the need to create users or manage credentials for that instance. You may have an application running on a compute instance that requires access to object storage. By grouping the appropriate compute instances as “principal” actors, you can simply attach policies to enable them to make API calls against other cloud services such as object storage.

Federation

Oracle IAM supports federation with Oracle Identity Cloud Service, Microsoft Active Directory Federation Services (AD FS), Okta, and any other SAML 2.0 compliant identity provider including Oracle Access Manager (OAM).

When you sign up for Oracle Cloud Infrastructure, your tenant administrator account is automatically federated with Oracle Identity Cloud Service. Federating with Oracle Identity Cloud Service automatically allows you to have a seamless connection between services without having to create a separate username and password for each one.

You may be leveraging your application’s own security mechanisms to provide authentication with integrated applications on-premises that leverage LDAP, OAM or other 3rd party solutions. Therefore, we recommend federating your favorite IDP with Oracle Identity Cloud Service which will automatically provide federation for all Oracle cloud offerings.

Cost Management and Governance

When transitioning from a CapEx model, where many costs are fixed at the implementation of a project, to an OpEx model, where costs scale up and down with the usage of the system, customers often require cost management tools to understand, control, and communicate these cloud costs within their organization.

Outcomes these tools can enable include:

  • Set and manage cloud budgets
  • Prevent overspending
  • Ensure accurate cost tracking across departments and projects
  • Analyze which departments, services and projects are contributing to cloud usage over time
  • Get granular usage details for invoice reconciliation
  • Identify areas to optimize costs

Compartments

As discussed earlier in the Identity and Access Management section, compartments can be used to ensure isolation of cloud resources between business units. In addition, they are also used to logically group resources for the purposes of measuring usage and billing. We typically recommend creating a compartment for each major part of your organization, such as business unit or department. Compartments can also be nested to support sub-departments as well.

Tagging

Leverage tags to track cost and usage of resources that are associated with a particular project that span multiple departments. In addition, you can streamline resource management by tagging and then scripting bulk actions on exactly the Oracle Cloud Infrastructuree resources you want. Tags leverage policies and controls to ensure tagging integrity and to prevent users from creating excessive tags, duplicate tags, and manipulating existing tags.

Budgets

Once resources are assigned to compartments that match your specific use-cases, departments or regions of operation, you can set budgets, view how spend is tracking against budgets, and configure alerts so that unexpected usage is flagged before a budget is actually exceeded.

Cost Analysis

The billing cost analysis dashboard can help visualize the big buckets that are contributing to cloud usage and cost. You can analyze costs by cloud service, compartments and tags. For example, an analyst or administrator can use this tool to identify the difference between increased production or dev/test usage, as well as the difference between increased usage of storage versus networking.

Detailed Usage Reports

CSV files containing detailed resource-level and hour-by-hour data, including all associated metadata, such as tags and compartments. Export detailed usage reports as CSV files and import into existing business intelligence tools for invoice reconciliation use cases, to get more granularity into your bill and to identify areas for cost optimization. For example, you can leverage the detailed usage data and combine with CPU utilization data from the Oracle Cloud Infrastructure Monitoring service to identify instances with low CPU utilization to shut down.



Visualize the big buckets that are contributing to cloud usage using the cost analysis dashboard:

  • Compartments logically group resources by department
  • Tag resources for project cost tracking that span departments
  • Set budgets and configure alerts to prevent overspending
  • Export resource-level, hour by hour usage data
  • Leverage existing third party business intelligence tools
  • With monitoring, combine usage data with resource utilization data for cost optimization

Monitoring

The objective of the observability architecture is to enable you to understand how your applications are behaving in production by generating highly granular insights into the behavior of systems along with rich context by gathering data from various sources whenever you need it. The use of new application architectures, such as microservices, serverless, and infrastructure as code require updated tools for monitoring and management. In addition, the move towards DevOps and rapid build/test/deploy cycles in agile environments make it more important to quickly and easily monitor applications that have been rolled into production.

Outcomes this architecture can provide include:

  • Gather data and actionable insights for Oracle Cloud Infrastructure resources, hybrid, and on-premises applications and infrastructure resources.
  • Provide a single platform to collect and access all performance and operational data in the form of logs and metrics, instead of monitoring individual systems and applications in silos (server, network, database, etc.).
  • Monitor your complete stack (applications, infrastructure, and services) and leverage alarms, logs, and events data to take automated actions and reduce Mean Time to Resolution (MTTR).
  • Gain actionable insights that help you optimize application performance, manage resource utilization, and understand system-wide operational health.

Oracle Cloud Infrastructure provides a suite of Enterprise grade monitoring solutions ranging from being modern and cloud-native to hybrid and on-premise focused. This means that new users have the flexibility to choose a monitoring solution that best suits their workloads. Let's discuss these monitoring solutions at a high-level.

Oracle Cloud Infrastructure Monitoring

The Oracle Cloud Infrastructure Monitoring service is a complete and a powerful end-to-end cloud-native “observability” solution. It enables you to actively and passively monitor your cloud resources using the Metrics and Alarms features. The resources that can be monitored using this service includes both Oracle Cloud Infrastructure native resources (compute, storage, network, etc.) and customer apps/services. Metrics, Alarms and Logs form integral pillars in making the Monitoring service a complete "observability" solution offered by Oracle Cloud Infrastructure. The service provides metrics and graphs for all the resources (Oracle Cloud Infrastructure and custom). It provides customizable alarms and real-time alerts and events using Notification and Events service respectively.



The monitoring service provides Metrics, Alarms, and Logs:

  • Metrics: Monitoring service uses the Metrics feature which relays metric data about the health, capacity, and performance of your cloud resources. A metric is a measurement related to health, capacity, or performance of a given resource. Resources, services, and applications emit metrics to the Monitoring service. Common metrics reflect data related to availability and latency, application uptime and downtime, completed transactions, failed and successful operations, and key performance indicators (KPIs), such as sales and engagement quantifiers. By querying Monitoring for this data, you can understand how well the systems and processes are working to achieve the service levels you commit to your customers. For example, you can monitor the CPU utilization and disk reads of your Compute instances. You can then use this data to determine when to launch more instances to handle increased load (autoscaling), troubleshoot issues with your instance, or better understand system behavior.

  • Alarms: Monitoring service also uses the Alarms feature which works with the Notifications service to notify you when metrics meet alarm-specified triggers. When configured, repeat notifications remind you of a continued firing state at the configured repeat interval. You are also notified when an alarm transitions back to the OK state, or when an alarm is reset.



  • Logs: The Oracle Cloud Infrastructure Logging Service provides a robust logging platform and will be the central logging product for all Oracle Cloud Infrastructure customers. Oracle Cloud Infrastructure Logging Service enables you to seamlessly collect and manage all logs into a single glass pane view. In addition it provides a search experience and API to search and analyze your logs and allows you to take actions on your logs with an intuitive and simple rules engine. The Logging service will provide a capability to ingest Oracle Cloud Infrastructure service and audit logs, customer generated application and security logs into a centralized platform, where the customers will have the ability to perform search and analyze capabilities and take actions accordingly, which can be either emitting a metric using Oracle Cloud Infrastructure Monitoring Service or feeding into a streaming service for further processing using Fn or triggering a notification using Notification Service (ONS). Logging service facilitates the ingestion of custom logs with the help of CNCF’s fluentd based agent, which helps ingest any type of customs logs from virtually any environment.

Oracle Enterprise Manager

Oracle Enterprise Manager is Oracle’s on-premises management platform, providing a single pane of glass for managing all of a customer's Oracle deployments, whether in their data centers or in the Oracle Cloud. Through deep integration with Oracle’s product stack, Enterprise Manager provides market-leading management and automation support for Oracle applications, databases, middleware, hardware and engineered systems. Oracle Enterprise Manager is widely deployed by Oracle customers on the basis of its deep capabilities for the Oracle Database, including the Diagnostics and Tuning packs, the Database Lifecycle Management pack and Cloud Management Pack for Oracle Database. Oracle Enterprise Manager can be used to manage all supported versions of Oracle Database, whether deployed on-premises and in Oracle Cloud. Oracle Enterprise Manager will be providing new capabilities for Autonomous Database, and is integrated with Oracle Management Cloud for customers who wish to manage their entire enterprise from one place.

Oracle Management Cloud

With Oracle Management Cloud, customers can analyze a single, unified data set with purpose-built machine learning designed specifically for the systems management and security problem set to instantaneously draw actionable conclusions about the performance and security posture of a heterogeneous, hybrid estate, and then take instantaneous action on the basis of those analytic conclusions. Oracle Management Cloud provides a platform that could ingest, analyze and draw intelligent conclusions from the vast quantities of operational and security telemetry generated by today’s applications, regardless of what kind of technology they are built on or where they are deployed. The metrics generated by Oracle Cloud Infrastructure Monitoring service can be fed into the Oracle Management Cloud to have a single pane of glass for drawing actionable insights on the data being generated. Oracle Management Cloud serves to be particularly important where there is a need for an integrated monitoring solution across on-premises and multiple clouds. Oracle Management Cloud also supports integration with Oracle Enterprise Manager and Oracle Cloud Infrastructure Monitoring service.

Migration and Deployment

When migrating a complex, highly customized and deeply integrated applications, it’s often important to have reference materials to highlight best practices to get the best results.

As discussed in the Migration Scenarios topic, we distinguish three main scenarios which we characterize as “Lift and Shift,” “Move and Improve,” and “Modernize,” each with their own goals, trade-offs, and benefits.

Some considerations to choosing the correct approach:

Is the application complete, requiring few updates, and with a fixed workload?

“Lift and Shift” is an approach that makes as few changes to the infrastructure as possible. It reduces the chances of introducing differences in behavior, while still delivering the cloud benefits of improved performance from using the best hardware, storage and networking, as well as the financial benefits of moving from a capex to an opex model.

Is the application still an active project, with regular updates and version releases?

“Move and Improve” lets you upgrade the components of your application infrastructure to the latest versions, such as migrating WebLogic to version 12.2 and Oracle database to version 19c. It uses an Oracle validated architecture that can be deployed from Terraform scripts. This implements the best practices for running applications on Oracle Cloud Infrastructure. This approach makes it easy to spin up/down instances of the applications for dev and test work and improves the quality of production releases.

Do you want to implement a cloud native architecture, with support for elastic scaling, continuous deployment, and self-healing?

The “Modernize” approach is based on the deployment of WebLogic based applications on Kubernetes clusters of Docker containers. Using OKE, OOracle Cloud Infrastructure’s managed Kubernetes service, it is easy to build highly resilient, scalable infrastructure, while levering your existing application code. This infrastructure is ideal to modern devops approaches to software development.

Oracle Database Cloud Migration Services

Migrating on-premises databases to the managed database services on Oracle Cloud Infrastructure unlocks many benefits such as reduced administration, improved availability, flexible scalability, and integration with other cloud services.

  • Simple & Efficient: Oracle automated tools make it seamless to move your on-premises database to the Oracle Cloud with virtually no downtime. Using the same technology and standards on-premises and in the Oracle Cloud, you can facilitate the same products and skills to manage your cloud-based Oracle Databases as you would on any other platform.
  • Flexible: You can directly migrate your Oracle Database to the Oracle Cloud from various source databases into different target cloud deployments depending on your requirements and business needs. A well-defined set of tools gives you the flexibility to choose the method that best applies to your needs.
  • Cost Effective: The same flexibility that lets you directly migrate your Oracle Database to the Oracle Cloud is applied to finding the most cost-effective solution for the purpose and duration of the migration. Even if the automated tools determine that an Oracle licensable product should be used to optimize your migration, Oracle will provide a cost neutral solution.
  • Highly Available & Scalable: The tight integration of all migration tools with the Oracle Database lets you maintain control and gain better efficiency when moving your databases to the Oracle Cloud, while the Maximum Availability Architecture (MAA)-approved tools as well as Zero Downtime Migration (ZDM)-based migrations ensure that your migration is handled as smoothly as possible.

Additional Oracle Cloud Infrastructure Features

There are some other key Oracle Cloud Infrastructure features that your applications can leverage that haven’t been discussed in detail in the preceding topics.

Compute Services

This is the most basic service that lets you manage your compute hosts called instances. Oracle Cloud Infrastructure offers compute in the form of either Bare Metal (BM) hosts – dedicated to a customer, or Virtual Machines (VMs) – virtual environment running on top of a physical host. This is best for shared environment where multiple environments are segregated by various mechanisms to ensure there's no compromise on privacy and security of customers' data. Oracle Cloud Infrastructure provides multiple shapes for its VM and BM offering based on the workload in question. Although there's no specific recommendation for using a specific shape of the VM for running your applications on Oracle Cloud Infrastructure, the customer can choose any shape (such as number of cores) based on the size of their environment and concurrent users.

File Storage Service

Oracle Cloud Infrastructure File Storage service provides a durable, scalable, secure, enterprise-grade network file system. You can connect to a File Storage service file system from any bare metal, virtual machine, or container instance in your Virtual Cloud Network (VCN). You can also access a file system from outside the VCN using Oracle Cloud Infrastructure FastConnect and Internet Protocol security (IPSec) virtual private network (VPN).

Large Compute clusters of thousands of instances can use the File Storage service for high-performance shared storage. Storage provisioning is fully managed and automatic as your use scales from a single byte to exabytes without upfront provisioning. You have redundant storage for resilient data protection. The File Storage service supports the Network File System version 3.0 (NFSv3) protocol. The service supports the Network Lock Manager (NLM) protocol for file locking functionality.

Oracle Database Exadata Cloud Service and DbaaS

DB systems allow you to leverage the power of Exadata within the Oracle Cloud Infrastructure. An Exadata DB system consists of a quarter rack, half rack, or full rack of compute nodes and storage servers, tied together by a high-speed, low-latency InfiniBand network and intelligent Exadata software. You can configure automatic backups, optimize for different workloads, and scale up the system to meet increased demands.

For high availability requirements, Oracle recommends that you use one of the following options to set up your application database instances:

  • Two-node, Oracle Real Application Clusters (Oracle RAC) database systems on virtual machine.
  • Oracle Database Exadata Cloud Service instances. This service provides Oracle Database hosted on Oracle Exadata Database Machine in Oracle Cloud.

Place database systems in a separate subnet. The database instances are set up to be highly available, and both instances of the database in an availability domain are active. Requests received from the application tier are load balanced across the database instances. If one database instance is down, then the other database instance services the requests. You can use Oracle Cloud Infrastructure Object Storage to back up the application database using RMAN.