In this chapter, there isn’t any code walk-through so there are no technical requirements that need to be downloaded from GitHub. This being the final chapter, you should ensure you have downloaded all previous chapters in case there have been updated resources due to any late-breaking changes while you have been reading.

Understanding API Connect late-breaking changes

In the course of authoring this book, over a period of 5 months, IBM has provided several updates to API Connect for a variety of reasons. We discussed the versioning of API Connect releases in Chapter 2, Introducing API Connect.

A number of them address security and prevent cybercriminals from disrupting your business, but the majority of these updates provide improvements and bug fixes. During the 5 months, we have seen a modification release, two fix pack releases, and one -ifix release. Here is a list of those updates. This book started with version 10.0.1.1:

• Version 10.0.1.1
• Version 10.0.1.2
• Version 10.0.1.2-ifix1
• Version 10.0.2.0 (Continuous Deployment)
• Version 10.0.3.0 (Continuous Deployment)
• Version 10.0.1.5 (rollup of v10.0.2.0 and v10.0.3.0)

Each one of the releases addresses bug fixes and additional product features. Care should be taken when updating to certain releases. In some cases, the releases must be implemented in sequence, and in other cases, they contain cumulative updates. You should refer to the IBM Documentation page, https://www.ibm.com/docs/en/api-connect, anytime a new release is announced to determine whether there are special considerations.

Note

IBM refers to supported versions of API Connect as Long-Term Support (LTS). As new features are developed, IBM releases a Continuous Deployment (CD) version so customers can try out the new features. These CD releases are not supported. v10.0.2.0 and v10.0.3.0 were CD releases but are now included in v10.0.1.5.

You should also pay attention to what’s new. In some cases, there could be updates that improve how configurations are applied. An example is how custom user policies are applied. In version 10.0.1.5, you can now apply the custom policies with the user interface. In previous releases, you needed to install them using the CLI. Also, keep in mind that with any release there are supporting components such as the CLI that require download and re-distribution. This applies to customers using DevOps to build and deploy artifacts using the CLI commands. In version 10.0.1.5, IBM made performance enhancements, as well as a number of other enhancements to improve the developer’s experience.

It is important to have a good understanding of how IBM provides fixes and upgrades. It provides you with the knowledge on how often fixes are released and the choices you have to apply them. You can refer to those upgrades by visiting the What’s new in the latest release section of the IBM documentation: https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=overview-whats-new-in-latest-release-version-10015.

Note: v10.0.1.5 Enhancements

There is a considerable amount of changes released in v10.0.1.5. A few noteworthy updates are vertical and horizontal pod gateway scaling, GraphQL enhancements, and performance enhancements, to name a few.

Given that digital transformation and modernization are taking advantage of cloud capabilities you should be aware of how API Connect is continuing advances towards hybrid cloud and multi-cloud implementations. Having this knowledge will help your organization plan for future strategies for cloud implementations and the approaches that are provided. Having a good understanding of how API Connect merges into a hybrid cloud will be important. You will learn that next.

Understanding API Connect and Hybrid Cloud

In Chapter 2, Introducing API Connect, we discussed the deployment models of API Connect. IBM has placed considerable emphasis on the hybrid cloud and that can’t be any more apparent than its acquisition of Red Hat for $34 billion. IBM’s hybrid cloud strategy and its Watson AI technology are becoming a differentiator in the corporate hybrid architectural strategy and Digital Transformation journey.

To be successful in hybrid cloud, customers will be looking for a common platform and the ability to continue integration with new cloud applications and on-premise systems of record.

Let’s begin with the OpenShift common platform from Red Hat.

OpenShift

Is there a notion of an open hybrid cloud architecture? With containerization and open source Kubernetes, you may believe that there is, but Kubernetes in each cloud provider has its challenges. There are nuances in every implementation and Kubernetes is a huge paradigm shift. Similar to Object-Oriented Programming, there is an associated learning curve that comes with Kubernetes that makes customers cautious.

Consider the challenges your company would face to undertake a Do-it-yourself (DIY) Kubernetes implementation. Here is a short list:

• Building a full DIY Kubernetes stack
• Testing your Kubernetes stack
• Staying abreast of Kubernetes changes
• Patching security CVEs (weekly)
• Troubleshooting Kubernetes stack problems
• Repairing Kubernetes problems

The big question is do you have the expertise in-house? If not, do you increase staff to find qualified resources? Consider the complexities of implementing Kubernetes shown in Figure 16.1:

Figure 16.1 – Complexity of Kubernetes implementation

All of these unplanned complexities warrant looking for something simpler and supporting critical functionality such as security, monitoring, and easy upgrades. This is where Red Hat OpenShift makes sense.

OpenShift is deployable both on cloud and on-premises. Utilizing the OpenShift platform addresses many of the issues identified in this section. Figure 16.2 highlights the difference between what you gain by standardizing on OpenShift versus doing it on your own with Kubernetes:

Figure 16.2 – OpenShift and Kubernetes comparison

As you can see in Figure 16.2, not only is it easier to use Kubernetes under OpenShift but you also get additional critical components for your digital transformation journey such as a web user experience (Web UX) for your administrators and developer tools such as Spring Boot, a built-in capability for DevOps, and container build capabilities such as source to image (S2I).

Wherever you choose to deploy, whether in the cloud, on-premises, or hybrid, having a common platform has its benefits. Figure 16.3 provides a good picture of those choices:

Figure 16.3 – OpenShift on multiple clouds and on-premise

The strategic decision is two-fold. Having a choice of clouds provides your organization the flexibility to change to another cloud because OpenShift is portable in a write once, run anywhere open hybrid cloud platform architecture.

Note

Be careful about cloud platform lock-in. There are cloud platform services that are unique to the provider and are tightly coupled. If you decide to change providers and want to move data and applications to another cloud, you may find the cost of re-coding or vendor-required advanced notice prohibitive. In a DIY implementation, you can easily lock yourself into that cloud platform by adding cloud-specific implementations and/or additional components.

Once you have decided on how you want to approach digital transformation and modernization (whether you decide on OpenShift or not), your next challenge will be integrating all of the new and existing services in a cloud-friendly manner. This is where Cloud Pak for Integration fits nicely, especially if you have on-premise integrations you wish to move up to the cloud. You’ll learn about that in more detail next.