Although Oracle have been late to the cloud party they are certainly making up for it, by bringing products to the cloud at an amazing pace, and using their core products to build out new offerings at a rate that will mean they will at least catch  all the competition across  the breadth of PaaS very quickly.

When it comes to taking on Oracle PaaS  it does have  some quirks, some relate to Oracle’s normal licensing approach, and others I’m told relate to the way US accounting has to work when it comes to realised revenue. A couple of other characteristics I suspect are linked to the fact that the infrastructure for Oracle’s cloud is still being rolled out and grown for capacity.

So firstly the carry over – well outside of a trial account you need to agree and sign a general agreement which provides an overarching legal framework defining terms, conditions and liabilities. This makes dealing with each subsequent purchase a little simpler. Rather than purchasing services as you go, you then purchase credits from Oracle which have a maximum life of 1 year. This does mean you’re not got a pure OPEX spend model – although you do stand a chance of negotiating a better deal as the numbers are naturally bigger. As part of the agreement you’ll get a rate card, so different services cost different amounts – for example a standard edition database will cost x and an enterprise high performance version will cost a bit more. The credits are for specific product families such as SaaS products, products in the PaaS domain for example document cloud, Java cloud, SOA and so on. But make sure the products you might want are in the families you get credits for, there is the odd surprise for example MBaaS isn’t in the same family as the integration products.

In addition your negotiation you need to consider whether  services are in metered or unmetered models.  Unmetered means you agree a level of capacity for the year. This will obviously work out cheaper than a metered model where you can use up your credits as you choose, with different metering rates – for example hourly and monthly. When this was first explained it looked really good for dealing with the situation of having a baseline demand which could be unmetered and then purchasing metered services to capacity burst. Sadly this isn’t possible out of the box. I suspect because of the way Oracle cloud allocates workload to different work domains. So bursting workload would have to be done as if you’re bursting in 2 different clouds. So if you have a dynamic load you either go unmetered to your maximum demand or metered for everything. Either way you’re not getting the best in terms of cost management.  I have to admit I don’t know whether the likes of AWS and Azure when you enter into long term agreements have the same challenges.

One the positive side, with the credits you can then purchase a broad range of configurations of products from just ADB schema all the way a full size  Exadata setup. So performing PoCs is pretty easy and figuring out scaling just means burning your credits quickly and instantiating more capacity.

Before getting into instantiating your cloud instances you’d best  setup access controls to allow people access controls to creating instances. Then you can start creating instances of the products you want. Make sure you protect your credentials as the way things are setup anyone else recovering them will be a problem.

With services such as SOA and Java you do need to go through the process of creating the different layers, storage, then the database and so on. But unlike building on premise each step only requires a couple of clicks and your done. To put it into context the first time I built a small footprint 11g environment took me a couple of days to work my way through on my own create a DB, deploy RCU,Weblogic, SOA and AIA foundation (no load balancing or security etc) and was no way near secure as a cloud instance. Oracle PaaS in three hours we:

• Meet our Customer Success Manager (more on this shortly)
• Got the utilities such as putty installed on my laptop
•  Walked through putty’s key generation quirks and how to avoid the gotchyas
• being walked through the process, of setting up management rights to our credits and instance creation
• Instaniated storage, debated on the DB option to use, created the SOA CS instance with OSB, a load balancer and configured SSH security and web access routes to our cloud. Plus setup my developers
• Had a couple cups of coffee and ordered lunch

With SOA CS and atleast some of the other cloud offerings you also get SSH access to the OS so you can tinker and tune your SOA container and Weblogic etc. Some would argue that totally undermines the ideal of PaaS and that exploiting such a capability means you can end up customising your deployment to the point it will break the moment an update or patch comes along. So it is very double edged. In my mind (but I’m a techie at heart so seeing the engine running is always interesting) it’s good, but must be handled with great care. As they say – with great freedom comes great responsibility.

One of the real wins is that Oracle allocate customers a Cloud Success Manager who are tasked with enabling you to use the Oracle cloud – any problems, guidance needed can be addressed through these people. A cynic might say they exist to help you spend money which becomes released revenue. But our experience is the CSMs are genuinely enthusiastic and helpful  – answering questions at 6pm on a Friday (despite my school boy error).

So in our experience so far I’d suggest Oracle could do two things to really make a big advancement – commercially atleast:

• Allow payments to be made on a reoccurring model as an alternative to the credits model, perhaps this approach restricts you to metered only services
• Allow metered and unmetered services to be utilised together – perhaps as a stretched cluster mentality.

This was first made available at https://community.oracle.com/groups/united-kingdom-user-group/blog/2016/03/25/starting-with-oracles-soa-cs