Building responsiveness applications is a never-ending task. With the rise of powerful and multicore CPUs, more raw power is available for applications to consume. In Java, threads are used to make the application work on multiple tasks concurrently. A developer starts a Java thread in the program, and tasks are assigned to this thread to get processed. Threads can do a variety of tasks, such as read from a file, write to a database, take input from a user, and so on.
In this article, we’ll explain more about threads and introduce Project Loom, which supports high-throughput and lightweight concurrency in Java to help simplify writing scalable software.
Continue reading “Project Loom: Lightweight Java threads”
Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:
- Places artificial barriers on development speed, and therefore time to value,
- Creates single points of failure in the infrastructure, and
- Stifles innovation through inflexibility.
Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.
Continue reading “Application lifecycle management for container-native development”
At this year’s Red Hat Summit, Red Hat announced Thorntail 2.4 general availability for Red Hat customers through a subscription to Red Hat Application Runtimes. Red Hat Application Runtimes provides application developers with a variety of application runtimes running on the Red Hat OpenShift Container Platform.
Introduction to Thorntail
Thorntail is the new name for WildFly Swarm, and it bundles everything you need to develop and run Thorntail and MicroProfile applications by packaging server runtime libraries with your application code and running it with
java -jar. It speeds up the transition from monoliths to microservices and takes advantage of your existing industry standard Java EE technology experience.
Continue reading “Announcing Thorntail 2.4 general availability”
In Part 7 of this series, we looked at details that determine how your integration becomes the key to transforming your customer experience. It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Let’s continue looking at more specific examples of how these blueprints solve specific integration use cases.
Continue reading “Integration blueprint example for mobile integration (part 8)”
The integration space is in constant change. Many open source projects and closed source technologies did not withstand the tests of time and have disappeared from the middleware stacks for good. After a decade, however, Apache Camel is still here and becoming even stronger for the next decade of integration. In this article, I’ll provide some history of Camel and then describe two changes coming to Apache Camel now (and later to Red Hat Fuse) and why they are important for developers. I call these changes subsecond deployment and subsecond startup of Camel applications.
Continue reading “Subsecond deployment and startup of Apache Camel applications”
I recently had the opportunity to speak at Red Hat Summit 2019. In my session, titled “Vert.x application development with Jaeger distributed tracing,” I discussed how scalable event-driven applications could be built with Eclipse Vert.x, a Java Virtual Machine toolkit for building reactive applications.
Thanks to many developer tools, creating these applications is no longer the most effort-consuming task in IT. Instead, we now have to understand how parts of our application function together to deliver a service, (across dev, test and production environments). This can be difficult because, with distributed architectures, external monitoring only tells you the overall response time and the number of invocations, providing no insight into the individual operations. Additionally, log entries for a request are scattered across numerous logs. This article discusses the use of Eclipse Vert.x, distributed tracing, and Jaeger in the context of this problem.
Continue reading “Building and understanding reactive microservices using Eclipse Vert.x and distributed tracing”
This article is a continuation of Migrating Java applications to Quarkus: Lessons learned, and here, I’ll make a comparison of performance metrics for building and running a Java app before and after Quarkus. My goal here is to demonstrate how awesome Quarkus is and maybe help you decide to use Quarkus to build your cool microservices.
Continue reading “Migrating Java applications to Quarkus, Part 2: Before and after”
OpenJDK 12 is now out, and it has new features. These are:
189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
230: Microbenchmark Suite
325: Switch Expressions (Preview)
334: JVM Constants API
340: One AArch64 Port, Not Two
341: Default CDS Archives
344: Abortable Mixed Collections for G1
346: Promptly Return Unused Committed Memory from G1
When I follow the link from the OpenJDK 12 project page to the open source builds page, I see the downloadable binaries. I download the Linux binary and install it, then see if the first item on the feature list, Shenandoah, works:
$ ./jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -cp ~ Hello
Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported
Oh! What is going on?
Continue reading “Not all OpenJDK 12 builds include Shenandoah: Here’s why”
In Part 6 of this series, we looked into details that determine how your integration becomes the key to transforming your customer experience. It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint.
Having completed our discussions on the blueprint details, it’s time to look at a few specific examples. This article walks you through an example integration scenario showing how expanding the previously discussed details provides blueprints for your own integration scenarios.
Continue reading “Integration blueprint example for process automation (part 7)”
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”