Oracle Cloud is growing and maturing at a tremendous rate if the breadth of PaaS capabilities is any indication. However, there are a few gotchas out there, that can cause some headaches if they get you. These typically relate to processes that impact across different functional areas. A common middleware stack (API CS, SOA CS, OIC etc) will look something like the following:
As the diagram shows when you build the cloud services, the layers get configured with credentials to the lower layers needed (although Oracle have in the pipeline the Oracle managed version of many services where this is probably going to be hidden from us). Continue reading
I’ve just come to the end of a very busy 25 hours at the UK Oracle User Group (UKOUG) Conference in Birmingham. Four presentations – interestingly the same subject area, that of Oracle Integration Cloud (OIC) / Integration Cloud Service (ICS) started and ended the day. Between this we also covered some approaches to start working towards Microservices in a Monolith World and Oracle Messaging Cloud.
Below are the presentations on the Microservices and ICS/OIC. The piece on Oracle Messaging Cloud was largely demo based, so rather than sharing the presentation slides, which won’t tell you too much. The best way to find out about this is to read the 2 articles about the capability in the OraWorld magazine (issues 6 & 7). With issue 7 perfectly timed by becoming available in the last couple of days.
With the Oracle Messaging Cloud article, there is one word of caution. When the article was written and submitted I used a free cloud service (which using contemporary terminology we’d describe as Serverless) called WebScript.io. The WebScript piece served to make it easy to consume the webservice calls illustrating the PushListener feature. This service however is being closed down – a shame as it was an elegantly simple solution. Given this I am currently working on a blog post which will show how another services can take the place of WebScript.io; whilst not finalised, this maybe Google Cloud Functions.
If this wasn’t enough we also squeezed in the keynote presentations, a meeting with several other contributors to OMESA (Open Modern Enterprise Software Architecture) , a lunch conversation with our Publisher (Packt) and several other Oracle book authors, Oracle Ace dinner (great food with a lot of brilliant & friendly people), some very valuable incidental conversations and some work for a customer.
Microservices in a Monolith World
Look at Oracle Integration Cloud – its relationship to ICS. Customer use Cases an Insight into why ICS
My presentation for UKOUG Tech 16 can be seen by following the link – Introduction to SOA CS. or see below It was a tremendous 4 days (if you include the Tech stream’s Super Sunday). If you are a UKOUG member and didn’t make it to the conference I’d look out for the material to be become available.
Whilst I’m not a big Apex fan (stitching business logic into the persistence layer feels wrong to a middleware person), i did attend the keynote session which covered Apex’s history and future direction, and there are some very exiciting things coming and if everything materialises as I understand it then some big steps to getting developers engaged with Oracle cloud offerings.
Oracle has done a lot of work on the middleware layer with apps container (using common Docker configurations without needing to worry about Docker), Kafka, Node.js and others to engage developers and provide the means to offer a polyglot microservices platform that is not just attractive to the traditional Oracle customer base but also those wanting the middle ground of supported open source. What Oracle are missing is the means to get developers trying the technology and being creative with it. Amazon and Red Hat have got this by offering limited footprints for a long time. Oracle offer 30 day trials which is fine to do a project sponsored PoC. But to hook grass roots users you need a lengthy period where people in spare time can built some cool/geeky solutions.
Now this maybe down to the fact that Oracle cloud is built on their Exa machines with clever on silicon security features, and Oracle can’t manufacture it quick enough. Whereas other cloud providers work with largely commodity components. But if they want to challenge Amazon as Ellison says they need to change this.
The background to this post, and the OTN Appreciation Day can be seen at Oracle-Base.
Oracle Messaging Cloud Service (OMCS) is I think an overlooked gem of Oracle iPaaS portfolio. I say this as it offers a JMS 1.1 compliant Java library but at the same time provides a means through which integration through REST APIs can be performed. This means it is possible to pretty transparently connect legacy JMS based integrations with new REST based products. The magic sauce (and therefore my favourite feature) is the concept of the Push Listener. Through the REST API it is possible to register a REST URL as a target for queues and topics to have messages sent to. Once registered when a message appears on the queue or topic it will get passed on as a REST call. Whilst is is possible to do with with a little bit of Java code. the Push Listener simplifies the job to a REST call with a bit of XML configuration.
There is one small challenge that makes the integration completely transparent to the recipient of the PushListener today, and that is it currently demands that authentication process take place on initial contact. This is not a complicated or challenging thing to address, but does require a tiny bit of code to address.
So no new blog entries as I have been busy publishing elsewhere, with the Oracle User Group we appear in the latest edition of the Oracle Scene Journal:
We also have a submission in for the November edition, which will be published before the user group’s Tech 16 conference – which I will be presenting at.
We have been posting a lot on our website that supports the book – oracle-integration.cloud. Lots of useful references to supporting resources, and some blog posts providing supporting information (and more in the pipeline). Not to mention with pressing on with the last couple of chapters.
Then finally a webinar, the first in a series for the UKOUG about adopting cloud – details at – http://www.ukoug.org/events/ukoug-applications-journey-to-cloud-webinar-1/. The webinar was recorded and the presentation that went with it are accessible if you are a UKOUG member.
We have taken our book on ICS into Packt Publishing’s Alpha programme so that if you order the book now – you can see the chapters as soon as they have received editorial approval and the complete final book will be made available to you as soon as we’re have addressed all the feedback, made any final improvements we have identified once we have completed the book’s draft.
The book can be found on the Packt website – here
Details about the Authors from Packt can be seen at:
- Phil Wilkins
- Robert van Mölken
When you’re using SOA Suite to run round the clock services you need to give a fair bit of thought to your deployment configuration so it becomes possible to perform rolling patches and other maintenance tasks not only to SOA itself but all the way down to the hardware – and at the low levels you have no control on the maintenance process. Although it is very easy to think that the moment you’re using PaaS that these problems are taken care for you, life isn’t as simple as that.
Oracle cloud services typically go through a patching process once a month and usually within a defined 8 hour period on a Friday night. During this period you may lose the use of your servers as the maintenance is performed within a particular availability zone. In an ideal world this would be a rolling process so you don’t lose everything at once. If the maintenance window is used to to deploy SOA Suite patches then although you will be told of the maintenance window you actually wont have an outage, but post the maintenance window your cloud dashboard will have the option to apply the patches at a time that best suits you. Not only that the patch application process is smart enough to apply it in a rolling manner as the Weblogic nodes in the cluster will have information on each other which the patch mechanism can utilise.
So where is the problem. It is very easy to forget that the PaaS platform is virtual, this means the virtualization platform being software will inevitably need patching whether that is for bug fixing, addressing security requirements or adding new capabilities. These kinds of changes today will trigger a service shutdown. Let’s be honest when trying to balance a rolling change and maximise PaaS client density is going to create a monumentally complex problem, so simplicity and and speed of roll-out suggests a small outage is easier. So how do I therefore assure I can maintain a quality of service if I accept this as a necessity?
Well the answer is pretty much the same as an on premise reference architecture. Have SOA with its supporting databases running in a second availability zone that will have a different patch time. This is going to push up the cost as you’ll need a database with Dataguard. Assuming an active-passive model across your centres, as you approach the maintenance window you’ll get your load balancer to route work load to the second location and let the existing workload run dry on the servers due to go through the maintenance process. Then after the maintenance window you’ll reverse the process.
The current gotchya with this is that you pay for SOA by the month so you in effect have to run two clusters, although hour and daily models are coming.With the hourly model you can have the second availability zone ready for use by keeping the DB alive there, but only startup the SOA instances on the hourly rate when you know the maintenance window is going to occur and it is clear there will be an infrastructure impact.
The other sticky point, is presently as the period allocated is upto eight hours, your second centre needs to be running in a timezone with atleast 8 hours difference (allowing time to fail back). This would mean if you are using the Amsterdam or Slough locations your second location is going to West coast US or Asia Pacific once live later this year or Japan. All of which will present serious issues regarding personal data.
I have been told that some signficiant customers have accepted the situation on the basis the downtime in reality isn’t frequent and correlates to low business periods. But I suspect competition and customer demand will force this to change.