Achieving high-performance, low-latency networking with XDP: Part I

XDP: From zero to 14 Mpps

In past years, the kernel community has been using different approaches in the quest for ever-increasing networking performance. While improvements have been measurable in several areas, a new wave of architecture-related security issues and related counter-measures has undone most of the gains, and purely in-kernel solutions for some packet-processing intensive workloads still lag behind the bypass solution, namely Data Plane Development Kit (DPDK), by almost an order of magnitude.

But the kernel community never sleeps (almost literally) and the holy grail of kernel-based networking performance has been found under the name of XDP: the eXpress Data Path. XDP is available in Red Hat Enterprise Linux 8 Beta, which you can download and run now.

Continue reading “Achieving high-performance, low-latency networking with XDP: Part I”

Share

Common architectural elements for modern integration architectures (Part 2)

In Part 1 of this series, we explored a use case around integration being the key to transforming your customer experience.

I laid out how I’ve approached the use case and how I’ve used successful customer portfolio solutions as the basis for researching a generic architectural blueprint. The only thing left to cover was the order in which you’ll be led through the blueprint details.

This article, which is Part 2 of the series, starts the real journey at the very top, with a generic architecture from which we’ll discuss the common architectural elements one by one.

Continue reading “Common architectural elements for modern integration architectures (Part 2)”

Share

Extending support to Spring Boot for Red Hat OpenShift Application Runtimes

What Red Hat is providing

Red Hat OpenShift Application Runtimes (RHOAR) is a recommended set of products, tools, and components for developing and maintaining cloud-native applications on the Red Hat OpenShift platform. As part of this offering, Red Hat is extending its support to Spring Boot and related frameworks for building modern, production-grade, Java-based cloud-native applications.

Spring Boot lets you create opinionated Spring-based standalone applications. The Spring Boot runtime also integrates with the OpenShift platform, allowing your services to externalize their configuration, implement health checks, provide resiliency and failover, and much more. To learn more about how Spring Boot applications integrate with the wider Red Hat portfolio, check out the following OpenShift Commons Briefing by Thomas Qvarnstrom:

Continue reading “Extending support to Spring Boot for Red Hat OpenShift Application Runtimes”

Share

The Non-complexity of /etc/nsswitch.conf

In most glibc-based operating systems, there’s a file /etc/nsswitch.conf that most people ignore, few people understand, but all people generally rely on. This file determines where the system finds things like host names, passwords, and protocol numbers. Does your company use LDAP? NIS? Plain files? The nsswitch file (it stands for “name services switch”) tells the system what service to use for each type of name lookup.

Here’s a snippet from a sample /etc/nsswitch.conf file:

passwd:   files nis
group:    files nis

hosts:    files dns myhostname

In this example, user information (the passwd and group services) come first from “files” (like /etc/passwd or /etc/group), and if no entries are found there, a query to an NIS server (configured elsewhere) will be used. Host information first comes from /etc/hosts (files), then a DNS server (dns), and if neither of those work, at least a fallback of “myhostname” so that the local machine has some name.

The non-complexity comes in the “and if that doesn’t work” rule. When multiple services are listed, they’re tried in order, and a sevice either succeeds or fails. If it fails, the next is tried, etc. There’s a way to check for a few other cases (entry not found, or service temporarily unavailable) but the only thing you can do based on those is either try the next service, or don’t.

This simplicity has already led to one drawback, which is the handling of a user’s groups when there are both local groups and global (LDAP for example) groups. You wouldn’t want to have to choose between the two, you’d rather be allowed into the union of the two sets of groups. The nsswitch.conf syntax has a special case for that:

groups:   files [SUCCESS=merge] ldap

Normally, a successful lookup would terminate the lookup and return a value. This special case says that even if the “files” lookup worked, try the “ldap” service also and merge the two lists of groups together. Another special case has come up recently, with systemd providing some services for the local machine. The problem here is “local machine” – it doesn’t provide global services, but the nsswitch syntax doesn’t allow for “delegation”. If the systemd service doesn’t find a record, is that “not found” authoritative?

And what if you wanted different services for different domains? Currently, your only option is to configure a local DNS server that has all the logic for domain delegation, and refer to that in nsswitch.conf. That only works if the DNS server is running, which may not be the case when the machine is first booting, and may not be easy to configure when you change networks (wifi? vpn?).

So what’s the point of this article? I’ve been contemplating the non-complexity of this file, and wondering what its future might contain. What if you could select services based on a pattern match of the search string? What if it could test for outside conditions like time of day, or VPNs? What if your corporate security rules required a more deterministic failure mode? I’m not suggesting nsswitch.conf become some full programming language (nsswitch.py anyone? 😉 but if it had some decision-making syntax beyond what it already has, what would it look like? What kinds of problems would it solve? Do you have any problems that could be solved by a more flexible nsswitch.conf? If so, share them in the comments below!

Share

Eclipse MicroProfile for Spring Boot developers

By now you have probably heard of Eclipse MicroProfile (MP). It is a community-driven initiative to define specifications for enterprise Java microservices. MicroProfile is only two years old, yet it has delivered eight innovative specifications and is evolving fast. It provides metrics, API documentation, health checks, fault tolerance, distributed tracing, and more. With it, you can take full advantage of cutting-edge cloud-native technologies and do it in a vendor-neutral fashion!

For developers familiar with Spring Boot, we have prepared this article, which compares the basics of developing applications with Spring Boot and with MicroProfile. We wrote two applications, one with each solution. In this article, we will go through the differences between them. You can find the source code for both projects on GitHub.

For the MicroProfile application, we use Thorntail (formerly know as Wildfly Swarm), but except for the setting up part, Open Liberty, Payara, TomEE, or any other implementation would look exactly the same.

Throughout this article, we assume you know Spring Boot and we focus on what is different in MicroProfile.

Continue reading “Eclipse MicroProfile for Spring Boot developers”

Share

Support Lifecycle for Clang/LLVM, Go, and Rust

On the heels of our recently announcement, General Availability of Clang/LLVM 6.0, Go 1.10, and Rust 1.29, I want to share how we’ll be supporting them going forward. Previously, these packages had been in “Technology Preview” status, which means that they were provided for “you to test functionality and provide feedback during the development process”, and were “not fully supported under Red Hat Subscription Level Agreements, may not be functionally complete, and are not intended for production use”.

So now that we’ve promoted them to fully supported status, what does that mean? In the simplest terms, General Availability (GA) means that these packages have officially entered the “Full Support Phase” of their lifecycle:

Continue reading “Support Lifecycle for Clang/LLVM, Go, and Rust”

Share

Introducing Application Streams in RHEL 8

With the introduction of Red Hat Enterprise Linux 8 (RHEL 8) we have tried to greatly simplify the layout of the content available in Red Hat Enterprise Linux. The main repository, BaseOS, provides the parts of the distribution that give you a running userspace on physical hardware, a virtual machine, a cloud instance or a container. The Application Stream (AppStream) repository provides all the applications you might want to run in a given userspace. The Supplemental repository provides other software that has special licensing. The CodeReady Linux Builder provides mostly build time components for developers (see Introducing CodeReady Linux Builder).

As a result, most RHEL 8 systems will only need two repositories enabled. However, this may lead to the the question, where do I find alternate versions of software if there is only 1 application repository? In prior versions, you would look to the RHSCL or Extras repositories. However, in RHEL 8, through a new technology called Modularity, we can offer those alternate versions in the same physical repository.

Continue reading “Introducing Application Streams in RHEL 8”

Share

Red Hat Enterprise Linux 8 Beta is here

Red Hat Enterprise Linux 8 Beta is here

And it’s been built with production stability and development agility in mind.

There’s so much to say about RHEL 8 Beta, but I want to focus on just a few points from the corporate announcement that highlight Red Hat Enterprise Linux 8 Beta as a developer platform that:

  • Simplifies application development – with less setup and config effort, you can more quickly get to writing code
  • Is the easiest RHEL yet for developers that are new to Linux
  • Is for traditional and cloud/container applications with many new tools for both
  • Already delivers dozens of tools to build and test applications

Now let’s zoom in on what these mean.

Download the RHEL 8 Beta here. 

“Too slow, too fast”

We’ve gotten this feedback a lot when discussing availability and support of development packages. To address this dichotomy, Red Hat Enterprise Linux 8 Beta has built in the concept of Application Streams to deliver userspace packages (programming languages, compilers, databases, etc.) more simply and with greater flexibility – this addresses the “too slow”.  For the “too fast” requirement, there are also “Core” components that have the same lifecycle as the operating system – 10 years. Users will often have a version in each grouping. Application Streams – think of them as “son of Software Collections” – are a simpler way to deliver this modularity with improved installation, use, and re-use

Continue reading “Red Hat Enterprise Linux 8 Beta is here”

Share

PHP 7.2, Node.js 10, NGINX 1.14 and others now GA for RHEL

We are pleased to announce general availability Red Hat Software Collections 3.2, which adds these components to Red Hat Enterprise Linux 7:

  • PHP 7.2
  • Varnish Cache 6.0
  • MySQL 8.0
  • NGINX 1.14
  • Node.js 10
  • Git 2.18
  • Update of Apache HTTP server 2.4

These versions are available on Red Hat Enterprise Linux 7 (Devtools or RHSCL channel) for x86_64, s390x, aarch64, and ppc64le.  Read more details about each component in the “New Components details” section.

Continue reading “PHP 7.2, Node.js 10, NGINX 1.14 and others now GA for RHEL”

Share

GCC 8.2 now GA for Red Hat Enterprise Linux

We are pleased to announce general availability of Red Hat Developer Toolset 8 for Red Hat Enterprise Linux 6 and 7.  The key new components for this release are:

  • GCC 8.2.1
  • GDB 8.2
  • Updated components such as SystemTap, Valgrind, OProfile, and many more

Like other tools, these are installable via yum from the Red Hat Enterprise Linux 6 or 7 Devtools or RHSCL channel.  For more details, see the “New Features” section below.

Continue reading “GCC 8.2 now GA for Red Hat Enterprise Linux”

Share