Category Archives: Oracle

All things related to Oracle

On Line Training – API Driven Architecture

15 Friday Feb 2019

Posted by in General, Oracle, Packt, Technology

≈ Leave a comment

Tags

, , , , ,

In January we presented our 1st online training, looking at API Design and use of Apiary and Swagger. Things went well until near the end where for some reason voice and video dropped for no apparent reason. Our coordinator Lindsay kept the recording going and soon as we reconnected I continued the session and went through the Q&A.

So if you missed the end of the end of the training, please do check back with the recording.

If you missed the training – we’ll be rerunning in March – go here.

For those on the training will have seen at the start of the training links to my social media profile, so happy to try respond to any further questions.

We are also scheduled to run the session again in a month or so.

One of the questions received during the session I thought worth mentioning was when would Apiary support Open API 3.0. Well according to their blog very soon, looking forward to it as the OAS 3 does look a little cleaner.

Making Scripts Work with IDCS Deployed PaaS

09 Saturday Feb 2019

Posted by in API Platform CS, APIs & microservices, General, Oracle, Technology

≈ 3 Comments

Tags

, , , , , ,

A while back I made some utilities I developed to help with managing the API Platform. At the time we didn’t have access to an IDCS based environment, so credentials worked using basic auth (I.e. user name and password). But with environments managed by IDCS tokens are used.

As a developer with a Java background I have to admit to liking Groovy over Python for scripting, not to mention for the API Platform groovy is part of the gateway deployment and SDK. Meaning it is readily available in its 2.x form (3.x is relatively recent and aligning to the latest Java idioms). We haven’t tested against Groovy 3.0

Thank you to Andy Knight for sharing with us some Java code which I adapted to be pure Groovy (removing external dependencies for processing JSON). The result is a script that can taken can be taken and worked into other scripts (which is what we have done for our previously provided scripts – Understanding API Deployment State on API Platform, Managing API Policy Versioning in Oracle API Platform, Documenting APIs on the Oracle API Platform). But this script can be used to get a token and display it on the command line or write it to file. Writing tokens to files is generally not good practise, but as a temporary measure when working on developing scripts arguably a managed risk.

The script can be found at https://github.com/mp3monster/API-Platform-Utils/tree/master/getToken and all the details on using the script can obtained by passing -h as a parameter. The important thing is to understand how to obtain the Client ID and Client Secret, the details of which are described at https://docs.oracle.com/en/cloud/paas/api-platform-cloud/apfad/find-your-client-id-and-client-secret.html

Oracle Developer Meetup – London Feb 19

05 Tuesday Feb 2019

Posted by in Dev Meetup, development, General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , ,

Last night was the first Oracle Developer Meetup in London for 2019.  We were very fortunate to have Tomas Langer fly over to talk about the new micro container/framework being developed as an open source solution by Oracle.

Oracle Developer Meet-up - Tomas Langer presenting on Helidon

Tomas, opened by explaining the evolution of the micro-profile being championed by the Eclipse Foundation who are now the guardians of J2EE also known as Jakarta and how the J2EE and Micro-Profile standards compare (in simplistic terms – micro-profile is J2EE stripped back to be simple and support what is typically needed in a microservice world).

The presentation then went onto compare Helidon SE and Helidon MP (micro-profile).  What was really pleasing is that with a couple of exceptions everything that Helidon MP can do, can be done in the SE edition, the difference being that for SE you have to implement more code, rather than the auto-magic of annotations, but in return you have a Reactive Java platform with a development paradigm which relates to JavaScript Express.

In addition to talking about what can be done, Tomas described the kinds of features being developed, this includes:

  • Bringing micro-profile support up to the very latest specification,
  • More reactive persistence technologies support,

With the scene set, Tomas then worked through a series of live code scenarios starting with a clean slate and building Hello World in both the SE & MP models illustrating the differences in approach.  This was then built upon to add the following capabilities:

You can get the complete example which uses Helidon in both configurations from Tomas GitHub.

In addition to Helidon itself on GitHub, there resources provided include rich documentation and examples of each key feature.  Plus a Slack community, that if you contact any of the Helidon team will get you invited allowing you to discuss with the development team how to do things along with other developers using Helidon.

Tomas can be contracted via @Langer_Tomas.  Helidon project also has its own Twitter account – Helidon Project

Helidon itself can be found at:

I have previously blogged on Helidon at Exploring Helidon – Part 1

 

API Caching with the Oracle API Platform

01 Friday Feb 2019

Posted by in API Platform CS, APIs & microservices, General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , , , , , ,

We have been developing some advanced custom API policies for a client and in the process picked up on a few insights that didn’t even make into the API book. One of these policies is to provide an optimization around caching of API calls. The rest of this blog will talk about the tricks we have specifically applied to link an API Gateway to a caching mechanism and why.

Before I go into the details, I’d like to thank the Oracle product management team and particularly Glenn Mi at Oracle for their support getting through the deeper undocumented elements of the capabilities of the API Platform SDK.

Caching Options

Caching comes in may forms, and is motivated by varying reasons and not always the wanting the same behaviours. When getting into the subject of caching it is surprising how polarised people’s view points can be about which cache strategies are correct. The following diagram illustrates the diversity of caches that could appear in an end to solution solution.

Bringing together a caching technology in the Reverse Proxy model and an API Gateway makes a lot of sense. Data being provided to API consumers needs to be protected whether it comes from a cache or an active back-end system. At the same time you also want to exploit an API Gateway to provide analytics on API traffic, so any caching needs to be behind the gateway. But, if In front of an application layer then we can reduce the application workload.

When it comes to caching technology to partner with the gateway, there are a number of options available from Coherence to ehCache, memcache and Redis. We have avoided Coherence, whilst the gateway currently runs on a WebLogic server, we don’t want to need to unduly distort the performance profile and configuration of the Gateway by forcing a cache onto that server. In addition to which as Coherence is a licensed addition to WebLogic it raises difficult questions about licensing when deploying gateways (with gateways licensed based on logical groupings and API volumes but Coherence is licensed by OCPU). We also know that Oracle is moving towards having a micro-gateway which may mean we see the gateway engine moved onto something like Helidon (but this last point is my speculation).

We have elected to use Redis for several reasons –

  • Available as a PaaS service with several cloud providers (AWS & Azure) so no setup or management effort but can also be deployed on-premises,
  • Has an out of the box deployment that means cached entities can have a time to live (TTL) rather than needing to implement separate processes to expire cached values,
  • The ability to make it scale through clustering,
  • Cost

This caching model also allows us to optionally allow application development teams to push into the cache directly results. So rather than waiting on TTL the cache can be refreshed directly or even primed, rather than having to create fake requests to prime a cache.

Custom Policy

Continue reading →

UKOUG Conference 2018

04 Tuesday Dec 2018

Posted by in API Platform CS, APIs & microservices, General, ICS, Oracle, Technology

≈ Leave a comment

Tags

, , , , , ,

With the start of December comes the UK Oracle User Group conference, or to be more precise the Independent UKOUG.  This year the conference is back in Blackpool, a slightly smaller venue than the ICC in Birmingham, but in many respects that made the event feel more vibrant and busy.

The user group also announced some of the changes it is making going forwards reflecting the changing needs of its members – SIGs being largely superseded by multi-stream single day events (Summits) with the Call for Papers for the first of these here.  A wider list of Oracle related Calls for Papers is available here.

Of course being a UKOUG Volunteer, I have been presenting and co-presenting.  The slides from my presentation sessions can be found at:

This was an abridged version of the an update on my presentation here 

My second presentation was a review of Oracle Integration Cloud, in which I presented some customer use cases of OCI  as part of a wider presentation on OIC by Sid Joshi. 

This was followed on the second day with two API based sessions, the first being a deep dive into custom API Policies on the Oracle API Platform.

The final session, was another short one looking at Apiary which was primarily a demo of what the solution can do.

On top of trying to keep up with my usual workload – a very hectic couple of days.

Defining Boundaries for Logical Gateways on the API Platform a multi cloud / multi region context

31 Wednesday Oct 2018

Posted by in API Platform CS, General, Oracle, Technology

≈ 2 Comments

Tags

, , , ,

The Oracle API Platform takes a different licensing model to many platforms, rather than on CPU it works by the use of Logical Gateways and blocks of 25 million successful API calls per month. This means you can have as many actual gateway nodes as you like within a logical group to ensure resilience as you like, essentially how widely you deploy the gateways is more of a maintenance consideration (i.e. more nodes means more gateways to take through a maintenance process from the OS through to the gateway itself).

In our book (here) we described the use of logical gateways (groups of gateway nodes operating together) based on the classic development model, which provides a solid foundation and can leverage the gateway based routing policy very effectively.

logical partitions

But, things get a little trickier if you move into the cloud and elect to distribute the back end services geographically rather than perhaps have a single global instance for the back-end implementation and leverage technologies such as Content Delivery Networks to cache data at the cloud edge and their rapid routing capabilities to offset performance factors.

map1

Classic Global split of geographies

Some of the typical reasons for geographically distributing solutions are …

  • Low hit rate on data meaning caching solutions like CDNs are unlikely to yield performance benefits wanted and considerable additional work is needed to ‘warm’ the cache,
  • Different regions require different back end implementations ordering of products in one part of the world maybe fulfilled using a partner, but in another it is directly satisfied,
  • Data is subject to residency/sovereignty rules – consider China for example. But Germany and India also have special considerations as well.

So our Global splits start to look like:

map2

Global Split now adding extra divisions for India, China, Russia etc

The challenge that comes, is that the regional routing which maybe resolved on the Internet side of things through Geo Routing such as the facilities provided by AWS Route53 and Oracle’s Dyn DNS as a result finding nearest local gateway. However Geo DNS may not be achievable internally (certainly not for AWS), as a result routing to the nearest local back-end needs to be handled by the gateway. Gateway based routing can solve the problem based on logical gateways – so if we logically group gateways regionally then that works. But, this then conflicts with the use of gateway based routing for separation of Development, Test etc.

Routing Options

So, what are the options? Here are a few …

  • Make you Logical divisions both by environment and by region – this is fine if you’re processing very high volumes i.e. hundreds of millions or more so the cost of additional Logical gateways is relatively small it the total budget.

map3

Taking the geo split and applying the traditional layers as well has increased the number of Logical gateways

This problem can be further exacerbated, if you consider many larger organisations are likely to end up with different cloud vendors in the same part of the world for example AWS and Azure, or Oracle and Google. So continuing the segmentation can become an expensive challenge as the following view helps show:

map4

It is possible contract things slightly by only have development and test cloud services where ever your core development center is based. Note that in the previous and next diagrams we’ve removed the region/country specific gateway drivers.

map5

  • Don’t segment based on environment, but only on region – but then how do you control changes in the API configuration so they don’t propagate immediately into production?
  • Keep the existing model but clone APIs for each region – certainly the tooling we’ve shared (Managing API Policy Versioning in Oracle API Platform) makes this possible, but it’s pretty inelegant and error prone as it be easy to forget to clone a change, and the cloning logic needs to be extended to take into account the bits that must be region specific.
  • Assuming you have a DNS address for the target, you could effectively rewrite the resolution of the address by changing its meaning in each gateway node’s host file. Inelegant, but effective if you have automated deployment and configuration of your gateway servers.
  • Header based routing with the region and environment as header attributes. This does require either the client to set the values (not good as you’re revealing to your API consumer traits of the implementation), or you apply custom policies before the header based routing that insert those attributes based on the gateway’s location etc.
  • Build a new type of gateway based routing which allows both the environment (dev, test etc) and location (region) to inform the routing,

Or, and the point of this blog, use gateway based routing and leverage some intelligent DNS naming and how the API Platform works with a little bit of Groovy or a custom Java policy.

Continue reading →

Helidon and the embracing of micro services

24 Wednesday Oct 2018

Posted by in development, General, Oracle, Technology

≈ 2 Comments

Tags

, , , , , , , , , , , , , ,

XEYO9H51_400x400Oracle have announced another Open Source project called Helidon (Helidon.io) as a microservices platform built on top of Netty (which is built around a contemporary async model). If you look at the literature you’ll note two flavours one called SE which aligns to the programming characteristics or Node.js – asynchronous. The other is MP which aligns to the rapidly evolving J2EE MicroProfile which essentially follows a coding style along the lines of J2EE annotations.

Whilst it is perfectly possible to run Helidon based solutions in either profile natively, it is clearly geared up for running in any Docker+Kubernetes style environments such as Oracle Kubernetes Cloud (OKE) or even ACCS. Helidon website provides the means to quickly package your solution into Docker.

In both SE and MP forms the dependencies are hugely stripped back compared to the giants of WebLogic, GlassFish (now EE4J with the handover of J2EE to the Eclipse Foundation.

It does raise a number of questions what are the futures of WebLogic and Oracle support of EE4J (some answers here, but no Oracle specific)? WebLogic has never been the fastest to align to the latest J2EE standards (EE8 standard released last year should be become available sometime this year for WLS – see here), but today it is so central to many Oracle products it isn’t going to disappear, will it just end up slowly ebbing away? Which would be a shame, I have heard it said by Oracle insiders that if the removing the end of one component could be sorted then WebLogic could be easily be configured to have a small lightweight foot print.

The other interesting thing is what is happening to Open Source and what it might mean for the future.  Up until perhaps 3 or 4 years ago the use of open source you would think of software made available on of a small group of key sponsored organisations such as Apache, Linux Foundation, Eclipse which through its governance framework, provided levels of equality and process. As result, levels of quality, trust crucially married to strong level of use and contribution that meant that to extrapolate Linus’ Law – bugs could be weeded out quickly and easily.  However with the advent of services like GitHub, whilst it has become easier to contribute and fulfill Linus’ Law. It also means that it is very easy to offer a solution that is Open Source. But, doesn’t necessarily garner the benefits of Linus’ Law and the other preconceptions we often have about Open Source such as it is/can be as good as a commercial solution. After all, throwing code into GitHub does not guarantee the many eyes/contributors. Nor does it assure the governance, checks and balances that an Apache project for example will assure.

It is important to say that I am not against github, in fact I am very much pro, and use GitHub myself to host utilities I make freely available (here). The important point is we have to be more aware of what open source actually means, in each context and can’t assume it is likely to have a strong community driving things forward, and critically dealing with bugs, and ensuring quality assurance processes are realized.

Helidon joins a number of other offerings in this space such as Micronaut (also built on Netty). Micronaut takes a different approach to Helidon by adopting a strong inversion of control / injection approach. In and in some respects feels a bit like the earlier versions of JBoss Application Server (now known as WildFly) which had a small footprint and made good use of Spring. This is in addition to Spark and Javalin. There is a good illustration of the different servers from Dmitry Kornilov  shown below and the associated article can be seen here (who also happens to the Lead Engineer for Helidon).

helidon_landscape

Unlike Spark, Micronaut and a couple of others, Helidon only supports Java today rather than JDK based languages such as Kotlin and Groovy for example, but is the only solution that can cover both the Micro Profile and Framework domains. It also has a challenge in terms of getting established, Spark has been around since 2015. Javalin appeared in May 2017. The J2EE Micro Profile standard is also driving a lot forward progress, so getting established will continue to get harder. Liberty, another Micro Profile solution is based on IBM WebSphere and Thorntail has links to WildFly (more here). We hope that it will make good headway with a Reactive engine in the form of Netty and avoiding IoC or introspection from the core should mean it will be very quick (particularly during startup) but it needs to show its value differentiation and importantly build a strong community contributing to it.

We hopefully will get the chance to further experiment with Helidon and write more about it here.

ODC Appreciation Day : ODC Podcasts

11 Thursday Oct 2018

Posted by in General, Oracle

≈ Leave a comment

Tags

, , ,

So I’m probably up bending the spirit of the ODC Appreciation Day, as the focus should be on tech. But this year I’d like to flag the podcasts put together by Bob Rhubart. These are as at-least diverse in subject as the Oracle technology portfolio. One month the podcast will be about API and the next AI, from Women in Technology to NoOps. Even if the subject is not an area that maybe of interest to you technically, the podcasts are still worth a listen you’ll encounter at-least one nugget of interesting information.

I have been fortunate enough to participate in the recording of a couple of podcasts. That combined with having In a previous roles been involved in recording and editing audio and video together means I can appreciate the effort that goes into producing the podcast. From gathering a group of different people together, often from around the world into a call isn’t always easy. Then editing the conversation to smooth out the introductions, pauses that can occur as all those non verbal cues are lost, shed any background noise to give a cohesive podcast takes time and practise.

Bob and Javed might make it look easy when recording Periscope videos at Open World and other events, but that comes from being able to control the environment – something you can’t do when participants are so far apart.

Analytics and Stats for APIs

05 Friday Oct 2018

Posted by in API Platform CS, General, Oracle, Technology

≈ 1 Comment

Tags

, , , , , , , ,

NOTE:This utility needs revamping to support IDCS for more see Making Scripts Work with IDCS Deployed PaaS

The Oracle API Platform provides the means to examine statistics and slice and dice the numbers by application, gateway, duration and so on resulting in visually appealing graphical representations.  The way the analytics works means you can book mark specific views, so you can return the same report view with the relevant features as often as you like.  However, presently there is no data export option.

The question why would I want to export the information comes down to several possible use cases, all of which relate to cost management.  The API Platform will eventually have all the desired data views, but now something to help address the following:

  • money-tization, we can see which consumer has been using the services by how much and then send the data to a companies accounting systems to invoice the users
  • Ability to examine demand and workload over time to create a projection of the likely infrastructure – to achieve this the API statistics need to be overlaid with infrastructure and performance details so we can extrapolate API growth against server workload.

To address these kinds of requirements, we have taken advantage of the fact the API Platform has drunk its own Champagne as they say and made many of the analytics querying APIs publicly available.  As with the other API Platform tools, the logic has been written in Groovy, and freely available for use – we’ve covered the code through a Create Common license.

Tool includes a range of parameters to allow the data retrieved into a CSV file having filtered in a number of different ways – which logical gateways to examine, which API or Application(s) to report on.  Finally, just to help some basic stats are produced with a count of logical gateways, API calls, APIs defined and Application definitions. The first three factors inform your cloud costs. Together the stats can help Oracle understand your use case. Note that the parameters which impact the CSV generation can also materially impact the reporting numbers.

Parameters:

The 1st three values must always be provided and in the order shown here

  1. user name to access the source management cloud
  2. password for the source management cloud
  3. The server address without any attributes e.g. https://1.2.3.4

All the following values are optional

  • -h or -help – provides this information
  • -g – Logical gateway to retrieve numbers from e.g. production or development. using ALL with this parameter will result in ALL gateways being examined
  • -f – the file to target the CSV data should be written to. If not set then the default of
  • -t – indicates whether the data provided should be taken from an APPS perspective or from an API view by passing either APPS | API
  • -d – will get script to report more information about what is happening
  • -p – reporting period which is defined by a number as follows:
    • 0 – Last 365 days – data is given as per month
    • 1 – Last 30 days – this is the default if no information is provided – data is given as per day
    • 2 – Last 7 days – data is given as per day
    • 3 – Last day – data is given as per hour

NB – still testing the utility at this moment – will remove this comment once happy