Modern Application Development With Kong Konnect Enterprise and Red Hat OpenShift

This is a guest post by Kong.

Scenario

Microservices have become an architectural approach to building applications for companies to achieve agility, faster time to market for new products, and reduce their development costs.

On the other hand, companies have existing monolithic, SOAP-based critical applications that need to be modernized and broken down using microservice architecture for the company to compete in the digital world.

Several perspectives should be weighed for this modernization process:

• The actual Monolith-to-Microservices transitioning is not an overnight process, so it is reasonable to imagine that a diverse environment with both monolith and microservices will exist for a considerable period of time.
• Hybrid deployment: It is part of the modernization process, the ability to manage multiple runtimes at the same time. That is, a single application would be running in a hybrid and distributed environment including VMs, containers, orchestrators, Cloud, and MultiCloud.
• APIs: The exposure of the microservices should be API based, and their respective consumption should be controlled. An API Gateway, sitting in front of the services and microservices, would be responsible for both activities.
• Modern microservice development and implementation should focus on business logic only, offloading critical and complex processing like caching, rate limiting, authentication and authorization, log processing to other components of the enterprise architecture.
• DevOps and APIOps: Each microservice should be built and deployed independently, so it is  very critical to embrace DevOps practices and make constant iteration (CI) and delivery (CD). At the same time, APIOps should be considered, so the CI/CD pipelines would be applied to control not just the Microservices but the APIs life cycle as well.

In summary, to be able to develop new microservices and modernize their applications, companies should consider reference architectures to support the process. The good news is that both Kong and Red Hat provide flexible products to help address this issue.

Reference Architecture

The diagram below illustrates a Reference Architecture to support the Monolith-to-Microservice modernization process, as well as to implement new and advanced use cases related to security, microservices communication, legacy systems integration, and others.

1: Monolith-to-Microservice Modernization Process

The architecture supports the long-term modernization journey, where the Monolith-to-Microservice process handles the development of the new microservices as existing services are being phased out.

As the new microservice platforms, the diagram presents three options:

• Red Hat Enterprise Linux, for regular Operating System deployments.
• OpenShift, which is the preferred platform to run new microservices, supporting continuous integration with enterprise orchestration through Kubernetes.
• OpenShift Service Mesh, to implement Service Meshes, the natural evolution of Microservices.

2: RESTful APIs

To support the application modernization process, the architecture should include new components. The first one is Kong Konnect Gateway sitting in front of the existing service infrastructure and new microservices runtimes to expose them and control their consumption.

Kong Konnect Gateway deployment defines two layers:

• Control Plane: responsible for admin tasks. Deployed, for example, as Docker Containers in a RHEL server, the control plane provides capabilities to define APIs and policies like authentication, rate limiting, and caching.
• Data Plane: responsible for exposing the existing services through the RESTful APIs and controlling the exposure with the Policies defined in the Control Plane.

3: Enterprise Policies

Kong Konnect Enterprise provides an extensive list of extensions (called plug-ins) to implement typical policies at the API Gateway layer to protect services and microservices deployed behind it.

The list includes plug-ins for:

• Authentication: Basic, API Key, LDAP, mTLS, OAuth/OIDC, and others
• Security: CORS, IP Restriction lists, OPA (Open Policy Agent) to implement authorization policies, and others.
• Traffic Control: Canary Release, caching, rate limiting, and others.
• Analytics and monitoring
• Transformation: gRPC-REST, REST-to-GraphQL, REST-to-Kafka, request and response transformation, and others.
• Logging: Data stream, file log, StatsD, and others.

The diagram is exploring the main services like rate limiting and caching

4: Enterprise Security Services

The next component in the diagram is Red Hat SSO. It is responsible for implementing enterprise class and advanced authentication and authorization mechanisms such as:

• OIDC- based authentication processes
• MFA (Multi-Factor Authentication)
• Multiple user databases like LDAP, MS Active Directory, and Kerberos.

Kong provides a specific plug-in to implement OIDC flows with a close relationship between Kong Konnect data planes and Red Hat SSO.

5: Legacy Systems Integration

Despite the Microservice modernization process, the new architecture should still support legacy system integration. Red Hat Fuse provides an extensive list of connectors to integrate with the existing collection of systems including ERPs and CRMs.

At the same time, Kong Konnect Enterprise can also be used to control the exposure of those systems being managed by Red Hat Fuse.

6: Event Streaming Platform - Asynchronous Microservice Communication

The next two topics will discuss microservice communication models:

• Asynchronous: Microservices push events into an event collector that is  being consumed by other microservices.
• Service-to-service: Microservices directly consume and invoke other microservices.

Red Hat AMQ, based on Apache Kafka, is an event streaming platform for asynchronous service and microservices communication. Microservices, using systems like Red Hat AMQ, create events into a log collector/queue that will be asynchronously processed by other microservices whenever it decides to poll or listen for new events.

Even if some microservices are currently down for a long time, those events will nott be lost, and the data will be eventually consistent across the system as soon as the microservice goes online again.

Again, just like we have for Red Hat Fuse, Kong Konnect Enterprise can also be used to expose the event streaming platform for external consumers.

7: Service Mesh - Service-to-Service Communication

Red Hat Service Mesh implements this emerging architecture pattern for service-to-service communication. It addresses the typical communication requirements in a microservices-based application, including encrypted tunnels, health checks, circuit breakers, load balancing, and traffic permission. Leaving the microservices to address these requirements leads to an expensive and time-consuming development process.

8: Serverless

Serverless is an architecture that generally adheres to the following characteristics: no servers, virtual machines, or containers to manage. What makes something serverless is the fact that servers used for the processing are irrelevant and ephemeral, created on-demand.

Red Hat OpenShift Serverless is based on Knative, which extends Kubernetes to provide a set of components for deploying and running applications using the serverless methodology.

Modern Microservice Implementation - Multiregion and Multicloud

As the microservice modernization project progresses, naturally we will l have to manage three types of connections:

1. Edge Connectivity: That is  the traffic we receive from external consumers. This connectivity is implemented and controlled by Kong Konnect Gateway.
2. Cross-App Connectivity: Applications will talk to each other, so it is important to control this communication also. Another instance of Konnect Gateway is deployed to control it with specific and application-oriented policies.
3. In-App Connectivity: That is  where the service-to-service connectivity, implemented by the service mesh, is.

Taking a step forward in our hybrid and distributed deployment, a given application, implemented in a single logical service mesh, might have microservices running on totally different environments. For example, the diagram below shows a Distributed Canary Release running on three Kubernetes instances: one Amazon EKS cluster and two OpenShift clusters running on different regions of the same cloud or even different clouds.

That topology is particularly interesting for scenarios where we want to transfer the workload from one environment to another with no impact on the microservice consuming the Canary.

Kong provides Kong Mesh, which supports Kubernetes and Virtual Machine workloads for a single, hybrid, and distributed service mesh implementation.

APIOps With Red Hat

With APIOps, solid DevOps principles are being applied to the API life cycle just like we do with the microservices.

Kong provides Insomnia, the API spec designer that supports OpenAPI, Swagger and GraphQL standards. Insomnia connects directly to Git-based repositories, so all API designers can work with the same collection of API Specs.

Also, Insomnia can generate unit tests for the API and services.

Red Hat Ansible along with other tools like Jenkins or GitHub Actions can be used to implement the CI/CD pipeline and orchestrate three tools provided by Kong to automate Kong configuration and API life cycle: 

• Inso: A tool provided by Insomnia to parse API Specs to generate specific Kong declarative configs.
• decK: This pushes the declarations produced by Inso to Kong Gateway and exposes new APIs or new versions of an existing API.
• DevPortal CLI: Publishes the new API specs to Kong DevPortal.

The diagram below shows a reference for the CI/CD pipeline:

Kong Konnect Offer in Red Hat Marketplace With Seamless Deployment.

For a faster deployment, you can find and manage Kong Konnect Enterprise from within the Red Hat Marketplace. That makes it easier to purchase and get Konnect up and running with step-by-step installation guides, including OpenShift deployments and Red Hat products integration.