cloud-stack_CloudStack-cloud-270When ICS was launched it delivered on of the values of PaaS namely you didn’t need to worry about setting up storage, database and compute, it was all sorted out for you. Admittedly it come with a lack of elasticity when it came to resilience and scaling. In contrast Services such as SOA CS which required you to go through each of the layers, but gave you a degree of flexibility. The whilst simpler than building SOA on-premises it still represents a laborious and fiddly process that took time.

When OIC (Oracle Integration Cloud) arrived and the introduction Universal Credits we had a pricing model that made it a lot easier to be elastic in terms of approach to resourcing, but a deployment model that following SOA CS rather than ICS. To an extend, one step forward, and another back.

Fortunately we are seeing head way that means we have recovered that backward step. This recovery comes in the form of Oracle Cloud Stack (CSM for short and sometimes referred to as PSM or PaaS Stack Manager). I’m not sure that Cloud Stack has garnered the attention it perhaps deserves. So let’s quickly look at what it does. In simple terms it provides an environment build automation capability. Cloud Stack takes a YAML (Yet Another Markup Language – rather appropriate name given the broad range of notations we find for describing Oracle product configuration) and uses it to then build an environment. The great thing about it is that you provide all the configuration (or script it) and describe the component dependency chain. The dependency chain ultimately forms part of the YAML file, but Cloud Stack includes a web interface which means configuration including defining dependencies can be done visually (as illustrated). For example a database is needed for JCS to support ADF, so you can create additional storage, then define the DB followed by JCS itself. The YAML file can accommodate the description of dependencies so it can create each component in the order needed. The composition of components in the YAML file are considered to be a Stack – hence the name.

The nice thing is that this approach allows a couple of intriguing possibilities …

  • A stack can incorporate a range of technologies, so for example it can establish not only a complete JCS setup but also build other solutions. So if you’re solution required ACCS and IOT you can configure it all within a single Stack.
  • The stack capabilities can be executed from locations outside of the Oracle cloud through the use of a Command Line Interface or its own REST API. This means it is possible to include the Stack into a multi cloud build tooling such as a Vagrant can be easily achieved
  • As there are basic scripting capabilities included using features from Project Fn it becomes possible dynamically configure the cloud solutions, the following sample show a resource being configured based on some variables:


type: xyz


dbEnabled: {“Fn::Equals“:[{“Fn::GetParam”:”dbVersion”},”12.2″]}

cacheEnabled: {“Fn::GreaterThan“:[{“Fn::GetParam”:”cacheSize”},”0″]}

backupEnabled: {“Fn::Not“:[{“Fn::Equals“:[

With these functions it becomes possible to use the Cloud Stack to drive scale up and scale down e.g. apply logic to retrieve from existing servers details so that a node is included in an existing cluster for example.

  • with conditionality also comes parameterisation so that instances of the same combination of Services can be created but varying in size, so smaller versions of a production setup can be created as testing environments.

Oracle provides templates – predefined Cloud Stack YAML files so, standardised footprints as we used to have ICS can be created with minimal effort. Examples include IOC, IoT and a few others, but we can assume overtime we will see all the Oracle PaaS products have standard build footprints that can be used as a reference or point for customisation. As you can see from the following lifecycle diagram copying or cloning exist configurations is a common part of the lifecycle.

Cloud stack can be accessed from different parts of the UI has shown here:

In addition to creating instances of cloud services CSM also provides some other basic controls such as starting and stopping the entire stack. These kinds of services are always going to be limited as when it comes to an entire stack you’re going to be restricted by a lowest common denominator of capabilities.

Little Niggles …

The only slight criticism, is to use to use cloud stack you need to manually configure some storage capacity to hold the YAML files. We can hope that in due course someone will twig the irony of this, and will incorporate an option when you access the Cloud Stack UI that it recognises you haven’t got some initial storage and it will allocate you a small footprint to store the YAML resources automatically, it isn’t like you’re going to use GB or TB of storage.

CSM doesn’t yet fully support all PaaS Services, but it is only a matter of time before everything is available as the updates being provided are coming quickly and when you consider that the underpinning of how CSM works is largely the same as the same WebServices that are used to create the cloud services as a result of interacting with the UI.

Find Out More


I’d like to thank Simon Haslam for confirming a couple of details around the use of Cloud Stack.