We are pleased to announce the availability today of a major new whitepaper discussing how to successfully deploy API Connect in a wide range of topologies. The paper provides an extensive reference that answers many of the questions we are asked by customers as they grow their API Connect usage from simple development scenarios through their testing and validation phases and into complex production deployments with significant availability and resilience requirements.

Download the API Connect v5 Deployment Whitepaper now!

In the whitepaper we describe each of the major deployment components (shown in the diagram below) and deep dive into the key factors that affect the way that you size and deploy those components, and embed them into your wider infrastructure.

We also highlight the thought process that you might follow in determining the availability requirements for your deployment and outline the commonly observed deployment patterns such as multi-site deployments like that shown below. The paper talks largely about on-premises deployments that are managed by you – the customer – but also discusses the equivalent relevant aspects as they apply to Bluemix Dedicated.

We hope that you find this new whitepaper useful in your understanding and deployment of API Connect, and we look forward to hearing your comments!

Download the API Connect v5 Deployment Whitepaper now!

11 comments on"Now available – new whitepaper on API Connect deployment!"

  1. Hi Matt,

    Great article, this is something all APIConnect customer would love to have.
    Do you also have some information regarding APIC catalogue setup, which would be useful for our reference.

  2. Davi Cunha June 27, 2017

    Brilliant work! It is really useful not only from a deployment and architecture perspective, but it address complex capabilities such as Global and Multi-Region deployments, devops integration, handling analytics repositories, etc. You highlight features that are very unique in our solution. It’s much more than a deployment whitepaper!

    • Matt Roberts June 28, 2017

      Thanks for your comments Davi – I’m pleased the paper will be useful for you and our customers!
      Regards, Matt.

  3. LeonardoCosta June 29, 2017

    This is an excellent collateral, must-share for customers. Thanks for bringing it up.

  4. Sebastián Blanes July 17, 2017

    Great, great doc. Matt!!!

    Please update document with Docker/Linux gateway deployments. Ephemeral gateways doesn’t fit too well with CMC/API Manager and customers looking for elasticity need advice on how to deal with those scenarios

    • Matt Roberts July 17, 2017

      thanks Sebastian – I’m pleased you like it!

      I’ve passed your request for updates around the Docker/Linux gateway deployments on to the members of our team who handle those area for them to consider for the future.

      Best regards,


  5. Sebastián Blanes July 17, 2017

    Fig.12 show an even number of portal nodes. Is that right? I thought you must have always an odd number in all scenarios (both region available or only one region available)

    • Matt Roberts July 17, 2017

      Hi Sebastian,

      You are correct that originally the guidance was for an odd/different number of Portal nodes in each site due to the quorum mechanism used by the underlying Drupal database, however it is now possible to achieve the same failover behaviour using equal numbers of nodes by setting a weighting to each node – see the last paragraph of section 5.5.1 on page 38 for a pointer to more details.

      Best regards,


  6. Anshul Rastogi June 25, 2018

    Hi Matt,
    This is Great. I am working on ongoing API evaluation and working closely with IBM Sales & Tech folks. Please share if a similar study is available for new version v2018. Also, if we can leverage any calculation for sizing based on our requirements of API load, regional deployments, HA , DR, capacity, disk etc.
    I am still reading and again this is super-good.

Join The Discussion

Your email address will not be published. Required fields are marked *