Deploy Java microservices on Kubernetes with polyglot support

Summary

No application is an island. Today, developers are adopting integrated microservices and cloud-native microservices architectures. But with current application architectures, microservices need to co-exist in polyglot environments. In this code pattern, you learn how to deploy a Java microservices application that runs alongside other polyglot microservices, using service discovery, registration, and routing.

Description

In a polyglot world, microservices need to be deployed together and can’t simply rely on language native frameworks for service discovery, routing, and other tasks. This pattern shows you how to deploy a Java-based microservices application called “GameOn!” within a polyglot ecosystem.

The application is a throwback text-based adventure game built to help you explore microservice architectures and related concepts. The app runs on a Kubernetes cluster and has two types of microservices: core and platform. The core microservices are written in Java and use polyglot services for support. With this kind of pattern, microservices either use sidecars as processes inside the same microservice container or use separate container sidecars to leverage platform services for service discovery, registration, and routing. All of the microservices run in Docker containers managed by a Kubernetes cluster.

Flow

1. The user visits the GameOn! deployment on Kubernetes through a proxy, which is based on HAProxy and is responsible for surfacing the collection of APIs as a single facade for the entire application. WebApp is a simple NGINX process that provides the web front end to the client device.
2. The user interacts with the Player microservice to play the game. The microservice provides a public API for CRUD operations, and for managing API tokens.
3. The Player microservice uses the Auth Java microservice to authenticate the user with the selected social sign-on service and responds to the client with profile and progress data for the authenticated player.
4. The front-end client establishes a WebSocket to the Mediator service to begin playing the game. The Mediator service is implemented in Java using WebSphere Liberty, and it connects players to rooms over WebSockets.
5. The user creates a room by clicking a button in one of the sample walkthroughs.
6. The developer uses the Map microservice within the room implementation to ensure that the room is registered with the latest connection information. The Map service is a Java EE application running on WebSphere Liberty that provides a public REST API using JAX-RS.
7. The Map service checks with the Player service to ensure that the developer is permitted to update information about the room, based on an API token associated with the developer.
8. The Mediator service establishes WebSocket connections to the live Room service when the users navigate to the room.

Instructions

Ready to put this code pattern to use? Complete details on how to get started running and using this application are in the README.md file.