Overview

Not that long ago we were developing monolithic multi-tier applications where the main theme was:

[UI <-> JavaEE <-> Database]

This has changed since we started to embrace a Microservices Architecture and especially with the advent of Kubernetes.

"We have started to replace monoliths by sets of container-based microservices running in a
Kubernetes cluster"

In general we all agree these distributed architectures have lots of benefits but also pose some challenges. One of those challenges we’d like to highlight here is the problem a developer has to face when developing kubernetes native applications.

The truth is that, even though you will eventually run your code inside a kubernetes cluster, you still develop (in general) locally where you have your IDE, compilers, etc. There are several ways to explain the development cycle, for example.

There are two loops, one closer to the developer inner-loop; where you code, test, debug iteratively and one further away the outer-loop; where your code runs inside a container image you have to build, push and deploy and…​ that take a lot longer.

Inner vs Outer Loop
Figure 1. Inner vs Outer "one more debug session nightmare"

You may think…​ I can "test it all" locally, then just push my code and the rest is history. Something like this.

Kubernetes Native Development Loop
Figure 2. Kubernetes Native Development Loop

Well if this is your case…​ then you may not need to continue BUT if you happen to need to connect to several services, large database, etc. then having "it-all" locally maybe it’s not an option, if that is the case stay!

Well, the goal of this guide is simple exploring different approaches to help you with the inner-loop of the kubernetes native development workflow.

TL;DR

This tutorial will guide you to extend your Java Inner Loop so that it literally overlaps with your kubernetes cluster, something like this. You’ll find how to do this for Spring Boot and Quarkus. We will provide you with sample code and configurations for PostgreSQL and Oracle RDBMS.

  • This guide concentrates on Java but concepts and the approach involving Telepresence applies to any technology.

  • The examples involving Oracle RDBMS show how to deploy Oracle in an OpenShift cluster but also consider that database as external to the cluster.

Inner extended to the kubernetes cluster
Figure 3. Inner extended to the kubernetes cluster

The Challenge

Nowadays, given the distributed nature of applications, developers find themselves dealing with a plethora of services they need to integrate with at development time. So the challenge is for those services to be accessible/available and sometimes this is not easy.

Let’s review some of the approaches you can take in order to mitigate this problem.

Approaches To Mitigate The Problem

Here are some approaches to reduce the problem:

  • Using Docker Compose and deploy all the services locally

  • Using minikube, kind, etc. and deploy all the services there

  • Mocking up all the services you interact with

All these approaches are valid and plausible but sometimes they’re not the best way to go or just too complicated to maintain. For instance sometimes you need access to several services in different namespaces and you have to get them all locally…​ other times some services are external and reachable only from the remote cluster…​ and maybe mocking-up code is not your thing (or don’t have the skills or time to do it).

This guide explores some alternatives to extend your local development environment (inner-loop) to the remote cluster for Java applications using two frameworks: Spring Boot and Quarkus.

Details

This tutorial provides you with a super-simple CRUD microservice (in two flavors: Spring Boot and Quarkus), FruitService, that implements the usual functions: create, update, delete, find all, etc. mapped to a table in a relational database.

No need to code this time, the Java code is simple, it works and we have tested it against, H2, PostgreSQL and Oracle RDBMS.

So what will you do in this tutorial?

You will:

  • Deploy the code against PostgreSQL directly from the command line using the JKube maven plugin

  • You will also learn how JKube leverages Source to Image (S2I) to speed up the process of building container images inside OpenShift.

  • You’ll find out how to do the same for Quarkus but this time using the Quarkus OpenShift plugin instead of JKube

  • We will show you how to use Telepresence to speed up development iterations.

  • Finally you’ll learn how to enable Remote Development Mode for your Quarkus project

Optionally, although highly recommended, you will do the same but this time against an Oracle database. You will learn how to use a Kubernetes Service of type ExternalName to point to the Oracle database as if it were not deployed in your cluster, hence external.

No worries if you don’t have an Oracle database at hand, we’ll show you how you can have an Oracle database running in a container in your OpenShift cluster (for testing purposes and as long as you have an OTN developer account you can use to pull images from the Oracle Container Registry).

Lab parameters

This lab has requires you to have access to an OpenShift cluster. This cluster can be remote or local if you use CodeReady Containers or CRC for short.

Use this link if you want to jump directly to the instructions to download and install CRC.

Throughout the guide you’ll find URLs and commands crafted for your user and cluster, in order to make the experience as smooth as possible it would be great if you could craft a URL including the next variables and values.

Key Value

USERNAME

developer

PASSWORD

developer

CLUSTER_SUBDOMAIN

apps-crc.testing

If you click on the link above or have already added the mentioned variables you will see correct values below, if that’s not the case you will see '%' signs surrounding variables names as values.

Key Value

USERNAME

%USERNAME%

PASSWORD

%PASSWORD%

CLUSTER_SUBDOMAIN

%CLUSTER_SUBDOMAIN%