Red Hat OpenShift supports two workflows for building container images for applications: the source and the binary workflows. The binary workflow is the primary focus of the Red Hat OpenShift Application Runtimes and Red Hat Fuse product documentation and training, while the source workflow is the focus of most of the Red Hat OpenShift Container Platform product documentation and training. All of the standard OpenShift Quick Application Templates are based on the source workflow.

A developer might ask, “Can I use both workflows on the same project?” or, “Is there a reason to prefer one workflow over the other?” As a member of the team that developed Red Hat certification training for OpenShift and Red Hat Fuse, I had these questions myself and I hope that this article helps you find your own answers to these questions.

For developers working on a Kubernetes-based application environment such as Red Hat OpenShift, there are a number things that need to be considered to fully take advantage of the significant benefits provided by these technologies, including:

How do I communicate with the orchestration layer to indicate the application is operating correctly and is available to receive traffic?

What happens if the application detects a system fault, and how does the application relay this to the orchestration layer?

How can I accurately trace traffic flow between my applications in order to identify potential bottlenecks?

What tools can I use to easily deploy my updated application as part of my standard toolchain?

What happens if I introduce a network fault between my services, and how do I test this scenario?

These questions are central to building container-native solutions. At Red Hat, we define container-native as applications that conform to the following key tenets:

About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.

As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:

learn.openshift.com: A web-based OpenShift and Kubernetes learning environment where users get to interact through the web browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.

Istio tutorial: Want to try the web-based scenario yourself from scratch? This Git repo contains instructions on how to set up an environment for yourself.

This post is the fifth post of my Introduction to Eclipse Vert.x series. In the last post, we saw how Vert.x can interact with a database. To tame the asynchronous nature of Vert.x, we used Future objects. In this post, we are going to see another way to manage asynchronous code: reactive programming. We will see how Vert.x combined with Reactive eXtensions gives you superpowers.

Let’s start by refreshing our memory with the previous posts:

The first post described how to build a Vert.x application with Apache Maven and execute unit tests.

As the industry heads toward the Trough of Disillusionment with cloud-native microservices, finally understanding that distributed architectures introduce more complexity (weird, right?), services meshes can help soften the landing and shift some of that complexity out of our applications and place it where it belongs, in the application operational layer.

At Red Hat Mobile we understand the need for a flexible product that enables our customers to integrate with the tools they need to build their current and future applications. Our position as a leading contributor to the Kubernetes project ensures that the Red Hat OpenShift Container Platform offers this tremendous flexibility to customers and end users.

Red Hat Mobile also supports highly flexible integrations to a range of 3rd party services and products. In this article, we’ll demonstrate how Red Hat Mobile v4 and OpenShift v3 enable customers to rapidly deploy and secure their mobile applications by integrating with a third party product provided by Intercede. We’ll be using Intercede’s RapID product to enable two-way TLS (often referred to as Client Certificate Authentication or CCA) for our mobile application.

A previous article described the specifications in the Eclipse MicroProfile 1.2 release and the benefits for Java-based cloud-native applications. This article shows how software developers writing Java-based microservices can leverage those specifications to take advantage of the management capabilities provided by Red Hat OpenShift.