We are continuing to evolve the developer experience in Red Hat OpenShift 4.7. This article highlights what’s new for developers in the OpenShift 4.7 web console. Keep reading to learn about exciting changes to the topology view, an improved developer catalog experience, new developer quick starts, user interface support for Red Hat OpenShift Pipelines and Red Hat OpenShift Serverless, and more.
Continue reading New developer quick starts and more in the Red Hat OpenShift 4.7 web console
Java has been in a bit of an awkward spot since containers took off a few years ago. In the world of Kubernetes, microservices, and serverless, it has been getting harder and harder to ignore that Java applications are, by today’s standards, bloated. Well, until now. In this article, I explore the basics of Quarkus, a Kubernetes-native Java framework built to specifically address Java’s bloatedness problem.
Continue reading Ramp up on Quarkus: A Kubernetes-native Java framework
We are pleased to announce the release of Red Hat CodeReady Workspaces 2.1. Based on Eclipse Che, its upstream project, CodeReady Workspaces is a Red Hat OpenShift-native developer environment enabling developer teams for cloud-native development.
CodeReady Workspaces 2.1 is available now on OpenShift 3.11 and OpenShift 4.3+.
This new version introduces:
- Dashboard: A new onboarding flow.
- Quarkus: A new workspace gets you started with Quarkus.
- Languages: The addition of .NET Core 3.1, Java 11, and Camel DSL (Apache Camel K).
- Other: Editor and AirGap improvements.
Continue reading “Red Hat CodeReady Workspaces 2.1: Improved cloud tools bring more languages, better flow”
Developing applications on a Kubernetes distribution like Red Hat OpenShift—or on Red Hat Enterprise Linux (RHEL), or by using our Universal Base Images—is easier with Red Hat’s build of Node.js. The latest update of Red Hat Runtimes now includes Node.js 12.4.1, which provides a supported runtime for LTS releases. This new Red Hat build of Node.js together with the release of Red Hat Enterprise Linux 8.1 provides a number of new features and enhancements compared to Node.js 10.
This article focuses on these new features and enhancements.
Continue reading “Node.js update for Red Hat Runtimes brings improved support for native modules, diagnostic reporting, and more”
With the growing number of APIs and microservices, the time given to creating and integrating them has become shorter and shorter. That’s why we need an integration framework with tooling to quickly build an API and include capabilities for a full API life cycle. Camel K lets you build and deploy your API on Kubernetes or Red Hat OpenShift in less than a second. Unbelievable, isn’t it?
For those who are not familiar with it, Camel K is a subproject of Apache Camel with the target of building a lightweight runtime for running integration code directly on cloud platforms like Kubernetes and Red Hat OpenShift. It was inspired by serverless principles, and it will also target Knative shortly. The article by Nicola Ferraro will give you a good introduction.
In this article, I’ll show how to build an API with Camel K. For that, we will start first by designing our API using Apicurio Studio, which is based on the OpenAPI standard, and then we will provide the OpenAPI standard document to Camel K in order to implement the API and deploy it to Red Hat OpenShift.
Continue reading “Build and deploy an API with Camel K on Red Hat OpenShift”
Quarkus is Kubernetes native, and to accomplish that we’ve spent a lot of time working across a number of different areas, such as the Java Virtual Machine (JVM) and various framework optimizations. And, there’s much more work still to be done. One area that has piqued the interest of the developer community is Quarkus’s comprehensive and seamless approach to generating an operating system specific (aka native) executable from your Java code, as you do with languages like C and C++, which we believe will typically be used at the end of the build-test-deploy cycle.
Although the native compilation is important, as we’ll discuss later, Quarkus works really well with vanilla OpenJDK Hotspot, thanks to the significant performance improvements we’ve made to the entire stack. The native executable aspect Quarkus offers is optional and, if you don’t want it or your applications don’t need it, then you can ignore it. In fact, even when you are using native images, Quarkus still relies heavily on OpenJDK. The well-received dev mode is able to deliver near-instantaneous change-test cycles all due to Hotspot’s rich dynamic code execution capabilities. Additionally, GraalVM internally uses OpenJDK’s class library and HotSpot to produce a native image.
Still, there’s the question: Why have native compilation at all if the other optimizations are so good? That’s the question we’ll look at more closely here.
Continue reading “Quarkus: Why compile to native?”
Are serverless and Function as a Service (FaaS) the same thing?
No, they’re not.
Wait. Yes, they are.
Frustrating, right? With terms being thrown about at conferences, in articles (I’m looking at myself right now), conversations, etc., things can be confusing (or, sadly, sometimes misleading). Let’s take a look at some aspects of serverless and FaaS to see where things stand.
Continue reading “The evolution of serverless and FaaS: Knative brings change”
“The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.” (Edsger W. Dijkstra)
Rule-based artificial intelligence (AI) is often overlooked, possibly because people think it’s only useful in heavyweight enterprise software products. However, that’s not necessarily true. Simply put, a rule engine is just a piece of software that allows you to separate domain and business-specific constraint from the main application flow. We are part of the team developing and maintaining Drools—the world’s most popular open source rule engine and part of Red Hat—and, in this article, we will describe how we are changing Drools to make it part of the cloud and serverless revolution.
Continue reading “Quarking Drools: How we turned a 13-year-old Java project into a first-class serverless component”
Our connected world is full of events that are triggered or received by different software services. One of the big issues is that event publishers tend to describe events differently and in ways that are mostly incompatible with each other.
To address this, the Serverless Working Group from the Cloud Native Computing Foundation (CNCF) recently announced version 0.2 of the CloudEvents specification. The specification aims to describe event data in a common, standardized way. To some degree, a CloudEvent is an abstract envelope with some specified attributes that describe a concrete event and its data.
Working with CloudEvents is simple. This article shows how to use the powerful JVM toolkit provided by Vert.x to either generate or receive and process CloudEvents.
Continue reading “Processing CloudEvents with Eclipse Vert.x”
Microservices and serverless architectures are being implemented, or are a part of the roadmap, in most modern solution stacks. Given that Java is still the dominant language for business applications, the need for reducing the startup time for Java is becoming more important. Serverless architectures are one such area that needs faster startup times, and applications hosted on container platforms such as Red Hat Openshift can benefit from both fast Java startup time and a smaller Docker image size.
Let’s see how GraalVM can be beneficial for Java-based programs in terms of speed and size improvements. Surely, these gains are not bound to containers or serverless architectures and can be applied to a variety of use cases.
Continue reading “Natively compile Java code for better startup time”