Category Archives: APIs & microservices

Different aspects of APIs and microservices from API Design to utilities to work with API Platform and microservices from mindmasps on design to paradigm concepts

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.

My next Packt Project has been announced!

17 Saturday Nov 2018

Posted by in APIs & microservices, Packt, Technology

≈ 1 Comment

Tags

, , , , ,

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.

Oracle Developer Meetup London – September 2018

18 Tuesday Sep 2018

Posted by in APIs & microservices, Dev Meetup, General, Technology

≈ Leave a comment

Tags

, , , , , , , , , ,

#OracleDevMeetup in London - GraphQL

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:

 

The next meetup is planned for Monday November 19th.  Topics  will be published soon.

 

#OracleDevMeetup in London - GraphQL

Could RedHat’s absolute commitment to OpenShift put them into difficult waters?

26 Thursday Jul 2018

Posted by in APIs & microservices, General, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , ,

As a middleware (to use a fading term) or technical architect, I preferred not to get too involved in the detailed OS layer considerations when it can be helped (my Infrastructure Architect colleagues will always know more about NICs, port bonding, kernel versions etc etc than I ever will) and why I prefer to work with PaaS over IaaS.

But there is an undeniable trend where having a greater understanding of the OS is necessary, this is because we’re seeing PaaS expanding to cover code abstracted solutions such as Oracle’s Integration Cloud, Mulesoft, Dell’s Boomi etc. down to every things as code in the form of Terraform, Kubernetes, Docker and of course  microservices.

So what does this have to do with OpenShift?  Well to apply those heady aspirations we’ve had with middleware of “I can build my solution and run it on my platform anywhere” means in the world of microservices I need to find a common denominator on which I can be portable.  This comes in the form of Kubernetes and Docker and we’ll probably see service meshs in due course (Istio, Linkerd etc). Docker obviously brings the need to understand the OS albeit not at the level of bonding network connections, but still a good level of OS knowledge to do things properly. Over the last couple of years there has been a fair bit of work to achieve this with the inertia of Cloud Native Computing Foundation (CNCF), Open Container Initiative (OCI).

Continue reading →

Implementing Oracle API Platform Cloud Service

31 Thursday May 2018

Posted by in APIs & microservices, Books, General, Packt, Technology

≈ Leave a comment

Tags

, , , , , , , , ,

After months of labour, the arrival of new family members for a couple of the authors the Implementing Oracle API Platform Cloud Service book as finally been published. The book has been included into Packt’s Expert series so, earns(?) the privilege of having photos of the authors on the cover.  The book can be purchased directly from Packt (go here) or from book retails such as Amazon (here).

 

B08683_front-Coverx600

It has been an interesting experience. Whilst working as part of a team of four authors lightened the writing load, a lot more energy went into communication so things were lined up. If you want a challenge, why not read the book and try to work out who wrote which chapters!

Continue reading →

Microservices are not simple

08 Tuesday May 2018

Posted by in APIs & microservices, development, General, Technology

≈ 2 Comments

Tags

, , , , ,

It’s a bit controversial to say ‘Microservices are not simple’ given much is said about using Microservices to simplify and accelerate software delivery. So, how can this statement be made? It is a point actually stated in Chris Richardson’s excellent new book Microservice Patterns (avalable here and here), indirectly in Eric Evan’s Domain Driven Design (here). Martin Fowler in one his blogs says that they come at a premium (here). So, I’m not the first to say this, and wont be the last.

But the assertion that Microservices done right are simpler, and allow rapid delivery and evolution of solutions – a bit of a contradiction. As they say a picture is worth a thousand words, so take a look at this …

Continue reading →

Domain Driven Design

05 Thursday Apr 2018

Posted by in APIs & microservices, General, mindmap, Technology

≈ Leave a comment

Tags

, , ,

I have been wading through Eric Evan’s Domain Driven Design Book. As with many design and architecture focussed books I try to mindmap as I go so I have a quick reference resource. The mindmap for this book can be seen below and is linked to the WiseMap version which is dynamic.

In terms of of a review of the book, it contains lots of nuggets of helpful ideas and information but it is a rather heavy going to read. Some points feel over laboured such as the use of consistent language, at times it feels like half the book is dedicated to this one point. Whilst Chapter 14 – Maintaining Model Integrity sounds unadventurous as a chapter, I found this to have a lot of really helpful content such as going into the details Bounded Contexts and so on which is highly relevant to the world of microservices.

design book.png

Managing API Policy Versioning in Oracle API Platform

27 Tuesday Feb 2018

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

≈ 4 Comments

Tags

, , , , , , , , ,

Oracle’s API Platform (API-P) product avoids the use of external configuration management. If you want to better understand why, then checkout our forthcoming book as it goes into detail about why this is the case (it can be pre-release version of the book can be obtained here). In a previous blog I wrote about and illustrated the use of the API-P’s own APIs so that it was possible to see what API iterations had been deployed to API Gateways.

In this blog I want to explore the issues of version management a bit further. API-P provides internal version management through the idea of iterations as previously explored (Understanding API Deployment State on API Platform). In addition to this there are API policy attributes called version, status etc. This information whilst having some impact on behavior reflects the version of the ‘contract’ that the API represents between the consumer and provider, and requires a manual change.

The API policies themselves are version tracked through the iteration identifiers. Each time a policy is saved the iteration is is incremented. What the API-P doesn’t support is the concept of branching. In relatively simple API Policy branching is unlikely to ever be an issue.

Why is a reversion capability needed?

Let’s take a more complex scenario.  In our book API Platform we introduced the some APIs that would allow the retrieval of meta data about artists in the record companies’ catalog. It has however come to light that the API has been targeted with malicious calls, firstly through trying to attack using injection attacks and secondly trying to overload the back end by creating data requests that make the back-end work hard in retrieving data.

To defend against this, the API Policy has been enhanced to include some custom groovy policies to inspect the values provided. Strictly speaking following the principles of Semantic Versioning the API version should go from 1.0.0 to 1.0.1. However seeing that the ‘contract’ as presented to the consumer hasn’t really changed – the data models are the same, the URI goes unaltered resulting in the implementation team not changing the version.

During development processes, it is not unusual to be developing existing logic, and decide that approach being used isn’t right or not going to perform as well. So you abandon your changes and revert back to the last approved version. However, this isn’t possible as any save will result in a new iteration. The API-P will be getting some enhanced version management features. But today to be able to undo the changes we need a means to ‘revert forward‘ (hence the tool name) that is to take an older iteration and make it the latest, as illustrated in the next diagram.

Today the API-P doesn’t provide a means to perform this process within the User interface. However when looking at a gateway you can review the API policy deployed. As we established previously that you may have different gateways deployed with different iterations. Given this, as API-P has been built true to the principles of separating the UI from the backend through the use of APIs we can deduce there should be a means to get the details of an API with a specific iteration.

To this end we have built on the pattern previously illustrated to provide the means to ‘Revert Forward’ by creating a Groovy script that will use the APIs provided by API-P to retreive an iteration and push it back at the latest version. When the policy is pushed back it also modifies the description to show which iteration has been pushed.

You may ask, why not use the conventional developer approach of branching as suggested in the following diagram. However API-P’s iteration framework doesn’t extend to support this.

The next with this is pretty predictable – how do I know which iteration to revert to. You have two options here, firstly either revert in order so you can see the prior version in turn – which whilst visually good, is not necessarily the most practical option. So in the tool we have a parameter that will allow you to display on the console the configuration of each iteration. This does mean you are going to see the policies in a JSON presentation. To make life easier we would recommend good practise and recording in the policy description information that helps determine the policy’s characteristics – and this can be used to better determine iteration behaviour.

If we are able to take an earlier iteration and make it the latest one by pushing it back then it is a short step to actually target a different management cloud in effect migrating the policies. Whilst possible it comes with some serious cautions …

  • You risk undermining your version management, which management cloud has the master, and the iteration numbers will NOT migrate so it’s not like this info can be used to distinguish the laster version
  • The logic included doesn’t accommodate handling differences in policy versions – so if trying move between instances of the API Platform they need to be the same version otherwise your configuration could make a mess of thing
  • This issue is further compounded if you are deploying custom Java policies.
  • Environment specific policies simply won’t work for example gateway based routing.

Oracle does not recommend that the policies be stored anywhere outside of the platform, whilst it this utility makes that a possibility, it deliberately avoids writing any of the information to the file, the policies only reside outside of the platform for the duration of the process execution.

The Tools Commands

All the parameters assume the values will not contain any space characters. Each command is preceded by a dash eg. revertForward.groovy -inpassword mypass -inSvr https://a.b.com

  • -h or -help – provides this information
  • -inName – user name to access the source management cloud
  • -inPass – password for the source management cloud
  • -inSvr – The server address without any attributes e.g. https://1.2.3.4
  • -policy – numeric identifier for the policy of interest
  • -iter – iteration number of interest for the policy – optional
  • -outName – optional, the target management cloud username, only needed for migrations
  • -outPass – optional, the target management cloud password, only needed for migrations
  • -outSvr – optional, the target management cloud server address – same formatting as inSvr, only needed for migrations
  • -override – optional, if migrating to another management, tells the script to replace the existing policy of the same name if found
  • -view – optional, separate command to allow viewing of the policy – requires one of the following values:
    • display – displays all the details of the policy, if no iteration is provided this will be the latest iteration
    • summary – provides the headline information of the policy including name, change date etc
    • summary-all – summarizes all the iterations from the current one back to the 1st
  • -debug – optional, will get script to report more information about what is happening

The code can be obtained from my GitHub repository here.

Tracing Executions in an API Environment

07 Wednesday Feb 2018

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

≈ 2 Comments

Tags

, , , , , , ,

As APIs become more pervasive within our solutions we see the arrival of not just design and cataloging tools such as Apiary, Apigee and others but also the arrival of gateways. The gateways provide execution of operations including validation, accounting (moneytization), routing, and other controls such as throttled checks that would often not occur until the first contact with a service bus. For example initial routing based on the API call, fine grained authentication and authorisation (differing from your firewalls who will just perhaps authorise).

In the more traditional integration middleware of Oracle Service Bus and SOA (regardless of cloud, on-premises) you can trace the execution through the middleware end to end. This tracing can be achieved because the platform creates and assigns the a UUID (aka eCID) and ensures that it is carried through the middleware. It is this very behaviour that allows Oracle to provide Business Activity Monitoring without any need to be invasive. Burt not only that in a highly distyributed environment you can track the processing of a transaction from end to end.

The challenge now is that the first point of middleware style behaviour can be at the gateway. So we actually need to move forward the UUID or equivalent forward the the first point of contact. Not only that we need to think about the fact we will see non Oracle integration middleware involved.  Within Spring, Kabana and other established frameworks and tools which are getting signficiant traction with the rise of Microservices, the Ids being used are not the same as the UUIDs used by Oracle. For example Spring Cloud Slueth uses the same HTTP header Ids that Zipkin and Kabana support:

  • X-B3-TraceId
  • X-B3-SpanId
  • X-B3-ParentSpanId

More information can be found here and here.

For the new Oracle API Platform Cloud Service we can check for the existance of the header attributes as a policy and apply actions such as:

  • Apply a header with a TraceId or spanId,
  • If a SpanId exists then we may wish to nest our call as a child span by moving the SpandId to the ParentSpanId and creating a new SpanId.

Ultimately it would be more attractive to apply the logic using the API Platform’s SDK but to get things rolling applying the IDs with the API Groovy policy is sufficient (more here).

Next question that begs, is where to put the ID and want to call it? Put the value in the body, and you’re invading the business aspect of an API with execution specific details, not to mention potentially  changing the API definition. Whilst stuffing HTTP(s) headers with custom attributes is often discouraged as the values aren’t to immediately visible. In my opinion at least the answer largely has been set by president for us. If you weren’t using HTTPS but JMS then you would use the header, but also a number of frameworks already exist that do make use of this strategy such as those mentioned above.

Using the header defined by Kabana etc means that the very process will mean that a number of Support tools out of the box will understand and be able to help visualise your logs with no additional effort.

The following is a Groovy script that could ber used for the purposes of applying an Id appropriately into the HTTP header in the API Platform:

if (!context.getApiRequest().getHeaders().containsKey ("baggage-UUID "))
{
  // use current time to seed random generator
  def now = java.time.Instant.now()
  def random = new java.util.Random(now.getEpochSecond())

  // create an array of 16 bytes to hold the random value
  byte[] uid = new byte[16]
  random.nextBytes(uid)

  // convert the random string from Hex to an ASCII string
  Writable uidInHex= uid.encodeHex()
  String uidStr= uidInHex.toString() 

  // set the outbound header
  context.getServiceRequest().setHeader("baggage-UUID", uidStr)
}

API Design

05 Monday Feb 2018

Posted by in API Platform CS, APIs & microservices, Books, General, mindmap

≈ Leave a comment

Tags

, , , ,

When it comes to ensuring I keep up good practises, I try to look at books  in areas I think I have a good handle on such as APIs.  Why?  well it confirms and validates I’m upto date; sometimes another view point can spark ideas on how to make something better, improve an approach or simply understand another way of explaining an idea.  The later is important as the key benefit of knowing something is the opportunity to help someone else. Not everyone communicates or understands ideas in the same so this is always helpful.

Designing Great Web APIsSo recently I ran through James Higginbotham’s Designing Great Web API’s book(let).  Often when goping through a book I mindmap it so that I can share it, and refer to it as a lit of prompts reminders if necessary.  Whilst’s James’ book doesnt  reveal anything new or relevatory for anyone working with APIs it does provide a good succinct explination to  basic practises. So here is the mindmap:

great APIs

You can also access my MapWise view here. James’ book can be obtained freely from O’Reilly here.

The book doesn’t go into the depth of details for practises that Apiary (Pro Edition) offers with style guidelines which will describe morec detailed recommended practises (more here).