As the adoption of Oracle Cloud grows, there is increasing demand to bring a variety workloads to run on it. Due to the popularity of the Cloud Foundry application development platform, over the last year, Oracle customers have requested the option of running Cloud Foundry on Oracle Cloud. Reasons include:
Cloud Foundry is a very popular application development platform and many Cloud Foundry developers are using Oracle Cloud for other interrelated projects
Oracle Cloud has a large ecosystem of Platform services that can be used to augment Cloud Foundry applications or, conversely, Cloud Foundry can be used to extend Oracle services in new ways.
Many Cloud Foundry users have significant Oracle workloads that they need to integrate with and more and more Oracle customers are finding it easier and easier to move those workloads to Oracle Cloud. Co-locating Cloud Foundry workloads near those Oracle workloads in the cloud enables them to easily interoperate and integrate.
So what has Oracle done to make this possible?
Over the last several months, Pivotal and Oracle engineering teams have been collaborating to build out several pieces of an integrated solution to run Cloud Foundry on Oracle Cloud.
We started with the BOSH Cloud Provider Interface. This layer of the Cloud Foundry architecture abstracts away the infrastructure provider to the Cloud Foundry application developer. This allows Cloud Foundry to be installed on various cloud providers like AWS, Microsoft Azure, Google Cloud Platform and now Oracle Cloud Infrastructure.
The code for this was just pushed into our GitHub repositories and is being actively worked on by the Oracle team. At this stage, it’s not currently GA, so use it for proof of concepts. You can look at it here
This work has been a great collaboration between Oracle and Pivotal. Over the next few month, our expectation is that this CPI will become regularly tested as part of the standard Cloud Foundry build processes and part of the collection of CPIs available for Cloud Foundry.
Beyond running Cloud Foundry on Oracle Cloud Infrastructure, one of the key technical requirements we’ve heard from developers is the desire to integrate with various Oracle Cloud Services – from Database to WebLogic Server to MySQL.
Cloud Foundry has a natural model for doing this through an interface called a Service Broker. Service brokers enable Cloud Foundry applications to easily interact with services on or off Cloud Foundry. Operations include provisioning and de-provisioning, binding and unbinding, updating instances and catalog management.
The first service broker type is for our Oracle Cloud Platform PaaS services. In this model, by configuring one service broker – hosted on Oracle Cloud - we enable Cloud Foundry to interact with upwards of five different PaaS services including Database Cloud Service, Java Cloud Service, MySQL Cloud Service, DataHub Cloud Service (Cassandra) and Event Hub Cloud Service (Kafka). This is an initial set of cloud services and Oracle will evaluate others based on market demand. The diagram below shows a pictorial diagram of this service broker approach.
The second service broker Oracle has developed is for the Oracle Cloud Infrastructure capabilities—in particular our Oracle Cloud Infrastructure Oracle Database Cloud Service and our Oracle Cloud Infrastructure Object Storage. These are service brokers that can be installed and configured in Cloud Foundry to give direct access to these Oracle Cloud Infrastructure services. The diagram below provides a pictorial diagram of this model.
All of this integration between Cloud Foundry and the Oracle Cloud naturally begs the question around what are the typical deployment topologies that one will typically see this solution used. For an initial overview our expectation is that there will be three types of topologies:
All in Oracle Cloud. The all in Oracle Cloud approach is where both Cloud Foundry and the services it interacts with will be running in the Oracle Cloud – nothing runs on premises. The diagram below brings together the BOSH CPI and the two service brokers to illustrate this.
The second approach is more of a hybrid approach where Cloud Foundry runs off Oracle Cloud - either on premise or potentially on other cloud infrastructures but via the service brokers integrates remotely with Oracle Cloud services. This approach is clearly constrained architecturally by issues such as network latency, but depending on the cloud services, may be a useful topology for some use cases. The diagram below illustrates this in action.
The third approach is an all on-premises approach leveraging a capability Oracle calls Oracle Cloud at Customer. This enables customers to run Oracle Cloud services in their data center. This approach is particularly useful for customers who have data residency concerns, regulatory concerns and even performance/latency concerns when running Cloud Foundry on premises and reaching out to public clouds. Oracle Cloud at Customer includes all the services available via the Oracle PaaS Service Broker running on Oracle Cloud Machine, as well as Oracle Exadata Cloud Machine – all running on premises. The diagram below illustrates this topology in action.
Overall there’s a lot of choice and opportunity here and these three different approaches are really meant to give ideas of how it could be done rather than being prescriptive.
This work is the start of a journey to run Cloud Foundry workloads on and interacting with Oracle Cloud. Watch for more announcements as we move this work forward over the next few months!
Introduction In this tutorial I demonstrate how to connect an app written in Python, Node.js or PHP running in Oracle Cloud...
In this post I’m going to demonstrate how quick and easy one can create an Autonomous Transaction Processing, short ATP, instance of...