If you have customers around the world you might want to serve them from a global APIp footprint such that they can call the API from a location closest to them reducing latency.

In this example I'm deploying my APIs to the 6 current regions of the API Connect Multi-tenant SaaS service on AWS. At the time of writing these are N. Virginia, Frankfurt, London, Sydney, and Mumbai. I will use N. Virginia as the initial source location.

Automatically Deploy APIs and Products to all locations

Create a pipeline that deploys APIs and products to all regions - you could base this around the sample github action available or build it using the example CLI scripts. This then will enable me to

Create an API Connect instance in each region

Create an API Connect instance in each of the regions you want to deploy to. You can use the same image as your source location, but make sure to specify a different hostname for each instance. Each paid subscription for API Connect SaaS includes up to 3 instances which can be distributed as you wish across the available regions.

Configure the portal for the source location

In my simple example I opted to use the new Consumer Catalog as I don't need to configure any custom branding or anything like that. However I did enable approval flows for sign ups so that I can manage who has access to my APIs and products.

Configure ConfigSync to push configuration changes to all regions

As config sync runs from a source to a target region, you need to run it for each target region in turn. In my case this is done with a loop through the hostnames and a lookup for the appropriate API Key to use for each region.

The script I'm using looks like this:

#!/bin/bash

# US East is always the source catalog
export SOURCE_ORG=ibm
export SOURCE_CATALOG=production
export SOURCE_REALM=provider/default-idp-2
export SOURCE_TOOLKIT_CREDENTIALS_CLIENTID=599b7aef-8841-4ee2-88a0-84d49c4d6ff2
export SOURCE_TOOLKIT_CREDENTIALS_CLIENTSECRET=0ea28423-e73b-47d4-b40e-ddb45c48bb0c

export SOURCE_MGMT_SERVER=https://platform-api.us-east-a.apiconnect.automation.ibm.com/api
export SOURCE_ADMIN_APIKEY=$(grep 'us-east-a\:' ~/.apikeys.cfg | awk '{print $2}')


# Set common properties for all targets - in SaaS the toolkit credentials are common across regions.
export TARGET_ORG=ibm
export TARGET_CATALOG=production
export TARGET_REALM=provider/default-idp-2
export TARGET_TOOLKIT_CREDENTIALS_CLIENTID=599b7aef-8841-4ee2-88a0-84d49c4d6ff2
export TARGET_TOOLKIT_CREDENTIALS_CLIENTSECRET=0ea28423-e73b-47d4-b40e-ddb45c48bb0c

# Loop through the other regions to use as sync targets
stacklist="eu-west-a eu-central-a ap-south-a ap-southeast-a ap-southeast-b"
for stack in $stacklist 
do
    export TARGET_MGMT_SERVER=https://platform-api.$stack.apiconnect.automation.ibm.com/api
    export TARGET_ADMIN_APIKEY=$(grep "$stack\:" ~/.apikeys.cfg | awk '{print $2}')
    ./apic-configsync
done

For handling the API Keys for each region I have a file ~/.apikeys.cfg in which each line contains a pair of values in the form region: apikey

Verify that everything works as expected

• In the source region, register a consumer org in the portal and subscribe to a product that contains an API to use.
• Use the "Try now" section to invoke the API
• Ensure the configsync job has had time to complete successfully for each region
• Call the same API across the other regions to validate that everything is working as expected.

Possible next steps

• Configure global load balancing to route customers to the closest location automatically.
• Configure each location to use local replicas of backend applications through catalog properties

Last week I had the opportunity to attend the three-day Product Academy for Teams course at the IBM Silicon Valley Lab in San Jose.

This brought together members of our team from across different disciplines - design, product management, user research, and engineering. It was fantastic to spend time face to face with other members of the team that we usually only work with remotely and to all go through the education together learning from each others approaches and ideas. The API Connect team attendees were split into three smaller teams to work on separate items and each was joined by a facilitator to help us work through the exercises.

We spent time together learning about the different phases of the product development lifecycle and in each looking at the process some of the best practices and ways to apply them to our product. It was particularly effective to use real examples from our roadmap in the exercises so we could collaboratively apply the new approaches and see how they apply directly to our product plan.

Each day of the course looked at a different phase of the product development lifecycle - Discovery, Delivery and Launch & Scale:

Discovery - Are we building the right product? - looking at and assessing opportunities and possible solutions we could offer for them, using evidence to build confidence and reviewing the impact this would have on our North Star Metric.

Delivery - Are we building it right? - ensuring we have a clear understanding of the outcomes we're looking for, how we can achieve them and how we can measure success.

Launch & Scale - Are customers getting value? - ensuring we enable customers to be successful in their use of the product and that we are able to get feedback and data to measure this and improve.

Each of these phases has an iterative approach to it and we looked at how we could apply these to our product plan. We also looked at some of the tools and techniques that can be used to help us apply this and members from the different product teams attending shared how they are using these today.

On the final day of the course I also had the opportunity to share some of our journey with instrumentation, how this has evolved and some of the lessons we learnt along the way - such as the benefits of having a data scientist on the team. I am looking forward to sharing this with the wider team and seeing how we apply some of the learning to improve our systems going forward. For example, better validation of decisions through measuring and improving our use of data.