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.
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 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,
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.
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.
My next Packt project (via O’Reilly) is not a book, but a short online training course about good API design, API 1st and some tools that can support an API 1st methodologies. Register for the session here.
It includes a closer look at cloud tools such as Oracle’s excellent Apiary (sorry if this sounds like a sales pitch, but it is a good tool and the words of the found of RestLet confirm this) along with SwaggerHub and a few other options.
A good API goes beyond just the payload definition and I’ll walk through the other considerations and explain why these other areas are important.
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.
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.
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:
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.
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.
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:
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.
- 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.
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.
The 1st three values must always be provided and in the order shown here
- user name to access the source management cloud
- password for the source management cloud
- The server address without any attributes e.g. https://188.8.131.52
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
Last night we ran the latest of the Oracle Developer Meetups in London. This time Luis Weir presented on GraphQL, which got an very engaged discussion about the strengths and weaknesses of GraphQL, in-depth points about how the error paths should be handled among many other things.
The presentation material Luis used is based upon his Devoxx session earlier this year and can be seen here:
The links to Luis’ examples can be found on his GitHub account – https://github.com/luisw19/graphql-samples
After a insightful and thought provoking presentation on GraphQL the Drones with APIs project had its latest update. Providing a lot of laughter to the evening’s proceedings. Including demonstration of flying the drone using REST APIs published via a gateway and Go back-end. This included the DroneDash presenting a visual presentation of the commands being issues via REST, as seen here:
All the code, API definitions and documentation for people to add or extend can be found in the meetup’s GITHub – https://github.com/oracledeveloperslondon/.
A few of the useful links used or mentioned last night are:
- Apollo Express
- GraphiQL – GraphQL Design Tool
- Cheerios Library for screen scraping
- Oracle JET toolkit
- Luis’ GraphQL Samples
- GitHub repository with all the drone resources
- API Documentation for the Drone, and the Drone Dash
- Request Bin (capture and display HTTP requests) https://requestbin.fullcontact.com/
The next meetup is planned for Monday November 19th. Topics will be published soon.