Cloud Hosting Considerations & Patterns
For Independent Software Vendors (ISVs)
Independent Software Vendors (ISVs) need secure, scalable, and reliable platform & infrastructure services to host their applications. Even more so than information technology (IT) organizations running a back-office system in the cloud, ISVs need to contend with 24x7 operations, geographically diverse deployments, dynamic customer traffic patterns which may require elastic scaling, and the security challenges of exposing their application to the public Internet.
An ISV moving to or operating on one or more hyper-scale cloud providers has a number of important choices and patterns to consider. Should you lift-and-shift your application as-is or use a cloud migration as an opportunity to re-architect into a more cloud-native posture and potentially start leveraging a provider's managed PaaS services? Can a cloud deployment transform your high-availability (HA) and disaster recovery (DR) posture by introducing the ability to leverage in-datacenter fault domains, in-region availability domains, or cross-region interconnects? What tools does your cloud provider offer you to secure your data, your internal network, your compute hosts/containers, as well as your interactions with your customers? Finally, are you deploying your application as a multi-tenant SaaS or in a single-tenant configuration for each of your customers?
In addition to hundreds of applications Oracle has moved to OCI, our Cloud Engineering team has helped dozens of ISVs plan for and subsequently move to OCI. This microsite will provide guidance and present distinct hosting patterns for ISVs.
We explore various topics through the lens of different approaches to adopting Oracle Cloud.
This microsite is not meant to be read in a linear fashion. The diagram below visually represents the flow you can follow through this site based on your own profile. After completing this introduction please read the Our Process section and then, depending on your current hosting model, choose the Born in the Cloud or On-Premises/Colocation section. Then, read either the Multi-tenant SaaS or Single-tenant SaaS section depending on what your application delivery model is. Finally, all readers should read the common Cross Cutting Concerns sections along with the Summary.
Our Process
- Born in the Cloud
- On-premises / Colocation
- Multi-Tenant Application Delivery Model
- Single-Tenant Application Delivery Model
Many ISV SaaS providers are ‘born in the cloud' which sounds like ‘cloud native' but is not always the case. Born in the cloud typically means a desire to no longer be coupled to legacy systems and to be built following modern application design principles. Modern Application Design is the architectural guidance that embodies the principles outlined as a Twelve Factor App. This is also not the same as, but is closely related to, Cloud Native architecture. For those looking for a deeper treatment of cloud native from an Oracle perspective, it is worth reviewing Cloud Native Patterns, an e-book focusing on cloud native design.
Whether the SaaS application is built following modern application design or cloud native principles there are some key drivers that are the same:
- Desire to follow modern application development principles
- Desire to focus on the application and not the infrastructure
- Reduced time to value for features
- Continuous, dependable and repeatable deployments
- Decoupling from what are seen as ‘legacy' or single vendor systems
- Desire to build, operate and support a modern architecture
- Desire to operate in the elastic manner that cloud computing enables
ISVs that have started out with these goals typically have a more decoupled service architecture. Application components in their workload are independently deployable, often as containers, and the application architecture is built to handle application continuity in the event of component failures. Applications need to not only handle consistency of data but also availability of the application.
Depending on the runtime architecture chosen, the ISV they will likely have integrated monitoring and notifications into the control of their infrastructure. OCI provides services to support:
- CNCF Cloud Events with our Cloud Events Service
- CNCF OpenTracing as part of our Cloud Observabilty and Management Platform provides a full interoperates with the Cloud Functions (serverless) and Notifications Service which simplifies not only lifecycle management for your server fleet but also eases governance tasks.
The inter-component communication typically implements an asynchronous pattern whereby components produce and respond to events rather than direct instructions. OCI offers the Streaming Service which is a Kafka compatible, serverless streaming service that is often used to handle this communication. The advantage of this approach is the protection of components during failure whereby the blast radius is reduced by utilization of intelligent queuing or routing.
Additional decoupling is achieved by separating applications from infrastructure. Enablement of elasticity is often achieved by utilization of cloud service provider (CSP) provided autoscaling mechanisms. Autoscaling could be at the container level utilizing the Oracle Kubernetes Engine (OKE), the instance grouping level or at the server group level.
Over time, some SaaS applications start to diverge from their originally planned standards-based architecture as the teams start to take advantage of the native PaaS services that a single CSP provides. Examples of this include: using a data management service that is exclusive to a single cloud, embedding a direct API call to a vendor flavored NoSQL platform without proper layers of abstraction in the implementation for future replacement, utilizing IDEs that generate vendor-specific code. To maintain cloud portability, ISVs must be careful to balance the convenience of a platform service with the threat of vendor lock-in that may result if the service is not vendor neutral. Many ISVs have started a re-modernization journey for their applications, aiming to have a true multi-cloud footprint. To do so, they are re-examining the tight coupling points with single vendor or single use technologies.
Over time, there could be a drift in infrastructure configuration. Most ISVs adopt an Infrastructure as Code (IaC) approach and OCI supports industry standard tools but goes one step further; OCI Resource Manager, a managed Terraform service, can be used to monitor, track, and repair drift in infrastructure.
A Lift-and-Shift implementation consists of migrating your production workloads running on-premises or in a colocation facility to Oracle Cloud Infrastructure (OCI). In some instances, you may wish to take advantage of the native cloud services offered within OCI to enrich your applications. This "move and improve" activity is another compelling reason to move to OCI. The following sections will cover the Lift-and-Shift process and address the Move-and-Improve considerations where needed.
This scenario is ideally suited for ISVs who are looking to benefit from reduced capital expenditure and to delegate some of the operational complexities around availability, security, and performance to a Cloud Service Provider (CSP) such as Oracle. Typically, an ISV will implement one of the following strategies:
- Lift and Shift: Migrate their on-premises or co-located applications to OCI
- Move and Improve: Migrate on-premises or co-located applications to OCI and then enrich them by leveraging cloud native services or migrating databases to cloud-based offerings.
There's nothing preventing you from mixing and matching these strategies where some workloads are moved as is, others are modified to leverage OCI managed services (PaaS).
Lift and Shift
The Lift and Shift cloud migration strategy consists of moving your on-premises application to OCI so the resulting deployment closely resembles the on-premises deployment. The first step of this process is to identify workloads/applications which will allow you to exercise the capabilities of OCI and achieve your strategic objectives. We have many hosting modalities that you can choose from depending on your data residency, latency, and connectivity requirements. You will have access to OCI's complete portfolio, regardless of which of the following hosting types you choose.
| Hosting Type | Description |
|---|---|
| Public Cloud | Broad platform of IaaS, PaaS & SaaS services |
| Government Cloud (restricted realms) | Broad platform of IaaS, PaaS & SaaS services deployed in a restricted realm for public sector entities |
| Dedicated Region Cloud@Customer | Broad platform of IaaS, PaaS & SaaS services deployed in your data center |
| Roving Edge Infrastructure | Broad platform of IaaS, PaaS & SaaS services deployed in Ruggedized Oracle Roving Edge Devices (Oracle REDs) delivering cloud computing and storage services at the edge of networks and in disconnected locations |
| Oracle Cloud VMWare | Move VMware-based workloads to the cloud or extend your on-premises VCenter to include the cloud without rearchitecting applications or retooling operations. |
As you design your cloud architecture, understand that Oracle supports a variety of network connectivity options that will allow you to architect a hybrid cloud solution that mixes OCI resources with components running within your datacenter or a multi cloud solution which interconnects your OCI footprint with that of another cloud service provider. Both of these approaches are very common and can help facilitate the migration of workload dependencies for existing applications running on-prem, or in other cloud vendor environments, to meet data residency requirements, IT SLAs or other requirements.
OCI enables this communication over the public internet, via an IPSec VPN, or using dedicated connectivity (FastConnect). The following table describes some of the characteristics of each of these approaches:
| Method | Latency | Cost | Reliability | Security |
|---|---|---|---|---|
| Public Internet | Variable | Variable | Variable | Least Secure |
| IPSec VPN | Variable | Variable | Variable | Traffic is encrypted, but the tunnel is through the public internet |
| OCI FastConnect | Low, and predictable | Predictable | Most reliable | Most secure; traffic traverses a private connection |
In addition, while cloud-cloud interconnect is possible between OCI and any other cloud using the above technologies, Oracle does have a partnership with Microsoft Azure to provide low-latency, productized interconnectivity between both clouds in many regions around the globe.
Oracle has a number of partners who specialize in automating migration to OCI from any number of sources including competitor public clouds and virtualized/non-virtualized on-premises environments. The full list of migration vendors can be found in our Marketplace with notable examples being Rackware and ZConverter.
When considering migration of Oracle Database from other clouds or on-premises environments, Oracle provides a number of tools to facilitate either offline or zero-downtime/live migration. These diverse tools include Zero Downtime Migration (ZDM), OCI Database Migration (DMS), GoldenGate, DataPump, RMAN, and others. The tool of choice depends on your source and target database characteristics and your operating environment. More details can be found by reviewing OCI's Database Cloud Migration Landing Page.
Move and Improve
The Move and Improve cloud migration strategy consists of enriching or replacing an existing service with a cloud offering. As your team steps through the process of identifying the suitable candidates to migrate to the cloud, consideration for opportunities to enrich or replace services should be top of mind. For example, you may improve existing on-premises applications by migrating the on-premises database supporting a mission critical application to our managed Database Cloud Service, our premier self-driving Autonomous Database, or Exadata Cloud Service which is the fastest platform to run Oracle Databases in the cloud.
In addition, adopting Oracle Cloud Infrastructure grants access to an entire portfolio of services ranging from:
- Data Science Cloud which includes technologies like Machine Learning, AI, Big Data Service
- Applied Technologies Software which includes technologies like Digital Assistants and Blockchain
- Application Development which includes technologies like Container Engine for Kubernetes, APEX (Low Code), Visual Builder Studio (CI/CD) and Mobile Hub
- Security Services which includes technologies like WAF, Identity & Access Management, Cloud Guard and Access Security Broker
- Analytics Cloud
A multi-tenant delivery model for SaaS vendors utilizes software running on shared infrastructure to support individual ISV end-customers (tenants).
The customer data is typically stored in a set of shared tables and all application layers are aware of a customer's unique identifier. The application itself is designed to be multi-client aware. The application itself is typically also responsible for the management of user subscriptions. In addition, the infrastructure also needs to be categorized into server groups based on the number of customers, transactions, and regulations that need to be supported.
Why Choose This Model
A multi-tenant model brings advantages to the ISV (Independent Software Vendor). There are many efficiencies gained when utilizing the economies of scale provided in a multi-tenant model. As the server group composition is well-known there are efficiencies gained in infrastructure management and monitoring. Launching a new service area is as simple as executing your infrastructure automation code and then deploying the application. The common set of infrastructure also provides a unified ‘single plane of glass' for monitoring.
Customers being hosted on common compute, storage, and database makes for a simpler application deployment strategy. ISVs utilizing this model will typically have a single code base which makes for easier deployment of updates across the customer base. Many ISVs utilizing this model allow customers to opt-in to new features with the utilization of feature flags.
Of course, all these benefits may also pose drawbacks. Supporting customers that have specific data residency requirements entails a regional deployment strategy and there may be scenarios wherein customers have business requirements of not being housed in the same servers as a competitor. Depending on the architecture of the application the clients may be subjected to the noisy neighbor scenario. When a server group becomes saturated the ISV needs to decide to either migrate the customer to a newer lesser utilized server group or to expand the capacity of the existing group.
One of the unintended consequences of properly supporting the multi-tenant SaaS model is that your application architecture needs to be well thought out and planned at a higher level than in a single-tenant architecture. Proper access controls and data segregation models need to be architected into the application framework from the beginning and ISVs need to ensure they have the in-house engineering skills to accomplish all of this.
Oracle can help to bridge the gap by involving our cloud architects to help advise on modernizing your application and tweaking it for cloud success. Our architects work with other ISVs across the spectrum and can bring experience working with similar problems and best practices to your cloud transformation.
Server Group Isolation
A key construct of the multi-tenant model is a shared environment for hosted tenants. As an ISV, you need to ensure that the SaaS application has been architected to properly segregate and protect customer data during runtime. You also need to be able to properly manage, monitor, and maintain what goes on in the various server groups hosting your application.
You may have specific requirements to keep customers from specific regions away from customers in other regions (or sub regions). This type of segregation can be achieved by deploying your workloads into the combination of OCI regions and compartments. An example of this would be a SaaS vendor in the US that sells services to both the healthcare and general manufacturing market. The vendor could use regional and compartment constructs to segregate those workloads and provide differentiated capabilities (i.e., HIPPA/HITRUST compliance for the healthcare workloads).
One natural evolution for ISVs that started with a multi-tenant model is to evolve the offering to provide better isolation of customer data. Typically, this evolution happens at the data level first and Oracle Database supports a multi-tenant model which allows for independent, pluggable databases to be embedded in a single container database.
A single-tenant delivery model uses software running on dedicated infrastructure to support individual ISV end customers. Unlike a multi-tenant model where multiple customers share the same compute cycles and co-mingle data inside common database tables, a single-tenant model relies on distinct compute VMs, distinct databases, and distinct supporting infrastructure (load balancers, message queues, etc) for each customer.
Why Choose This Model
A single-tenant model brings many advantages to the ISV (Independent Software Vendor). Each customer/tenant hosted on separate compute, storage, and database makes a clearer case for separation of concerns from both a security and performance perspective; customer ‘A' cannot affect customer ‘B' either through malicious action or by inadvertently consuming more than their fair share of resources. In addition, the blast radius for catastrophic failure is smaller; the failure of a single component (i.e., database or message queue) might impact a single customer instead of the entire SaaS application. Each tenant has their distinct environment customized with unique features and patches making for a highly customer-centric delivery model.
Of course, all of these benefits may also pose drawbacks. Every benefit derived from, for example, providing customer-centric environments may be offset with the additional burden of configuration management and increased monitoring and maintenance. Many other benefits of this approach are realized in a multi-tenant model, albeit through a more rigorous design and implementation of the ISV's SaaS application.
In the end, the decision comes down to whether an ISV wants to invest in multi-tenant enabling their SaaS application which largely depends on whether they have the in-house software engineering skills to do so. If not, they may choose to rely on the inherent compartmentalization capabilities provided by their software platform and/or hyperscale cloud provider. Each ISV must make this choice based on their unique situation.
Oracle can help you navigate these choices by involving our cloud architects to help advise on modernizing your application and tweaking it for cloud success. Our architects work with other ISVs across the spectrum and can bring experience working with similar problems and best practices to your cloud transformation.
Tenant Isolation
A key construct of the single-tenant model is an isolated environment for each tenant. As an ISV, you want to provision dedicated compute, network, storage, messaging, and database resources for each of your customers. You want to do this in such a way that these resources are segregated from each other from both a runtime and a management perspective.
OCI provides a unique feature called compartments which provide for strong logical separation between any OCI resource. You can place an entire customer environment including network, compute, etc inside a compartment and write OCI policies which control access to these resources. Through the use of these two core OCI features, you are able to effectively separate customer ‘A' from customer ‘B' and prevent any resource, management, or information cross-contamination. Compartments are hierarchical so you have the ability to nest compartments and can model complex customer setups using this approach; for example, imagine a realistic customer with multiple divisions who desire some segregation between business units while also maintaining some common corporate resources.
Although the compartment model provides the strongest guarantees for segregation, there are some intermediate approaches that can be utilized at certain tiers of the application to improve resource utilization while still relying on a non-customized method for separating tenants. For example, rather than creating a separate database system for each tenant you can leverage the multitenant capabilities of the Oracle database to implement a single container database with multiple pluggable schemas. This approach reduces the overhead of standing up multiple database clusters while still allowing the database to enforce separation rather than forcing a rewrite of the application schema. Oracle's virtual machine and bare metal Database-as-a-Service support multitenancy out-of-the-box as does the Autonomous Dedicated Database which can be used for your most demanding workloads.
Using this intermediate approach isn't supported only at the data tier. If your application is containerized you can then leverage Oracle's Container Engine for Kubernetes (OKE) to deploy multiple customer containers into a single infrastructure. You then leverage native Kubernetes primitives like namespaces, role-based access control (RBAC), secrets, and resource quotas to maintain tenant separation. Just like with the database, rather than re-writing your application to be tenant-aware, you can simply leverage the capabilities of the underlying cloud services.
See why ISVs are choosing Oracle Cloud
ISVs deliver better value to their customers with OCI’s wide range of services and support.
Cross-Cutting Concerns
Perhaps you are a "Born in the Cloud" ISV who is building a single-tenant SaaS infrastructure leveraging your hyperscaler's innate capabilities. Maybe you started on-premises and are migrating your multi-tenant SaaS application to live solely in the cloud. Or, perhaps your business is some permutation of these approaches. Regardless of which path you have followed, every ISV operating in the cloud must be concerned with key cross-cutting concerns like security, observability, business continuity, and automation. In the following sections, we review how Oracle is positioned to meet these functional challenges and differentiate from our competition.
Security, Governance, and Compliance
Oracle's approach is that security should always be "on" by default and should be simple and prescriptive. We also believe that customers shouldn't have to choose between cost and security and strive to provide all security related services either at no cost or low cost with partners providing alternatives through our marketplace. Our belief is that customers don't get breached because tools to prevent vulnerabilities don't exist but because those tools are either too costly or too difficult to operate for most organizations.
Oracle believes that security is a shared responsibility between the cloud provider and the ISV. We provide certain core capabilities, like isolated network virtualization and hardware root-of-trust, and augment them with tools and services that the ISV can use to customize their security posture. ISVs interested in getting an overview of our security offerings should start by reviewing our security landing page and cloud security architecture.
Core security starts with our robust identity & access management (IAM) implementation which unifies role-based access controls with our intuitive policy framework. This capability covers a variety of topics including users, groups, identity federation, and instance/resource principal authorization. While not covered by IAM, another core security concept relates to user-defined networking through the use of network security rules, groups, and lists.
As you start to develop a secure technical architecture on Oracle Cloud Infrastructure (OCI), a good starting point is the Center for Internet Security (CIS) which is a vendor neutral organization that catalogs security best practices. CIS has developed a secure benchmark for OCI applications and Oracle has developed automation that helps ISVs implement CIS recommendations through Terraform.
OCI provides a number of other foundational security services spanning:
- Management of encryption keys and secrets
- Host, container, and network vulnerability scanning
- API management & security capabilities like DDoS protection, API access control, and identity integration
- Web Application Firewall (WAF) capabilities supporting threat intelligence, security compliance policies, and adaptive bot management
- A bastion service allowing customers to provide restricted and time-limited access to private resources
- A certificate service allowing for the storage and management of public key cryptography (PKCS) certificates.
Moving up the stack, a unique capability of OCI is Maximum Security Zones which automatically set up and enforce security policies in OCI. This allows for declarative security to be enforced using security best practices and provides a proactive rather than reactive approach to security for the most critical resources.
Finally, no security story is complete without security posture management which is provided by Cloud Guard for your entire OCI estate and by Data Safe for your database workloads. Both services are provided at no cost to OCI customers and ensure that misconfigured resources and insecure activity are quickly detected and remediated in an automated fashion with out-of-the-box security recipes or by sending data to SIEM/SOC systems.
Observability
All organizations require the ability to gather insights into the performance of their cloud estate for the purpose of supporting operations and for future IT planning. ISVs, in particular, need richer capabilities since they are typically running custom applications which often require deeper application performance instrumentation. Additionally, ISVs may be running their workloads at cloud-scale with a 24x7 external consumer base which necessitates higher levels of uptime than a typical back-office system.
At a base level, OCI provides our Monitoring service which enables real-time insights into the performance of your workloads on OCI and offers out-of-the-box metrics for health and performance. Users can configure alarms to detect and respond to anomalies. This service is paired with our core Logging service which surfaces OCI logs in addition to logs generated by your workloads. Any conditions or problems identified through either of the aforementioned services can be handled by our Notifications service which provides a highly available, low-latency publish-subscribe system that sends alerts to serverless functions (for automatic remediation), email, or message delivery partners like SMS, Slack, and PagerDuty.
Moving up the stack, Oracle provides a number of machine learning (ML) driven services that provide deeper analytics in the areas of logging, application performance, database performance, and operations. Logging Analytics allows you to monitor, aggregate, index, and analyze all log data and use ML to detect problem clusters and anomalies in a visual fashion. Application Performance Monitoring is a standards-compliant (OpenTracing & OpenMetrics) service which enables synthetic monitoring, distributed tracing, and transaction execution analysis of custom applications including native support for microservices telemetry derived from Kubernetes/docker environments that many ISVs offer. Database Management provides monitoring capabilities for Oracle Database fleets and Ops Insights which enables administrators to uncover performance issues, forecast consumption, and plan capacity using ML analytics. Organizations can use these capabilities to make data-driven decisions to optimize resource use, proactively avoid outages, and improve performance.
All of these observability capabilities are provided as integrated services on OCI and boast generous "free tiers" allowing the ISV to utilize services in limited scenarios and then expand to greater usage based on initial successes.
Business Continuity
An ISV's business continuity requirements can often be more rigorous than those of a traditional ISV organization. While downtime for a traditional back-office system like a human capital management (HCM) or enterprise resource planning (ERP) system can be problematic, most ISVs cannot tolerate even temporary interruptions to their customer facing systems which are the lifeblood of their business. To this end, concepts like high availability (HA) and disaster recovery (DR) are extremely important and ISVs need to leverage the capabilities that OCI provides in these arenas to the fullest extent possible.
High Availability
An OCI region is a localized geographic area composed of one or more availability domains, each composed of three fault domains. High availability is ensured by a redundancy of fault domains within the availability domains.
An availability domain is one or more data centers located within a region. Availability domains are isolated from each other, fault tolerant, and unlikely to fail simultaneously. Because availability domains do not share physical infrastructure, such as power or cooling, or the internal availability domain network, a failure that impacts one availability domain is unlikely to impact the availability of others.
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. As a result, an unexpected hardware failure or a compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.
All the availability domains in a region are connected to each other by a low-latency, high bandwidth network. This predictable, encrypted interconnection between availability domains provides the building blocks for both high availability and disaster recovery.
You can design solutions across multiple regions, multiple availability domains, or multiple fault domains, depending on the class of failures you want protect against.
There are also a lot of capabilities that OCI offers and choices that you can make to protect your network resources, storage systems, and database resources against localized failures. A great place to get started is to fully read the OCI Architecture Center's High Availability Solution Playbook and to make choices appropriate to your operating model.
Disaster Recovery
A disaster can be any event that puts your applications at risk, from network outages to equipment failures to natural disasters. A well architected disaster recovery (DR) plan enables you to recover quickly from disasters and continue to provide services to your users. OCI's DR capabilities build on-top of the extensive HA capabilities discussed in the previous section.
When considering your DR strategy you must first consider your recovery time objective (RTO) and recovery point objective (RPO). The RTO is the target time within which a given application must be restored after a disaster occurs. Typically, the more critical the applications, the lower the RTO. The RPO is the period after a disaster occurs for which the application can tolerate lost data before the disaster begins to affect the business.
Next, you must determine what type of disaster scenario you are architecting for. Are you trying to protect against application failure, network failure, data center failure, regional outages, or all of the above? The answer to this question, combined with your RTO/RPO determinations, will drive your DR strategy.
OCI provides guidance for building disaster tolerant architectures at the compute, network, storage, application, and database levels. You can use these tools to build either an active-active architecture where your apps are functioning simultaneously in two regions and a failure in region ‘a' can be handled by region ‘b', a warm backup scenario where a secondary region is primed and ready to take on traffic on primary region failure, a cold backup scenario where a mix of manual and/or automated steps may be required to restore business operations, or some hybrid combination thereof.
A great place to get started is to fully read the OCI Architecture Center's Disaster Recovery Solution Playbook and to make choices appropriate to your operating model.
Budgets and Quotas
As an ISV running a SaaS application that leverages OCI compartments for isolation, you may want to consider a few related primitives to help you – and your customers – better manage their resources. Each OCI tenancy typically comes pre-configured with a certain annual dollar limit and while overages don't incur any penalty, most ISVs like to maintain tight control over resource utilization.
ISVs should start by looking at compartment quotas as a tool to divide up tenancy-wide resources across various compartments in the tenancy. Using this primitive, common resources like CPUs and storage blocks or more specialized resources like GPUs and Exadatas can be allocated across compartments to make sure no tenant gets an outsized allocation of resources and that certain specialized resources are allocated in the right places.
Quotas operate on cloud resources. When controlling for dollar allocations, ISVs should take a look at OCI budgets. This capability allows you to set usage budgets on each compartment and to receive alerts when a budget is approaching a soft limit or has exceeded a hard limit. Use of this feature can help ISVs manage their spend across multiple customers and help predict the need for future resource growth.
Chargeback
While every ISV prices their SaaS service differently, a common input into many pricing models is the concept of cost-of-goods-sold (COGS). Without knowing how much you spend to create and deliver a product, it is difficult to know how to fairly price it and how to vary that price across different consumers.
A SaaS service has many pricing inputs including costs for engineering and marketing but one key component is the cost of cloud hosting. This is an area where OCI Cost Analysis can help by providing dynamic visualizations of usage across your customer tenants segmented by compartments and/or cost tracking tags. Using these tools can help you understand how much you are spending to host each of your customers and help guide you as to whether or not you may need to adjust the pricing you present to them.
If you need more granular data than our visualizations provide, you can export fully granular usage data in a machine-readable format for further analysis using a tool of your choice. And, if you happen to operate in a hybrid cloud environment, you're free to use a multi-cloud 3rd party tool like CloudHealth to do unified analysis.
Infrastructure Automation
Very few organizations build their environments by hand. ISVs especially have recognized the value of infrastructure orchestration and configuration management through the use of Infrastructure-as-Code (IaC) tools like Terraform, Ansible, Puppet, etc. While IaC is ideal regardless of your organization's size, technical footprint, or deployment approach it is particularly critical for growing ISVs who are constantly expanding their regional footprint and installed base. Without automation, your maintenance overhead will scale exponentially and become difficult to manage.
OCI provides support for a number of industry-standard automation tools that will allow you to implement a cloud-neutral automation strategy. These include productized support for HashiCorp Terraform, Ansible, and Chef. Because OCI exposes all of its functionality via SDKs and via a CLI it is easy to integrate with any number of other tools, like Puppet.
In addition, OCI builds upon Terraform's capabilities by offering a managed service called Resource Manager. This service, which is offered at no cost to OCI customers, allows for Terraform to be run from within the confines of OCI's policy-based security model and provides for out-of-the-box state management, templating, resource discovery, and GitHub/GitLab integration.
Software Lifecycle Automation
ISVs use automated build and deploy tools to move their code through the software development lifecycle. When considering a single-tenant delivery model, strong automation becomes even more important as a single deployment may be delivered to hundreds of tenant instances. In addition, these deployments must often be performed in a rolling fashion to eliminate downtime and must be flexible enough to handle specific branch-based customizations for individual customers.
OCI supports the vast majority of industry leading CI/CD tools in the marketplace. Whether you're using Jenkins, Jenkins-X, Spinnaker, TravisCI, GitHub Actions, CircleCI, or others there is someone in the software ecosystem likely to be using your tool of choice with OCI.
In addition, OCI provides an easy to use DevOps Service which is an end-to-end, continuous integration and continuous delivery (CI/CD) platform for developers. ISVs can use this service to easily build, test, and deploy software on OCI as well as manage source code with hosted, private Git repositories.
Conclusion
Oracle recognizes that every ISV brings with them a unique origin story, source environment, technical architecture, deployment model, and business & technical requirements. There is no "one size fits all" approach to moving to Oracle Cloud Infrastructure (OCI) that does not consider all of these unique factors and take them into account when leveraging OCI's capabilities.
A key component of our "white glove" approach to ISV migration is a combination of our engagement process which brings together architects, business consultants, and specialist engineers to help design your cloud solution along with our use of Cloud Lift Services to work hand-in-hand with you to bring your workload to OCI.
What makes Oracle unique in the ISV space is our willingness and desire to engage one-on-one with customers at the strategic, go-to-market (GTM), architectural, and implementation layers and to pair our experts with yours to jointly meet your requirements in the cloud.