James Falkner

Recent Posts

Bringing Coolstore Microservices to the Service Mesh: Part 2–Manual Injection

Coolstore+Istio Logo

In the first part of this series we explored the Istio project and how Red Hat is committed to and actively involved in the project and working to integrate it into Kubernetes and 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 OpenShift 3.7 or later. Also don’t miss Don Schenck’s series of blogs on Istio technology in general to learn more about it and what Red Hat is doing in this space.

In this post, we will deploy the existing Coolstore microservices demo as a service mesh and start to demonstrate the tangible value you can get out of the system without any major rewrite or rearchitecture of the existing app. We’ll also improve our project along the way to adhere to Istio (and general microservice) best practices. In the real world, your applications and developers often make bad assumptions or fail to implement best practices, so with this information you can learn something about your own projects. For Coolstore, many of these workarounds will eventually find their way into the source code of the demo.

Continue reading “Bringing Coolstore Microservices to the Service Mesh: Part 2–Manual Injection”

Share

Bringing Coolstore Microservices to the Service Mesh: Part 1 – Exploring Auto-injection

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”

Share

Announcing: Node.js General Availability in Red Hat OpenShift Application Runtimes

Node.js Foundation Logo

Summary

Today Red Hat is making Node.js generally available to Red Hat customers through a subscription to Red Hat OpenShift Application Runtimes (RHOAR). RHOAR provides application developers with a variety of application runtimes running on the OpenShift Container Platform.

Node.js is based on the V8 JavaScript engine and allows you to write server-side JavaScript applications. Node.js joins the existing set of supported runtimes and offers developers an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Continue reading “Announcing: Node.js General Availability in Red Hat OpenShift Application Runtimes”

Share

The Skinny on Fat, Thin, Hollow, and Uber

“I used WildFly Swarm to shrink my app from 45 megabytes to only 2243 bytes.”

I was recently playing around with various techniques for packaging Java microservices and running on OpenShift using various runtimes and frameworks to illustrate their differences (WildFly Swarm vs. WildFly, Spring Boot vs. the world, etc). Around the same time as I was doing this an internal email list thread ignited discussing some of the differences and using terms like Uber JARs, Thin WARs, Skinny WARs, and a few others. Some folks were highlighting the pros and cons of each, especially the benefits of the thin WAR approach when combined with docker image layers.

Continue reading “The Skinny on Fat, Thin, Hollow, and Uber”

Share

Microservices: Comparing DIY with Apache Camel

Microservices are currently enjoying immense popularity. It is rare to find a tech conference without at least a few mentions of them in corridor conversations or titles of talks, and for good reason: microservices can provide a path to better, more maintainable, higher quality software delivered faster. What’s not to love?

Of course there are the “negatives” and details in the implementation of microservices that can trip up even the most seasoned architect-developer, but at the same time we are collectively learning from mistakes and creating or reusing fantastic open source projects and products that can help smooth over those rough bits.

One such project is Apache Camel (and Fuse, its Red Hat-supported distribution.) Created way before the microservices revolution, Apache Camel was born to ease integration of disparate computing systems by implementing well-tested enterprise integration patterns (EIPs) and supplying a developer-friendly interface for writing code to do the integration.

Continue reading “Microservices: Comparing DIY with Apache Camel”

Share

Using Jenkins in the Red Hat CI/CD Ecosystem

The last 4-5 years have seen the debut of many new software products specifically targeting both infrastructure services and IT automation. The consumerization of IT has caused its architects to take a fresh look at their existing, often times monolithic apps and IT infrastructure and asking: Can we do better? How do I keep IT relevant? How do I keep track of all these VMs and data? How do I scale out my IT environment without a huge budget increase or physical buildout? How do I develop and get bits to production faster and with higher quality?

These organizations are looking to evolve their development and deployment processes to be more agile and accelerate time-to-market. They are trying to embrace things like DevOps and Continuous Deployment to do that. They are breaking monolithic apps out into microservices that can be independently updated, with a focus on speed and agility, so their apps can be more reactive to changes in their business. They are evolving from traditional virtualization to public and private cloud deployments.

There are strong parallels between the way open source communities produce great software and how IT orgs build and deliver great software and services. Red Hat, a recognized pioneer in open source, is using its deep experience in open source to build products that support microservice-oriented, DevOps-embracing, container and cloud-centric IT shops.

Continue reading “Using Jenkins in the Red Hat CI/CD Ecosystem”

Share

JBoss EAP 7 on OpenShift

RHJB_EnterpriseApplicationPlatform_Logotype_RGB-Gray_0213_cw_72JBoss EAP 7 was recently released, and brings with it a whole host of new features and support, such as support for Java EE 7, reduced port usage, graceful shutdown, improved GUI and CLI management, optimizations for cloud and containers, and much more. EAP 7’s small footprint, fast startup time and support for modern Java and non-Java frameworks make it uniquely suitable for deployment onto PaaS cloud environments, and Red Hat happens to have a leading one: OpenShift.

Continue reading JBoss EAP 7 on OpenShift

Share

Installing JBoss EAP 7 on RHEL using RPMs

JBoss EAP 7 was recently released, and brings with it a whole host of new features and support, such as support for Java EE 7, Undertow (a highly scalable web server), reduced port usage, graceful shutdown, improved GUI and CLI management, and much more.

Go ahead and download it, unzip, and run bin/standalone.sh and check out all these great features. What’s that? It didn’t work? Did you check that your JRE is compatible? Are there outstanding incompatibility or security issues that may be resolved in an available patch? Perhaps you’ve already installed it elsewhere on your system and you are trying to install a conflicting version. You’re not running it as root are you?

ZIP files are awesome for getting bits up and running quickly (as a developer I use them myself quite a bit), but its simplicity hides many issues related to production software management, such as those I just mentioned. It’s perfect for cross-platform developers or those non-RHEL CI/CD setups but for production RHEL systems it’s the tl;dr of enterprise software deployment. This is where Red Hat and RPM can help. You can be sure of what you’re installing, that it’ll work securely, that you’ll know it’s there when asked, and that it’ll be manageable using your other investments (think RHEV+RHEL+Satellite+JBoss).

Continue reading “Installing JBoss EAP 7 on RHEL using RPMs”

Share

Offline CLI with JBoss EAP 7

Over the years, I’ve come across many command line interfaces (CLI) to larger applications, each with varying levels of access and power. Having a CLI at all is a great first step for an application, as it opens up a much wider range of possibilities: administration, extension, and trust.

CLIs also promote scriptability – the ability to create and maintain repeatable scripts, and the easier it is to develop said scripts, the better. Sometimes scripts can solve issues that developers of the app never thought of. (Pro tip: find good user experience designers who know the product and are comfortable on the command line, then put them in charge of the CLI user experience. Your users will love you.

Continue reading “Offline CLI with JBoss EAP 7”

Share

Maven mirrors on OpenShift with and without Source to Image (S2I)

velocimetroI’m guessing if you’ve done enough repeated builds on OpenShift, using Maven, that you are probably aware of the “download the internet” phenomenon that plagues build times. You start a build, expecting all those Maven dependencies you downloaded for your last build to be re-used, but quickly see your network traffic ramp up while the same 100MB of jars are downloaded again and again. Even builds of a few minutes tend to grind on me, frustrate me as a developer when I’m trying to test/deploy/fix quickly.

Thankfully, Maven has a nice feature that allows you to set up local mirrors that cache dependencies and make them available to future builds, only updating from the upstream repo as needed on a regular (and configurable) schedule.

Continue reading “Maven mirrors on OpenShift with and without Source to Image (S2I)”

Share