Category Archives: APIs & microservices

API Gateway Deployment Patterns

14 Tuesday Jan 2020

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

≈ 2 Comments

Tags

, , , , ,

When it comes to deployment of API Gateways, there are a couple of well-known patterns, that of the Internal Gateway and External Gateway (described in several resources including here).

These two deployments essentially reflect the considerations of offering endpoints up to less secure network segments such as the internet (external gateways) and trusted network zones (internal gateways). But in addition to the physical deployment within a network, these deployments are likely to host APIs with different characteristics, reflecting levels of trust, and emphasis on enterprise decoupling/abstraction (internal) –  the reason why APIs are sometimes associated with the idea of SOA 2.0. Compared with security sensitivity, and potentially monetization or at least usage metrics to help protect specific attack vectors.

These deployment patterns can be seen in the following diagram.

B06989_05_04

Both the internal and external gateways are reflective of interest in the origin of the API traffic. However a rarer 3rd pattern does exist.

Outbound Gateway

This pattern of crops up when you need to consider the ability to manage how internal solutions connect to outside services, for reasons such as:

Continue reading →

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).

 

API Security

01 Saturday Jun 2019

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

≈ Leave a comment

Tags

, , , , , ,

I’ve started to subscribe to the APISecurity.io newsletter. The newsletter includes the analysis of recent API based security breaches along with other useful API related news. Some of the details of the breaches make for interesting reading and provide some good examples of what not to do. It is rather surprising how regularly the lack of the application of good practises is, including:

  • Checking the payload is valid to the definition,
  • Checking the payload size to ensure it is in the expected bounds,
  • Use strong typing on the content received it will help validate the content and limit the chances of poisonous content like injected SQL,
  • owaspEnsuring the API has mitigation’s against the classic OWASP Top 10 – SQL Injection, poor authentication implementation.

More broadly, we see that people will recognise the need for applying penetration testing, and look to external organisations to perform the testing, when such work is commissioned the understanding of what the pen tester does is not understood by those logocommissioning the tests (SANS paper of security scoping), therefore know whether all the risks are checked. When you add to that, the temptation to keep such costs down resulting in the service provider not necessarily probing your APIs to the fullest extent. Not all penetration test services are equal, so simply working to a budget isn’t wise, yes there is a need for pragmatism, but only when you understand the cost/risk trade-off.

But also remember application logic and API definitions and the security controls in place change over time as do the discovery of new vulnerabilities on the stack you’re using, along with evolving compliance requirements. All meaning that a penetration test at the initial go-live is not enough and should be an inherent part of an APIs lifecycle.

cloudgs_apimgrWhen it comes to payload checks etc, products like Oracle’s API Platform make it easy to realise or provide out of the box checks for factors such as size limits, implementing payload checks, so better to use them.

If you ever need to be reminded that of why best practises are needed and should be implemented; a mindset of when not if a breach will happen will ensure you’re prepared and the teams are motivated to put the good practises in.

Integrating API Management with the rest of your Development Pipeline

30 Thursday May 2019

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

≈ Leave a comment

Tags

, , , , ,

Oracle API Management keeps API policy configuration and management internalized for a number of reasons including security (after all you don’t want your security rules for APIs out in the open).  The Platform does provide simple versioning.  But you need to able to link the policies to the back end implementations – so the policy configuration is aligned to what is implemented. For example you don’t want the policy to accept parameters that your back end can’t handle in version 1, but does in version 2 of your solution. I have blogged about some of these considerations in the past here.

We have had the good fortune to sit and discuss the challenges of how API configurations could be managed with Flexagon. As a result of our input and from others Flexdeploy has a number of new features making the configuration management of APIs very easy. In addition to this is further simplifying gateway deployment processes. When combined with a very powerful CI/CD that can handle traditional development, microservices and development with integration products such as like SOA Suite and OIC a huge amount of flexibility is made available enabling configuration management, multi environment deployments.

cropped-flexagon_diagram_81816-01-1024x343

Flexagon have started a series of blogs on the subject – recommend checking them out – here.

Oracle Groundbreakers Podcast – Helidon

21 Sunday Apr 2019

Posted by in APIs & microservices, development, General, Helidon, Oracle, Podcasts, Technology

≈ Leave a comment

Tags

, , ,

One of the things I am fortunate enough to get involved with on occasion is the Oracle Groundbreakers Podcast (previously known as the Oracle Developer Podcast) and something I have written about in the past, even as Oracle Developer Community (ODC) Appreciation Day post.

As a result of the recent Meetups on the subject of Helidon that have been occurring recently, we made the suggestion that Helidon is the subject of a Groundbreaker’s Podcast, net result I was invited to be part of the panel.  The podcast was recorded a few weeks ago, and know available (here). Go check it out, as it includes the key contributors to the project Dmitry Kornilov and Tomas Langer.

GBPodcast-image-365

Microservice & APIs Exploiting HTTP Response Codes

16 Tuesday Apr 2019

Posted by in APIs & microservices, General, Technology

≈ Leave a comment

Tags

, , , , , ,

When it comes to the use of micro-services and APIs. It appears pretty common for a few key response codes to be used. However, if you look at the IANA Status Code Registry of defined codes, there a number of other very useful codes that can help convey issues clearly, without compromising security.

The IANA list references the relevant IETF RFCs, but I’ve taken this a step further and obtained the relevant deep hyperlinks to the code explanations. In addition to that, I’ve also highlighted some response codes, that perhaps benefit from a closer look, or considered with caution.

Continue reading →

Image

API Driven Architecture – back by demand

18 Monday Mar 2019

Tags

,

Screenshot 2019-03-18 01.29.11

Posted by | Filed under APIs & microservices, General, Packt, Technology

≈ Leave a comment

Making Scripts Work with IDCS Deployed PaaS

09 Saturday Feb 2019

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

≈ 5 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 be 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 be 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

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 →