Tag Archives: Oracle

Managing API Gateway Costs with Oracle API Platform

03 Wednesday Jul 2019

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

≈ 2 Comments

Tags

, , , , , , ,

The Oracle API Platform adopted an intelligent pricing model by basing costs on API call volumes and Logical gateway node groupings per hour. In our book about the API Platform (more here). We suggested that a good logical grouping would be to reflect the development, test, pre-production and production model. This makes it nice and easy to use gateway based routing to different environments without needing to change the API policy configuration as you promote your solution through environments.

We have also leveraged naming and Role/Group Based Access Controls to make it easy to operate the API Platform as a shared service, rather than each team having its own complete instance. In doing so the number of logical gateways needed is limited (I.e. not logical gateway divisions on per team models needed). Group management is very easy through the leveraging of Oracle’s Identity Cloud Service – which is free for managing users on the Oracle solutions, and also happens to a respected product in its own right.

Most organisations are not conducting development and testing 365 days a year, for 24 hours a day (yes in an ideal world prolonged soak and load tests would be run to help tease out cumulative issues such as memory leaks, but even then it isn’t perpetual). As a result, it would be ideal to not be using logical gateways for part of the day such as outside the typical development day, and weekends.

Whilst out of the out of hours traffic may drop to zero calls and we may even shutdown the gateway nodes, this alone doesn’t effectively reduce the number of logical gateways as the logical gateway aspect of the platform counts as soon as you create the logical group in the management portal. This in itself isn’t a problem as the API Platform drinks it’s own Champagne as the saying goes, and everything in the UI is actually available as a published REST endpoint. Something covered in the book, and in previous blog posts (for example Making Scripts Work with IDCS Deployed PaaS and Analytics and Stats for APIs). Rather than providing all the code, you can see pretty much all the calls necessary in the other utilities published.

Before defining the steps, there are a couple of things to consider. Firstly, the version of the API deployed to a specific logical gateway may not necessarily be the latest version (iteration) and when to delete the logical gateway this information is lost, so before deleting the logical gateway we should record this information to allow us to reinstate the logical gateway later.

As deleting logical gateways will remove the gateway from the system, when recreating the gateway we can use the same name, but the gateway is not guaranteed to get the same Id as before, as a result, we should when rebuilding always discover the Id from the name to be safe.

A logical gateway can not be deleted until all the physical nodes are reallocated, so we need to iterate through the nodes removing them. When it comes to reconnecting the nodes, this is a little more tricky as reconnecting the gateway appears to only be achievable with information known to the gateway node. Therefore the simplest thing is when bringing the node back online we take the information from the gateway-props.json file and run a script that determines whether the management tier knows about the node. If not then just re-run the create, start, join cycle., otherwise just run the start command.

As with the logical gateway, re-running the create, deploy, start cycle will result in the node having a new Id. This does mean that whilst the logical gateway name and even the node names will remain the same, the analytics data is likely to become unavailable, so you may wish to extract the analytics data. But then, for development and test, this data is unlikely to provide much long term value.

So based on this, our sequence for releasing the logical gateway needs to be…

  1. Capture the deployed APIs and the iteration numbers,
  2. Ideally shutdown the gateway node process itself,
  3. Delete all the gateway nodes from the logical gateway,
  4. Delete the logical gateway,

Recover would then be …

  1. Construct the logical gateway,
  2. Redeploy the APIs with the correct iteration numbers to the logical gateway using the recorded information- if no nodes are connected at this stage, the UI will provide a warning
  3. As gateway nodes, come back online, determine if it is necessary to execute the create, start, join or just start

Of course, these processes can be all linked to scheduling such as a cron job and/or server startup and shutdown processes.

Popping Up on the Net and more

28 Friday Jun 2019

Posted by in APIs & microservices, Books, Dev Meetup, development, General, Oracle, Packt, Technology

≈ Leave a comment

Tags

, , , , , ,

It’s been a quiet month for this blog, but I’ve been pretty busy with a raft of other activities…

  • a recent article on our sister site – oracle-integration.cloud on  RPA.
  • I also appear in an interview with K21 Academy here.
  • 4186btedcpl._sx403_bo1204203200_Reviewing a new book on Enterprise API Management for Packt which we would very highly recommend if you want to understand the more Enterprise perspectives of adopting APIs, particularly if you’re considering APIs as a potential new revenue stream.
  • UK Oracle User Group committees for TechFest (having been reviewing the paper submissions it looks like it’s going to be an excellent conference in December) and Southern Summit (next week).
  • Just launched a number of sessions for the Oracle London Developer Meetup, with another to be announced soon (Blockchain) and potentially two more before the end of the year (we’re working on the speakers now).

 

EMEA PaaS Forum 2019 in review

15 Monday Apr 2019

Posted by in General

≈ 1 Comment

Tags

, , , , , , , , , , ,

Image by @motivcx

Image by @motivcx

Another Spring means another excellent Oracle EMEA PaaS Forum for Oracle partners. Every Year Juergen Kress organizes the event, finding really nice venues to host several hundred people over four and half days.

The event is split into several parts,  Monday afternoon normally involves Oracle Ace’s presenting on best practices, insights on applying the various technologies etc.  For me this meant presenting on the London Developer Meetup, looking at how it worked, what has been successful, and what hasn’t.  For those know have read my blogs on the subject (here) will know about our Drone initiative.

Picture by @AmyGrangeX

Then Tuesday is a single stream day where Juergen has managed to pull in SVPs and Senior Product Managers from around the globe to provide a high-level view of what has been going on with their products. For anyone consulting in the Oracle domain, this is incredibly useful. For example, there is a clear strategy coalescing around AI and Machine Learning both as a service proposition to users, but also how these technologies are being made available and used within other products.  Other areas such as OIC and SOA CS have stability and maturity, and the road map is about maximising connectivity with the newer products.

But before the sessions start, Juergen starts with opening remarks, and demos’ something engaging.  In previous years this has been things like Digital Assistants/Chatbots and so on.  This year, we have been fortunate to be an active contributor by demoing the drone through the use of APIs and talking about the ideas.  The dry runs of the demo on Monday went without a problem, but when it came to the main show, the drone was a little uncooperative – we think because the air-con had really kicked in.  But importantly, even not achieving the desired result, the message of engagement made it home.

Wednesday is split into streams with in-depth sessions from the different Product Managers, he amount of insight gained from these sessions is tremendous, some of which is very much protected by safe harbour statements or not for public disclosure such is the honest and open discussions. The day closes with an Ace Director initiative which demonstrates the application of Oracle Cloud products to a plausible use case, and Luis Weir (Capgemini Oracle CTO) is part of. This session has become something of a tradition now.

The day’s business concludes awards, and for a second year the UK Capgemini team have taken home two awards for APIs and PaaS Contribution.

Luis Weir with his API award

The final two days are then a choice of Hackerthon or 1/2 day training sessions on different products with the relevant Product Managers, and an excellent opportunity to pick the brains of the presenters as well as get hands-on experience with the different products.

The week isn’t without it’s social and networking activities of course …

Oracle Developer Meetup – London Feb 19

05 Tuesday Feb 2019

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

≈ 2 Comments

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 micro-service 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 are 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

≈ 4 Comments

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 →

Helidon Live

26 Saturday Jan 2019

Posted by in General, Helidon, Oracle, Technology

≈ Leave a comment

Tags

, , , , ,

The London Oracle Developer Meetup (here) are excited to say that on that we’ll have 2 of the lead engineers with us from the Helidon.io project with us to introduce and demo the new open-source micro container platform. Bring your laptop and code along if you like.

Hope to see you there.

Exploring Helidon – Part 1

01 Tuesday Jan 2019

Posted by in General, Helidon

≈ 4 Comments

Tags

, , ,

So I recently blogged (here) about the announcement of Helidon – the open source project from Oracle to provide a microservice app server that includes optional support for the J2EE Microprofile.

This is the first of what will probably become a series of blogs about Helidon, particularly in its SE form (non J2EE Micro-Profile) as Micro Profile and the wider J2EE model in general will have been documented more widely.

Hello World

Helidon comes with a quick start example app implemented both in SE and MP forms.  It is worth following the very simple instructions provided by the Helidon site to instantiate both versions of the Hello World app as it provides a good way to start to understand the differences in the way Helidon can be used.

The thing that really jumps out when you compare the code (for me at least) is the fact that the SE code being driven from values loading from configuration is more dynamic. The configuration can be sourced in a number of different ways from YAML files to etcd.So for our for first experiment we took the hello World app, and made the path /greet dynamic by loading the path from from some additional configuration. Enhancing the main with :

private static Routing createMultiRouting() {
Map greetingConfig = Config.create().get(“greeting”).asMap();
Routing.Builder routing = Routing.builder();
if (!greetingConfig.isEmpty())
{
greetingConfig.forEach((k,v)->
{
System.out.println (“Read config value>” + k + “=” + v + “<“);
// as the key is the fully qualified name, I just want the last piece,
// so let’s strip it to be a substring
String key = (String)k;
key = key.substring(key.lastIndexOf(“.”)+1);
// each different URI should have its own instance of the Greet Service
// with its tailored key which will mean it responds with the key e.g. France
routing.register(JsonSupport.get())
.register(“/”+v, new GreetService(key));
});
}
else
{
System.out.println(“No config\n”);
}
return routing.build();
}
 

We can create URLs for greetings in different languages, and see the different instances of the Service object responding to the web calls. Whilst many may associate this approach with Node.js for me it felt more like the webserver multiplexer (MUX) such as Gorilla used with Go (you can see what I mean here).

Helidon and On the Road

Two of the leading figures Tomas Langer and Dmitry Kornikov will be presenting at a number of meet-ups in Europe, including the London Meetup (go here)

Part 1?

Yes, I will be blogging more about Helidon as soon as I can, but presently wrapping up a white paper and running an API Design training session soon.

London Oracle Developer Meet-up – November 18

19 Monday Nov 2018

Posted by in development, General

≈ 1 Comment

Tags

, , , , , ,

Another Oracle Developer Meet-up took place in London yesterday. This meet-up focused on Terraform and Microservices. The summary of the evening slides:

Chris Hollies’ slides can be found at here.  As demo’s aren’t included in the deck, the following videos are alternatives:

Our second session, that I presented on how we can establish paths of transition that make it easy to adopt microservices. The presentation material for this is available here:

UK Oracle User Group Annual Conference

01 Thursday Nov 2018

Posted by in General, OUG, Technology

≈ Leave a comment

Tags

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

As we rapidly approach the end of the Year.  We’re still pretty busy.  The UK Oracle User Group Annual Conference covering Oracle Technology (Tech18) ranging from Database on premises to Polyglot development in Oracle and other clouds passing through Hybrid Integration, SOA and so on.  Alongside this is also Apps18 which covers Oracle Applications from EBusiness Suite and Seibel to the Fusion cloud solutions such HCM, Financials, Taleo and so on. Then finally the 3rd part covering all things JDEdwards.

tech18

Being on the committee for the conference means that I have been heavily involved in developing the conference agenda and choosing sessions.  So I can say with great confidence that there is a very diverse range of sessions from highly respected SMEs and presenters along with new blood presenting on subjects from Oracle JET to Robotic Process Automation (RPA) for example.

I hope we’ll see you there.

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

≈ 3 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 …

  • The 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 may be 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 may be 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 the 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 to contract things slightly by only have development and test cloud services where ever your core development centre 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 the 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 →