Deploy Java microservices on Kubernetes with polyglot support  

Deploy Java microservices on Kubernetes within a polyglot ecosystem

Last updated | By Animesh Singh, Anthony Amanse


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 developer journey, you’ll learn how to deploy a Java microservices application that runs alongside other polyglot microservices, leveraging service discovery, registration, and routing.


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 journey 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 leverage 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.


  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 connects players to rooms over WebSockets.
  5. The user creates a new room by clicking a button in one of the sample walkthroughs.
  6. The developer uses the Map microservice within the room implementation to ensure 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 as users navigate to the room.

Related Blogs

Two “edgy” AI TensorFlow models for you!

The global Call for Code is well underway, we want to share some visual recognition models which could help you. These AI models can operate on the edge, which could be particularly useful for this years’ theme: disaster preparedness. How could visual recognition help in relief work? From satellite and drone imagery analysis, to classifying...

Continue reading Two “edgy” AI TensorFlow models for you!

Leveraging the power of AI at Unite Berlin

Last week, from June 19 – 21, we were at Unity’s premiere in Berlin: Unite 2018. This conference brought together Unity’s video game and development community. Unity touches 770 million gamers all over the world and is the market leader for consumer AR and VR use cases and is also rapidly emerging as the market...

Continue reading Leveraging the power of AI at Unite Berlin

Related Links