Forem: Niklas Heidloff

New Open-Source Multi-Cloud Asset to build SaaS

Niklas Heidloff — Thu, 03 Feb 2022 07:29:46 +0000

Over the last months I’ve worked with many companies who want to build SaaS (Software as a Service) to scale their solutions to new markets and to save costs. To address these needs, our team has produced an asset that demonstrates how to build cloud-native applications that can be deployed to multiple clouds and how they can be exposed in multiple marketplaces. Red Hat OpenShift is a perfect technology to address these requirements.

Check out the SaaS repo.

Introduction

When software is provided as a managed service (SaaS), using a multi-tenant approach helps minimise costs for the deployments and operations of each tenant. In order to leverage these advantages, applications need to be designed so that they can be deployed to support multiple tenants, while maintaining isolation for security reasons. At the same time, common deployment and operation models are required so that new SaaS versions can be deployed to existing tenants, or to onboard new tenants, in a reliable and efficient way.

A new open-source project from IBM developers aims to support a DevSecOps approach to building multi-tenant SaaS for different platforms including Kubernetes, Red Hat OpenShift, IBM Code Engine (serverless), IBM Satellite, and public clouds including IBM Cloud, AWS and Azure. The asset includes DevSecOps toolchains to automate the process for deploying a sample cloud native application to a common platform and create per-tenant cloud services for persistence and authentication.

The initial release uses Continuous Integration and Continuous Delivery (CI/CD) toolchains on IBM Cloud to deploy SaaS to IBM Code Engine, Red Hat OpenShift on IBM Cloud, or IBM Kubernetes Service on IBM Cloud. We have plans to extend the deployment to support multi-cloud using Red Hat OpenShift on AWS (ROSA) and Azure Red Hat OpenShift (ARO).

This asset has been created by IBM's Build Labs:

Challenges

Organisations offering SaaS will need to deliver rapidly and often, while maintaining a strong security posture and continuous state of audit-readiness. Achieving this goal involves several teams including developers, IT operations and security. DevSecOps integrates a set of security and compliance controls and makes application and infrastructure security a shared responsibility for all these teams, and automatically bakes in security at every phase of the software development lifecycle, bringing speed and security. This is of particular importance for SaaS where the challenges and benefits are a factor of the number of tenants!

The project provides a starting point for learning how to create an application which is ready for SaaS, using best practices for DevSecOps such as detecting code or container vulnerabilities, and using CI/CD pipelines to automate deployments. The key value of this asset is that it shows how to reuse the same application code, containers, and CI/CD, with the flexibility to deploy to a dedicated or shared Kubernetes cluster, while maintaining isolation and security.

Support for multiple platforms

The following diagram shows the different deployment platform options, currently including several alternatives for IBM Cloud, as indicated by the green boxes. The orange boxes represent planned future developments, including the addition of IBM Cloud Satellite which will allow the SaaS application to be deployed on-premises at client data centers, while still taking advantage of an OpenShift cluster managed by IBM Cloud. Additionally, the same SaaS application could be deployed to other managed OpenShift services like AWS ROSA and Azure ARO.

The easiest way to get started is with serverless, using the fully managed IBM Code Engine platform to run the application. For more advanced cloud-native applications, a dedicated Kubernetes or OpenShift cluster can be used. Compute isolation can be achieved with a shared cluster using Kubernetes namespaces/OpenShift projects, or by having dedicated clusters for each SaaS tenant.

Core technologies used:

Kubernetes using either IBM Kubernetes Service or OpenShift on IBM Cloud
IBM Code Engine (serverless)
IBM Continuous Delivery CI/CD pipelines using Tekton
IBM Cloud Databases for PostgreSQL
IBM App ID
IBM Container Registry
Terraform

Sample e-commerce application

A sample e-commerce application is provided, which is deployed as two containers. A frontend web application displays a catalogue of products. The data for the catalogue is provided by a backend microservice. Configuration properties are used extensively to customise both the frontend and backend at deployment time, including titles, connection details for the PostgreSQL database and authentication service etc. This means the same e-commerce sample application can easily be used for multiple tenants, perhaps one selling books, the other shoes.

Automation first

Everything in this project embraces automation and a series of approaches to deploy SaaS are provided, each with an increasing degree of capability. You are able to start with any of the following approaches:

Simple bash scripts to create and deploy the sample application container images, and the PostgreSQL and AppID cloud services.
A simple DevOps toolchain with CI/CD pipelines which deploys to IBM Code Engine. The pipelines orchestrate build, test, and deployment jobs (optionally across multiple environments) as changes progress from the developer to production.
A more comprehensive DevSecOps toolchain which deploys to a Kubernetes cluster. This brings a more robust process where the CI/CD pipelines ensure that code is scanned for security vulnerabilities (e.g. secrets or credentials), and repository branch protection prevents a developer from directly updating the main branch without first issuing a pull/merge request to be approved by a second developer. In addition, the container images are scanned for vulnerabilities, a dynamic application security testing tool looks for vulnerabilities in the deployed application, and application acceptance tests all contribute to a secure and quality assured release.

Any of these approaches are ready to deploy the multiple tenancies of a SaaS application. Simply change the externalised properties and re-run the script or trigger the pipelines.

For deployments to IBM Kubernetes Service or OpenShift, terraform templates are also provided to automate the cluster creation on IBM Cloud.

Ready for regulated industries

Regulated industries such as financial institutions, insurance, healthcare and more, all want the advantages of a hybrid cloud, but need assurance they can protect their assets and maintain compliance with industry and regulatory requirements. The key to hosting regulated workloads in the cloud is to eliminate and mitigate the risks that might be standing in the way of progress. In regulated industries, critical risks fall into the general categories of compliance, cybersecurity, governance, business continuity and resilience.

The DevSecOps approach of our CI/CD pipelines are based an IBM DevSecOps reference architecture, helping to address some of the risks faced by regulated industries. The CI/CD pipelines include steps to collect and upload deployment log files, artifacts, and evidence to a secure evidence locker. In addition, a toolchain integration to IBM Security and Compliance Center verifies the security and compliance posture of the toolchain by identifying the location of the evidence locker, and the presence of the evidence information.

What's next?

Our project is constantly evolving. You can expect more supported platforms including IBM Cloud Satellite and other public clouds including support for their native database and authentication services. We still have some work to do on the documentation, e.g. explaining how to observe multi-tenant runtime logs, and understand how much cloud resource each tenant is consuming, to help calculate the bills.

In the meantime, we invite you to explore the repo and give it a try. Why not start by using our most simple script-based approach with IBM Code Engine, and see for yourself how easy it is is to be a SaaS provider! We would also be happy to work together with you on using this asset to build your SaaS.

If you have feedback or comments, please don't hesitate to get in touch via our social media links above.

Accessing Apache Kafka from Quarkus

Niklas Heidloff — Wed, 18 Mar 2020 10:23:11 +0000

This article describes how to develop microservices with Quarkus which use Apache Kafka running in a Kubernetes cluster.

Quarkus supports MicroProfile Reactive Messaging to interact with Apache Kafka. There is a nice guide Using Apache Kafka with reactive Messaging which explains how to send and receive messages to and from Kafka.

The guide contains instructions how to run Kafka locally via Docker with docker-compose. While this is probably the easiest way to get started, the next step for microservices developers is often to figure out how to access Apache Kafka in Kubernetes environments or hosted Kafka services.

Option 1: Apache Kafka running in Kubernetes

The open source project Strimzi provides container images and operators for running Apache Kafka on Kubernetes and Red Hat OpenShift. There is a nice blog series on Red Hat Developer that describes how to use Strimzi. In order to access it from applications there are several different options, for example NodePorts, OpenShift routes, load balancers and Ingress.

Sometimes these options can be overwhelming for developers, especially when all you need is a simple development environment to write some reactive hello world applications to get started. In my case I wanted to install a simple Kafka server in my Minikube cluster.

There is a quickstart guide how to deploy Strimzi to Minikube. Unfortunately it doesn’t explain how to access it from applications. The second part of the blog series Accessing Apache Kafka in Strimzi: Part 2 – Node ports explains this.

Based on these two articles I wrote a simple script that deploys Kafka to Minikube in less than 5 minutes. The script is part of the cloud-native-starter project. Run these commands to give it a try:

$ git clone https://github.com/IBM/cloud-native-starter.git
$ cd cloud-native-starter/reactive
$ sh scripts/start-minikube.sh
$ sh scripts/deploy-kafka.sh
$ sh scripts/show-urls.sh

The output of the last command prints out the URL of the Kafka bootstrap server which you’ll need in the next step. You can find all resources in the ‘kafka’ namespace.

In order to access Kafka from Quarkus, the Kafka connector has to be configured. When running the Quarkus application in the same Kubernetes cluster as Kafka, use the following configuration in ‘application.properties’. ‘my-cluster-kafka-external-bootstrap’ is the service name, ‘kafka’ the namespace and ‘9094’ the port.

kafka.bootstrap.servers=my-cluster-kafka-external-bootstrap.kafka:9094`
mp.messaging.incoming.new-article-created.connector=smallrye-kafka`
mp.messaging.incoming.new-article-created.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

When developing the Quarkus application locally, Kafka in Minikube is accessed via NodePort. In this case replace the kafka.bootstrap.servers configuration with the following URL:

$ minikubeip=$(minikube ip)
$ nodeport=$(kubectl get svc my-cluster-kafka-external-bootstrap -n kafka --ignore-not-found --output 'jsonpath={.spec.ports[*].nodePort}')
$ echo ${minikubeip}:${nodeport}

Option 2: Kafka as a Service

Most cloud providers also host managed Kafka services. For example Event Streams is the managed Kafka service in the IBM Cloud. There is a free lite plan which offers access to a single partition in a multi-tenant Event Streams cluster. All you need is an IBM id, which is free and you don’t need a credit card.

As most Kafka services in production, Event Streams requires a secure connection. This additional configuration needs to be defined in ‘application.properties’ again.

kafka.bootstrap.servers=broker-0-YOUR-ID.kafka.svc01.us-south.eventstreams.cloud.ibm.com:9093,broker-4-YOUR-ID.kafka.svc01.us-south.eventstreams.cloud.ibm.com:9093,...MORE-SERVERS
mp.messaging.incoming.new-article-created.connector=smallrye-kafka
mp.messaging.incoming.new-article-created.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
mp.messaging.incoming.new-article-created.sasl.mechanism=PLAIN
mp.messaging.incoming.new-article-created.security.protocol=SASL_SSL
mp.messaging.incoming.new-article-created.ssl.protocol=TLSv1.2
mp.messaging.incoming.new-article-created.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="token" password="YOUR-PASSWORD";

In order to enter this information, you need 1. the list of Kafka bootstrap servers and 2. your password for the Event streams service. You can receive this information in the web frontend of the Event Streams service or you can use the IBM Cloud CLI.

My colleague Harald Uebele has developed a script that creates the service programmatically and returns these two pieces of information.

Next Steps

The scripts mentioned in this article are part of the cloud-native-starter project which describes how to get develop reactive applications with Quarkus. My previous article describes the project.

Try out the code yourself.

Read the other articles of this series:

Development of Reactive Applications with Quarkus

Niklas Heidloff — Thu, 12 Mar 2020 09:39:46 +0000

In the context of cloud-native applications the topic ‘reactive’ becomes more and more important, since more efficient applications can be built and user experiences can be improved. If you want to learn more about reactive functionality in Java applications, read on and try out the code.

Challenges when getting started with reactive Applications

While the topic ‘reactive’ has been around for quite some time, for some developers it’s not straightforward to get started with reactive applications. One reason is that the term is overloaded and describes different aspects, for example reactive programming, reactive systems, reactive manifesto and reactive streams. Another reason is that there are several different frameworks which support different functionality and use other terminologies. For example for me with my JavaScript background it wasn’t obvious to figure out the Java counterparts for JavaScript callbacks, promises and observables. Yet another reason why it can be challenging for some developers to get started is that reactive programming requires a different type of thinking compared to writing imperative code.

There are a lot of resources available to start learning various reactive concepts. When learning new technologies simple tutorials, samples and guides help to understand specific functions. In order to understand how to use the functions together, it helps me to look at more complete applications with use cases that come closer to what developers need when building enterprise applications. Because of this I’ve implemented a sample application which shows various aspects of reactive programming and reactive systems and which can be easily deployed on Kubernetes platforms.

Architecture of the Sample Application

Rather than reinventing the wheel, I reused the scenario from the cloud-native-starter project which shows how to develop and operate synchronous microservices that use imperative programming.

The sample comes with a web application which displays links to articles with author information in a simple web application. The web application invokes the web-api service which implements a backend-for-frontend pattern and invokes the articles and authors service. The articles service stores data in a Postgres database. Messages are sent between the microservices via Kafka. This diagram describes the high level architecture:

Technologies and Functionality

The sample leverages heavily Quarkus which is “a Kubernetes Native Java stack […] crafted from the best of breed Java libraries and standards”. Additionally Eclipse MicroProfile, Eclipse Vert.x, Apache Kafka, PostgreSQL, Eclipse OpenJ9 and Kubernetes are used.

Over the next days I’ll try to blog about the following functionality:

Sending in-memory messages via MicroProfile
Sending in-memory messages via Vertx event bus
Sending and receiving Kafka messages via MicroProfile
Sending Kafka messages via Kafka API
Reactive REST endpoints via CompletionStage
Reactive REST invocations via Vertx Axle Web Client
Reactive REST invocations via MicroProfile REST Client
Exception handling in chained reactive invocations
Timeouts via CompletableFuture
Resiliency of reactive microservices
Reactive CRUD operations for Postgres

The sample application demonstrates several scenarios and benefits of reactive applications.

Scenario 1: Reactive Messaging

One benefit of reactive models is the ability to update web applications by sending messages, rather than pulling for updates. This is more efficient and improves the user experience.

Articles can be created via REST API. The web application receives a notification and adds the new article to the page.

This diagram explains the flow:

Scenario 2 – Reactive REST Endpoints for higher Efficiency

Another benefit of reactive systems and reactive REST endpoints is efficiency. This scenario describes how to use reactive systems and reactive programming to achieve faster response times. Especially in public clouds where costs depend on CPU, RAM and compute durations this model saves money.

The project contains the endpoint ‘/articles’ of the web-api service in two different versions, one uses imperative code, the other one reactive code.

The reactive stack of this sample provides response times that take less than half of the time compared to the imperative stack: Reactive: 793 ms – Imperative: 1956 ms.

Read the documentation for details.

This diagram explains the flow:

This is the result of the imperative version after 30000 invocations:

This is the result of the reactive version after 30000 invocations:

Supported Kubernetes Environments

We have put a lot of effort in making the setup of the sample as easy as possible. For all components and services there are scripts to deploy and configure everything. For example if you have Minikube installed, the setup shouldn’t take longer than 10 minutes.

Closing Thoughts

A big thank you goes to Harald Uebele and Thomas Südbröcker for their ongoing support. Especially I want to thank Harald for writing the deployment scripts for CodeReady Containers and Thomas for writing the deployment scripts for IBM Cloud Kubernetes Service. Additionally I want to thank Sebastian Daschner for providing feedback and sending pull requests.

Try out the code yourself!

Read the other articles of this series:

Persistence for Java Microservices in Kubernetes via JPA

Niklas Heidloff — Thu, 23 May 2019 15:05:22 +0000

Over the last weeks I’ve worked on an example application that demonstrates how Java EE developers can get started with microservices. The application is a full end-to-end sample which includes a web application, business logic, authentication and now also persistence. It runs on Kubernetes and Istio and there are scripts to easily deploy it.

Get the cloud-native-starter code from GitHub.

Java Persistence API

In the example I use a full open source Java stack with OpenJ9, OpenJDK, Open Liberty and MicroProfile. In order to deploy the microservices to Kubernetes, I’ve created an image. Read my article Dockerizing Java MicroProfile Applications for details.

Open Liberty provides some pretty good guides. One guide is specifically about JPA: Accessing and persisting data in microservices. I don’t want to repeat everything here, but only highlight the changes I had to do to run this functionality in a container, rather than via a local Open Liberty installation.

Here is a short description of JPA:

JPA is a Java EE specification for representing relational database table data as Plain Old Java Objects (POJO). JPA simplifies object-relational mapping (ORM) by using annotations to map Java objects to tables in a relational database. In addition to providing an efficient API for performing CRUD operations, JPA also reduces the burden of having to write JDBC and SQL code when performing database operations and takes care of database vendor-specific differences.

Configuration of the Sample Application

The following diagram shows the simplied architecture of the cloud-native-starter example. A web application invokes through Ingress the Web-API service that implements a backend-for-frontend pattern. The Web-API service invokes the Articles service which stores data in a SQL database on the IBM Cloud. Obviously you can use any other SQL database instead.

In order to access the Db2 on the IBM Cloud, first the driver needs to be downloaded via Maven. Note that the driver does not go into the war files together with the business logic of the microservices, but it needs to be copied in a certain Open Liberty directory: /opt/ol/wlp/usr/shared/resources/jcc-11.1.4.4.jar

Next you need to define in server.xml information about the driver and the data source.

<server description="OpenLiberty Server">
    <featureManager>
        <feature>webProfile-8.0</feature>
        <feature>microProfile-2.1</feature>
    </featureManager>

    <httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="8080" httpsPort="9443"/>

    <library id="DB2JCCLib">
        <fileset dir="${shared.resource.dir}" includes="jcc*.jar"/>
    </library>

    <dataSource id="articlejpadatasource"
              jndiName="jdbc/articlejpadatasource">
        <jdbcDriver libraryRef="DB2JCCLib" />
        <properties.db2.jcc databaseName="BLUDB"
            portNumber="50000"
            serverName="DB2-SERVER"        
            user="DB2-USER"
            password="DB2-PASSWORD" />
  </dataSource>
</server>

Next the persistence unit needs to be define in persistence.xml.

The tricky part was for me to figure out the right location for this file. In order for all Maven versions to build it correctly I put it in ‘src/main/resources/META-INF/persistence.xml’. This produces an articles.war file with the internal structure ‘classes/META-INF/persistence.xml’.

<persistence version="2.2"
    xmlns="http://xmlns.jcp.org/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
                        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
    <persistence-unit name="jpa-unit" transaction-type="JTA">
        <jta-data-source>jdbc/articlejpadatasource</jta-data-source>
        <properties>
            <property name="eclipselink.ddl-generation" value="create-tables"/>
            <property name="eclipselink.ddl-generation.output-mode" value="both" />
        </properties>
    </persistence-unit>
</persistence>

Usage of JPA in Java

Once all the configuration has been done, writing the Java code is simple.

First you need to define the Java class which represents the entries in a table. Check out the code of ArticleEntity.java with the five columns id, title, url, author and creation date. As defined in persistence.xml this table is created automatically.

The CRUD operations for articles are defined in ArticleDao.java. The code is pretty straight forward. The only thing that confused me, was that I have to begin and commit transactions manually for the create operation. In the Open Liberty sample this was not necessary. I’m trying to find out what the difference is.

In JPADataAccess.java the logic is implemented to add and read articles. The ArticleDao is injected. Again, the code looks simple. The lesson that I learned here is, that dependency injection only seems to work when the upper layers that invoke this code use dependency injection and @ApplicationScoped as well.

How to run the Example

I’ve written scripts to create the SQL database and create the Articles service. Check out the documentation to run the sample yourself on Minikube or the IBM Cloud Kubernetes Service.

Once installed the OpenAPI API Explorer can be used to create a new article.

The table is displayed in the Db2 console.

The data in the table can be displayed in the console as well.

To learn more about microservices built with Java and MicroProfile, check out the cloud-native-starter repo.

Example Java App running in the Cloud via Kubernetes

Niklas Heidloff — Wed, 10 Apr 2019 12:29:41 +0000

Over the last weeks I’ve worked on a new sample application which demonstrates how to build microservices-based architectures. While there are still some minor things I’d like to add, I think the sample is pretty comprehensive now and a good option for developers, especially Java EE developers, to learn microservices and cloud-native patterns.

The example is available as open source. The GitHub repo is called cloud-native-starter.

Kubernetes, Istio and Java

When building cloud-native applications, developers are challenged to figure out how to address topics like traffic routing, resiliency, distributed monitoring, service discoveries and more. Fortunately most of these new challenges are handled by the orchestration platform Kubernetes and the service mesh Istio. This functionality works generically for microservices, regardless of the language they are implemented in and without changes to the application logic.

However, some functionality can not be covered by orchestration platforms and service meshes. Instead it must be handled in the business logic of the microservices, for example application specific failover functionality, metrics, and fine-grained authorizations.

Java developers can leverage Eclipse MicroProfile to implement this functionality. MicroProfile is an extension to Java EE (Enterprise Edition) to build microservices-based architectures and it complements Kubernetes and Istio capabilities. In addition to the application specific logic which Kubernetes and Istio cannot handle, it also comes with convenience functionality that you typically need when developing microservices, for example mechanisms to invoke REST APIs and functionality to implement REST APIs including their documentation.

Design Principles

The example application follows these design principles:

Leverage platforms as much as possible – do as little as possible in language-specific frameworks
Use open-source components for the core services of the application only
Make the first time experience as simple as possible
Be able to run the application in different environments

Let me explain the design principles in more detail.

Leverage platforms as much as possible – do as little as possible in language-specific frameworks

The advantage of using Kubernetes and Istio for features like traffic management is, that these features are language agnostic. Cloud-native applications can be, and often are, polyglot. This allows developers to pick the best possible languages for the specific tasks.

Use open-source components for the core services of the application only

In my role as developer advocate I talk with many developers. Pretty much everyone loves open source. In order to reach as many developers as possible, the sample application uses for the core services of the application only open source projects. For example the Java stack leverages OpenJ9, OpenJDK from AdoptOpenJDK, OpenLiberty and MicroProfile. Kubernetes and Istio are obviously open source projects as well. The components of the application that are not available as open source are optional and can be exchanged.

Make the first time experience as simple as possible

There are many samples, snippets, articles and tutorials available for the various cloud-native features and many of them are really good. However, I’ve had issues to run some of these features together in one application. Sometimes they used different Java stacks, sometimes different versions and sometimes the articles were outdated.

The example application shows several features working together, see below for details. There are also scripts to deploy services very easily, basically one script per service, similar to the ‘cf push’ experience for Cloud Foundry applications.

Be able to run the application in different environments

Fortunately this is one of the main advantages of Kubernetes since you can run workloads on-premises, hybrid or public cloud infrastructures. The repo has instructions how to deploy the application to Minikube and to the managed IBM Cloud Kubernetes Service.

Functionality of the Sample Application

The project demonstrates the following functionality:

This diagram shows the services and components:

The web application invokes an API of a BFF (backend for frontend) service to display articles with authors.

Call to Action

If you want to learn cloud-native applications, get the code of the example application and follow the instructions to set up a local Minikube environment and to deploy the microservices. If you have already a Kubernetes cluster, the setup should not take longer than half an hour.

You can also run this application on the IBM Cloud Kubernetes Service which is a managed service that comes with an Istio plugin. IBM provides an IBM Cloud Lite account which is free, no credit card is required and there is no time restriction. In order to use the Kubernetes service, contact Harald and myself to get a promo code. Then follow these instructions to deploy the services to the IBM Cloud.

As always, I’d like to get feedback. Please let me know what you think about the example and how it could be improved. My direct messages on Twitter are open: @nheidloff

I also want to thank everyone who has helped to create this application, especially Harald Uebele who has written a lot of the code and scripts.

Debugging Microservices running in Kubernetes

Niklas Heidloff — Mon, 25 Mar 2019 09:26:02 +0000

In order to learn more about microservices, container orchestration and service meshes, I’ve set up a local development environment with Minikube, Istio and tools like Kiali and created a sample application. In this article I describe how to debug these services locally.

Microservices can be developed in various languages and with multiple frameworks. For the different implementation types there are specialized and established IDEs (integrated development environments) and tools to debug the single services.

The new challenge when debugging cloud-native applications is that applications often have many microservices and there is a lot of communication between them. Testing and debugging only separate services is not sufficient.

Requirements

Here is a list of my debugging requirements. In the optimal case I’d like to …

Run and debug my code in my favorite IDE locally (rather than using a slow remote debugger)
Run the single service as part of the overall application, for example invoke it from another service (rather than via unit tests and mock objects only)
Run the code in the same container locally as in production (rather than installing application servers locally)
Do changes in the code locally and test them immediately (rather than restarting containers)

Telepresence

There are several different ways to debug microservices. One great solution is to use Telepresence, which is an open source tool for the “FAST, LOCAL DEVELOPMENT FOR KUBERNETES AND OPENSHIFT MICROSERVICES”.

Here is an example. I’m using a simple application which has two microservices so far. The BFF (backend for frontend) ‘web-api’ microservice invokes another ‘articles’ microservice. I want to debug the ‘articles’ service locally and let the ‘web-api’ service invoke it which runs in a Kubernetes cluster.

I’ve implemented these services with JavaEE, OpenJ9, Open Liberty and MicroProfile within Eclipse. There is a lot of documentation available how to debug Open Liberty in Eclipse via the Open Liberty Tools. You can import the ‘articles’ service as existing Maven project. In order to run the service in the local Open Liberty server, you need to check ‘Dynamic Web Module’ in the ‘Project Facets’ settings. After this, you can start the local Open Liberty server.

In order to run the ‘articles’ service on Kubernetes, I’ve written a simple script to deploy it. Here is the yaml file:

kind: Service
apiVersion: v1
metadata:
  name: articles
  labels:
    app: articles
spec:
  selector:
    app: articles
  ports:
    - port: 9080
      name: http
  type: NodePort
---

kind: Deployment
apiVersion: apps/v1beta1
metadata:
  name: articles
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: articles
        version: v1
    spec:
      containers:
      - name: articles
        image: articles:1
        ports:
        - containerPort: 9080

Now to the exciting part. Telepresence allows you to swap a pod running in Kubernetes with a service running locally. All requests to the pod in Kubernetes are redirected to the local URL and port.

After you have installed Telepresense, the following command can be run:

$ telepresence --method inject-tcp --swap-deployment articles --expose 9080:9080

Once the Kubernetes remote port 9080 has been mapped to the local port 9080, the locally running service can be invoked from the ‘web-api’ service running in Kubernetes. The best part is you can also use the Eclipse debugger as if everything would run locally.

Calling from local Services to Kubernetes

With this easy setup services in Kubernetes can invoke local services. Unfortunately the other direction doesn’t work. For example a locally running service ‘web-api’ can not invoke the Kubernetes service ‘articles’ via http://articles:9080.

Fortunately Telepresense comes with a mechanism to support this as well. Essentially you can run your code in a local Docker container and debug it with a remote debugger. Telepresense can replace the Kubernetes pod with a two-way proxy that handles the traffic to your local Docker container. There is even support for ‘hot code replace’ (see documentation).

I haven’t tried the two-way communication yet, but the functionality sounds very promising and would fulfill the requirements above!

If you want to give it a try, use the sample application, set up a local development environment and follow the instructions above.

Introducing the Fun Cloud Showcase #BlueCloudMirror

Niklas Heidloff — Fri, 15 Mar 2019 14:06:09 +0000

Blue Cloud Mirror is a game where players need to show five specific emotions and do five specific poses in two levels. The faster, the better.

Play the game. It only takes a minute. All you need is a webcam and a Chrome browser.

Get the code from GitHub.

Here are my results:

The game uses key technologies of the IBM Cloud and has three main parts:

Core game: Implemented as serverless web application and via Cloud Functions since it is not accessed 24x7
Users service: Implemented via IBM Cloud Private to avoid having the personal data in a public cloud
Scores service: Implemented via Cloud Foundry Enterprise Edition to demonstrate developer productivity

The following diagram shows the key components:

I’ve built Blue Cloud Mirror together with my colleagues Thomas Südbröcker and Harald Uebele. Check out our series of blog entries about it.

You can also run the application locally. The setup shouldn't take longer than five minutes:

$ npm install -g @vue/cli
$ git clone https://github.com/IBM/blue-cloud-mirror.git
$ cd blue-cloud-mirror/game
$ yarn install
$ yarn run serve

Try the Game!

Lightweight serverless Java functions with Quarkus

Niklas Heidloff — Wed, 13 Mar 2019 07:24:04 +0000

Quarkus is a “next-generation Kubernetes native Java framework” which is available as open source. Quarkus promises fast boot times and low memory usages. This makes Quarkus a perfect fit for Java workloads running as microservices on Kubernetes as well as Java workloads running as serverless functions.

Read the article Why Quarkus to learn how Quarkus works. In a nutshell Quarkus compiles Java source code in native binaries via GraalVM. The Quarkus framework helps developers to easily build applications that can leverage the GraalVM benefits.

Most developers use JavaScript/Node.js to build serverless functions nowadays. One reason is that Node.js applications usually (used to?) start faster and consume less memory. Since you typically pay for memory and time in the cloud, Node.js often saves you money and provides better experiences.

Today I looked briefly into how to use Quarkus to build lightweight and fast Docker images which can be run as serverless functions on Apache OpenWhisk based platforms like IBM Cloud Functions. One of the great features of OpenWhisk is that you can use Docker to develop functions.

I’ve put together a little sample on GitHub.

Here is how you can try Quarkus on IBM Cloud Functions. All you need is a free IBM Cloud lite account and the ibmcloud CLI.

First download the code:

$ git clone https://github.com/nheidloff/openwhisk-quarkus-starter.git
$ cd openwhisk-quarkus-starter

Before the actual Docker image is built, the native binary is created. Follow the instructions on the Quarkus web site how to set up GraalVM, a Java JDK and Maven.

Then build the image (replace ‘nheidloff’ with your Docker name).

$ mvn package -Pnative -Dnative-image.docker-build=true
$ docker build -t nheidloff/quarkus-serverless:1 .
$ docker push nheidloff/quarkus-serverless:1

In order to invoke the function locally, run these commands:

$ docker run -i --rm -p 8080:8080 nheidloff/quarkus-serverless
$ curl --request POST \
  --url [http://localhost:8080/run](http://localhost:8080/run) \
  --header 'Content-Type: application/json' \
  --data '{"value":{"name":"Niklas"}}'

In order to change the implementation of the sample function, use your favorite Java IDE or text editor. When you run the following command, the application will be updated automatically every time you save a file:

$ mvn compile quarkus:dev

The OpenWhisk function can be created on the IBM Cloud with these commands:

$ ibmcloud login
$ ibmcloud fn action create echo-quarkus --docker nheidloff/quarkus-serverless:1 -m 128

Note: The deployed Quarkus function only consumes 128 MB memory. I think this is pretty amazing.

The easiest way to invoke the command is via the ibmcloud CLI:

$ ibmcloud fn action invoke --blocking echo-quarkus --param name Niklas

Next I want to look more at the speed of the Quarkus functions.

Setup of a Local Kubernetes and Istio Dev Environment

Niklas Heidloff — Fri, 08 Mar 2019 08:45:40 +0000

As developer I like to do as much development as possible locally, because it’s generally easier and faster to develop and debug code. In order to build cloud-native applications and microservices, it’s very convenient to have a local Kubernetes cluster and Istio running locally. This article describes how to install these components and some additional tools like Kiali.

Minikube

In order to run Kubernetes clusters locally, there are different alternatives. One is to use the Kubernetes functionality integrated in Docker Desktop. The alternative that I’ve chosen is Minikube which runs a single-node Kubernetes cluster inside a VM on your development machine.

Follow the instructions to install kubectl and Minikube. As hypervisor I’m using VirtualBox which is supported on Mac, Linux and Windows.

When running Istio and your own applications, you need more more memory and CPUs than you get by default. Here are my settings:

$ minikube config set cpus 4
$ minikube config set memory 8192
$ minikube config set disk-size 50g
$ minikube addons enable ingress
$ minikube start

‘minikube start’ can take several minutes when starting it for the first time. Be patient.

Sometimes ‘minikube start’ doesn’t work for me. In that case I stop my VPN, invoke ‘minikube delete#, delete the ‘.minikube’ directory, restart my machine and start it again.

After this you can get the Minikube IP address and open the Kubernetes dashboard via these commands:

$ minikube ip
$ minikube dashboard

Minikube comes with it’s own Docker daemon, so that you don’t have to use Docker Desktop. You only need the ‘docker’ CLI and point it to Minikube:

$ eval $(minikube docker-env)

To stop the cluster run this command:

$ minikube stop

Istio

To download Istio, run this command:

$ curl -L [https://git.io/getLatestIstio](https://git.io/getLatestIstio) | sh -

Follow the instructions in the terminal to set the path.

To install Istio, run these commands:

$ cd istio-1.0.6
$ kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml
$ kubectl apply -f install/kubernetes/istio-demo.yaml

Make sure that all pods are running or completed before continuing. This can take several minutes when starting the pods for the first time. Be patient.

$ kubectl get pod -n istio-system

This screenshot shows all Istio pods running or completed (ignore the Kiali one for now).

In the last step enable automatic sidecar injection:

$ kubectl label namespace default istio-injection=enabled

After the setup of Minikube and Istio you can use the following tools:

Kubernetes Dashboard

$ minikube dashboard

Jaeger Dashboard

$ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686:16686

URL to Open Jaeger: http://localhost:16686

Grafana Dashboard

$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &

URL to open Grafana: http://localhost:3000/dashboard/db/istio-mesh-dashboard

Prometheus Dashboard

$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &

URL to open Prometheus: http://localhost:9090

Kiali

Run the following command to install Kiali:

$ bash <(curl -L [http://git.io/getLatestKialiKubernetes](http://git.io/getLatestKialiKubernetes))

Note: For some reason the script didn’t work for me. I had to replace one line:

get_downloader
github_api_url="[https://api.github.com/repos/kiali/kiali/releases/latest](https://api.github.com/repos/kiali/kiali/releases/latest)"
kiali_version_we_want="v0.15.0"

To launch Kiali you need the IP address and NodePort:

$ minikube ip
$ kubectl get svc -n istio-system kiali --output 'jsonpath={.spec.ports[*].nodePort}'

URL to open Kiali: https://[minikube-ip]:[kiali-nodeport]/kiali

Sample Application

I’m working on a simple sample application that shows some of the Istio and MicroProfile functionality to build cloud-native applications. I’ll blog more about this soon.

For now you can install two sample microservices from this project. Make sure Minikube runs and you have installed all necessary prerequisites:

$ git clone [https://github.com/nheidloff/cloud-native-starter.git](https://github.com/nheidloff/cloud-native-starter.git)
$ scripts/check-prerequisites.sh
$ scripts/deploy-articles-java-jee.sh
$ scripts/deploy-web-api-java-jee.sh

The following screenshot shows a BFF (backend for frontend) ‘web-api’ microservice invoking another ‘articles’ webservice:

Most of the information in this article I got from Harald Uebele. Thanks Harald. I just added some details that I had to do differently.

Recent Java Updates from IBM

Niklas Heidloff — Wed, 06 Mar 2019 07:32:50 +0000

In preparation for a Java conference, I’ve spent some time to catch up on the latest activities in the Java community. With Java EE’s move to Eclipse and projects like MicroProfile there are a lot of things going on and there is a lot of innovation. Below are some pointers to articles my colleagues have published recently.

Licensing

Oracle has changed the licensing for commercial use. Fortunately IBM open sourced OpenJ9 which is available together with the OpenJDK at no cost from AdoptOpenJDK, even for commercial use.

More about licensing:

Eclipse OpenJ9

The code of the open source JVM OpenJ9 is the same code base used by the IBM SDK for Java which means that it’s enterprise ready. Plus startup time is 40% faster and memory usage is 60% lower compared to other JVMs which makes it a perfect fit for container based workloads.

More about OpenJ9:

Eclipse MicroProfile

MicroProfile allows building cloud-native enterprise microservices. I like especially that MircoProfile based services can supplement Istio functionality, for example for application specific fallbacks.

More about MicroProfile:

More Resources

To learn more about what IBM provides for Java developers, check out the following resources: