At the recently concluded Microsoft Ignite 2018 conference in Orlando, I had the honor of presenting to a crowd of Java developers and Azure professionals eager to learn how to put their Java skills to work building next-gen apps on Azure. Of course, that meant showcasing the technology coming out of the popular MicroProfile community, in which Red Hat plays a big part (and makes a fully supported, productized MicroProfile implementation through Thorntail, part of Red Hat OpenShift Application Runtimes).
We did a demo too, which is the main topic of this blog post, showing how easy it is to link your Java MicroProfile apps to Azure services through the Open Service Broker for Azure (the open source, Open Service Broker-compatible API server that provisions managed services in the Microsoft Azure public cloud) and OpenShift’s Service Catalog.
Here’s how to reproduce the demo.
Continue reading “Deploying MicroProfile apps on Microsoft Azure using the Azure Open Service Broker”
Attention desktop IDE users: Red Hat Developer Studio 12.9 and the community edition, JBoss Tools 4.9.0 for Eclipse 2018-09, are now available. You can download the Developer Studio bundled installer, which installs Eclipse 4.9 with all of the JBoss Tools already configured. Or, if you have an existing Eclipse 4.9 (2018-09) installation, you can download the JBoss Tools package.
This article highlights some of the new features in both JBoss Tools and Eclipse Photon, covering WildFly, Spring Boot, Camel, Maven, and many Java-related improvements—including full Java 11 support.
Developer Studio/JBoss Tools provides a desktop IDE with a broad set of tooling covering multiple programming models and frameworks. If you are doing container/cloud development, there is integrated functionality for working with Red Hat OpenShift, Kubernetes, Red Hat Container Development Kit, and Red Hat OpenShift Application Runtimes. For integration projects, there is tooling covering Camel and Red Hat Fuse that can be used in both local and cloud deployments.
Continue reading “Announcing Red Hat Developer Studio 12.9.0.GA and JBoss Tools 4.9.0.Final for Eclipse 2018-09”
In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
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.
Continue reading “Source versus binary S2I workflows with Red Hat OpenShift Application Runtimes”
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:
- DevOps automation
- Single concern principle
- Service discovery
- High observability
- Lifecycle conformance
- Runtime confinement
- Process disposability
- Image immutability
This may seem like a lot of overhead on top of the core application logic. Red Hat OpenShift Application Runtimes (RHOAR) and Istio provide developers with tools to adhere to these principles with minimal overhead in terms of coding and implementation.
In this blog post, we’re specifically focusing on how RHOAR and Istio combine to provide tools for DevOps automation, lifecycle conformance, high observability, and runtime confinement.
Continue reading “Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio”
Recently, I wrote a post called Zero to Express on OpenShift in Three Commands, which shows how to get started using Node.js, Express, and OpenShift together as fast as possible using the Node.js s2i (source-to-image) images that were recently released as part of Red Hat OpenShift Application Runtimes (RHOAR).
This post will add to the last one and show how we can start to debug and inspect our running code using the Chrome Developer Tools (DevTools) inspector.
Continue reading “How to Debug Your Node.js Application on OpenShift with Chrome DevTools”
[Cross posted from the OpenShift blog]
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.
- Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
- Blog posts on the OpenShift and Red Hat Developer blogs
Continue reading “Getting Started with Istio and Jaeger on Your Laptop”
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.
- The second post described how this application became configurable.
- The third post introduced
- In the fourth post, we replaced the in-memory back end with a database and introduced
Future to orchestrate our asynchronous operations.
In this post, we are not going to add a new feature. Instead, we’ll explore another programming paradigm: reactive programming.
Continue reading “When Vert.x Meets Reactive eXtensions (Part 5 of Introduction to Vert.x)”
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 we are committed to (and actively involved in) the upstream Istio project and working to integrate it into Kubernetes and Red Hat OpenShift to bring the benefits of a service mesh to our customers and the wider communities involved. If you want to play with Istio, check out the Service Mesh Tutorials on learn.Openshift.com. If you want to install it, follow the Istio Kubernetes quickstart instructions and install it on Red Hat OpenShift 3.7 or later (or 3.9 if you want to use auto-injection).
Continue reading “Bringing Coolstore Microservices to the Service Mesh: Part 1 – Exploring Auto-injection”